From: gad@eclipse.its.rpi.edu (Garance A. Drosehn)
Subject: Re: Drive drive
Date: Mon, 25 Jan 1993 23:22:57 GMT

scott@nic.gac.edu (Scott Hess) writes:
> anderson@macc.wisc.edu (Jess Anderson) writes:
> >Background: Several people have suggested solving the archive server
> >space crunch by asking users to kick in money to purchase additional
> >drives for sonata and orst.  I've volunteered to collect pledges
> >and to contact Purdue and Oregon State to see what they think of
> >the idea.  I'll do that at the beginning of next week.  Five people
> >pledged money in the first hour, six counting me.  The amounts so
> >far are like $10-$20 for each server site.
> >
> >Respondents so far think it's a cool idea and are making other
> >useful suggestions too.
> 
> I would be willing to toss in a couple bucks.  My problem, though,
> is that I am not certain if I wish to donate money for disk space.
> It seems to me that the major problem at Purdue is _not_ diskspace,
> it is management.  I've talked to Allen (the student manager)
> before, and he's a great guy, but I suspect he's been a bit busy,
> lately.  Cleaning up the submissions directory would probably free
> up a number of meg right off the bat.
> 
> Furthermore, one poster on the net has put forth the opinion that
> they think that using a better compression algorithm isn't the way
> to go, so rather than waste everyone's time, buy more disk space.
> Well, yes and no.  I have no doubt that even if we purchase a gig
> or two of disk space, it will soon be gone in _any_ case.

I agree that getting more disk space is not the ultimate solution.  Once an  
archive site has "a reasonable amount" of disk space, it is more important  
to manage the disk space it has than to simply throw more on the system.

My feeling is that sonata is not at that "reasonable amount".  Cs.orst.edu  
might be now, with the disk they just added to their system.  I do feel that  
the money we come up with should probably be split between those two archive  
sites, as those are the two largest repositories for NeXT-specific software.

I have no doubt that if we purchase a gig or two of disk space, it will soon  
be gone.  I also have no doubt that if maintainers of the archive took the  
time to clean out & compress everything, the space gained will also be soon  
gone.  (to claim otherwise is to claim that cleaning up and compressing  
things will free up more than 2 gig.  I consider that unlikely).

My feeling is that we will better off if both things happen.  I suspect that  
no matter which route we go right now, we'll *have* to have both things  
happen fairly soon.  This will be particularly true once NeXT is shipping  
NS486 and NS-RISC systems.

> I have a feeling that most system administrators would back me up on
> that point!  In my experience, zip (or gzip) would reduce the disk needs
> by up to %40, which is a pretty substantial improvement.  Furthermore,
> compression is free and works even if new disk space is purchased,
> so investment in a reasonable compression scheme is going to keep
> paying back in the future.

Instead of racing to convert everything over to gzip, and later buying disk  
space, I (personally) would rather buy the disk space and then slowly ease  
into superior compression mechanisms.  I'm sure that wizards like Scott will  
have no trouble with whatever compression scheme is used, but we don't know  
that all NeXT users will be ready for this.  I'd rather ease into a change  
in compression schemes, instead of cutting over in some mad rush to save  
some (sorely needed) disk space.

The ideal solution would be to find out that NeXT included gzip on NS3.1,  
but I guess that even that wouldn't make the transition painless.  Someone  
who is downloading software for a NS1.0 system (assuming all that is kept  
around) isn't going to be too happy to find out they have to upgrade to  
NS3.0 in order to decompress the file they have.

Does the new gzip compile on older versions of NeXTSTEP?

--
Garance Alistair Drosehn     =     gad@eclipse.its.rpi.edu
ITS Systems Programmer            (handles NeXT-type mail)
Rensselaer Polytechnic Institute;           Troy NY    USA
Newsgroups: comp.sys.next.misc