AT&T Joining OSF

[Doug Gwyn]

In article <313 at dtscp1.UUCP> scott at dtscp1.UUCP (Scott Barman) writes:
>... I think that if Unix is to survive it needs a mass cleanup to go
>*back* to its original idea of "small is beautiful" and get some of the
>junk out of it ...

The UNIX product will "survive" even with all the added cruft.
The extra baggage persists because none of the marketing types
will seriously consider changing the system in ways that cause
massive amounts of existing customer applications to break.

The correct solution would have been to resist adding features
in the first place and to change kernel functionality only after
considerable careful thought.  In fact the Bell Labs "research"
version of UNIX has suffered far less from feeping creaturism
than the commercial products (4.nBSD & System V).

Generally the real UNIX gurus are well aware of the problem.
Even many of the AT&T UNIX product development staff understand
the basic philosophy to some degree; to take one of your examples,
the tty driver has indeed been converted to STREAMS, it just
wasn't ready for Release 3.0.

For another example, in response to a call for public-domain
contributions I sent Berkeley a "cat" with NO options that
preserves record structure.  9th Edition UNIX has a similar
version of "cat".  We really DO want to stamp out the cruft.
In the research world, it appears to still be possible.  The
commercial versions of UNIX are probably a lost cause due to
uneducated customer demand for features.  Features sell a system,
even though its underlying logic determines its real worth.

There are many good new ideas that can be incorporated into
future operating systems.  Whether it would be fair to call
such a system "UNIX" is a debatable point.  There is one in
the works called "Plan 9" that embodies some good concepts..
The best operating systems really are developed by small teams
working with little interference; this has been demonstrated
several times by history.  That doesn't keep managers from
missing the lesson and organizing huge project teams!  Maybe
the real problem lies in typical technical management?