home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / os / os2 / misc / 29728 < prev    next >
Encoding:
Text File  |  1992-09-10  |  2.2 KB  |  44 lines
  1. Newsgroups: comp.os.os2.misc
  2. Path: sparky!uunet!spool.mu.edu!caen!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!iitmax!rice.iit.edu!rgpxs360
  3. From: rgpxs360@glen-ellyn.iit.edu (Peter Stein)
  4. Subject: Re: v13i299: zip19x32.zoo, Info-ZIP Zip 1.9 - OS/2 2.0 version (part 01/05)
  5. Message-ID: <1992Sep10.150950.22010@glen-ellyn.iit.edu>
  6. Organization: Illinois Institute of Technology, Rice Campus
  7. References: <1992Sep8.043831.8152@uwm.edu> <2AAD239E.5017@deneva.sdd.trw.com> <1992Sep9.204002.16961@njitgw.njit.edu>
  8. Date: Thu, 10 Sep 1992 15:09:50 GMT
  9. Lines: 33
  10.  
  11. In article <1992Sep9.204002.16961@njitgw.njit.edu> dic5340@hertz.njit.edu (David Charlap) writes:
  12. >In article <2AAD239E.5017@deneva.sdd.trw.com> reimert@mamacass.etdesg.trw.com (Scott P. Reimert) writes:
  13. >>Part 3 of Info-ZIP Zip 1.9 never made it this far. Would it be possible to 
  14. >>get it reposted please?
  15.  
  16. Ditto. Neither of the 2 sites I read news at received it.
  17.  
  18. >
  19. >Just ftp the program from ftp-os2.nmsu.edu.  Everything posted to
  20. >comp.binaries.os2 is sent there.  It's currently in /pub/os2/new.
  21. >It'll be moved elsewhere RSN.  It'll also be mirrored in the
  22. >"archives" directory tree - where all c.b.o2 submissions end up.
  23. >
  24. >-- 
  25. >   |)  David Charlap           "LECTURER, n.  One with his hand in your pocket,
  26. >  /|_  dic5340@hertz.njit.edu   his tongue in your ear, and his faith in your
  27. > ((|,)                          patience."
  28. >  ~|~                              --- Ambrose Bierce, The Devil's Dictionary
  29.  
  30. Not everyone has internet access and obtaining files via mail servers is
  31. agonizingly slow and error prone. Even though I now have access I am
  32. constrained to download files from that site at 2400 baud. Furthermore,
  33. what you're suggesting is terribly inefficient. If a single piece didn't
  34. make it to a large number of sites would it be better to repost that
  35. piece or have the subscribers retrieve the file in its entirety ?
  36.  
  37. It is particularly annoying to spend several days collecting the pieces
  38. of a multipart submission only to discover that something is missing 
  39. and then having to wait (sometimes in vain) for that piece to arrive.
  40. Depending on the size of the submission one could also be tying up a
  41. significant chunk of storage during this wait.
  42.  
  43.  
  44.