What kinds of things would you want in the GNU OS?

[Brandon S. Allbery]

As quoted from <422 at ladcgw.ladc.bull.com> by frank at ladc.bull.com (Frank Mayhar):
+---------------
| In article <106326 at sun.Eng.Sun.COM> bitbug (James Buster) writes:
| }Security:	ACLs? Get rid of root? Security monitors? Auditing?
| }		Provably secure(A1)?
| 
| Better security is always a good thing.  Security's not my forte, so
| I'll leave it alone.
+---------------

...provably secure?  From RMS???  You dream.  (On the other hand, the lack
of security that RMS prefers would be the biggest stumbling block in getting
people to *use* GNU... whereas I, for one, would like to see a lot of tin
gods topple when GNU becomes the industry standard.  [ 1/2 ;-) ]

+---------------
| and maybe even adjustable on the fly by a privileged user.)  This
| would keep one user from starting sixteen compiles and bringing a
| system to its knees.
+---------------

...I think I'm in trouble.  ;-)

+---------------
| }Virtual Memory:	Should GNU run on non-VM machines? Algorithm ideas?
| }		How general (map *everything* into VM space, like Multics)?
| }		Shared libraries?
| 
| I like the SunOS virtual memory concept (minus the current crop of bugs, of
| course).  If you're writing a Real Operating System, why worry about machines
| that won't support virtual memory.  Hell, by the time Gnu is ready, non-VM
| machines will probably be a thing of the past anyway.  Shared libraries
| are good.  Shared instruction space (text?) is another good idea, that can
| help save on memory requirements for often-used programs.
+---------------

Aside from unburied corpses like ncoast, non-VM machines already *are* a
thing of the past.  Heck, any 386 has VM.

+---------------
| }Networking:	NFS? RFS? Something better?
| }		Interfaces: Streams? TLI? Something better?
| }		TCP/IP? OSI? SAA/SNA:-)?
| }		RPC Services? What kind?
| 
| Something better.  But don't ask me what.  NFS is OK, but it has problems.
| You would want to support TCP/IP, at least at first (maybe using the BSD
| code), but OSI is probably the way to go.  SNA makes me gag.  (Actually,
| all of IBM makes me gag. :-)
+---------------

OSI, with a TCP wrapper for compatibility with present systems.

I'd prefer Streams.  REAL Streams, not the botch that was added to System V.
(Or did V8 live in vain?)

Network file systems:  something better than NFS.  Something better than RFS.
I suspect it has to be stateful; file locking effectively ended the reign of
stateless NFS. But RFS can't handle non-UNIX filesystems *transparently*.
(On the other hand, the File System Switch helps to cure that.)

I advise mixing and matching from NFS and RFS, combined with anything else
you can come up with that would *work* (no kluges, please!!!).

+---------------
| }Overall Design:	What nice ideas from other OSes could we use?
+---------------

I'd like to see a generalized namei() which supports environment variables.
This is upwardly compatible with DEC-style logical names and also provides
something similar to symlinks -- with the kind of multiple-universe stuff
that many Unixes now have (useful if Gnu itself diverges in any appreciable
way from Berkeley Unix, and also useful to us die-hard System V users).

+---------------
| }How about this? Make everything a user process which serves
| }a resource to a client. Resources include the CPU (scheduler),
| }memory (VM), disk (file system), network (sockets, etc),
| }serial lines (terminal handlers), etc. Each server determines the access
| 
| Excellent idea!  Promotes modularity, and allows flexibility.  Almost a
| plug-and-play operating system.  One problem, though:  there would have
| to be some sort of privilege level system, so that the resource handlers
| can do things like write other user's memory, directly access devices,
| re-map memory, etc.  And you would have to provide at least minimal
| functions in each module in the initial release.  Not everybody is
| an OS developer.
+---------------

"Minimal functions"?  I think that what'll be provided is the set of servers
which implements standard GNU (and, obviously, with source -- well-commented,
I hope (hint, hint!).  --Multiple copies of these should be able to run at
the same time.  OS compatibility then becomes a non-issue; if a System V-er
gets an account, start up the System V-emulating servers, which will be
paged out unless and until that user makes a System-V-style request.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery at ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery at hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser