UNIX-like, or profitable?

[Marcus J. Ranum]

rcd at ico.isc.com (Dick Dunn) writes:
>
>In my heart, I believe it's the royal road to disaster--I believe I can see
>a heat death coming.  But what do I know?  It hasn't happened yet [...]

	I admit this causes my mind to boggle, sometimes. By the time you
look at the state of the U*IX watermelon (formerly kernel) and add the
layered stuff on top of it, there is simply too much for any one person
to understand well. This lack of understanding causes failures, and
has a strong negative impact on the cost of products - development time
increases, development costs increase, and the customer funds it.

	I don't agree with Dick - heat death is a long way off, and may
never come. My suspicion is that U*IX and its associated layered stuff
(windows systems, GUIs, utilities, compilers, etc) is already complicated
past the point where any one person can truly be said to understand it
all. Specialization is the result. In most large organizations that have
a bunch of U*IX gurus around, there will typically be some kind of
division of knowledge - some mess with X, some are into filesystems,
some hack network stuff, and so on. This model works - it has worked
in the past - if you go to a "typical IBM mainframe shop" you'll find
the same kind of division of labor as a result of the sheer number
of layers of arcana and backwards compatibility - a thin slice of
compuarcheology.

	How many of your U*IX filesystems are a grotty web of symbolic
links because systems software providers prefer to make a link:
/usr/adm -> /var/adm
	rather than to simply *FIX* the applications that have hardcoded
paths in them? Possibly these kinds of bletcherous backwards compatibility
hacks will produce enough software friction that things will collapse from
complexity.

	I want to applaud the guys at Berkeley - their efforts in
separating pathnames out into stuff like pathnames.h is a good start,
unfortunately the market is betrothed to the false god Backward
Compatibility, who dictates that old mistakes must be preserved,
and that the current U*IX scheme of "each system software package
has its own configuration file someplace (undefined) each of which
is written in a different syntax, none of which use the same API to
access it". The market demands "commercial quality U*IX" but will
not tolerate the momentary upset that fixing the grot would cause.
In fact, because of all the "features" that would have to be
provided to make a minimal "U*IX" that the market would like,
it would take too long to produce - there's just too much sheer *stuff*.

	Currently any product on U*IX has about a page of copyrights
and licensing credits, containing the names of just about every U*IX
vendor out there. This is because there is just too much sheer *stuff*
for anyone to throw it away and rewrite it cleanly, so any vendor who
wants to market U*IX in a timely manner winds up licensing goo from
all over the place. This adds to the customer's costs, and adds
tremendously to complexity, as well as delaying shipping (sometimes)
- all for what?

>OK, enough marketplace cynicism for a moment.  What are we gonna DO about
>it?

	Educate the customer. As long as "informed consumer" remains
an oxymoron, this will continue.

	If someone writes a public domain microkernel tomorrow that
ran splendidly but couldn't support X11 - it'd be mostly ignored,
and completely ignored by the "users" until some martyr grafted X
onto it.

mjr.
--
Clearly, all these opinions are my own. My cats don't even agree with me.