User: Password:
|
|
Subscribe / Log in / New account

Ghosts of Unix past, part 2: Conflated designs

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 8:32 UTC (Thu) by mti (subscriber, #5390)
Parent article: Ghosts of Unix past, part 2: Conflated designs

I do agree with the author that that some parts of the Unix API is less than optimal for a modern computer. But I do very much not agree that it is bad design, quite the opposite. Calls like open(), read(), write(), mount() were designed ~40 years ago and are still quite usable (if not perfect). This is really good design.

It is not much we can learn from the "design flaws" mentioned in the article. It would have been very hard for Thompson and Ritchie to predict CDROM, sockets or distributed file systems.

The beauty of the original design was its simplicity. This made it possible to later extend the design.

If we want to look at bad designs there are better examples. I would suggest SYSV IPC or curses. Or maybe look outside Unix. See how the equivalent of read(), write() and mount() were done on CP/M or DOS 1.0.


(Log in to post comments)

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 11, 2010 23:51 UTC (Thu) by bronson (subscriber, #4806) [Link]

It's a waste of time look at a bad design and discuss all the ways it could be better. Anybody can do that. Taking an excellent design and finding ways to improve it, now that is interesting. SysV IPC and curses (and device numbers and terminfo/tty and nondeterministic exec and...) have been beaten to death for decades. No need for that on LWN.

Not sure where you see the author saying anything is bad design. He's just considering how good things can be made better. Show me something that can't!

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 12, 2010 22:58 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

I believe the author does say that conflating is bad design.

And the point of looking at design patterns is that one shouldn't expect to predict things like CDROMs, sockets, and network filesystems. Instead of trying to list all the ways your thing will be used, just follow certain patterns and things will work out by themselves. Even if you can't see, or there doesn't exist, any present downside to conflating two designs, don't conflate them anyway and you will be more successful.

We may still be able to excuse Thompson and Ritchie with a hindsight argument by saying that the way things looked at the time, creating a filesystem image and adding it to the namespace were fundamentally a single gestalt, and it is only since then that we have learned to think of it as two things.

Ghosts of Unix past, part 2: Conflated designs

Posted Nov 18, 2010 15:32 UTC (Thu) by renox (subscriber, #23785) [Link]

> Taking an excellent design and finding ways to improve it, now that is interesting.

I agree but Plan9's designers already did this to Unix..
So improving on Plan9 would be interesting, but I'm not sure I see the point for Unix!


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds