For people who have a hard time seeing the image, here's the text of the comment:
Rob Pike - It's a different kind of mess, and for different reasons, but the Unix/POSIX/Linux systems of today are messier, clumsier, and more complex than the systems the original Unix was designed to replace.
It started to go wrong when the BSD signal stuff went in (I complained at the time), then symlinks, sockets, X11 windowing, and so on, none of which were added with proper appreciation of the Unix model and its simplifications.
So let the whiners whine: you're right, and they don't know what they're missing. Unfortunately, I do, and I miss it terribly.
Of all the things he mentions for sure signals are the worst thing. To do such a simple thing of delivering a tiny bit of information to a process the implementation and semantics of signals is so bad that you have to use atomic variables, deal with interrupted system calls, write reentrant functions, and so forth.
He wasn't complaining about signals. Signals were in the original Unix. He was complaining about "the BSD signal stuff", which changed the semantics of signals incompatibly, in order that a program could possibly handle externally-sent signals without race conditions, and also added a bunch of signals for goofy stuff like SIGWINCH.
Signals are just a software interrupt mechanism, doubling as a way to kill runaway processes. All the things you are complaining about are problems with interrupts in general. Yet all computers since the 1960s still have interrupts, because they allow you to do things you can't do without them. And that's still true when you're talking about signals. Signals allow you, for example, to implement preemptive multithreading (with SIGALARM) or transparent transactional persistence (with SIGSEGV) or buffer overrun checking (ElectricFence, with SIGSEGV) in a userspace library.
However, they've clearly been expanded far beyond what they are necessary or even good for, and lamentably are still not usable for the primary use of hardware interrupts: I/O.
It's funny that you should bring that up... During this whole back-and-forth I can't help but think that Apple's libdispatch solves most of the issues brought up by both sides:
* Use a dispatch queue and dispatch_async a block to handle computation. Since the queues work from a shared thread pool and are managed at the kernel level, a long-running Fib calculation won't hold up other blocks from processing on any concurrent queue (it would still hold up a sequential queue...obviously).
* Use dispatch_sources to do your IO. Now you don't have to worry about clumsy callbacks, and your IO operations are perfectly happy co-existing with your long-running computations.
* Use dispatch_read/dispatch_write to persist to disk and you don't have to worry about different latency and throughput characteristics of files vs sockets
...and to the point about signals:
* Use a signal dispatch_source to do things in response to signals that you would never have thought possible. This is possible because libdispatch sets up a trampoline to catch the actual signal and then turn around and queue your dispatch_source block. It's not a complete panacea, but it's close...
Plan9 was a project that intended to be more Unix than Unix. For example, when Unix says "Everything is a file... except sockets, windows, etc." Plan9 says "no really, everything is a file." Here is a list of things that are not in Plan9 http://c2.com/cgi/wiki?WhatIsNotInPlanNine Oh, and did I mention Pike was one of the original leaders of the Plan9 project?
Ultimately, today's UNIX is not that far from this ideal. In Linux, you can make pretty much everything be an fd: signals can be delivered over a descriptor (signalfd(2)), filesystem change notifications can be delivered over a descriptor (inotify(7)), and so on. Everything ends up being something you can pass to select (or a variant), and so you don't really need to handle the different concepts in different ways: a modern Linux application reads from a bunch of fds and takes action based on what it receives.
Doug McIlroy (inventor of pipes, original author of diff) was on my undergrad thesis committee. I think he would agree with Rob here.
While the design of these additional features violates the "UNIX way," it doesn't violate pragmatism. Too often in our field, perfect is the enemy of good enough. Is BSD's model and implementation of sockets perfect? Surely not. Is it good enough? From the purists perspective, maybe not. From the pragmatists perspective, absolutely. I probably wouldn't be typing this today (on my macbook pro) without the implementation of BSD sockets.
I recall this missive from Linus Torvalds on the design of Linux:
"If you want to see a system that was more thoroughly _designed_, you should probably point not to Dennis and Ken, but to systems like L4 and Plan-9, and people like Jochen Liedtk and Rob Pike. And notice how they aren't all that popular or well known? "Design" is like a religion - too much of it makes you inflexibly and unpopular."
On the other hand, signals were just a poor design. They are much nicer now on Linux with signalfd(2), which gives you a file descriptor to read them on, a much nicer interface than all the old syscalls for signals.
I can't help but juxtapose this current dialog (which now includes one of the Unix forefathers) with the idea of "Worse is Better" (http://www.jwz.org/doc/worse-is-better.html). Maybe it's the Jersey in me but at the end of the day working, shipped software is all that concerns me.
BSD sockets has somehow made it's way through the entire computing world and we're never going to get rid of it. Even the tiniest of embedded systems have decides that sockets are the one-true-way of network programming.
What's the alternative? OS/2 had nice features; it got crushed. BeOS had some nice features; it got crushed. (Yes, I'm aware that they're probably still around in some OSS version.) Plan9 keeps being mentioned, but do regular users understand it? (Is there a "this is why we do things, and this is why that's good" written for people who haven't written their own compiler?)
Are people working on experimental new OSs to "fix problems" in existing systems, or have we gone way past the point of no return? Is there any work on new microprocessor architecture? How much stuff in my modern OS is there because of legacy 8086 stuff?
I think, but I'm not sure, that the length of time it's taken people to get (for one example) IPv6 rolled out shows that change is not likely.
> Plan9 keeps being mentioned, but do regular users understand it? (Is there a "this is why we do things, and this is why that's good" written for people who haven't written their own compiler?)
This will give you a good overview of the basic design decisions in the system and their rationale, for further details on how Plan 9 deal with issues from toolchain design to authentication and security see the rest of the papers: http://doc.cat-v.org/plan_9/4th_edition/papers/
They are a wonderful read even if you never touch Plan 9, they are full of insights, ideas and criticisms of existing approaches, and many even include discussion on how to apply them to existing nix systems (sadly most of this has gone almost completely ignored by the nix community).
(a) He is qualified to speak about these issues in so far as he is the designer of node.js and is a programmer.
(b) Rob Pike's comments are a "big deal" because Rob Pike is one of the "original neckbeards" that worked on Unix, Plan 9, and has recently been developing the Go language at Google. i.e. He helped developed the OS that Ryan is complaining about.
(c) "right or wrong" depends heavily on what you are trying to accomplish. Much like anything in the real world, there is no right or wrong answer.
You forgot BeOS, which lives on in Haiku. One of my favorite "alternative" operating systems of the time. I still wish I had more hours in the day so I could hack on Haiku once in a while.
This is not sarcasm by the way. I like being nostalgic and apparently I like system related stuff as opposed to web programming. But keep doing what y'all did.
Symlinks are bad. They break the natural semantics of a hierarchical tree-like filesystem, and turn it into a messy half-assed graph.
What happens if you move a symlink? Will it still point to the same object? That depends on whether it's relative or absolute. What if you move the directory containing it? Do you have to recursively check for the correctness of links every time you operate on a directory? Sounds unreasonable to me... What if it links to a location which isn't mounted? Whats the definition of '..'? If you cd into a linked directory and do an 'ls ..', should that list the parent of the target or the link? How would you implement that?
The point is, symlinks are a messy kluge which probably wasn't thought out very well. You can look at what Rob Pike has to say about it himself on http://cm.bell-labs.com/sys/doc/lexnames.html
I can understand why he wouldn't like symlinks. They weren't introduced until 4.2BSD and they seem like a bit of a hack. Compare them to hard links. If you move the destination file the hard link remains, but the symlink is broken and there's no simple way to figure out where the destination file was mved to. Also hard links include reference counting so you know that someone is pointing to your file. Not so with symlinks. Also, hard links mirror the permissions of symlinks.
Note that the history shows up in the ln command which originally only created hard links, and then got the -s parameter when symlinks were introduced.
>Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
etc etc.
filesystems are a mess, and it'd be great if something could fix them.
He said they weren't added with proper appreciation of the Unix model and its simplifications. So he could mean that symlinks can be implemented in a more Unixy way?
Utilizing single purpose programs with a highly unintegrated scripting language breaks the whole idea of do one thing and do it well as there are now n things that do the same thing but with different trade offs. We have n flags, massive unmaintainable messes of bash, posix sh and other variants. Sun's shot with a 'managed' os with javaos was more than ahead of its time.
I would guess the problem with sockets is in the whole creation process. Instead of just calling open() on a magic pathname (like how you deal with devices in Unix), you call socket(), then bind()/listen()/accept() on the server side, or connect() on the client side. Luckily they didn't totally screw it up, and it's just a regular file descriptor after that point... except on Windows, where they did screw it up.
[+] [-] brlewis|14 years ago|reply
Rob Pike - It's a different kind of mess, and for different reasons, but the Unix/POSIX/Linux systems of today are messier, clumsier, and more complex than the systems the original Unix was designed to replace.
It started to go wrong when the BSD signal stuff went in (I complained at the time), then symlinks, sockets, X11 windowing, and so on, none of which were added with proper appreciation of the Unix model and its simplifications.
So let the whiners whine: you're right, and they don't know what they're missing. Unfortunately, I do, and I miss it terribly.
[+] [-] mannylee1|14 years ago|reply
[+] [-] antirez|14 years ago|reply
[+] [-] kragen|14 years ago|reply
Signals are just a software interrupt mechanism, doubling as a way to kill runaway processes. All the things you are complaining about are problems with interrupts in general. Yet all computers since the 1960s still have interrupts, because they allow you to do things you can't do without them. And that's still true when you're talking about signals. Signals allow you, for example, to implement preemptive multithreading (with SIGALARM) or transparent transactional persistence (with SIGSEGV) or buffer overrun checking (ElectricFence, with SIGSEGV) in a userspace library.
However, they've clearly been expanded far beyond what they are necessary or even good for, and lamentably are still not usable for the primary use of hardware interrupts: I/O.
[+] [-] jballanc|14 years ago|reply
* Use a dispatch queue and dispatch_async a block to handle computation. Since the queues work from a shared thread pool and are managed at the kernel level, a long-running Fib calculation won't hold up other blocks from processing on any concurrent queue (it would still hold up a sequential queue...obviously).
* Use dispatch_sources to do your IO. Now you don't have to worry about clumsy callbacks, and your IO operations are perfectly happy co-existing with your long-running computations.
* Use dispatch_read/dispatch_write to persist to disk and you don't have to worry about different latency and throughput characteristics of files vs sockets
...and to the point about signals:
* Use a signal dispatch_source to do things in response to signals that you would never have thought possible. This is possible because libdispatch sets up a trampoline to catch the actual signal and then turn around and queue your dispatch_source block. It's not a complete panacea, but it's close...
...now if only Linux would implement kqueue
[+] [-] sp332|14 years ago|reply
[+] [-] jrockway|14 years ago|reply
Incidentally, this is node.js' model.
[+] [-] adobriyan|14 years ago|reply
Unix said that, but in fact meant "everything has a unique descriptor associated (an integer)".
Directory is not a file, it's a set of files and other directories. Unix doesn't even tries to camouflage this simple observation and returns EISDIR.
[+] [-] naner|14 years ago|reply
oh yes that is so elegant...
[+] [-] etrain|14 years ago|reply
While the design of these additional features violates the "UNIX way," it doesn't violate pragmatism. Too often in our field, perfect is the enemy of good enough. Is BSD's model and implementation of sockets perfect? Surely not. Is it good enough? From the purists perspective, maybe not. From the pragmatists perspective, absolutely. I probably wouldn't be typing this today (on my macbook pro) without the implementation of BSD sockets.
[+] [-] nicolaus|14 years ago|reply
"If you want to see a system that was more thoroughly _designed_, you should probably point not to Dennis and Ken, but to systems like L4 and Plan-9, and people like Jochen Liedtk and Rob Pike. And notice how they aren't all that popular or well known? "Design" is like a religion - too much of it makes you inflexibly and unpopular."
http://kerneltrap.org/node/11
[+] [-] justincormack|14 years ago|reply
[+] [-] mdellavo|14 years ago|reply
I can't help but juxtapose this current dialog (which now includes one of the Unix forefathers) with the idea of "Worse is Better" (http://www.jwz.org/doc/worse-is-better.html). Maybe it's the Jersey in me but at the end of the day working, shipped software is all that concerns me.
[+] [-] adestefan|14 years ago|reply
[+] [-] DanBC|14 years ago|reply
What's the alternative? OS/2 had nice features; it got crushed. BeOS had some nice features; it got crushed. (Yes, I'm aware that they're probably still around in some OSS version.) Plan9 keeps being mentioned, but do regular users understand it? (Is there a "this is why we do things, and this is why that's good" written for people who haven't written their own compiler?)
Are people working on experimental new OSs to "fix problems" in existing systems, or have we gone way past the point of no return? Is there any work on new microprocessor architecture? How much stuff in my modern OS is there because of legacy 8086 stuff?
I think, but I'm not sure, that the length of time it's taken people to get (for one example) IPv6 rolled out shows that change is not likely.
Plan9 LiveCD and installer: (http://cm.bell-labs.com/plan9/download.html)
Haiku: (http://haiku-os.org/)
[+] [-] uriel|14 years ago|reply
Yes, you can start with the main Plan 9 paper: http://doc.cat-v.org/plan_9/4th_edition/papers/9
And follow up with The Organization of Networks in Plan 9: http://doc.cat-v.org/plan_9/4th_edition/papers/net/
And The Use of Name Spaces in Plan 9: http://doc.cat-v.org/plan_9/4th_edition/papers/names
This will give you a good overview of the basic design decisions in the system and their rationale, for further details on how Plan 9 deal with issues from toolchain design to authentication and security see the rest of the papers: http://doc.cat-v.org/plan_9/4th_edition/papers/
They are a wonderful read even if you never touch Plan 9, they are full of insights, ideas and criticisms of existing approaches, and many even include discussion on how to apply them to existing nix systems (sadly most of this has gone almost completely ignored by the nix community).
[+] [-] achompas|14 years ago|reply
(a) Ryan Dahl is qualified to speak about these issues (i.e. he worked on the original Unix design or something)
(b) Rob Pike's comments are a big deal to Ryan, and
(c) whether Ryan is right or wrong?
I'm one of the "new guys" that doesn't know what he's missing, and I'd love to put this into context.
[+] [-] hvs|14 years ago|reply
(b) Rob Pike's comments are a "big deal" because Rob Pike is one of the "original neckbeards" that worked on Unix, Plan 9, and has recently been developing the Go language at Google. i.e. He helped developed the OS that Ryan is complaining about.
(c) "right or wrong" depends heavily on what you are trying to accomplish. Much like anything in the real world, there is no right or wrong answer.
[+] [-] chernevik|14 years ago|reply
http://cm.bell-labs.com/cm/cs/upe/
[+] [-] mhd|14 years ago|reply
Ok, maybe Chuck Moore complaining about Oberon after that. Can we go any deeper?
(Also: Discussing this on the web is a wee bit ironic.)
[+] [-] hello_moto|14 years ago|reply
It was fun back then.
I think I'm going to grab my time machine and warp back.
[+] [-] michaelchisari|14 years ago|reply
http://haiku-os.org/
[+] [-] hello_moto|14 years ago|reply
[+] [-] metabrew|14 years ago|reply
[+] [-] saljam|14 years ago|reply
What happens if you move a symlink? Will it still point to the same object? That depends on whether it's relative or absolute. What if you move the directory containing it? Do you have to recursively check for the correctness of links every time you operate on a directory? Sounds unreasonable to me... What if it links to a location which isn't mounted? Whats the definition of '..'? If you cd into a linked directory and do an 'ls ..', should that list the parent of the target or the link? How would you implement that?
The point is, symlinks are a messy kluge which probably wasn't thought out very well. You can look at what Rob Pike has to say about it himself on http://cm.bell-labs.com/sys/doc/lexnames.html
[+] [-] jgrahamc|14 years ago|reply
Note that the history shows up in the ln command which originally only created hard links, and then got the -s parameter when symlinks were introduced.
[+] [-] dtf|14 years ago|reply
http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames
[+] [-] DanBC|14 years ago|reply
>Symbolic links make the Unix file system non-hierarchical, resulting in multiple valid path names for a given file. This ambiguity is a source of confusion, especially since some shells work overtime to present a consistent view from programs such as pwd, while other programs and the kernel itself do nothing about the problem.
etc etc.
filesystems are a mess, and it'd be great if something could fix them.
[+] [-] davidw|14 years ago|reply
And he has earned the right to do so.
[+] [-] eterps|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] dextorious|14 years ago|reply
(that is, not only "not having anything like them").
[+] [-] mmahemoff|14 years ago|reply
Pity.
[+] [-] seclorum|14 years ago|reply
[+] [-] nwmcsween|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]
[+] [-] jmderm|14 years ago|reply
[+] [-] tsuyoshi|14 years ago|reply
[+] [-] riobard|14 years ago|reply
[+] [-] jberryman|14 years ago|reply
[+] [-] dextorious|14 years ago|reply
[+] [-] peterwwillis|14 years ago|reply
I don't care.
Learn to use what you have or get something else and stop fucking complaining. The End.