Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery From: allbery@ncoast.ORG (Brandon S. Allbery) Newsgroups: comp.unix.wizards Subject: Re: What kinds of things would you want in the GNU OS? Message-ID: <13688@ncoast.ORG> Date: 31 May 89 22:41:59 GMT References: <106326@sun.Eng.Sun.COM> <422@ladcgw.ladc.bull.com> Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery) Followup-To: comp.unix.wizards Organization: Cleveland Public Access UN*X, Cleveland, Oh Lines: 102 As quoted from <422@ladcgw.ladc.bull.com> by frank@ladc.bull.com (Frank Mayhar): +--------------- | In article <106326@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@ncoast.org uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu Send comp.sources.misc submissions to comp-sources-misc@ NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser