Newsgroups: comp.misc
Path: utzoo!telly!moore!bkj386!anton
From: anton@bkj386.uucp (Anton Aylward)
Subject: Re: A tirade about inefficient software & systems
Reply-To: anton@analsyn.UUCP (PUT YOUR NAME HERE)
Organization: Chaos in the Basement
Date: Mon, 5 Nov 90 23:42:45 GMT
Message-ID: <1990Nov5.234245.5862@bkj386.uucp>
References: <9886@milton.u.washington.edu> <1990Nov1.002513.8984@ico.isc.com> <8539@scolex.sco.COM>

In article <8539@scolex.sco.COM> seanf (Sean Fagan) writes:
>
>One of the reasons I like Mach, or at least it's potential, is that the
>"features" everyone wants can be added as user-level programs.  That is,
>they can be swapped out, run only when needed, removed from the disk if you
>don't want it, etc.  (Some of the features everyone wants are built in, such
>as the VM, task switching, etc.  Others, such as unix compatability [which
>unix? you ask 8-)] can be made seperate modules, as can device drivers.
>Including networking.)

Huh? You can do this already with UNIX !!
Why SCO puts everything in the kernel I don't know.
Some things hae to be there, yes, but....

	The auto-logout is done as a user-domain daemon on most systems,
	SCO seem to have it in the kernel.

	Networking is done in the user domain on ATT boxes and ATT derived 
	UNIX.  SCO went the berkeley way and put it in the kernel.

Now correct me if I'm wrong, but isn't it a whole lot harder to page 
the kernel than it is to page a user process ?
Doesn't this mean that the bloated kernel is probably resident ?

>Keep it small and simple, and try to allow for generalities.  One of the
>nicest things to come from AT&T in recent history was the STREAMS stuff.  If
>a STREAMS module could be added without reconfiguring the kernel (and
>rebooting), and could optionally run in user-mode, it would be *wonderful*.
>(As it is, it's only nifty-keen 8-).)

As I understand it, it can, as long as you have the "head" and the 
"tail" ends alredy in there.   I've used 3B machines with almost 
all the comms (network, tty etc) in user space.
I see no reason why the disk strategy and drivers as well as the buffers
couldn't be done this way.

>How does this fit into the thread?  Well, like programming, if you keep your
>programs and/or utilities small and simple, there is less chance of things
>breaking (or, when they do, you will [hopefully] have a better chance of
>understanding and fixing the code).  

Right.  Like "old" UNIX before G-XXX and X-XXXX.
Shell type things, like K&R & Pike espoused.
Before Berkeleyisms bloated "cat" by adding the "harmful" -v.

					By splitting the various services into
>different programs, and documenting the interface, someone can decide to
>throw in new features of their own, or replace existing ones (as people do
>already with shells [ksh vs. csh vs. sh vs. bash etc]).

Gee, sounds like Object something or other to me.
Maybe I've been OOP-ing aloing is shell for the last 12 years 
without realising it?

/anton aylward		Analysis Synthesis Consulting Inc.
			anton@analsyn.uucp
			12 Years with UNIX

