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

51–60 of 150 posts

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

#51

Post by AnonymousPlanet »

dizhn wrote: post #23
kloud wrote: post #12

Earlier quoted context omitted.

+1 I think such writing would find its audience. What I would like to see is something that is to systemd what PipeWire is to PulseAudio. Before PulseAudio getting audio to work properly was a struggle. PA introduced useful abstractions, but when it was rolled out it was a buggy mess. Eventually it got good over time. Then PipeWire comes in, and it does more with less. The transition was so smooth, I did not even rea…

systemd and pulseaudio are by the same guy (avahi too). He just writes shit software that sort of works.

There's a podcast [1], which features him as a guest to talk about Linux in general. The main impressions I got from it: he is very confused about what UNIX is and he apparently despises UNIX.

I think he's well suited for his new employer (Microsoft).

[1] (in German) https://cre.fm/cre209-das-linux-system

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

#52

Post by moomin »

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 address the design of C, usually by replacing it. Equally, sh remains a problematic scripting language but at least it’s reliably there, unlike many of its many alternatives.

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

#53

Post by op00to »

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 like systemd too. After working with it for a long time, a lot of the "wtf" moments eventually are made clear as having at least some semblance of a good reason behind the decision.

1. systemctl is the controller. Its job is to change and report on the state of units. journalctl is the query engine. Merging the query engine into the systemctl controller would make the controller bloated and complex, so a dedicated tool is the cleaner approach. I think you can also rip out the journal and use other tools if you so decide, making building logs into systemctl a bad idea.

2. systemd is a system manager, not just a service manager. It replaced not only the old init system but also a collection of other tools that managed the machine's core state

3. A service runs a process, which can fail for many transient reasons. Trying again is a sensible and effective recovery strategy. A mount defines a state in the kernel. If it fails, it's almost always for a "hard" reason that an immediate retry won't fix. Retrying a failed mount would just waste time and spam logs during boot.

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

#54

Post by op00to »

atoav wrote: post #37
kloud wrote: post #32

Earlier quoted context omitted.

Also he has no regards for breaking userspace to the point of needing to get scolded by Linus. But some ideas are good and there is a lot of pioneering work that moves the needle. The trajectories of PulseAudio and systemd are similar, it just needs cleaning up. PulseAudio got fixed up by PipeWire, whereas systemd is at the point of lifecycle yet to reach that stage.

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.

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

#55

Post by skydhash »

anthk wrote: post #40

We need, OTOH, the other side of the coin: The EMACS hater handbook. Under a GFDL license, of course. No multithreading, I/O locks under GNUs/eww, glacial slow email header parsing under GNUs, huge badass file for RMAIL if you don't like GNUs (instead of parsing MailDir) and so on.

I have no real experience with mbox and pop3 (maildir is what I’ve always used). But I still think you would need to partition mbox files because that’s what you would do with physical mail (which is the basis of the protocol and everything around it). I kinda like rmail.

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

#56

Post by skydhash »

atoav wrote: post #36
e-khadem wrote: post #17

Earlier quoted context omitted.

These are fine points, and there are rough edges, but: 1. `systemctl status nginx.service` suffices in many cases. journalctl is for when you need to dig deeper, and it demands many more options. You would have complained about "too noisy CLI arguments" if these were unified. 2. I am not sure about how I should parse this. You mean there are too many arguments in total (2a) or the man page or the help message is not…

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.

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

#57

Post by xandrius »

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…

All those points could be fixed with a wrapper "systemd2" but I definitely see your points.

I like thinking of the minimum set of changes required to fix a problem and this could help, you probably could LLM most of it in less than 30min.

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

#58

Post by skydhash »

kloud wrote: post #45
b112 wrote: post #30

Earlier quoted context omitted.

The inconsistency comes from the author thinking "All this init stuff is ancient, and filled with absurd work arounds, hacks, and inconsistencies. I'll fix that!". Then as time passes discovering that "Oh wait, I should add a hack for this special case, and this one, and this one, guess these were really needed!" as bug reports come in over the years. To be fair, this could happen to any of us, especially early in ca…

When a complex system cannot be meaningfully reduced, another approach might be trying to reduce scope. Current areas include managing services on a server, managing a single-user laptop, and enterprise features for fleet of devices/users. There is some overlap at the core where sharing code is useful, but it feels way more complexity than needed gets shipped to my laptop. I wonder how much could be shaved off when f…

I like openrc for laptop or workstation. Writing service is as easy as writing a systemd files (with less options of course, but I never really wanted those).

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

#59

Post by lizknope »

ferguess_k wrote: post #39

As a side point, I believe David Cutler, the venerable OS engineer who programmed and designed three OSes, did not like Unix very much back in the 90s. I wonder what was the reason, and did he change his mind later?

The only thing I remember is from the book Showstopper

https://retrocomputing.stackexchange.com/questions/14150/how...

[Cutler] expressed his low opinion of the Unix process input/output model by reciting "Get a byte, get a byte, get a byte byte byte" to the tune of the finale of Rossini's William Tell Overture.

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

#60

Post by TrackerFF »

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.

Having observed my fair share of beginners transition from win to linux, the most common source of pain I've seen is getting used to the file permissions, and playing fast and loose with sudo.
Post reply on HN