> 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.
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 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.
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.
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.
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.
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 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 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.
Pretty much all of the benefits provided by the hardware of lisp machines are provided by modern CPUs, just in more general ways.
Most of the benefit was pushing their interpreter into microcode, leaving more of the data bus free for actual data. Now we have ubiquitous icaches which give you a pseudo harvard architecture when it comes to the core's external bandwidth.
Some of the benefit was having a separate core with it's own microcode doing some of the garbage collection work. Now we have ubiquitous general multicore systems.
> Equally, sh remains a problematic scripting language but at least it’s reliably there
I too still have a hard copy of this from way back. This book was my introduction to Unix, as I shifted from programming for DOS/Windows/NT to SunOS, and later, Linux. Despite the many issues (humorously) exposed by this book, the one thing that hooked me is what that quote above implies: It was accessible, durable, and thus worth taking the time to learn, warts and all.
Yeah, I learned an enormous amount from it when I encountered it (in hard copy of course) in 01996, and some of what I learned is now no longer relevant.
Also, Morello includes some Lisp-machine-like features. In my view knowing about the history of hardware architectures is far more important for designing new ones than for reproducing old ones.
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.
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.
Lots (most) OSes had a process concept. But in Unix, they not only existed, they were everywhere, they were dynamic, and they were "cheap". They were user accessible. A process with its ubiquitous stdin/out interface gave us great composablilty. We can click the processes together like legos.
For example, VMS had processes. But after 4 years of using it, I never tossed processes around using it like I did on Unix. I never "shelled out" of an editor. I never & something into the background. Just never came up. One terminal, one process.
On Unix, however, oh yea. Pipe construct on the command line, bang out of the editor, :r! in vi. And the eco-system the was created out of this simple concept. The "Unix Way(tm)".
And anything was a process. A C program. A shell script. At this level, everything was a "system language".
Then, They (those Unix wizard folks) made networking a well behaved citizen in this process stdin/out world. `inetd` could turn ANYTHING (because everything had stdin/out) into a network server. This command is magic: `ls | cpio -ov | rsh otherhost cat > /dev/tape`
Does `ls` know anything about file archives? No. Does `cpio` know anything about networking, or tape drives? No. Heck, `cat` doesn't know anything about tape drives.
You just could not, back in the day, plumb processes and computers together trivially like you could with Unix. Humans could do this. They didn't need to be wizard status, "admins", guys in white coats locked in the raised floor rooms, huffing Halon on the side. Assuming you could grok the arcane syntaxes (which, absolutely, were legion), you could make Unix do amazing things.
This flexibility allowed me to make all sorts of Rube-Goldbergian constructs of data flows and processes. Unix has always been empowering, and not constraining, once you accept it for what it is.
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
[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.
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.
OK I have a question. I've been trying to track down a Unix book that was similar from that time period, covering command-line tools and shell programming. It had some funny cartoons in between the text. One particular cartoon featured a man who had spent too much time at the command line and was using single-word commands for everything, e.g. when he needed to send a letter he would point to it and say "MAIL" and when someone knocked on his door he would point to it and say "ENTER". Does anyone else remember that one?
Asked ChatGPT and it told me the book might be "The Unix Programming Environment". It happens that the second link on Google is a pdf so I took a brief look, but did not find any cartoon. I asked it a second time and it said "UNIX for the Impatient", which does look like the one but I didn't find any pdf. Hopefully it helps.
The good news is that we now have alternative UI's in web/mobile, microkernel-based systems, and unikernels in high-level languages... all in production use.
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?
floren|6 months ago
> 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.
EarlKing|6 months ago
Definitely the politest way anyone has ever been told to eat shit in human history.
B1FF_PSUVM|6 months ago
cyberax|6 months ago
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.)
op00to|6 months ago
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.
e-khadem|6 months ago
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.
bionsystem|6 months ago
kloud|6 months ago
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.
b112|6 months ago
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.
hulitu|6 months ago
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
xandrius|6 months ago
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.
dotancohen|6 months ago
moomin|6 months ago
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.
monocasa|6 months ago
Most of the benefit was pushing their interpreter into microcode, leaving more of the data bus free for actual data. Now we have ubiquitous icaches which give you a pseudo harvard architecture when it comes to the core's external bandwidth.
Some of the benefit was having a separate core with it's own microcode doing some of the garbage collection work. Now we have ubiquitous general multicore systems.
Etc.
drweevil|6 months ago
I too still have a hard copy of this from way back. This book was my introduction to Unix, as I shifted from programming for DOS/Windows/NT to SunOS, and later, Linux. Despite the many issues (humorously) exposed by this book, the one thing that hooked me is what that quote above implies: It was accessible, durable, and thus worth taking the time to learn, warts and all.
kragen|6 months ago
There are some people building new Lisp machines: https://opencores.org/projects/igor https://github.com/lisper/cpus-caddr https://interlisp.org/ http://pt.withington.org/publications/LispM.html http://pt.withington.org/publications/VLM.html https://github.com/dseagrav/ld http://www.aviduratas.de/lisp/lispmfpga/ https://groups.google.com/g/comp.lang.lisp/c/36_qKNErHAg https://frank-buss.de/lispcpu/
Also, Morello includes some Lisp-machine-like features. In my view knowing about the history of hardware architectures is far more important for designing new ones than for reproducing old ones.
flavio81|6 months ago
There have been two open source Lisp Machine OS created in the last 15 or 10 years.
However a big part of the power of the Symbolics/LMI machines was in the software itself (applications), and this is still propietary code.
To reimplement the Lisp Machine applications would take quite a big effort.
coreyh14444|6 months ago
pjmlp|6 months ago
If you want really everything is a file, that was fixed by UNIX authors in Plan 9 and Inferno.
ok123456|6 months ago
TrackerFF|6 months ago
whartung|6 months ago
It's my favorite OS.
And I like it for its fundamental process model.
That combined with stdin/out and pipes.
All stitched together with a process aware shell.
Lots (most) OSes had a process concept. But in Unix, they not only existed, they were everywhere, they were dynamic, and they were "cheap". They were user accessible. A process with its ubiquitous stdin/out interface gave us great composablilty. We can click the processes together like legos.
For example, VMS had processes. But after 4 years of using it, I never tossed processes around using it like I did on Unix. I never "shelled out" of an editor. I never & something into the background. Just never came up. One terminal, one process.
On Unix, however, oh yea. Pipe construct on the command line, bang out of the editor, :r! in vi. And the eco-system the was created out of this simple concept. The "Unix Way(tm)".
And anything was a process. A C program. A shell script. At this level, everything was a "system language".
Then, They (those Unix wizard folks) made networking a well behaved citizen in this process stdin/out world. `inetd` could turn ANYTHING (because everything had stdin/out) into a network server. This command is magic: `ls | cpio -ov | rsh otherhost cat > /dev/tape`
Does `ls` know anything about file archives? No. Does `cpio` know anything about networking, or tape drives? No. Heck, `cat` doesn't know anything about tape drives.
You just could not, back in the day, plumb processes and computers together trivially like you could with Unix. Humans could do this. They didn't need to be wizard status, "admins", guys in white coats locked in the raised floor rooms, huffing Halon on the side. Assuming you could grok the arcane syntaxes (which, absolutely, were legion), you could make Unix do amazing things.
This flexibility allowed me to make all sorts of Rube-Goldbergian constructs of data flows and processes. Unix has always been empowering, and not constraining, once you accept it for what it is.
ferguess_k|6 months ago
JdeBP|6 months ago
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
lizknope|6 months ago
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.
anthk|6 months ago
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.
flavio81|6 months ago
All this would not happen if RMS had chosen Common Lisp to implement it...
skydhash|6 months ago
tgv|6 months ago
RichardCA|6 months ago
ferguess_k|6 months ago
nickpsecurity|6 months ago
salvesefu|6 months ago
lalabert|6 months ago
paulnpace|6 months ago
ChrisMarshallNY|6 months ago
modeless|6 months ago
rconti|6 months ago
epilys|6 months ago
swatson741|6 months ago
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?
awesome_dude|6 months ago
justin66|6 months ago
tomhow|6 months ago
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)
microtonal|6 months ago
JdeBP|6 months ago