SteveGoob

Fair enough, but there’s a reason no one runs almost any of the systemd services in isolation. There’s a big difference between “takes a bit of tinkering” and “need to maintain massive patch files to make journald independent of systemd”

Yeah, I noticed that too. At the end of the day, it’s not particularly important, but it is a bit of an embarassing mistake.

Except that the author does not end the discussion at “it doesn’t follow the Unix philosophy.” Granted, they do spend a number of words refuting the argument that systemd is modular; whether or not it’s a strawman, it sounds like you already agree with the author on that point. While they do pay some lip service to the value of the Unix Philosophy, their arguement hardly ends there.

From the article, (bold emphasis mine):

This lack of modularity – where “modularity” means free choice in interchanging components for other, unrelated projects – is where most of the criticism of systemd stems. It’s the purest, and most important, criticism of systemd, but my personal grievances against systemd go further. Because, in my experience, systemd isn’t good software.

The author provides evidence for that claim with examples regarding journald, networkd, and session keyrings. None of those criticisms are specific to the Unix Philosophy. Their whole point appears to be “yes, I value software that follows the Unix Philosophy, and systemd does not, but I believe there are many other valid reasons that systemd isn’t good.”

Of course these concerns play into each other, but the nuance there is kinda the whole point. The author points out that it would be a lot easier to use only the good parts if systemd had a more genuinely modular architecture, but it’s simply not built for that. And it’s a real and material example of a negative consequence of not following the Unix Philosophy. Rather than say “it’s not developed with the UP in mind, it must therefore be bad,” the author gives a tangible example representative of why they believe that to be important.

Just as the Unix Philosophy is a thought-terminating cliché (because of course it is), it is similarly unhelpful to claim that consolidation brings performance and cross-cutting capabilities. The proof is in the pudding, and as critical readers we should not overlook valuable perspectives like the one the author has brought.

(Not that it’s critical to your point, but we’re you trying to argue that Wayland is monolithic? I have to assume you didn’t mean it like that, since it’s a protocol that decouples clients and compositors, and it’s certainly not monolithic in that sense)

That argument is addressed in the article. With few practical exceptions, systemd components expect you to be running the other systemd services. E.g. running systemd without journald is not a supported usecase.