From: anderson@macc.wisc.edu (Jess Anderson)
Subject: Re: Drive drive
Organization: Madison Academic Computing Center, UW-Madison
Date: Mon, 25 Jan 93 12:10:21 GMT

In article <SCOTT.93Jan24203511@nic.gac.edu>
scott@nic.gac.edu (Scott Hess) writes:

>I would be willing to toss in a couple bucks.  

That would put you in with 49 others so far.

>My problem, though,
>is that I am not certain if I wish to donate money for disk space.

I suppose we all would rather not, but I'm impressed that
people seem to be willing to pony up, too.

>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.

When I talk to the various places, I'm intending to discuss
management issues.  A key factor in all this is in fact the
cost of labor.  It's entirely possible that the schools will
not have funds available to support a gift of hardware.  The
common perception that such gifts are "free" is simply
mistaken.  It's also true that labor is quite a lot more
costly than the hardware we're talking about: for the cost
of my time, we could buy a gig every week!

>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 have

Of course, there's no such thing as *enough* when it comes
to memory, disk space, time, money, or fast living!  Not to
mention sex, drugs, and rock'n'roll!  :-)

>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.

Unquestionably better compression technologies are a wise
investment.  They pay back not only for the servers, but for
the user community as well, because most of us are anything
but swimming in extra disk space.

But of course there are practical problems, as with any kind
of technology update, not the least of which are plain old
human nature (I don' wanna if I don' hafta) and politics
(don' tell me what I oughta).  

There are significant labor costs in this dimension too.
F'rinstance, were I to update my MS-DOS archive, which is
stored on 800 floppy disks, from ARC to ZIP, I'd be looking
at the time it takes to do this on a 12 MHz AT clone,
feeding the disks one at a time.  I have 300 more disks
before I run out, at which time it could be cheaper to toss
stuff away, most of it being software I'll probably never
need again, and better versions being readily available if I
should need them.

And this last is one of the major reasons for having an
archive server in the first place -- they keep it so we
don't have to.

Yet another dimension, one I will be looking into, is
freeing up space on the servers by discarding things no one
really needs or wants.  Ticklish, to be sure, but not to be
overlooked.  Still another is duplication.  Geographical
factors become less and less an issue as networking
technology develops.  This brings in turf issues that I will
also be discussing with the site management people.

>So, in my view it comes down to three things, management, disk
>space, and compression.  Compression is actually contained within
>management, and so, to a certain extent, is disk space.  Just
>throwing hardware at the problem is not going to solve it.  Of
>these, I think that if we put forth the bucks to help defray
>management costs, we'll get the best return on our dollar.

As you see, I agree with all your points but not with your
conclusion, Scott.  Management costs 50 times as much as
disk space.  That doesn't mean that the management aspect
shouldn't be pursued, of course it should; but it does mean
the tradeoffs are more complicated than your model allows
for.

To conclude, I propose to continue collecting pledges for at
least another week.  I can report that hardware vendors have
contacted me who are willing to help out.  I'll know more in
a couple days about a lot of the implementation details and
snags (there are sure to be some), and will report to y'all
then.

-- 
[Jess Anderson <> Madison Academic Computing Center <> University of Wisconsin]
[Internet: anderson@macc.wisc.edu <-best, UUCP:{}!uwvax!macc.wisc.edu!anderson]
[Room 3130 <> 1210 West Dayton Street / Madison WI 53706 <> Phone 608/262-5888]
[---------> Discrimination, Bigotry, and Hate are not Family Values <---------]
Newsgroups: comp.sys.next.misc