
Rob Pike comments on Ryan Dahl's rant - arturadib
https://plus.google.com/115094562986465477143/posts/aEJE2vff4jS
======
brlewis
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._

~~~
mannylee1
Click on the image. It should bring it up as a readable image.

~~~
decklin
Not if you're using a screenreader.

------
antirez
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.

~~~
jballanc
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...

...now if only Linux would implement kqueue

~~~
bdonlan
What does kqueue give that epoll doesn't?

Note also that signalfd() can do something similar to your dispatch_source.

~~~
FooBarWidget
Epoll is limited to file descriptors. Kqueue also supports waiting on process
events (process exit, process fork, process exec, etc), on filesystem events,
and a bunch of other things. Epoll also does not support batch updates and
requires multiple system calls to apply updates for multiple file descriptors,
while kqueue supports batch updating _and_ polling in a single system call.
All in all kqueue is just superior to epoll. See also
<http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod> for various ways in
which epoll is broken (search for "The epoll mechanism deserves honorable
mention as the most misdesigned of the more advanced event mechanisms")

~~~
kqueue
Not to mention that kevent contain the number of bytes to be read, or the
number of connections to accept, which can avoid you a system call that
returns EAGAIN in a non-blocking socket.

------
sp332
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?

~~~
adobriyan
> Unix says "Everything is a file... except sockets, windows, etc."

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.

~~~
kragen
Even in 6th Edition Unix, devices were files in the filesystem as well. And in
6th Edition Unix, you could open and read a directory as a file; that was how
you found out what its children were. There was no EISDIR. I believe this
behavior persisted until at least SunOS 4.

Adding sockets and windows outside the filesystem is one of the things Rob is
specifically complaining about here, and in fact complained about at the time
as well.

------
etrain
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.

~~~
nicolaus
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."

<http://kerneltrap.org/node/11>

~~~
yxhuvud
Yes, like Apple.

.. oh wait.

It is rather that good design make you popular and not so good design doesn't.

~~~
william42
Apple's internal design was a mess pre-OSX though. Still kind of is. Apple's
praised for end-user interface design.

~~~
uriel
OS X design is still a horrible mess, a monolithic BSD kernel bolted on top of
a monstruous Mach 'micro'-kernel. Not to mention things like the new XML-based
init system, property list files, hacks around 'extended attributes' (or
whatever they call them) and many other aberrations.

~~~
dextorious
And those are a mess because?

Property list files: a big f*n win compared to the ad hoc mess in a Linux/BSD
/etc directory.

Hacks around extended attributes: any reason not to like those? Or just
because in 1977 a file was just a file, and that's the way it should be, god
damn it?

XML-based init system: a sane init system. And XML added in for
standardization.

OS X is a mess in several ways, but those are not it. And the "monolithic BSD
kernel bolted on top of a Mach 'micro'-kernel" sounds like a win-win
situation. Monstrous why? Because it doesn't fit some idealistic model?

~~~
FooBarWidget
Even standard system calls are messily implemented. poll() is broken. kqueue
is broken. See
[http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AN...](http://pod.tst.eu/http://cvs.schmorp.de/libev/ev.pod#OS_X_AND_DARWIN_BUGS)

Last year I even discovered a kernel bug in their file descriptor passing
implementation that, AFAIK, still isn't fixed. Various signal handling
properties are more buggy than on Linux.

~~~
udp
TCP_NOPUSH is broken, too - if you enable it and then later disable it with
setsockopt, it doesn't immediately send any pending data (as it does on
FreeBSD, and as TCP_CORK does on Linux).

IIRC, a lot of their code came from FreeBSD back in the day. I wonder why they
didn't keep it in sync?

------
DanBC
Assuming for a moment that they're right:

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
> 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?)

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).

~~~
oconnore

        >> 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?)
    
        > Yes, you can start with the main Plan 9 paper:
        http://doc.cat-v.org/plan_9/4th_edition/papers/9
    

So, he asks about regular, ipad-toting, angry-birds-playing, how-do-I-turn-on-
my-printer users and you link to a technical paper containing buzzwords such
as "compilers", "internet gateways", "distributed systems", "POSIX", and
"remote procedure calls". Do you see the problem with this?

~~~
p9idf
The problem is that he thought the "regular users" referred to people who use
the operating system itself rather than your iPad users.

Do your regular iPad users understand Unix, iOS, BeOS, or OS/2? No, they
don't. They understand point and click interfaces on top of them. The
operating system is irrelevant to people who want to Play Angry birds. Users
who can't turn on their printer are irrelevant to a discussion on the merits
of one operating system over another. The user interface on top the system and
its programs is a separate topic.

~~~
oconnore
As a programmer, I can make my programs do whatever I please. If I want to
autosave all of my documents, I can write an Emacs script to save after every
hundred keypresses. If I want greater security, I can write a tool to encrypt
my files and network traffic, and a firewall to prevent unwanted connections.
If I want to sync my files over the net, I can write a dropbox-clone. If I
want to get better battery life, I can set my disk to spin down, reduce my
screen brightness, or disable wireless. I am also more likely to know about
existing versions of these specialized tools, because it's me and my friends
who build them.

But as an "iPad user", I don't know any of that. If the feature isn't included
in the OS, "turtles all the way down" and enabled by default, then I will
never even know that such a thing is possible (and even if I did, wouldn't
know how to get it).

So it's really exactly for the non-expert users that OS development is so
important. Everyone else (and by that I mean the minority), is informed enough
to figure these things out no matter what OS you give them.

------
achompas
So this flies over my head a bit. Can someone explain why:

(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
(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.

~~~
enneff
'Rob Pike is one of the "original neckbeards" that worked on Unix'

Do you know that 'neckbeard' is a slur? It refers to someone who tries to grow
a beard but can only grow hair on below their jawline, which is typical of
adolescents.

FWIW, Rob has never had a beard. Ken, dmr, and bwk all have/had full beards,
not neckbeards.

I am kind of surprised to find myself writing this post, but here I am.

~~~
Confusion
I was under the distinct impression that 'neckbeard' had been reappropriated,
like 'nerd' and 'geek'.

~~~
enneff
Not to my knowledge. It doesn't make much sense.

~~~
lmkg
I think "neckbeard" may have gotten confused with "greybeard," which is used
to refer to the elders of ages since past, whom have bestowed upon us mortals
the eternally fecund gifts of unix, posix, C, etc.

------
mhd
Now we just need to get Niklaus Wirth complaining about ancient Unix'
complexity to close the circle…

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
When I was a teenager, my bubble only talks about Operating Systems: Linux,
BSD, Amiga. OSNews.com was the "it" place next to SlashDot.

It was fun back then.

I think I'm going to grab my time machine and warp back.

~~~
michaelchisari
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.

<http://haiku-os.org/>

------
metabrew
Wait, what? Is he saying symlinks are bad? I like symlinks.

~~~
jgrahamc
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.

~~~
billswift
I tried using hard links back in the late nineties when I was new to linux.
Instead of creating a second link to the file it copied the file to the new
directory. I discovered the problem when I modified one copy and found the
second copy, which was supposed to be a hard link, wasn't changed. I don't
know what went wrong, but with symlinks available, I just never bothered
trying hard links again.

ADDED: Note that I avoided hard links after that, because I was worried about
what would happen if I modified one file and deleted it, thinking it was a
link to another, when it was actually a copy. A person could lose a lot of
work if that happened. At least with a symlink, I know that something is or is
not a link.

~~~
bzbarsky
What probably happened there is that your editor helpfully broke the hardlink
for you. Some editors do that by default...

------
mmahemoff
"(It appears you cannot link to comments in G+…so I’ll just leave this
screenshot)"

Pity.

~~~
seclorum
Too bad the comments aren't just exposed as a file descriptor somewhere ..

~~~
franksalim
Or a URL.

------
nwmcsween
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.

------
jmderm
I don't quite understand the reason for thinking BSD sockets are horrible?

~~~
tsuyoshi
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.

------
jberryman
A G+ post of an image of someone's comment about someone's rant. Can we be
done with this "topic" please?

~~~
dextorious
Yes, because the origin and presentation of the comment matters so much more
than the contents of the comment itself, right?

------
peterwwillis
Oh look. And old operating system idealist is agreeing with a newbie that
everything's not the perfect way they want it.

I don't care.

Learn to use what you have or get something else and _stop fucking
complaining_. The End.

