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

11–20 of 150 posts

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

#11

Post by cm2187 »

microtonal wrote: post #4
tomhow wrote: post #2

Discussed a little, previously... The Unix-Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=40110729 - April 2024 (87 comments) The Unix-Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=38464715 - Nov 2023 (139 comments) The Unix-Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=31417690 - May 2022 (86 comments) The Unix-Haters Handbook (1994) [pdf] - https://ne…

As an aside: Hacker News is getting old, the 2008 discussion is closer to the book’s year (1994) than it is to now.

And for the millennials: compare the distance between your birth and ww2 vs your birth and now!

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

#12

Post by kloud »

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…

+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 realize it I had been running it for a while, just one day I noticed it in the update logs.

systemd now works well enough, but it would be nice to get rid of that accumulated cruft.

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

#13

Post by gunnihinn »

cm2187 wrote: post #11
microtonal wrote: post #4

Earlier quoted context omitted.

As an aside: Hacker News is getting old, the 2008 discussion is closer to the book’s year (1994) than it is to now.

And for the millennials: compare the distance between your birth and ww2 vs your birth and now!

Thanks, I hate it.

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

#14

Post by swatson741 »

They certainly came up with a lot of good one-liners for this book.

I wonder why Dennis Ritchie was so infuriated though. He criticizes them for wanting simple functionality, but it's not because language is a powerful tool for solving problems it's because it limits the potential of the platform to it's functionality (which has been simplified and in of itself limited).

So this is confusing to me. Using language to solve problems is the advantage that Unix offers. But, neither the authors nor Dennis care about this? Or they do care in limited ways, but ultimately it's about something else?

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

#16

Post by pjmlp »

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.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently.

If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

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

#17

Post by e-khadem »

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…

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 ordered correctly (2b)?

(2a). If you just care about services, you already know [well] a handful of subcommands (start, stop, enable, etc.) and just use those, the other args don't get in your way. For example your everyday commands have safe, sane default options that you will not have to override 99% of the time.

Furthermore, this is much better than the alternative of having a dozen different utilities that have a non-trivial inter-utility interaction that has to be solved externally. Sometimes an application that does (just) one thing won't do well.

(2b). This is subjective (?). I have experienced a few week-long total internet outages (in Iran). I had to study the man pages and my offline resources in those contingencies, and have generally been (extremely) satisfied with the breadth, depth, and the organization of the systems docs. In the age of LLMs this is much less of a problem anyways. I think reading the man page of a well-known utility is not an everyday task, and for a one-off case you will grep the man page anyways.

3. Your point is ~valid. But automount exists for ephermal resources. By default, we won't touch a failing drive without some precautions at least. So fail-fast and no retry is not always wrong. Perhaps it is virtue signaling ... On my PC I don't want to retry anything if a mount fails. In fact I might even want it to fail to boot so that it doesn't go undetected.

Also, for something as critical as mounting, I would probably want other "smart" behavior as well (exponential backoff for network, email, alert, DB fail-over, etc.) and these require specific application knowledge.

So ... they are trying to prevent a foot gun.

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

#18

Post by darkwater »

cm2187 wrote: post #11
microtonal wrote: post #4

Earlier quoted context omitted.

As an aside: Hacker News is getting old, the 2008 discussion is closer to the book’s year (1994) than it is to now.

And for the millennials: compare the distance between your birth and ww2 vs your birth and now!

I was exactly thinking this the other day while running and seeing an old, rusted lamp post in a rural street: "this was probably put there over 50 years ago, in the early seventies", and then thought at things from "over 50 years ago" when I was a child and well, WW2 was in its making. I don't know while I thought that but that's probably also a sign of our age: WW2 was the biggest thing "from the past" that our families lived or were touched more or less directly.

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

#19

Post by dark-star »

pjmlp wrote: post #16
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.

On UNIX the "everything is a file" quickly breaks down, when networking, or features added post UNIX System V get used, but the meme still holds apparently. If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.

Yeah, I was really confused when I learned that every device was simply a file in /dev, except the network interfaces. I never understood why there is no /dev/eth0 ...

That was back in the mid-90s but even today I still don't understand why network interfaces are treated differently than other devices

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

#20

Post by darkwater »

e-khadem wrote: post #17
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…

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…

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

I'm not at all a systemd hater (I think it was needed and it's nowadays a very solid piece of software) but the logs thing should be totally tweakable when viewing it from `systemctl status` and it is n.... [goes to check the man page]

  -n, --lines=
           When used with status, controls the number of journal lines to show, counting from the most recent ones. Takes a positive integer argument, or 0 to disable journal output. Defaults to 10.
Oooh, so TIL.
Post reply on HN