Comment by musicale | Hacker News Reader

Comment by musicale | Hacker News Reader

Parent Full thread

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

Reads like it came straight out of the UNIX-HATERS Handbook, nice. (For those unfamiliar: https://web.mit.edu/~simsong/www/ugh.pdf)

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.

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.

Unfortunately many of those critics are as up to date as when the book was originally published.

> fortunately lots of that book is now obsolete

I have read and re-read it. I would, coldly and seriously, say that significantly less than 50% of it is obsolete.

Yes, some parts definitely are. Many of the specific technical details that are attacked are.

But the architectural points, the design points, the usability issues -- those mostly remain entirely valid.

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.

> its programmer focus makes it worse for non-programmers,

Oh well, no arguing with that, but since I am one, yay? :)

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.

It is a bit of both.

Also to note that outside FOSS circles worshiping UNIX, no one cares about said philosophy, including commercial UNIX vendors.

People rarely care about the underlying philosophy of anything - not even government, nowadays. They care about results and, fortunately, Unix still delivers for many.

When it come to govt - they don't even appear to care about the results.

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

https://go.dev/talks/2012/splash.article

Rob Pike on UNIX,

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

You are misinformed. 9front is not dead. Go's roots are Limbo and the ?c compiler suite from plan9. BTW, go runs on 9front.

> Plan 9 [...] was pronounced dead around a decade ago.

9front would like a word.

Come to that, R9 would too.

https://github.com/dancrossnyc/r9

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:

https://archive.fosdem.org/2024/schedule/event/fosdem-2024-3...

I read UHH over 30 years ago and learned a lot about UNIX. Very useful.

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

I don’t know enough about kernel development to agree or disagree but I am thoroughly entertained

Reply on news.ycombinator.com