Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.micro.att,net.unix-wizards
Subject: Re: instability in Berkeley versus AT&T releases (absurdly long)
Message-ID: <2494@sun.uucp>
Date: Fri, 26-Jul-85 05:42:38 EDT
Article-I.D.: sun.2494
Posted: Fri Jul 26 05:42:38 1985
Date-Received: Sun, 28-Jul-85 05:39:39 EDT
References: <2067@ucf-cs.UUCP> <363@cuae2.UUCP> <2423@sun.uucp> <5819@utzoo.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 57
Xref: linus net.micro.att:337 net.unix-wizards:11230

> ...a quandary about which version of a utility to pick:  the one
> from AT&T usually has more bugs fixed, while the one from Berkeley often
> runs faster.

Which means, if the utility is important enough that it's worth the work,
the best strategy might be to "diff" the suckers and take the best from both
and put it into one version.  (There is one utility where the one from AT&T
runs faster, and the one from Berkeley has more bugs fixed - "awk".  The
S5R2 "awk" is quite a bit faster than all previous "awk"s, including the
4.2BSD one - one change is that it no longer uses structure-valued arguments
and functions - but it still has null-pointer-dereferencing bugs.  We beat
those out of the 4.2BSD one...)  (Then again, there are those utilities
where the only difference is the formatting of the code, or the presence,
absence, or shape of an SCCS ID - yes, there *are* utilities that haven't
changed since V7, as I know you're aware, but some people might be shocked
to hear that, especially the people who don't think AT&T had anything to do
with Berkeley UNIX...)

> The lack of file system quotas probably reflects AT&T's openly-expressed
> view (which I agree with) that except in special situations, if you think
> you need disk quotas then you really need more disks instead.

Maybe yes, maybe no.  I think Parkinson's Law applies to disk space as well;
give users more disk space and they'll find some way to fill it, even if
they just fill it with "net.politics" archives.

Think of it as an economic
problem; you have a scarce resource, but the price mechanism has a long
time-scale over which it works - possibly too long to prevent short-term
space shortages.  Quotas can keep users from eating the disks until you can
buy new ones, or until their managers get the bill for their disk space and
say "delete something or else".  I'd be curious to know how many commercial
VMS sites, say, use the VMS disk quota mechanism?  We've started to use disk
quotas here; we frequently have space problems.  We had them at CCI as well.
CCI's customers also had them; our office automation systems were often sold
to people who weren't necessarily experienced system administrators, and who
may not really think about the fact that every big document they keep around
represents a document that some other user can't keep around.  Again, there
are administrative techniques that can control disk usage over the long
term, but quotas can help deal with shortages in the short term.

> As many people have pointed out, unbundling (a) is a botch, and (b) is
> necessary if you are selling Unix boxes with small disks.  Not everybody
> has Eagles to put it all on.  Whether AT&T's unbundling strategy is
> rational, even given this excuse, is another question... but it is not
> totally without reason.

There's a difference between unbundling and charging separately; you can
provide a basic utility set and additional utilities as a single package, or
you can sell the additional utilities as add-ons.  I believe it is the
latter policy that people object to.  This policy is not a solution to the
technical problem of not having enough disk space to store all UNIX
utilities; it is a solution to the economic problem of paying for the
development and maintenance of software without charging people who have no
use for that software.

	Guy Harris