Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unix-Haters Handbook (1994) [pdf]

simson.net

Post reply on HN
Print view View original

61–70 of 150 posts

Re: The Unix-Haters Handbook (1994) [pdf]

#61

Post by kragen »

moomin wrote: post #52

I have a hard copy of this from back in the day. It’s a great read and a mixture of historical artefact and still relevant criticism. e.g. It’s really interesting reading about LISP machines but no-one’s building a new one. Equally, all the criticism of sendmail and csh is valid but no-one uses them anymore either. Most of the reliability criticisms have been addressed over the years but people are still trying to ad…

Yeah, I learned an enormous amount from it when I encountered it (in hard copy of course) in 01996, and some of what I learned is now no longer relevant.

There are some people building new Lisp machines: https://opencores.org/projects/igor https://github.com/lisper/cpus-caddr https://interlisp.org/ http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/VLM.html https://github.com/dseagrav/ld http://www.aviduratas.de/lisp/lispmfpga/ https://groups.google.com/g/comp.lang.lisp/c/36_qKNErHAg https://frank-buss.de/lispcpu/

Also, Morello includes some Lisp-machine-like features. In my view knowing about the history of hardware architectures is far more important for designing new ones than for reproducing old ones.

Re: The Unix-Haters Handbook (1994) [pdf]

#62

Post by ok123456 »

coreyh14444 wrote: post #9

As someone in the midst of transitioning to Linux for the first time ever, the thing is: I still kinda hate Unix, but my AI friends (Claude Code / Codex) are very good at Unix/Linux and the everything is a file nature of it is amenable to AI helping me make my OS do what I want in a way that Windows definitely isn't.

The problems of commercial Unix in 1993 are totally different from Linux in 2025.

Re: The Unix-Haters Handbook (1994) [pdf]

#63

Post by atoav »

op00to wrote: post #54
atoav wrote: post #37

Earlier quoted context omitted.

Afaik one of the main problem with the software of his is that it tends to sacrifice ergonomics in the 99% common cases for some obscure theoretical observation. This is of course about tradeoffs and about the complexities of the problems you're solving, but his software is full of choices that only make sense if you priorize elegant code over elegant software only to then grow into something that is neither.

Lennart worked at Red Hat when he was developing systemd. Red Hat's largest customers often have wacky, weird requirements that you would have never thought of unless you were in that specific customer's situation.

Good point.

Re: The Unix-Haters Handbook (1994) [pdf]

#64

Post by SSLy »

skydhash wrote: post #56
atoav wrote: post #36

Earlier quoted context omitted.

I parsed (2) in the obvious way of: A manual should start with the common stuff 99% of people need and not with something obscure that you will only need once you are at the level that you know the tool you're using inside out. That is like opening the manual for your dishwasher and reading a section about how you may check the control-boards conformal coating after the warranty has expired. Useful when you need it a…

That’s a tutorial or a getting started guide. The manual is a memory helper, like a tiny encyclopedia, not a teaching material.

tutorial vs reference https://diataxis.fr/

Re: The Unix-Haters Handbook (1994) [pdf]

#65

Post by bostik »

hulitu wrote: post #28
cyberax wrote: post #5

I want to write a systemd haters handbook. Like: 1. You start and stop services with 'systemctl start/stop nginx'. But logs for that service can be read through an easy-to-remember 'journalctl -xeu nginx.service'. Why not 'systemctl logs nginx'? Nobody knows. 2. If you look at the built-in help for systemctl, the top-level options list things like `--firmware-setup` and `--image-policy`. 3. systemd unifies devices, m…

> I want to write a systemd haters handbook. Why ? Systemd really fits the Unix haters handbook. It is anti unix as much as it can be ( one command to rule them all, binary logs, etc). In the end it realy seems that the mantra: GNU is not UNIX is true. Just look at the GNU/Linux: pulseaudio, systemd, polkit, wayland, the big, fat linux kernel

For a brief period of time, binary configs[0] were a thing. In mobile world only, but still. It wasn't that people generally wanted them, but because random seek I/O latency on early mobile devices (and especially on their eMMC storage devices) was atrocious.

Opening up tens or hundreds of XML config files for resync was disgustingly slow. I've developed software on Maemo and Scratchbox; the I/O wait for on-device config changes was a real problem. So of course someone came up with a modified concept of Windows registry - a single, binary format config storage, with a suitably "easy" API. As a result you'd sacrifice write/update latency for the cases where you wanted to modify configurations and gain a much improved read/refresh latency when reading them up.

Of course that all broke down when reading a single config block required to read the entire freaking binary dump and the config storage itself was bigger than the block device cache. Turns out that if you give app developers a supposedly easy and low-friction mechanism to store app configs, their respective PMs would go wild and demand that everything is configurable. Multiply by tens, even low hundreds of apps, each registering an idle-loop callback to re-read their configs to guarantee they would always have the correct settings ready. A system intended to improve config load/read times ended up generating an increased demand for already constrained read I/O.

0: https://wiki.gnome.org/Projects/dconf

Re: The Unix-Haters Handbook (1994) [pdf]

#66

Post by atoav »

skydhash wrote: post #56
atoav wrote: post #36

Earlier quoted context omitted.

I parsed (2) in the obvious way of: A manual should start with the common stuff 99% of people need and not with something obscure that you will only need once you are at the level that you know the tool you're using inside out. That is like opening the manual for your dishwasher and reading a section about how you may check the control-boards conformal coating after the warranty has expired. Useful when you need it a…

That’s a tutorial or a getting started guide. The manual is a memory helper, like a tiny encyclopedia, not a teaching material.

How does that change my point about an order by frequency of use being superior? If it is a memory helper, then the stuff people tend to use more often is certainly the stuff that needs to be looked up more.

Re: The Unix-Haters Handbook (1994) [pdf]

#67

Post by lakkal »

simonh wrote: post #24
cm2187 wrote: post #22

Earlier quoted context omitted.

But also ww2 is this black and white thing from our history books. As we get older we get to know more about how recent and relevant it is, we met people who lived it and told us about their actual experience. But it still feels like something that belongs to history rather than a recent event. That's kind of the "anything that happened before my birth I don't care" attitude of today's teenagers.

I'm a Brit born in 66, and growing up I felt that WW2 was recent history. War films were a dominant genre in my early life, we visited the German defences on the French coast while camping as a teenager along with my Grandfather, who served there and visited some locations he remembered. Some buildings still had war damage. In many ways the world of the 70s felt closer to the war era than to nowadays. It was still th…

That's interesting. I was also born in 1966, but in the US. WW2 didn't seem/feel all that recent to me, probably because it had mostly happened far away. I was interested in learning about it and read lots of books, and watched movies. The drive to visit relatives did go by an aircraft carrier (USS Essex) at the scrapyard, but other than that physical artifacts of the war were rare. And the only relative I had who fought in the war was a great-uncle, but he passed away when I was very young.

Re: The Unix-Haters Handbook (1994) [pdf]

#68

Post by drweevil »

moomin wrote: post #52

I have a hard copy of this from back in the day. It’s a great read and a mixture of historical artefact and still relevant criticism. e.g. It’s really interesting reading about LISP machines but no-one’s building a new one. Equally, all the criticism of sendmail and csh is valid but no-one uses them anymore either. Most of the reliability criticisms have been addressed over the years but people are still trying to ad…

> Equally, sh remains a problematic scripting language but at least it’s reliably there

I too still have a hard copy of this from way back. This book was my introduction to Unix, as I shifted from programming for DOS/Windows/NT to SunOS, and later, Linux. Despite the many issues (humorously) exposed by this book, the one thing that hooked me is what that quote above implies: It was accessible, durable, and thus worth taking the time to learn, warts and all.

Re: The Unix-Haters Handbook (1994) [pdf]

#69

Post by fuzztester »

pjmlp wrote: post #44
tankenmate wrote: post #33

Earlier quoted context omitted.

Some GOSIP (remember that?) implementations on some Unicies did have files for network connections, but it was very much in the minority. Since BSD was the home of the first widely usable socket() implementations for TCP/IP it became the norm; sockets are a file, but just not linked to any filesystem and control is connect()/accept() and the networking equivalent (setsockopt()) of the Unix system call dumping ground;…

I don't remember any of the ones I used having it, or then I missed it. Kind of, sockets don't do seek().

Psst - don't tell().

Re: The Unix-Haters Handbook (1994) [pdf]

#70

Post by op00to »

atoav wrote: post #63
op00to wrote: post #54

Earlier quoted context omitted.

Lennart worked at Red Hat when he was developing systemd. Red Hat's largest customers often have wacky, weird requirements that you would have never thought of unless you were in that specific customer's situation.

Good point.

It doesn't mean the requirements and solutions aren't wacky, weird, or inscrutable though.
Post reply on HN