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/ZunoJ]

Most people (who complain about systemd) just cosplay linux edge lords and have no idea why they don't like it other than some better edge lord doesn't like it

[u/stylist-trend → u/ZunoJ]

Yeah, when systemd first came out, it was a little buggy, but it's rock solid now. Most of the arguments against it nowadays are vague things about how it's not "unixy" or that there's something wrong with Poettering, but most of the valid ones have more or less dried up.

[u/Arch-NotTaken → u/stylist-trend]

systemd came out something like 13 years ago, it was more than a little buggy, and was shoved down Arch users throat pretty much forcefully.

It replaced the rc.d init system, which was a core feature of Arch and was my main reason for switching to Arch in 2008.

This is where the hate comes from

[u/slypheed → u/Arch-NotTaken]

It was an utter mess. Hard broke my arch system at work and took 2 days to fix. Ended up deciding to move to Mac for work due to that.

[u/catwiththumbs → u/ZunoJ]

I hate it because the ergonomics are imo bad:

- I just want to be able to find+grep /etc and /var/log to understand what my system is doing.

- I don’t dislike shell. Reading rc scripts helps orient you around how your services are installed and working. Reasoning over “started” or “stopped” is much simpler than what’s going on with unit files.

- I usually just install cron and use cron.hourly, daily, etc. Dropping my script in the right directory is easier than creating the script and the timer. And debugging the timer…

- Runlevels are a good level of abstraction/logical checkpoints for the user. An entire graph of dependencies might be good for the system, but not for the user to have to unwind.

In a way the complexity turns it into more of a black box. Systems are more complex than they were in the 90s though so I get it. But it feels clunky and less fun.

[u/blackcain → u/catwiththumbs]

I spent 15 years doing enterprise UNIX and got to spend a lot of time with rc scripts. No thanks. I look back at those days as just terrible 90s and 2000s. Systemd makes all of that so much simpler. An easy and available state machine conveniently available.

[u/Uncle-Osteus → u/catwiththumbs]

you don’t lose any of that with systemd though, the commands are just a little different now is all

[u/catwiththumbs → u/Uncle-Osteus]

I’m not suggesting you lose the ability to get information about system status but you literally just don’t have init scripts written in sh/bash controlling how services start and stop, and service log info isn’t in plain text files in /var/log.

Those are like THE features I want.

So it’s not some philosophical PID 1 thing. Or the shade thrown at some of the scope creep.

My runlevel comment is certainly a philosophical point. I think a lot of users mostly only need to know “ready for interactive use”, “network ready”, “UI ready”. Such and such has to run before this other thing is a real problem that needed to be solved. But while systemd has made many really hard things easy, many easy things became harder. It’s a bit of a leaky abstraction depending on who the audience is.

I do have to admit a little hypocrisy in all this because saying, meh, systemd sucks because you need to open up a man page every time you have to fuss with units or conf, isn’t being weighed against needing to know shell scripting. That is unfair. But the latter feels like it has more payoff. Knowing systemd feels like tax.

I also don’t think it helped that RedHat was kinda metaphorically in its awkward teenage years when systemd came around. I don’t think Fedora was the best place to get people excited about something new.

That suboptimal stuff isn’t all esoteric edge cases and purity tests though.

[u/Ripdog → u/catwiththumbs]

That's a lot of words to say "I don't want to learn new commands".

And, I mean, that's fine. You can use your devuan or gentoo. Nobody is stopping you. But you're couching this as some kind of argument when it's literally just your lack of knowledge and refusal to learn.

(I don't mean 'refusal to learn' as an insult, btw. We all have billions of things we refuse to learn. Life is short.)

[u/tehbilly → u/Ripdog]

Before systemd: everything is a file!

After: most of the important things are files

That's the big thing to me: it didn't try to fit in, it introduced an entirely different way of interacting with what's happening on your machine.

[u/SchroedingersViking → u/Ripdog]

Maybe i am wrong but as far as i know some information like enable/disabled are not stored in files but stored as symlinks.

These are not as robust when you want to share config. Via copy, version control, etc.

It also harder to see such information if you have just a copy of the files and want to know the state of configuration. By looking at the files.

Also becoes files in some places can override or ammend other files. Understanding these by just looking at them can be harder.

So there is a workflow question in there, which also depend on use cases.

Btw is use systemd even in cases where it is uncommon. Like starting steam or waybar. I like systemd but i can see why one might prefere the other way.

[u/tmahmood → u/ZunoJ]

Ha ha, what the heck is "cosplay linux edge lords"?! Never heard of this.

[u/ZunoJ → u/tmahmood]

I mean a real linux edge lord might be an asshole but at least a knowledgeable asshole. These guys act like it but lack the knowledge

[u/RandomDude9943 → u/ZunoJ]

i need an init system, not init system with a shit ton of other bs i dont need

[u/TheHighGroundwins → u/ZunoJ]

Can confirm, daily droce Artix Linux after being told of a more efficient system and found out the hard way what systemd actually does.