"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."
.. oh wait.
It is rather that good design make you popular and not so good design doesn't.
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?
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.
IIRC, a lot of their code came from FreeBSD back in the day. I wonder why they didn't keep it in sync?
One of the great things about Plan 9 is that everything implements the same interface. If you can interact with one thing, you can interact with everything. Using new parts of the system becomes obvious because you already know the interface.
A concrete example of why this works: In Plan 9, process information is available via (guess what) the file system, so the Plan 9 debugger just reads the state of running processes from those files. Because file systems are automatically exported over the network (also part of the file system), you can debug a running process on another machine without the debugger knowing anything about the network. Nobody had to implement network debugging - it just worked right away because of good design.
You know you have a good design when these kinds of complex behaviors just "fall out" without any additional work.
It is just that the end users are different people to the ones on Mac (and would indeed usually be power users or developers there).
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?
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...).
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.
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…
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)?
Let's cut to the chase: Why would you have a textbox and a specific site for what amounts to a simple discussion? There's really no big conceptual reason why we couldn't do this via email, nntp or some similar protocol.
Leaving that aside, the more difficult question is how you'd get the textbox on your screen, i.e. what's the "True Unix" way of "web browsing"? There aren't that many examples of a rather graphical, highly interactive programs that believers would classify as really Unix-like. Maybe something roff-like, where you have a pretty universal display language and different (server-side?) tools are used to create something that would be too hard to express in the language as is (cf. tbl, pic), but then how would you make that interactive without doing the same stuff as HTML/CSS/JS? I was quite fond of the concept of NeWs, where you'd distribute your application over the net as PostScript, and I think Pike's Newsqueak went in a similar direction.
And how would you handle things on the server side? I don't think it would be that much different from what we're doing now. HTTP is quite resource-oriented and thus maps closely to a file system (the path-like nature of URLs is no accident). A CGI/PHP model for simple "files" would suffice, and you could have an almost arbitrarily complex application that appears as a file system, just like you can have that now appearing as a bunch of HTTP resources. People wrote "big" C applications, even though they could've theoretically done it all with a bunch of shell scripts, awk and ed. The "one thing and one thing only" mantra never was that religiously adhered to.
So, in conclusion, I don't think we're that far off right now, especially on the server side. If you look at what Pike's complaining about, it's mostly how you do it. Quite often the wheel is needlessly reinvented or has too many spokes, it's not that driving somewhere is wrong.
I'd argue that our current system is closer to "Unix" than it would be too Lisp Machines, Smalltalk and other more homogenous systems.
It's basically the model for CGI scripts.
By the way, Plan 9 doesn't have sockets, it has /net: 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
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.
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.