> The Unix philosophy is not an end goal neither. It's not even something well defined.
You're right. But what I take issue with is that systemd authors deliberately decide to go against it. We know because there are other init systems that do follow these design principles much more closely.
Of course, an init system is not trivial, and is a special program that must be given additional permissions over most user space programs. But the problem with systemd is that it's not just an init system. It is a collection of tools that also manages logging, networking, DNS resolution, containers, and a bunch of other system tasks, which, in my opinion, it has no business managing. When you add to this the fact that these programs are all interdependent in some way, and that I can't use e.g. `journald` without systemd itself, it really drives the point that this is an attempt to establish a cohesive and centralized system, rather than rely on a collection of independent but composable tools, most of which already exist. So I get the appeal why some people would prefer this, particularly if they're not already experienced with existing tools, but it's also not a surprise why experienced Linux geeks would scoff at this.
In my experience, systemd doesn't give me anything that I can't do well with other tools. And instead of having the choice to use a tool of my preference for each individual task, I'm forced to use a gargantuan system designed by a single group of people. Whether or not this ultimately makes my life easier, it goes against the primary reason why I choose to use Linux in the first place. If I wanted someone else to make decisions about how I use my computer, I have Windows and macOS for that.
Tangentially, this is also why I have a love-hate relationship with NixOS. As much as I appreciate reproducibility, atomic upgrades and rollbacks, and having a fully declarative system, its authors insist on managing every part of my system with Nix, which is completely insane to me. So, for example, it tries to replace every single package manager in existence, whereas I much prefer using something like `mise` to manage my development environments. Technically, I still can and do that, but it's certainly not the "Nix way".
Interoperability and composability are the core tenets of the Unix philosophy IMO. It's this that allows me to use programs written decades ago together with programs written today, without either tool being aware of each other. In contrast, tools that try to take over my machine forcing their own UIs on me—no matter how supposedly superior they might be—are hostile to my overall computing experience.
Just to go off of this, I used to be a huge unix zealot - pipes, fork(), all of it, init, zombie processes.
I felt like systemd was an epiphany. Software doesn't need to a collection of simple tools that do one thing really well. You can have one tool that does everything shittily, the pdf reader of init if you will, and that's systemd. The author went on to do brilliant work with pulseaudio, you know, the whole /dev/dsp everything including sound is a file, oof. Let's make it a weird complex server process, oh, and let's make another sound system after that too.
I was very happy to see Lennart Poelering had joined microsoft to bring his brilliance to windows. I'm sure he's just cranking out masterpiece after masterpiece of design for them. I actually switched from unix to windows after being so inspired the tremendous quality and sensical design of both pulseaudio and systemd. Oh, and both very reliable, simple, and intuitive.
You're right. But what I take issue with is that systemd authors deliberately decide to go against it. We know because there are other init systems that do follow these design principles much more closely.
Of course, an init system is not trivial, and is a special program that must be given additional permissions over most user space programs. But the problem with systemd is that it's not just an init system. It is a collection of tools that also manages logging, networking, DNS resolution, containers, and a bunch of other system tasks, which, in my opinion, it has no business managing. When you add to this the fact that these programs are all interdependent in some way, and that I can't use e.g. `journald` without systemd itself, it really drives the point that this is an attempt to establish a cohesive and centralized system, rather than rely on a collection of independent but composable tools, most of which already exist. So I get the appeal why some people would prefer this, particularly if they're not already experienced with existing tools, but it's also not a surprise why experienced Linux geeks would scoff at this.
In my experience, systemd doesn't give me anything that I can't do well with other tools. And instead of having the choice to use a tool of my preference for each individual task, I'm forced to use a gargantuan system designed by a single group of people. Whether or not this ultimately makes my life easier, it goes against the primary reason why I choose to use Linux in the first place. If I wanted someone else to make decisions about how I use my computer, I have Windows and macOS for that.
Tangentially, this is also why I have a love-hate relationship with NixOS. As much as I appreciate reproducibility, atomic upgrades and rollbacks, and having a fully declarative system, its authors insist on managing every part of my system with Nix, which is completely insane to me. So, for example, it tries to replace every single package manager in existence, whereas I much prefer using something like `mise` to manage my development environments. Technically, I still can and do that, but it's certainly not the "Nix way".
Interoperability and composability are the core tenets of the Unix philosophy IMO. It's this that allows me to use programs written decades ago together with programs written today, without either tool being aware of each other. In contrast, tools that try to take over my machine forcing their own UIs on me—no matter how supposedly superior they might be—are hostile to my overall computing experience.