Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!brl-adm!umd5!vrdxhq!dgis!csed-1!roskos
From: roskos@csed-1.UUCP (Eric Roskos)
Newsgroups: comp.unix.wizards
Subject: Re: AT&T/Sun merged UNIX
Summary: it's a question of what you're standardizing
Message-ID: <262@csed-47.csed-1.UUCP>
Date: 2 Feb 88 14:47:47 GMT
References: <11558@brl-adm.ARPA>
Organization: IDA, Alexandria, VA
Lines: 37

In article <11558@brl-adm.ARPA>, bzs%bu-cs.bu.edu@bu-it.bu.edu (Barry Shein) writes:
> Basically the standards committees have spent most if not all their
> time standardizing Unix as it existed in 1978 with a few new items
> thrown in here and there ...
> Very little to none of the effort has been dealing with issues like
> networking, remote file systems, windowing etc, aka "modern needs".
> [Additional discussion of philosophies of standardization]

One thing to realize is that a standard that is too large and complex is
not likely to be accepted.  If standards are to tell people how to build
something (rather than just telling them to accept some existing product
as the standard), they have to be simple enough for people to be able
to build things to meet the standard.

In terms of the "modern needs" above, how much of that is *really*
necessary?  For example, for remote file systems you'd ideally like them
to look, to the user, like a local filesystem (with possibly a small number
of maintenance services added, but independent of the normal filesystem
services).  Likewise for windowing (an opinion based on experience with
the Macintosh, although I am expecting that discussion of this issue
will reemerge when OS/2 and its Presentation Manager come out, given
experience also with programming under Windows).  If you accidentally
standardize a lot of low-level features that turn out to be unnecessary,
you end up severely limiting future growth.

As for networking, issues of protocols should not show up in a mainline
Unix standard, should they?  This is not to say someone should not 
standardize network protocols (and of course that is being done), rather
that they should not tie in with Unix at the level the current standards
groups are working.

The point being, standards *should* be kept simple, the way the 1978-era
Unix was kept simple.  That's the only way you can keep the growth of
complexity under control.
-- 
Eric Roskos, IDA (...dgis!csed-1!roskos or csed-1!roskos@HC.DSPO.GOV)
	"Only through time time is conquered."  -- Burnt Norton