home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / sys / next / misc / 24064 < prev    next >
Encoding:
Text File  |  1993-01-25  |  4.3 KB  |  85 lines
  1. Newsgroups: comp.sys.next.misc
  2. Path: sparky!uunet!destroyer!gatech!rpi!usenet
  3. From: gad@eclipse.its.rpi.edu (Garance A. Drosehn)
  4. Subject: Re: Drive drive
  5. Message-ID: <!#p30+=@rpi.edu>
  6. Nntp-Posting-Host: eclipse.its.rpi.edu
  7. References: <SCOTT.93Jan24203511@nic.gac.edu>
  8. Date: Mon, 25 Jan 1993 23:22:57 GMT
  9. Lines: 74
  10.  
  11. scott@nic.gac.edu (Scott Hess) writes:
  12. > anderson@macc.wisc.edu (Jess Anderson) writes:
  13. > >Background: Several people have suggested solving the archive server
  14. > >space crunch by asking users to kick in money to purchase additional
  15. > >drives for sonata and orst.  I've volunteered to collect pledges
  16. > >and to contact Purdue and Oregon State to see what they think of
  17. > >the idea.  I'll do that at the beginning of next week.  Five people
  18. > >pledged money in the first hour, six counting me.  The amounts so
  19. > >far are like $10-$20 for each server site.
  20. > >
  21. > >Respondents so far think it's a cool idea and are making other
  22. > >useful suggestions too.
  23. > 
  24. > I would be willing to toss in a couple bucks.  My problem, though,
  25. > is that I am not certain if I wish to donate money for disk space.
  26. > It seems to me that the major problem at Purdue is _not_ diskspace,
  27. > it is management.  I've talked to Allen (the student manager)
  28. > before, and he's a great guy, but I suspect he's been a bit busy,
  29. > lately.  Cleaning up the submissions directory would probably free
  30. > up a number of meg right off the bat.
  31. > 
  32. > Furthermore, one poster on the net has put forth the opinion that
  33. > they think that using a better compression algorithm isn't the way
  34. > to go, so rather than waste everyone's time, buy more disk space.
  35. > Well, yes and no.  I have no doubt that even if we purchase a gig
  36. > or two of disk space, it will soon be gone in _any_ case.
  37.  
  38. I agree that getting more disk space is not the ultimate solution.  Once an  
  39. archive site has "a reasonable amount" of disk space, it is more important  
  40. to manage the disk space it has than to simply throw more on the system.
  41.  
  42. My feeling is that sonata is not at that "reasonable amount".  Cs.orst.edu  
  43. might be now, with the disk they just added to their system.  I do feel that  
  44. the money we come up with should probably be split between those two archive  
  45. sites, as those are the two largest repositories for NeXT-specific software.
  46.  
  47. I have no doubt that if we purchase a gig or two of disk space, it will soon  
  48. be gone.  I also have no doubt that if maintainers of the archive took the  
  49. time to clean out & compress everything, the space gained will also be soon  
  50. gone.  (to claim otherwise is to claim that cleaning up and compressing  
  51. things will free up more than 2 gig.  I consider that unlikely).
  52.  
  53. My feeling is that we will better off if both things happen.  I suspect that  
  54. no matter which route we go right now, we'll *have* to have both things  
  55. happen fairly soon.  This will be particularly true once NeXT is shipping  
  56. NS486 and NS-RISC systems.
  57.  
  58. > I have a feeling that most system administrators would back me up on
  59. > that point!  In my experience, zip (or gzip) would reduce the disk needs
  60. > by up to %40, which is a pretty substantial improvement.  Furthermore,
  61. > compression is free and works even if new disk space is purchased,
  62. > so investment in a reasonable compression scheme is going to keep
  63. > paying back in the future.
  64.  
  65. Instead of racing to convert everything over to gzip, and later buying disk  
  66. space, I (personally) would rather buy the disk space and then slowly ease  
  67. into superior compression mechanisms.  I'm sure that wizards like Scott will  
  68. have no trouble with whatever compression scheme is used, but we don't know  
  69. that all NeXT users will be ready for this.  I'd rather ease into a change  
  70. in compression schemes, instead of cutting over in some mad rush to save  
  71. some (sorely needed) disk space.
  72.  
  73. The ideal solution would be to find out that NeXT included gzip on NS3.1,  
  74. but I guess that even that wouldn't make the transition painless.  Someone  
  75. who is downloading software for a NS1.0 system (assuming all that is kept  
  76. around) isn't going to be too happy to find out they have to upgrade to  
  77. NS3.0 in order to decompress the file they have.
  78.  
  79. Does the new gzip compile on older versions of NeXTSTEP?
  80.  
  81. --
  82. Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
  83. ITS Systems Programmer            (handles NeXT-type mail)
  84. Rensselaer Polytechnic Institute;           Troy NY    USA
  85.