Home

Ghosts of Unix Past: a historical search for design patterns

Not strictly PLT-related, but Neil Brown has contributed an amazing series of articles to Linux Weekly News:

For this series we try to look for patterns which become visible only over an extended time period. As development of a system proceeds, early decisions can have consequences that were not fully appreciated when they were made. If we can find patterns relating these decisions to their outcomes, it might be hoped that a review of these patterns while making new decisions will help to avoid old mistakes or to leverage established successes.

By Manuel J. Simoni at 2010-12-05 04:12 | Software Engineering | other blogs | 30635 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

An interesting serie but

As the comments were made, trying to analyze Unix weaknesses and coming with something better was already made by Plan9 designers..

Yet Plan9 isn't used, maybe this is also a lesson in itself.

By renox at Sun, 2010-12-05 09:03 | login or register to post comments

I would expect the lesson to

I would expect the lesson to take from Plan 9 is not to change too much at once. For instance, if they had stuck with C as Plan 9's systems language, it would probably have caught on a lot more. As evidence, they've currently rewritten much in C as of this point.

By naasking at Sun, 2010-12-05 16:59 | login or register to post comments

plan9 isn't used but most of the good ideas were

like /proc

By tef at Sun, 2010-12-05 23:40 | login or register to post comments

Only a *few* of the good ideas have been used

I am afraid only a *few* of the good ideas have been used. And their implementers missed the forest for the trees. The idea was not to represent just a process as a file but every system object as a named file or directory. Second, these files may be local or remote and accessed using a standard protocol (9P). Third, the file name space is process centric and can be modified as needed. Fourth, one can write user level "file servers" using the same protocol (compared to 9p "fuse" is quite unwieldy). Had Unix really embraced these ideas from Plan 9, the benefit would've been a hugh simplification, a very modular & easily extensible system.

Unfortunately except for a few diehards it has remained a curiosity. And, IMHO, even the diehards have only scratched the surface as to what can be done with this simple model. New people check it out all the time but given a dearth of applications and eye-candy most of them won't or can't use it as their main OS (even as a hobby).

I believe their original idea of a "clean slate" design was right. That avoided Unix compatibility unduly impacting the design early on. Perhaps a more faithful emulation of Unix could've been provided later on.... (plan9 has a library called `ape' for Ansi/Posix Environment but it doesn't quite cut it).

In my view the main reason plan9 missed the popularity boat is that Bell Labs didn't open source it at the right time, which was 1993, around the time both 386bsd and linux-0.11 came out. Many of the early adapters of these two systems would've likely embraced plan9.

By Bakul Shah at Mon, 2010-12-06 17:57 | login or register to post comments

I think it's also

I think it's also informative to take a look at OpenVMS when analyzing the faults of Unix based systems and possible solutions. At first (coming from a Unix background) it might seem a bit awkward, but in my experience it's actually a very nice system with such features as ACLs, logical names, great interactive help system, and versioning of files built into the file system.

By Thomas Strathmann at Sun, 2010-12-05 13:10 | login or register to post comments

50,000 foot views

are only good for death spirals.

The author really needs to eradicate the word "this" from his vocabulary. He would do us all a favor in making his argument clearer. I counted "this" eleven times in the first article alone, and many of the usages seemed ill-advised.

I also dislike the phrase "full exploitation" in the article.

So while hierarchical namespaces were certainly well exploited in the early design, they fell short of being fully exploited, and this lead to later extensions [such as network devices] not being able to continue the exploitation fully.

What? The conclusion here did not follow from any of the examples given. For example, the quote below from an earlier paragraph in the same section:

Part of the difficulty is maintaining backward compatibility with the original Unix way of using device special files which gave, for example, stable permission setting on devices. There are doubtless other difficulties as well.

and earlier in the article where it states why the single, hierarchical namespace is supposedly good:

The design idea being fully exploited here is the hierarchical namespace. The result of exploiting it within a single storage device, across all storage devices, and providing access to devices as well as storage, is a "single namespace". This provides a uniform naming scheme to provide access to a wide variety of the objects managed by Unix.

So was the problem that the device special file namespace's permissions model was stupid? Or was it that the device special file wasn't in a common singly rooted DAG, and everyone who wants to add a new name to the namespace has to do an insert on the common singly rooted DAG? I don't get it. The author isn't clear. His examples don't actually seem to motivate his argument well. Its a string of disconnected examples with ephemeral "good" vs. "bad" qualifications and very few detailed sentences.

Then there is the following example:

By incorporating this feature directly in the namespace, the functionality becomes available to all programs.

Why should functionality become available to all programs? This is NOT even the reason behind a single, hierarchical namespace. Or even a single namespace!!

He touches upon access control, again:

The device special files in Unix provide only limited access to this namespace. It can be helpful to see them as symbolic links into this alternate namespace which add some extra permission checking. However while symlinks can point to any point in the hierarchy, device special files can only point to the actual devices, so they don't provide access to the structure of the namespace. It is not possible to examine the different levels in the namespace, nor to get a 'directory listing' of all entries from some particular node in the hierarchy.

It is probably best to think about what scenarios should support access to this information, and how to go about controlling that access. Since UNIX is a time-sharing environment, we need to think about how to do access control with consideration to concurrency.

This is why some people hate "patterns" discussion. Some people are really awful at patterns discussion. At least I give the author tons of credit for trying. He meant well.

By Z-Bo at Tue, 2010-12-07 22:12 | login or register to post comments