Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!mcvax!unido!tub!tmpmbx!netcs!pengo
From: pengo@netcs.UUCP (Hans Huebner)
Newsgroups: comp.unix.wizards
Subject: Re: New (GNU) [was kernels, now command-line options]
Keywords: UNIX progress; controversy
Message-ID: <156@prmmbx.UUCP>
Date: 3 Jun 89 14:26:53 GMT
References: <2501@gandalf.UUCP> <15810@vail.ICO.ISC.COM>
Reply-To: pengo@prmmbx.UUCP (Hans Huebner)
Organization: netCS GmbH, Berlin, West Germany
Lines: 55

Those of you who think of everything related to VMS being inherently evil
should probably better hit 'n' now.

Here are just a couple of (unboiled) features and ideas which I'd like to
see in some new operating system.

-	The GNU OS should provide a better exception handling mechanism
	than Unix has with it various signal handling schemes.  The VMS
	AST handling scheme is well defined, and could be used as a star-
	ting point.

-	Probably, something like VMS event flags schould be provided, es-
	pecially for asynchronous I/O operations (yes, I'm thinking of
	something like $QIO here).  All the simplicity of Unix could be
	emulated with a more powerful scheme, so I see no real point in
	keeping the I/O system of the GNU OS as stupid as current Unix
	I/O.

-	If streams are to be used for character I/O, they should of course
	be available to make use of event flags and ASTs.  This would allow
	for more signals to be generated by, for example tty drivers.

-	The system should give privileged users access to kernel data
	structures by means of a set of well-defined system calls.  The
	Unix scheme of seeking on /dev/kmem is unaacurate, slow and messy.

-	Some error handling and message generation facility should not
	be hard to implement and would help getting machine-programmer
	interaction clearer.  Perror is just not enough.  The VMS message
	handling facility again is some nice point to start off.

-	Some command definition utility for the shell would be nice.  I
	see many problems in this fields, especially if GNU OS is to be
	totally compatible to Unix.

-	Clone devices are a must.  It should be possible to associate
	a name with a cloned device.  Again, this idea is old in the
	VMS world, but was easier to implement there.
	It might be worthwile to discuss whether devices have to reside
	in the file system, or if a scheme like that used under VMS (or
	AmigaDOS or...) could be a good alternative.

I'd be interested in getting more information on the status of the GNU
OS.  How many people are working on it ?  What is the *primary* goal
of the project ?  Shall GNU OS be just another Unix, or a new, flexible
operating system which has evolved from different streams of development
like BSD Unix, System V, VMS (no pun intended) etc. ?  Shall it be a
production operating system or a research OS ?

				Thanks for your attention
								-Hans
-- 
Hans H. Huebner
pengo@tmpmbx, pengo@garp.mit.edu, huebner@db0tui6.bitnet
                                       				"Why not ?"