Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!ukc!dcl-cs!aber-cs!pcg
From: pcg@aber-cs.UUCP (Piercarlo Grandi)
Newsgroups: comp.unix.wizards
Subject: Re: What kind of things would you wnat in the GNU OS
Summary: SysV = V7 + N versions * M additions... Ugh.
Message-ID: <1001@aber-cs.UUCP>
Date: 10 Jun 89 12:12:49 GMT
Reply-To: pcg@cs.aber.ac.uk (Piercarlo Grandi)
Organization: Dept of CS, UCW Aberystwyth
	(Disclaimer: my statements are purely personal)
Lines: 62

In article <4455@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes:

    In article <19918@adm.BRL.MIL>, rbj@dsys.ncsl.nist.gov (Root Boy Jim) writes
    about bigger kernels today...
    > It takes more to do more.
    
    But is it really doing that much more?

Rhetoric question! V7 was (like Classic C) a remarkable balance of economy
and power. Power has increased a bit, economy has worsened a lot.
    
    What's the 5.2.3 kernel doing that the V7 kernel didn't do?
    
    	VM.
    	Streams.
    	RFS support (basically modifying namei() to support the network).
    	termio instead of sgtty.
    	?
    
    What have I missed? And how much does it really take?

On my SysV 3.2 I have potentially FIVE different pseudo terminal
implementations (xt???, sxt???, pty??, pts???, vt??), FOUR different IPC
mechanism (FIFO, shm+sem, streams, msg), FOUR different filsystem types
(S51K, S52K, Xenix, RFS), and so on, and so on, and so on, and so on, and so
on, and so on, .... (BSDs are occasionally even worse, and thank goodness
that BSD is still only a very partial implementation of Bill Joy's & C.
grandiose and hacky plans... :-<).

Not only each of them takes space if configured in (which for many is the
default), they also take space for the hooks, as each version does much the
same but in slightly different or totally incompatible ways, that require
different hooks.

Why this proliferation of (mostly pointless and misdesigned) variants?

Easy answer: because not many self styled Unix gurus are like the original
designers, have their depth and breadth of knowledge of other systems and
languages[**see note**], and (just like certain standard committees) are not
as gifted for simplicity and don't know what points of diminishing returns
are.

The idea that since we can afford more memory we can also afford sloppier
programming is as always ludicrous -- we want the extra memory for more
interesting applications, not to "afford" not much improved but badly
designed ones.

[**note**] to understand Unix/C and their evolution one must see them against
	a cultural background that includes CTSS, Multics, Tenex, GCOS,
	PDP/1, BCPL, Algol68, PL/360, etc..., things with which the original
	designers were directly or indirectly familiar and influenced by. It
	is terribly sad that the very diffusion of Unix/C (which was not
	meant as research but as a convenient tool, and was essentially a
	very clever retrenchment from more advanced designs under the
	pressure of limited hw resources) in Universities has meant that
	many CS grads and postgrads have not been exposed to anything else,
	except maybe cursorily. I am afraid that the phenomenon of the
	shallow (uncultured, historyless) Unix hacker is here to stay.
-- 
Piercarlo "Peter" Grandi           | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth        | UUCP: ...!mcvax!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk