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.
> 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.
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?
It was because adding one to each of the letters in UNIX yields gibberish, but adding one to each of the letters in VMS gets WNT.
Era-appropriate joking aside: There's no actual evidence that Cutler held the views on Unix, or even on DEC's Eunice, that have been ascribed to xem from anecdotes by Armando Stettner and edits to Wikipedia and writing by G. Pascal Zachary. I and others went into more detail on this years ago: https://news.ycombinator.com/item?id=22814012
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.
Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.
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().
I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good.
Haven’t googled yet what people had to say about that already before.
P.s. big fan of ur comments.
"We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that
UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX.
What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their
power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."
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
It's probably because ethernet and early versions of what became TCP/IP were not originally developed on Unix, and weren't tied to it's paradigms, they were ported to it.
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.
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, mounts, and services into unit files with consistent syntax. Except where it doesn't. For example, there's a way to specify a retry policy for a regular service, but not for mount units. Why? Nobody knows.
(To be clear, I _like_ systemd. But it definitely follows the true Unix philosophy of being wildly internally inconsistent.)
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 yuo 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.
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.
> 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.
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.
Systemd got better with time and I got better with it over time, which makes it acceptable for me now. I still miss SMF from Solaris years later though. I'm sure there are better systems out there but when the ubiquity is not there it's really hard to adopt them especially in corporate environments. And then you have to learn 2 things if you want to use something else at home, which is already too much for me...
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.
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.
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).
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 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.
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 focusing only on a single scenario.
> 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.
Don't forget the best one: "We don't support that uncommon use case, we will not accept nor maintain patches to support it, and you shoulden't do it that way anyway, and we are going to make it impossible in the future" -- to something that's worked well for decades.
I would like to subscribe to your newsletter... no but really if you ever do get around to writing that I want to read it. Ping me somehow, my Gmail username is the same as my HN username. Happy writing!
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
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?
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.
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 the cold war, and that was just an extension of the post-war stalemate.
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.
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.
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.
You forgot the last bit: "Bon appetite!"
Definitely the politest way anyone has ever been told to eat shit in human history.
Props for the inclusion of that in the book. "Mighty white of them", as they used to say in Bechuanaland.
My first instinct was that this phrase is racist, especially with you saying it was used in an ex-British southern African colony.
This was the best I could find as to its origins:
https://boards.straightdope.com/t/where-did-thats-mighty-whi...
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?
It was because adding one to each of the letters in UNIX yields gibberish, but adding one to each of the letters in VMS gets WNT.
Era-appropriate joking aside: There's no actual evidence that Cutler held the views on Unix, or even on DEC's Eunice, that have been ascribed to xem from anecdotes by Armando Stettner and edits to Wikipedia and writing by G. Pascal Zachary. I and others went into more detail on this years ago: https://news.ycombinator.com/item?id=22814012
Really? VOJY could easily be a modern company, couldn't it? The .dot was parked though ... :)
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.
Well it depends on what "file" means. Linuxian interpretation would be that file is something you can get file descriptor for. And then the "everything is a file" mantra holds better again.
Although many people nowadays misunderstand Linux for UNIX, it still isn't the same.
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().
I don't remember any of the ones I used having it, or then I missed it.
Kind of, sockets don't do seek().
I was recently thinking that object orientation is kind of everything is a file 2.0 in the form everything is an object I mean ofcourse didn’t pan out that good. Haven’t googled yet what people had to say about that already before. P.s. big fan of ur comments.
I actually read a decent paper on that a while back
Unix, Plan 9 and the Lurking Smalltalk
https://www.humprog.org/~stephen/research/papers/kell19unix-...
Late binding is a bit out of fashion these days but it really brings a lot of cool benefits for composition.
There is also an interesting from Xerox PARC,
"UNIX Needs A True Integrated Environment: CASE Closed"
http://www.bitsavers.org/pdf/xerox/parc/techReports/CSL-89-4...
For the TL;DR; crowd
"We 've painted a dim picture of what it takes to bring IPEs to UNIX. The problems of locating. user interfaces. system seamlessness. and incrementality are hard to solve for current UNIXes--but not impossible. One of the reasons so little attention has been paid to the needs of IPEs in UNIX is that UNIX had not had good examples of IPEs for inspiration. This is changing: for instance. one of this article's authors has helped to develop the Small talk IPE for UNIX (see the adjacent story). and two others of us are working to make the Cedar IPE available on UNIX.
What's more. new UNIX facilities. such as shared memory and lightweight processes (threads). go a long way toward enabling seamless integration. Of course. these features don't themselves deliver integration: that takes UNIX programmers shaping UNIX as they always have--in the context of a friendly and cooperative community. As more UNIX programmers come to know IPEs and their power. UNIX itself will inevitably evolve toward being a full IPE. And then UNIX programmers can have what Lisp and Small talk and Cedar programmers have had for many years: a truly comfortable place to program."
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
It's probably because ethernet and early versions of what became TCP/IP were not originally developed on Unix, and weren't tied to it's paradigms, they were ported to it.
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 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, mounts, and services into unit files with consistent syntax. Except where it doesn't. For example, there's a way to specify a retry policy for a regular service, but not for mount units. Why? Nobody knows.
(To be clear, I _like_ systemd. But it definitely follows the true Unix philosophy of being wildly internally inconsistent.)
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 yuo 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.
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.
> 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]
Oooh, so TIL.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.
Systemd got better with time and I got better with it over time, which makes it acceptable for me now. I still miss SMF from Solaris years later though. I'm sure there are better systems out there but when the ubiquity is not there it's really hard to adopt them especially in corporate environments. And then you have to learn 2 things if you want to use something else at home, which is already too much for me...
+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.
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.
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.
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
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 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.
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 focusing only on a single scenario.
> 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.
Don't forget the best one: "We don't support that uncommon use case, we will not accept nor maintain patches to support it, and you shoulden't do it that way anyway, and we are going to make it impossible in the future" -- to something that's worked well for decades.
I would like to subscribe to your newsletter... no but really if you ever do get around to writing that I want to read it. Ping me somehow, my Gmail username is the same as my HN username. Happy writing!
> 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
Huh. I forgot Don Norman wrote the foreword.
The only book I have that came with a barf bag. More books should do this.
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?
Thous shalt not write criticisms of a demigod!
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://news.ycombinator.com/item?id=19416485 - March 2019 (157 comments)
The Unix-Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=13781815 - March 2017 (307 comments)
The Unix-Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=9976694 - July 2015 (5 comments)
The Unix Haters Handbook (1994) [pdf] - https://news.ycombinator.com/item?id=7726115 - May 2014 (50 comments)
Anti-foreword to the Unix haters handbook by dmr - https://news.ycombinator.com/item?id=3106271 - Oct 2011 (31 comments)
The Unix Haters Handbook - https://news.ycombinator.com/item?id=1272975 - April 2010 (28 comments)
The Unix Hater’s Handbook, Reconsidered - https://news.ycombinator.com/item?id=319773 - Sept 2008 (5 comments)
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.
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 the cold war, and that was just an extension of the post-war stalemate.
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.
Thanks, I hate it.
I just realized that my most famous comment on HN is the same age as I was when I won the Putnam.
A sobering thought is that, when Mozart was my age, he had been dead for two years.--Tom Lehrer
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. (-: