21–30 of 150 posts
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…
Earlier quoted context omitted.
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 fam…
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 rea…
Earlier quoted context omitted.
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 fam…
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.
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.
Earlier quoted context omitted.
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
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.
I just realized that my most famous comment on HN is the same age as I was when I won the Putnam.
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…
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
I've always liked the end of the anti-foreword: > Here is my metaphor: your book is a pudding stuffed with apposite observations, many well-conceived. Like excrement, it contains enough undigested nuggets of nutrition to sustain life for some. But it is not a tasty pie: it reeks too much of contempt and of envy.
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…
To be fair, this could happen to any of us, especially early in career. But the real hubris is presuming that things are, as they are, without cause or reason. Along with never really knowing how things actually worked. Or why.
I envision a layperson (which is sort of understanding the author had of modern init systems, when starting on systemd). Said person walks up to a complex series of gears, and thinks a peg is just there for no reason, looks unused, and pulls it out. Only to have the whole mess go bananas. You can follow this logic with all of the half baked, partially implemented services like timekeeping, DNS, and others that barely work correctly, and go sideways if looked at funny.
I think if the author took their current knowledge, and this time wrote it from scratch, it could be far better.
However there still seems to be a chip on their shoulder, with an idea that "I'll fix Linux!" still, when in reality these fixes are just creating immense complication with very minimal upside. So any re-write would likely still be an over-complicated contraption.