This is a question we (hubris!) need to answer in order to decide what to put in a new OS.
I'm going to present my opinion about some of it, but actually I doubt its going to get nowhere near 90% good. Maybe 10% :-( Sorry. Let me first try to list in a broad sweep the parts of POSIX. I wonder what I'll forget. * Shared, unified file system space: .. and symlinks, mounts, special nodes and sockets, uid based access control. * File access API, mutable files looked up by full path name (but some by fd), process CWD (and root), but file handles for lots of stuff. (like capabilities:-) * uid/gid+gids security model+ setuid, euids etc. * process control/communication model: fork, pids, signals. sessions? * terminal control model - lots of ioctls. sessions again. Shell process control. * device model - like files, but ioctls * network model - sockets and protocols. * IPC - pipes, (signals), shared memory etc. wait pid etc. Hmm.. thats enough for now. I think I'll start dissing things with the low hanging fruit.... * pids are broken. They aren't persistent handles, like fds, so hello race conditions on anything using them. * devices are in the filesystem namespace, socket port numbers aren't. Whats with that? Means all sorts of things need too many privs, I can't block things from network by uid using access permissions. (ACLs?) * The main file API does things mostly by path name, within the mutable namespace. More race conditions! Look at all the temporary file and symlink bugs. I do get a process cwd, so can maybe directory handles etc. Later we add fstat etc, getting better. * uids are an amazingly coarse security measure. They are all or nothing. And every process gets the whole system call array to use: network, interprocess signals, etc. No way to create subsets. * The unified file namespace is tied all together by ".." parent acess and by symlinks relative to the root. (And now by shared libraries for binaries) Separating out individual directories is pretty pointless, and chroots are a pain to use. No chance of security subdomains there. * terminal subsystem - stuck in the days of serial access. What happened to graphics, multimedia? Oh yes, we've got X. Its ok, but somehow lacking in quite a lot. Where's my network transparent sound after 20 years? * File access API. Assumes most files are mutable. (clue: this turns out to be wrong!) Ignores multiple versions. Destroys transactional semantics by making files appear in filesystem on open, instead of on close. Hello access to half-completed files! Oh, wow, we do a get a transactional rename. Wot no metadata? * fork: oh dear, it leaves all the fds open, signals enabled, sessions wrong, uids gids etc. Its rarely what we actually want. Most things just (forget to) close lots of things and exec immediately. * device model. We've got character and block devices. How much of their behaviour is standardised? What about standards for other sorts? Hello ioctl hell! * Shell process control. Its stuck in the tty age. screen is your friend.... Except when ptys go bad. Can you say security nightmare? * pipes. raw character streams. all that richly formatted data squashed into it. Look at the hassle of making find | xargs grep work with arbitrarily named files. Ever thought why it isn't the default? (PS has anyone read MS monad shell spec - its been clear that unix needed pipes like this for ages) Ok, I'm tired. I'll let someone else make a list of the good bits. I can't think of any right now. I have a life's ambition: Someday I'd like to use a well designed computer. This includes hardware and software. Anyone offering odds? -- [EMAIL PROTECTED] _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
