Huh. I forgot Don Norman wrote the foreword.
The Unix-Haters Handbook (1994) [pdf]
31–40 of 150 posts
Re: The Unix-Haters Handbook (1994) [pdf]
#32Earlier 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.
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.
Re: The Unix-Haters Handbook (1994) [pdf]
#33As 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.
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; ioctl().
Re: The Unix-Haters Handbook (1994) [pdf]
#34Earlier 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…
As a German born in 87, it didn't feel _that_ recent any more. But it was definitely close, both my granddads served in the war and were scarred for life by that, mentally and physically. Family history a mess of war-torn biographies. I found some rusted, old big munition in the forest as a kid. Old bunkers and flak towers can still be seen in the cities, and many of the local kids in my hometown and age cohort adventured into the old mining shaft used as an air raid shelter and saw the gas masks that were still there. And then there was the GDR (or DDR, Deutsche Demokratische Republik, in German) and all the reunification that happened when I was already alive (although I was a child at the time).
Thinking about my childhood visit to Ost-Berlin still makes me shiver with thoughts about all the suffering. Many of the buildings still had bullet holes and it felt like you could touch history.
Re: The Unix-Haters Handbook (1994) [pdf]
#35Earlier 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.
[deleted]
Re: The Unix-Haters Handbook (1994) [pdf]
#36I 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…
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 and have the repair skills, but a bad way to start a manual.
Re: The Unix-Haters Handbook (1994) [pdf]
#37Earlier quoted context omitted.
systemd and pulseaudio are by the same guy (avahi too). He just writes shit software that sort of works.
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.
Re: The Unix-Haters Handbook (1994) [pdf]
#38Discussed 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…
Anyone who thinks that that is a lot should see how much it, and of course the mailing list, were brought up on Usenet in the 1990s. (-:
Re: The Unix-Haters Handbook (1994) [pdf]
#39As 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?
Re: The Unix-Haters Handbook (1994) [pdf]
#40We 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.