> they match, more or less, those of UNIX's philosophy
1. Good design is innovative
UNIX innovated by simplifying Multics -
throwing away ring security and PL/I's memory safety features.
Linux innovated by cloning UNIX, giving it away for free,
and avoiding the lawsuit that sidelined BSD.
2. Good design makes a product useful
Yet somehow people managed to use UNIX anyway.
3. Good design is aesthetic
UNIX threw away clear, long-form command forms and kept
short, cryptic abbreviations like "cat" (short for "felis cattus")
and "wc" (short for "toilet").
Its C library helpfully abbreviates "create" as "creat",
because vowels are expensive.
4. Good design makes a product understandable
See #3
5. Good design is unobtrusive
That's why UNIX/Linux enthusiasts spend so much time
configuring their systems rather than using them.
6. Good design is honest
The UNIX name indicates it is missing something
present in Multics. Similarly, "Linux" is the
gender-neutralized form of "Linus".
7. Good design is long-lasting
Like many stubborn diseases, UNIX has proven hard to eradicate.
8. Good design is thorough down to the last detail
UNIX/Linux enthusiasts love using those details
to try to figure out how to get Wi-Fi, Bluetooth,
and GPU support partially working on their laptops.
9. Good design is environmentally-friendly
Linux recycles most of UNIX's bad ideas, and many
of its users/apologists.
10. Good design is as little design as possible
Linux beats UNIX because it wasn't designed at all.
UNIX haters handbook exists, because many of us don't worship at the fate of UNIX church.
Yes, it did some things right, but also did plenty of them bad, lets not worship it as the epitome of OS design, cloning it all the time without critical thinking.
Alone the fact that its creators went on to design Plan 9, Inferno, Alef, Limbo and Go, shows even they moved on to better approaches.
The UNIX Hater's Handbook is not about hate against the UNIX philosophy but about frustrations with inconsistencies and idiosyncrasies in UNIX implementations. I have often seen people confusing the idea of UNIX philosophy and various UNIX implementation details (not the implementation of its philosophy but of mundane concepts like printing or the use of /usr), and then using these implementation details as strawman arguments against the philosophy.
People rarely care about the underlying philosophy of anything - not even government, nowadays. They care about results and, fortunately, Unix still delivers for many.
Granted, fortunately lots of that book is now obsolete and mostly just good for laughs about the bad old times. And most of the predictions it had about future innovation never turned out that way either.
The usability issues are mostly "I'm used to X, so I don't like Y".
I've started out on dos, then went from win3.11 to XP/7 and switched to Linux fully when 8 came out. They all suck in their own ways, but nowadays I just prefer Linux because it has become "it just works" for me. Mostly. Because while there is the occasional technical issue with some software or hardware, I personally just prefer the technical problems of Linux over the bullshit problems over on windows. Edge jumping in your face, the "office key", updates interrupting when you don't want them, ads in my start menu, telemetry, major UI changes between versions that seem half-baked and take a decade to be completed,...)
I feel the same with Win7 - for me "it just works" and I don't want to upgrade for as long as possible. I even don't install updates - especially since several of them contain telemetry. I simply don't have the time to fight with Linux. There were other good OSes (e.g. BeOS or OS/2) which were simply killed instead of open-sourcing the code. Haiku seems to be the successor of BeOS but it has too few donations.
You can support them by buying merch. I got a Haiku tshirt last year. I bought it purely to support out of nostalgia (I was on MacOS when Be was making waves and installed it to kick the tires once).
I am broadly from the same tech background, but a decade earlier. (ZX Spectrum and CP/M at home, then DOS at work; "I switched to Linux when XP came out.)
But I disagree with:
> The usability issues are mostly "I'm used to X, so I don't like Y".
I think that's true of some of them, but the usability issues of Unix and C are real, its programmer focus makes it worse for non-programmers, and its legendary lack of user friendliness hasn't changed over the decades -- it's just been wrapped in shiny GUIs.
> Alone the fact that its creators went on to design Plan 9, Inferno, Alef, Limbo and Go, shows even they moved on to better approaches.
I think you're confusing "different" with "better", and you're confusing someone'small almost personal experiments implemented as proof-of-concept projects as actually being improvements.
I mean, Plan 9 was designed with a radical push for distributed computing in mind. This is not "better" than UNIX's design goals, just different.
Nevertheless, Plan 9 failed to gain any traction and in practice was pronounced dead around a decade ago. In the meantime, UNIX and Unix-like OSes dominate the computing world still up to this day. How does that reflect in your "better approaches" assertion?
The argument on the Go programming language is particularly perplexing. The design goal of Go has nothing to do with the design goal of C. Their designers were very clear in how their design goals was to put together a high-level programming language and tech stack designed to improve Google's specific problems. This wasn't C's design requirements, were they?
> We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy.
Go is basically Limbo in a new clothing, Limbo took up the lessons on Alef's design failure.
They could have designed their C++ wannabe replacement in many other ways.
If anyone were brave enough to grasp the nettle, I proposed a fairly simple doable set of changes that could make it more useful in this talk last year:
A classic that needs to be updated for the modern (hellish) macOS/Linux/WSL/BSD/Dockernetes era, but it is still (or should be) an inspiration to us all.
Abbreviating create as 'creat' is a bit stupid but it is the kind of quirk that makes me feel at home. The opposite can be found here: https://devblogs.microsoft.com/scripting/weekend-scripter-us... . That is a world where well... I have switched jobs once specifically to get out of that world....
Unconfirmed speculation: The linker at the time ignored letters past the first 6. The compiler prefixed the symbols with '_' to namespace them, to separate user code vs compiler internals. People started writing only the part that mattered. Since either short or long name worked, it wasn't a hard rule that everything had to be shortened, but that still tended to happen. https://news.ycombinator.com/item?id=34814268
