7 ms·

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

by etrain 15y ago

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.

justincormack 15y ago
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.
- anatoly 15y ago
  Well, I'm not sure signalfd(2) was feasible back when signals were added. Was it? Today it's usual to structure your main() as some kind of select()-like loop; even if you don't need one for your main workflow, at the worst you can spawn an I/O thread and put it there. But back then, you didn't have threads. Lots of programs didn't read your input but still wanted to catch signals, e.g. to exit cleanly on kill -15. Many others read input, but without an event loop - they would just try to readchar() periodically when they had nothing else to do. Was there an obviously better design back then?
  - justincormack 15y ago
    An occasional readchar could be replaced with an occasional read to a signalfd. The problem is blocking calls, you need to not block for too long in case a signal arrives, which is more messy it is true.
    - ori_b 15y ago
      If you need to handle signals immediately, you can always put the signalfd reader into it's own thread.
    - caf 15y ago
      Blocking calls are not the problem - you simply block on select({stdin, signalfd}) instead of blocking on read(stdin). The problem rather is slow IO calls that nonetheless never block - the canonical example being a read() from a disk file. In this case (eg. /bin/tar) you would have to poll your signalfd after every read() - but this breaks the file abstraction for programs like /bin/cat that don't care whether the file descriptor they're reading from is the blockable type or not, so they'd have to do both. This is now starting to look considerably inelegant, and we haven't even talked about implementing the equivalent of synchronous signals provoked by a program's own action (SIGILL, SIGFPE, SIGSEGV, SIGBUS...).
mdellavo 15y ago
I absolutely agree with you. 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 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.
- mhd 15y ago
  The interesting bit here(I don't wanna say "problem"), is that we're actually a few steps further down this staircase of "let's ship". Unix wasn't exactly the purist ivory tower to begin with, then it merged with the partially compatible BSD, then we got some not-quite-Smalltalk GUIs on top of that, and now we're building elaborate web stacks on top (and/or instead) of that. And I don't even want to talk about mobile apps that in an almost unholy ceremony combine that again… It's a Babylonian tower made of mud (some would say camel poo). But it's brightly painted and has a good view, and all your friends live in it. Personally, I don't wanna move out either, but I still have to turn my head every time you see the paint come off somewhere…
  - DanBC 15y ago
    I'm not technical, but even I can appreciate some of the very many layers beneath my web-browsing. But, taking me typing into this text-box on HN as an example: What would the Unix way be? (If every tool does one thing and does it well, with text as input and output, and pipes to join it all together.) Would I really have an unholy long command-line of a bunch of tools piped together (but accessed by clicking an icon)?
    - hvs 15y ago
      No, the web server (one tool) would instantiate another tool (e.g. python/ruby/arc parser) which renders the HTML page pipes it back to the server which sends it to you. You fill out the form, press submit, the web server passes pipes those parameters back into the python/ruby/arc parser which ... etc. It's basically the model for CGI scripts.
    - 15y ago
adestefan 15y ago
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.
- uriel 15y ago
  And this is so sad. By the way, Plan 9 doesn't have sockets, it has /net: http://man.cat-v.org/plan_9/3/ip http://man.cat-v.org/plan_9/3/ip with the dial API built on top: http://man.cat-v.org/plan_9/2/dial http://man.cat-v.org/plan_9/2/dial This means that for example, Plan 9 applications that do networking are not tied to a specific network stack, you can mount multiple network stacks concurrently, you can have 'virtual' network stacks (for example running in user space and proxying to a remote host, or doing other neat tricks), and the apps don't need to care. Also when Ipv6 was added to the Plan 9 stack, no application code had to be modified, because the API nicely abstracts network addresses.
- yxhuvud 15y ago
  I'm curious: What is the alternative?
  - quadhome 15y ago
    http://en.wikipedia.org/wiki/STREAMS http://en.wikipedia.org/wiki/STREAMS
nicolaus 15y ago
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 http://kerneltrap.org/node/11
- uriel 15y ago
  That is a somewhat silly comment from Linus given that ken and rob designed and built Plan 9 together. (For example, ken designed UTF-8 while rob helped write the code: http://doc.cat-v.org/bell_labs/utf-8_history http://doc.cat-v.org/bell_labs/utf-8_history )
- yxhuvud 15y ago
  Yes, like Apple. .. oh wait. It is rather that good design make you popular and not so good design doesn't.
  - william42 15y ago
    Apple's internal design was a mess pre-OSX though. Still kind of is. Apple's praised for end-user interface design.
    - uriel 15y ago
      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 15y ago
        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?

by etrain 15y ago

justincormack 15y ago

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.

anatoly 15y ago
Well, I'm not sure signalfd(2) was feasible back when signals were added. Was it? Today it's usual to structure your main() as some kind of select()-like loop; even if you don't need one for your main workflow, at the worst you can spawn an I/O thread and put it there. But back then, you didn't have threads. Lots of programs didn't read your input but still wanted to catch signals, e.g. to exit cleanly on kill -15. Many others read input, but without an event loop - they would just try to readchar() periodically when they had nothing else to do. Was there an obviously better design back then?
- justincormack 15y ago
  An occasional readchar could be replaced with an occasional read to a signalfd. The problem is blocking calls, you need to not block for too long in case a signal arrives, which is more messy it is true.
  - ori_b 15y ago
    If you need to handle signals immediately, you can always put the signalfd reader into it's own thread.
  - caf 15y ago
    Blocking calls are not the problem - you simply block on select({stdin, signalfd}) instead of blocking on read(stdin). The problem rather is slow IO calls that nonetheless never block - the canonical example being a read() from a disk file. In this case (eg. /bin/tar) you would have to poll your signalfd after every read() - but this breaks the file abstraction for programs like /bin/cat that don't care whether the file descriptor they're reading from is the blockable type or not, so they'd have to do both. This is now starting to look considerably inelegant, and we haven't even talked about implementing the equivalent of synchronous signals provoked by a program's own action (SIGILL, SIGFPE, SIGSEGV, SIGBUS...).

mdellavo 15y ago

I absolutely agree with you. 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 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.

mhd 15y ago
The interesting bit here(I don't wanna say "problem"), is that we're actually a few steps further down this staircase of "let's ship". Unix wasn't exactly the purist ivory tower to begin with, then it merged with the partially compatible BSD, then we got some not-quite-Smalltalk GUIs on top of that, and now we're building elaborate web stacks on top (and/or instead) of that. And I don't even want to talk about mobile apps that in an almost unholy ceremony combine that again… It's a Babylonian tower made of mud (some would say camel poo). But it's brightly painted and has a good view, and all your friends live in it. Personally, I don't wanna move out either, but I still have to turn my head every time you see the paint come off somewhere…
- DanBC 15y ago
  I'm not technical, but even I can appreciate some of the very many layers beneath my web-browsing. But, taking me typing into this text-box on HN as an example: What would the Unix way be? (If every tool does one thing and does it well, with text as input and output, and pipes to join it all together.) Would I really have an unholy long command-line of a bunch of tools piped together (but accessed by clicking an icon)?
  - hvs 15y ago
    No, the web server (one tool) would instantiate another tool (e.g. python/ruby/arc parser) which renders the HTML page pipes it back to the server which sends it to you. You fill out the form, press submit, the web server passes pipes those parameters back into the python/ruby/arc parser which ... etc. It's basically the model for CGI scripts.
  - 15y ago

adestefan 15y ago

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.

uriel 15y ago
And this is so sad. By the way, Plan 9 doesn't have sockets, it has /net: http://man.cat-v.org/plan_9/3/ip http://man.cat-v.org/plan_9/3/ip with the dial API built on top: http://man.cat-v.org/plan_9/2/dial http://man.cat-v.org/plan_9/2/dial This means that for example, Plan 9 applications that do networking are not tied to a specific network stack, you can mount multiple network stacks concurrently, you can have 'virtual' network stacks (for example running in user space and proxying to a remote host, or doing other neat tricks), and the apps don't need to care. Also when Ipv6 was added to the Plan 9 stack, no application code had to be modified, because the API nicely abstracts network addresses.
yxhuvud 15y ago
I'm curious: What is the alternative?
- quadhome 15y ago
  http://en.wikipedia.org/wiki/STREAMS http://en.wikipedia.org/wiki/STREAMS

nicolaus 15y ago

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 http://kerneltrap.org/node/11

uriel 15y ago
That is a somewhat silly comment from Linus given that ken and rob designed and built Plan 9 together. (For example, ken designed UTF-8 while rob helped write the code: http://doc.cat-v.org/bell_labs/utf-8_history http://doc.cat-v.org/bell_labs/utf-8_history )
yxhuvud 15y ago
Yes, like Apple. .. oh wait. It is rather that good design make you popular and not so good design doesn't.
- william42 15y ago
  Apple's internal design was a mess pre-OSX though. Still kind of is. Apple's praised for end-user interface design.
  - uriel 15y ago
    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 15y ago
      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?