Retrofitting New Principles Onto Mature Systems

A large, mature system is retrofitted with a new feature (paradigm or principle) that crosscuts all functionality.

The result? Judge for yourself.

Why do retrofits fail? Because the new principle / paradigm is subordinate to the existing ones, it is strictly second class.

A clean architecture with the new feature is an instance of YouCantGetThereFromHere

What's wrong with Unix GUIs--and how exactly is "everything is a file" (which isn't really true in Unix--lots of kernel objects are not files) affect the GUI? Unix (and Unix-like systems) have had lots of graphical user interfaces (some excellent, some not). Among them:

Unix still seems to have a bad reputation left over from the days when X provided a crude windowing system, and little more--many tasks which should have been handled by the windowing system were left to applications. But the issues plaguing GUIs on Unix systems have everything to do with politics and corporate greed; and little to do with the underlying architecture of Unix. And certainly nothing whatsoever to do with the myth that "EverythingIsa" file in Unixland. Perhaps that's true for PlanNine; but that's not Unix.

-- ScottJohnson

"Myth" is hardly the word. "Everything is a file" is a famous slogan and goal of Unix, but kernel objects have nothing to do with anything. Unix failed at literally making everything a file almost immediately, in the realm of I/O device control, so that the special purpose stty(2) (especially pre-version 7) and ioctl(2) (increasing in use at supersonic speed starting with version 7) and some other such miscellaneous system calls had to be introduced to e.g. change serial line baud rate to modems and terminals.

Unix partially succeeded in that goal otherwise, and especially keeping in mind that it was meant in sharp opposition to other operating systems of the day. For the most part "everything is a file" in particular meant "a sequence of 8 bit bytes with a uniform API", whereas other OSes required entirely different system calls to deal with a record-based file than with a text file. Even directories were originally just files, in this sense; although marked with a "directory" flag bit, they were just sequences of bytes showing the inode and name of each file "in" that directory, and those directory files were read (e.g. by ls) using the same read(2) system call one used to read text files. Conventions like the "." and ".." entries were carefully maintained only by the mkdir and rmdir commands, nothing else, in the name of "everything is a file".

For the purpose of this page, the point is not whether X11 and its window managers and apps provide a sucky user experience, which has already been argued ad nauseum elsewhere, the point is that there is nothing whatsoever about X11 that even remotely pretends to be file-like. There is nothing whatsoever about X11 that fits into the original "everything is a file" approach.

One nitpick is that, with some X11 implementations, communication (events) between X11 client and server take place over a socket which is at least represented by a file descriptor, and therefore is partially file-like, however that is purely implementation specific. There are X11 implementations that use shared memory and no socket.

This means that one cannot wait on X11 events at the same time as file events (including TCP/IP events) using the select(2) system call, which is a truly horrid botch that requires enormous amounts of work to work around.

So it is true, retrofitting X11 onto Unix is indeed an example of nasty problems arising from RetrofittingNewPrinciplesOntoMatureSystems.

An example of the opposite is/was the Amiga, which had a nice clean message passing model at the foundation of its OS, and its GUI used messages just like everything else. (It did have a similar problem, though, in that they ran out of time and had to hurriedly buy a filesystem from the TriPos? OS and graft it onto the side; it was written in BCPL and exposed oddball BCPL and TriPos? notions in the API that were ugly and different than the rest of AmigaOs.)

-- DougMerritt

Yet, Tripos wasn't so different from the rest of AmigaOS that it was a botch-job. Sure, everyone knew it was a quick hack, but the messaging and memory management models used by Tripos almost exactly coincided with exec.library's original design for CAOS, so it was very simple to integrate the two systems. No new principles were applied to either Kickstart or to Tripos to create AmigaDOS. That Tripos was written in BCPL is an unfortunate, historical, vestigial inconvenience at best.

I think better examples of the principle exists, such as protected mode in Intel x86 architectures, which despite maintaining a similar programming model to real-mode (from ring-3's perspective), you had to work very hard to make a single program work in both real- and protected-mode environments. OS/2 1.x showed it was possible, but man, people hated it. Another example would be, I'd argue, the introduction of hot-plug support in the Linux kernel. Getting the kernel, the user-space tools it depends on, and all the moving parts these expose to the user working together continually proves to be a monumental undertaking -- so much so, it's still far from perfect even to this day. I plug in my SoundBlaster? USB sound device, and .... all my audio just stops working. I have to use ALSA's tools to reinitialize my cards. I absolutely dread any administrative tasks involving udev, to the point that I consider futzing with udev a red flag that it's soon time to just upgrade the whole distro. -- Samuel A. Falvo II

The original Unix SystemMetaphors were "everything is a file" and "every program is a filter". All Unix GUIs and graphical applications violate these metaphors in a big way. PlanNine has reinstated the "everything is a file" metaphor only by destroying the CDs and starting from scratch. (Slight correction: everything is a file system; files exist as an artifact of this more inclusive model.)

Related: BurnTheDiskpacks

EditText of this page (last edited October 15, 2014) or FindPage with title or text search