Enduring bits - Unix

Over the past few decades, certain software creations have withstood the test of time. They have not only retained their original charm but also resulted in many derivatives (and imitations :-)) around their basic architectural elements. Unix is one of them. It gave us the concept of unified namespace, files as simple sequence of bytes, standard input/output, pipes, a rich job control language in the form of shell, and a simple syscall interface wrapped around a standard C library.

The software came with a complete toolchain that any programmer could use to look into the innards, extend it or modify it in various ways. Back in the early eighties when I first got my hands on the Unix distribution, the kernel was only about 60,000 lines of code and quite remarkable for its elegant implementation of architectural elements. I am still amazed that just a couple of hours of reading Kernighan and Pike's book on Unix Programming Environment is sufficient for someone to put together complex pipelines for searching, editing and sorting text.

While the hardware capability has gone up a thousand fold, the kernel and the syscall libraries continue to remain simple, flexible and elegant. Of course, the number of variants have grown into thousands today but that is a testament to the strong conceptual integrity and sound architectural foundation.

There is one quirk in Unix that has never been fixed. The unified namespace that works so well with serial, parallel, sound, storage and other devices breaksdown when it comes to network interfaces. Network devices dont register themselves in the standard device tables. They use their own set of tables. There is no special file type that caters to network devices or ports. There is no /dev/eth0 or /dev/tcp/53 or /dev/udp/80. Network devices use their own set of i/o system calls.

I can transfer a file to disk by "cp hello.txt /media/sda/hello.txt" and not have to worry about the physical structure on the disk, but I cannot stream a file to another machine over a network with "cp hello.txt /dev/tcp/9000". I can restrict a bunch of users from using a CDROM, but there is not /dev/eth1 whose permissions I can set on a owner or group basis.

Is it because the network stuff was designed in Berkeley on the West Coast while the namespace stuff was done by Unix Systems Lab on the East Coast? When teams cannot (or should not) communicate amongst themselves on a regular basis, architectural convergence is difficult to achieve (see Conway's Law).

The Video drivers and X11 is another sub-system that is horribly divergent from the clean namespace interface. Taking a screenshot should have been as simple as copying /dev/window to a disk file. Now we have hundreds of system calls and each sub-system comes with its own set of tools.

Plan 9 set out to fix the problem, but it was hobbled by a restrictive license till a few years back. It continues to plod along. I guess Unix is so well-entrenched in the market that people are willing to put up with its quirks rather than take up something radically different. But then, the distributed operations intrinsic to Plan 9 could tilt the balance in its favor with the arrival of multi-core chips.

Perhaps, somewhere, some student could be cooking up a disruptive innovation with Plan 9.