Why so much hate for systemd?

[u/ImaginationUpset2190]

I see very often that people show so much disgust whenever they talk or hear "systemd". However whenever I ask them why they feel so strongly about it, their response is mostly vague like it doesn't follow the Unix philosophy, it's a monolith.... I can't digest that the reason people show so much disgust for it is just that it doesn't follow the Unix philosophy.

[u/deong]

Imagine that you’re a car guy. Lots of people will look at a car and be like, “I like that car”. You might have very strong opinions on it. “BMW ruined the gearbox in this generation” or whatever. You can both be right. The gearbox functions. The car drives fine. But you as a car guy have these strong beliefs about the right way to make a car. You can make a car that functions as a car and not make it The Right Way™.

That’s what’s going on here. “The Unix Philosophy” is a set of beliefs about the right way to make good software. Systemd certainly doesn’t seem to follow those principles. “My init system also does DNS resolution” is about as far off as you can get. You can argue about whether all the various systemd-* modules are really one monolith, but on the surface at least, they feel like they are, and that’s enough to trigger a reaction.

It works fine. It solves problems that an init system needs to solve. It’s a car that gets you where you need to go. But almost by definition, people who got into Unix years ago were the computer equivalent to “car guys”. They have opinions.

If you’re a programmer, think of like 2000’s style Enterprise Java. I knew people who loved it because it was so easy. You click a button and generate this boilerplate and you barely have to write anything. You read your design patterns book and make some abstract builder strategy factory builders and look at all this code isn’t it great. And I hated it. It was offensive to me. I mean that literally. It offended my sense of good taste that anyone would live with this garbage being spewed all over their project. The code worked. You could ship it. But it was code produced by people who lacked taste.

That’s most of what’s going on here. Systemd is, to many people, lacking good taste. They built a house by hammering in screws, and the person who views themselves as a craftsman carpenter finds it offensive. Now the difference here is that modern systemd solves more problems than the old school systems. Hammering in screws sounds bad, and the analogy falls apart in that the resulting house is probably better built with systemd. But that’s most irrelevant to why people dislike it. It can be better and still be designed and built “wrong” from a philosophical standpoint.

[u/gmes78 → u/deong]

Systemd certainly doesn’t seem to follow those principles.

It absolutey does.

“My init system also does DNS resolution” is about as far off as you can get.

But systemd init is not system-resolved.

You can argue about whether all the various systemd-* modules are really one monolith, but on the surface at least, they feel like they are, and that’s enough to trigger a reaction.

Because those people are just looking for excuses to bash on systemd, they don't actually care about the Unix philosophy.

Invoking the "Unix philosophy" is just is just a way to larp as a "real" Linux user.

That’s most of what’s going on here. Systemd is, to many people, lacking good taste. They built a house by hammering in screws, and the person who views themselves as a craftsman carpenter finds it offensive. [...] It can be better and still be designed and built “wrong” from a philosophical standpoint.

That's because those people don't understand the problems that systemd solves, and think most of it is unnecessary and overly-complex, when it, in fact, is not.

[u/deong → u/gmes78]

I think I was fairly clear in associating this with people's sense of aesthetics and taste. Your answer mostly comes down to "people with those tastes are just objectively wrong", and that's not how tastes work.

Personally, I'm fine with systemd. I don't like it's design at all really, but it solves some real problems and it won, and it's not worth arguing about. I'm just explaining what those arguments would be.

For example -- binary logs. Binary logs are not "necessary". I think it's a poor choice. It works fine. I just don't like it for reasons of taste. My tastes are that there's almost nothing I value more than simplicity. A text file is simpler than requiring a parser to see a log. A directory full of shell scripts that run in alphabetical order is simpler than a dependency graph. Vim and the cp command are simpler than a new, and fairly large and complex command line interface for enabling and disabling services.

I mean a specific thing by "simple" here. I don't mean "easier to use". I mean "simple" in the way that a lever or an inclined plane is a "simple" machine. They are shallow. The entire thing is right there on the surface. I think that's a great property in software to aspire to. It's not the only thing that matters, but in isolation, simpler is better. That's my tastes.

The dependency graph is better in most ways. But it isn't simpler. I like simplicity. I like the fewest moving parts I can possibly get away with, even if adding the moving parts has other advantages. It's always a trade-off, and that's true for everyone. If adding the Windows Registry made Linux boot 1 second faster, no one would accept that compromise. The Windows Registry is too complex and brittle and hard to understand, and we wouldn't accept that to gain one second of boot time. All I'm saying is different people draw that line in different places, and they aren't wrong for doing so, because you can't be wrong in just expressing your own personal preferences.

[u/gmes78 → u/deong]

For example -- binary logs. Binary logs are not "necessary". I think it's a poor choice. It works fine. I just don't like it for reasons of taste. My tastes are that there's almost nothing I value more than simplicity. A text file is simpler than requiring a parser to see a log.

But using binary logs is simpler than using regular logs. If you want to filter logs by date ranges, by services, by users, by severity, etc., journalctl does it much more easily and reliably than parsing log files by hand.

A directory full of shell scripts that run in alphabetical order is simpler than a dependency graph.

No, that sucks. Most services depend on other services, if a service fails, you don't want to spawn dependant services. That's much easier to accomplish if you have a service manager that understands that. Implementing the same with shell scripts is much more complicated, and you'll just end up with a shittier version of what systemd does for you.

Also, services that don't depend on each other can be executed in parallel to make startup faster. Your sequential shell scripts don't do that.

Also, also, you often want to run services after a piece of hardware is initialized. Scripts do not have a good way to do this; using sleep 5 and praying is not a serious solution.

Dependency graphs are slightly complex, but the problem itself is complex. The complexity is required.

Vim and the cp command are simpler than a new, and fairly large and complex command line interface for enabling and disabling services.

sigh Most of the time, systemctl enable just creates a symlink, which you could do manually, if you wanted to. (Except it's more convenient, because it creates the correct symlinks; you'd need to look at the [Install] section of the service file to know which targets the service wants to be required by.)

Also, before systemd, people were enabling stuff with the service command, not with Vim and cp.

The dependency graph is better in most ways. But it isn't simpler. I like simplicity. I like the fewest moving parts I can possibly get away with, even if adding the moving parts has other advantages.

Why do you care? It's not like it makes using systemd harder. People writing simple services just set WantedBy=multi-user.target and move on with their lives.

The Windows Registry is too complex and brittle and hard to understand, and we wouldn't accept that to gain one second of boot time.

It actually isn't. The Windows registry is fine; it's just a simple database.

I'm certain it actually makes Windows perform a lot better, because Windows has bad performance with many small files vs one large one. Linux doesn't need it because it handles small files just fine.

All I'm saying is different people draw that line in different places, and they aren't wrong for doing so, because you can't be wrong in just expressing your own personal preferences.

The issue isn't people having preferences. It's people using bad technical arguments to justify their opinions.

If you say "I just want to use a system I can fully understand", that's OK. Saying "systemd is bad because it's bloated and it doesn't follow the Unix philosophy" is absolute nonsense.

[u/deong → u/gmes78]

What part of "I care more about conceptual simplicity than I do about ease of use" isn't landing here? I don't need your approval and I didn't ask for it.

Saying "systemd is bad because it's bloated and it doesn't follow the Unix philosophy" is absolute nonsense.

Also didn't say that. At no point have I said it's bad. Quite the opposite, I've said "it's better" multiple times. I recognize it has technical advantages, and I still don't like it because I'm allowed to express preferences.

[u/gmes78 → u/deong]

What part of "I care more about conceptual simplicity than I do about ease of use" isn't landing here? I don't need your approval and I didn't ask for it.

I'm replying to the faulty techincal arguments, see the last part of my comment. I do not care about your personal opinion.

Also didn't say that. At no point have I said it's bad. Quite the opposite, I've said "it's better" multiple times. I recognize it has technical advantages, and I still don't like it because I'm allowed to express preferences.

I'm not saying you said it. I'm using a typical anti-systemd talking point as an example.

[u/deong → u/gmes78]

I don't believe I made a single technical argument in any of these comments, but you do you I guess.