Which 90% of POSIX /is/ good then?

[Brian Brunswick]

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?

--
address@hidden