David Chisnall on Where Unix Sucks (December 14, 2005)

David Chisnall has written a good article on limitations of Unix. It is well worth a read if you want to think about the limitations of a good, mature operating system. From the thinking I've done about it, David's analysis seems quite on.

Many of the followup comments show a shallow reading that I hope is not representative. Unix is good, but David's suggestions seem accurate.

On a particular couple of points that were dismissed in the comments:

• It is great that "everything is a foo", but why does "foo" have to mean a stream of bytes? Read, write, seek? Is this the right abstraction over all OS data structures? Does it match well to sockets? TCP sockets have out-of-band data, but due to the Unix abstraction to files it is awkward to access it. How about processes and process lists? Directories in the filesystem?
• On that note, the stream-of-bytes idea is a very low-level way to interoperate, and the ubiquitous lines-of-text semistructured reperesentation doesn't work well for a lot of applications. Something like s-expressions or XML would seem to work better. Something high-level like objects might also work out pretty well.
• The X11 design decision of network transparency is pretty, but it has turned out to be a useless feature plus a heavy constraint. Almost no one uses X11 that way, because it doesn't work well that way. But because of that design decision, there is a wedge between programs and the display. The first thing you have to do to get reasonable performance is use things like Xshm to undo this wedge. This feature is expensive in performance, in design effort, and in lost features, and I hope that the next popular open source graphics framework does not make the same mistake.

Additionally, I have to disagree with types per se as the way forward. If you take Smalltalk and treated it as an operating system, then most of David's requests would be answered immediately. The answer, it seems to me, is more about using language instead of types per se. It just so happens that a big chunk of language researchers these days are type enthusiasts.

Finally, the best way forward seems to involve POSIX compatibility. Swapping in a microkernel at a low level sounds helpful, because then existing programs could run but smarter programs could use the better interaction mechanisms. Another trick that is worth thinking about is that some Unices, including Linux, now allow using /dev/fd/nnn pseudofiles as a way to convert between file names and file descriptors. File descriptors allow richer interactions between programs than stdin/stdout, but many existing programs want to see file names instead of descriptors, so this provides a way forward.

But the most important thing of all for moving forward is that the people spending their time building tools need to be aware of what is possible and what the limitations are. Posts like David's are essential to spread this awareness.