5 ms·

As a Linux normie, I've never understood why systemd is/was so much opinioned about.

ramon156 4mo ago
I wasn't there but from what I understood was that people didn't like the fact it was re-inventing an already-existing wheel. In the long run it was useful for some (at least for me it was).
nightfly 4mo ago
People seem to think it tries and do too much. As a sysadmin I love systemd, especially way more than the init scripts it replaced
- fc417fc802 4mo ago
  It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
  - Jnr 4mo ago
    I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.
dockernod 4mo ago
I unironically believe Docker is a great deal of a reason why it has freshly opinionated newcomers.
- ndsipa_pomu 4mo ago
  I don't understand that as you don't usually interact with systemd in a container. If Flatpak does end up depending on systemd, then that'll make Flatpak less useful for containers.
aniviacat 4mo ago
The way it's structured (combining many previously separate utilities into one) hinders competition. That's tolerable while it's still one of the best solutions for the things it does, but will become an issue in the future.
- account42 4mo ago
  It's already an issue now because "best" is subjective but SystemD developers only care about their own views.
  - bboozzoo 4mo ago
    Why would they care about any other views but their own and those who contribute either financially or through code? Seems like all people can do these days is complain on github, X, mastodon, reddit, HN. It's only talk, talk and more talk, but no do.
    - account42 4mo ago
      Why should the community accept them as a mandatory dependency for every desktop if they don't? This is RedHat shitting up the Linux desktop we're talking about, not some hobby developers releasing things in their free time.
theandrewbailey 4mo ago
It violates the Unix philosophy of 'do only one thing and do it well', but personally, it has never been a problem for me. I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot https://wiki.archlinux.org/title/Systemd-boot
- zamadatix 4mo ago
  There is a lot systemd violates in regards to the traditional Unix philosphy rules. The one about do one thing well is probably the most arguable though since systemd is more a set of functionality across a ton of binaries, each with a more focused purpose. Where it differs is in how those interact vs a "normal" collection of Linux binaries where it's expected to be easy to swap out an individual component and still talk to the rest without implementing things like binary formats.
- happymellon 4mo ago
  > It violates the Unix philosophy of 'do only one thing and do it well' How? This is really where it's basically a marketing fail. Even your own link for system-boot shows that it is it's own rebranding of gummi-boot. It's not part of the init system, they just have an identically named project which has 100 utilities in it. It's dumb and it's community hostile.
- Jnr 4mo ago
  > after all it has replaced GRUB. With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.
- gf000 4mo ago
  Linux kernel, X server, web browsers all seriously violate the Unix philosophy. And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.
happymellon 4mo ago
Because systemd confuses a lot of things by having two projects with the same name. Systemd the init service is excellent. Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning. Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.
- Izkata 4mo ago
  > Systemd the init service is excellent. When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... (screen was also affected, not just tmux) I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add some systemd integration for their new API. As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.
  - ecnahc515 4mo ago
    I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run background tasks, even with tmux and screen.
    - Izkata 4mo ago
      Those were just the most prominent things, which were immediately noticed because it's completely normal to leave them open remotely to maintain context for something and quickly pick it back up when reconnecting. It's kind of their whole purpose. But the change affected everything, including for example the "daemonize" program.
PhilipRoman 4mo ago
It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way. Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.
- mrktf 4mo ago
  I will add this: if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)
Avshalom 4mo ago
Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it. Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.
- Jnr 4mo ago
  Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now. I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things. I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.
  - Avshalom 4mo ago
    Important to people being happy now is that Lennart Poettering didn't write pipewire. Also having a bunch of things barely held together with duct tape is part of the philosophy.
  - account42 4mo ago
    > Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now. Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted. I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles. But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC. And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon. Meanwhile ALSA with an up to date default dmix configuration worked just fine.
lousken 4mo ago
... and it's not even written in Rust
greatgib 4mo ago
I don't know recently, but at the time that systemd was shoved through our throat, you could look at the source code and it was a giant ball of horse shit. Following bad practices, hard coding things, ... With absolutely strong tendency to not give a shit about feedbacks from others, and supporting anything except the highway case that is the only one that they cared about. And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...

I wasn't there but from what I understood was that people didn't like the fact it was re-inventing an already-existing wheel. In the long run it was useful for some (at least for me it was).

nightfly 4mo ago

People seem to think it tries and do too much. As a sysadmin I love systemd, especially way more than the init scripts it replaced

fc417fc802 4mo ago
It's not that it does too much it's that it's monolithic (you can't necessarily swap out components) combined with the fact that the project is gradually subsuming more and more of the userspace utilities. Having the entirety of the userspace half of the OS under a single umbrella seems like a bad idea.
- Jnr 4mo ago
  I think it came from the necessity for rapid integrations between different parts of the OS. And if it is handled as a single project it takes less time to improve it, since you don't have to align with 10 different projects and their release cycles.

dockernod 4mo ago

I unironically believe Docker is a great deal of a reason why it has freshly opinionated newcomers.

ndsipa_pomu 4mo ago
I don't understand that as you don't usually interact with systemd in a container. If Flatpak does end up depending on systemd, then that'll make Flatpak less useful for containers.

aniviacat 4mo ago

The way it's structured (combining many previously separate utilities into one) hinders competition. That's tolerable while it's still one of the best solutions for the things it does, but will become an issue in the future.

account42 4mo ago
It's already an issue now because "best" is subjective but SystemD developers only care about their own views.
- bboozzoo 4mo ago
  Why would they care about any other views but their own and those who contribute either financially or through code? Seems like all people can do these days is complain on github, X, mastodon, reddit, HN. It's only talk, talk and more talk, but no do.
  - account42 4mo ago
    Why should the community accept them as a mandatory dependency for every desktop if they don't? This is RedHat shitting up the Linux desktop we're talking about, not some hobby developers releasing things in their free time.

theandrewbailey 4mo ago

It violates the Unix philosophy of 'do only one thing and do it well', but personally, it has never been a problem for me. I had a nightmare last week wherein I read a headline that systemd was writing its own kernel. When I woke up I realized it was a possibility, after all it has replaced GRUB. https://wiki.archlinux.org/title/Systemd-boot https://wiki.archlinux.org/title/Systemd-boot

zamadatix 4mo ago
There is a lot systemd violates in regards to the traditional Unix philosphy rules. The one about do one thing well is probably the most arguable though since systemd is more a set of functionality across a ton of binaries, each with a more focused purpose. Where it differs is in how those interact vs a "normal" collection of Linux binaries where it's expected to be easy to swap out an individual component and still talk to the rest without implementing things like binary formats.
happymellon 4mo ago
> It violates the Unix philosophy of 'do only one thing and do it well' How? This is really where it's basically a marketing fail. Even your own link for system-boot shows that it is it's own rebranding of gummi-boot. It's not part of the init system, they just have an identically named project which has 100 utilities in it. It's dumb and it's community hostile.
Jnr 4mo ago
> after all it has replaced GRUB. With unified kernel images there is no need for grub or any other bootloader anymore. And UKI simplifies boot configuration and helps improving security in some aspects.
gf000 4mo ago
Linux kernel, X server, web browsers all seriously violate the Unix philosophy. And to be perfectly honest, it's nothing more than a philosophy - it's not some universal truth, e.g. a browser by definition is not doing "one small thing" and complex workloads are better organized by monolithic software to a certain degree.

happymellon 4mo ago

Because systemd confuses a lot of things by having two projects with the same name. Systemd the init service is excellent. Systemd the catch all for trying to rewrite all services to come up with a baseline version of everything is a strange and NIH project. They would have been far better off politically by coming up with a spec and seeing if they could submit patches to get the current services to use the APIs they were planning. Instead they just have a bundle of things they have tried to reinvent, some more successfully than others. Hence the divisions in the communities.

Izkata 4mo ago
> Systemd the init service is excellent. When it's not actively going against decades of convention and breaking solid programs everyone has used forever: https://superuser.com/questions/1372963/how-do-i-keep-systemd-from-killing-my-tmux-sessions https://superuser.com/questions/1372963/how-do-i-keep-system... (screen was also affected, not just tmux) I'm not sure if it was linked from there, but somewhere in the discussions the systemd devs' recommended fix was for screen/tmux/anything else affected to add some systemd integration for their new API. As far as I'm aware the complaints about this stopped only because distros override the setting, while it's still the default for stock systemd.
- ecnahc515 4mo ago
  I've been impacted by this particular "issue" and while it's changing the way "decades of convention" it's not really a bad thing imo. Running things via screen and tmux as a solution to background tasks has always been a huge hack imo. Not only that but the alternative approaches with nohup and disown also have their own issues. Imo it's actually pretty reasonable to need to work work the OS service manager to run background tasks, even with tmux and screen.
  - Izkata 4mo ago
    Those were just the most prominent things, which were immediately noticed because it's completely normal to leave them open remotely to maintain context for something and quickly pick it back up when reconnecting. It's kind of their whole purpose. But the change affected everything, including for example the "daemonize" program.

PhilipRoman 4mo ago

It is a fantastic init system/service supervisor. My problem with it is basically everything else. I think its developers see systemd as central to the entire system, basically the userspace counterpart to the kernel. I prefer the approach of 'dinit', but I understand why they designed it that way. Due to this design they often have underspecified interaction between the different components, since the assumption is that everyone will use largely the same baseline systemd environment and as long as it works, who cares what it does underneath. If the different parts were more independent, they would be forced to develop a cleaner API contract between them.

mrktf 4mo ago
I will add this: if you treat systemd as one trick pony and use for few use-cases which developers envisioned - it run flawlessly, but moment do something not in this path prepare for problems and inferior experience (example of randomly picked tool: timedatectl - no force update date like ntpdate command, you cannot quickly insert ethernet cable update date and disconnect... need to wait for synchronization)

Avshalom 4mo ago

Okay so back in ~2000 the audio system in Linux was ALSA and it kinda sucked so along come a guy named Lennart Poettering who wrote pulseaudio which improved things in a lot of ways but also kinda constantly didn't work. Poettering in those years constantly blamed everything on other software in the stack and became kinda wildly disliked. We all had to use pulseaudio though because everything important decided to integrate it. Jump forward to systemd and absolutely none of trust Poettering farther than we can throw him. At the same time systemd basically did the job of half a dozen programs which offends a lot of people on philosophical grounds. Simultaneously a bunch of things start hard requiring this program that people neither trust nor like.

Jnr 4mo ago
Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now. I don't know about the philosophical aspects, but from pure technical point of view systemd brought some order into the mess. Before systemd it seemed like most distros were barely holding together with duct tape. Systemd standardized a lot of things. I am fine with a little bit of controversy if the result is a much better desktop OS experience for the user. And as a relatively long time Linux user, I can certainly say it is much better now than it was 20 years ago.
- Avshalom 4mo ago
  Important to people being happy now is that Lennart Poettering didn't write pipewire. Also having a bunch of things barely held together with duct tape is part of the philosophy.
- account42 4mo ago
  > Yes, but people learned from issues that pulseaudio had and then came pipewire. Everyone is happy now. Yes, I'm very happy that it mutes my audio when I accidentally unplug my headphones (something which I never asked for) and then often fails to unmute them when plugging them back in, something which requires digging up alsamixer to fix because pulse/pipeware-based GUI tools are being lied to about the output not being muted. I'm also especially fond of having to open the audio settings app to change audio from one display output to another because some very smart person decided to group all display audio (which are separate ALSA sinks) into one output with different profiles. But lets not forget that it at least simplified configuration. So much that GUI tools basically don't let you configure shit at all and you need to use one of two (yes, one was not enough) turing-complete configuration languages to accomplish anything slightly non-standard like giving outputs are better name than what your display manufactures cat produced while walking over his keyboard or hiding some of the bazillion useless audio devices that you might end up with somewhere in your PC. And then of course it still has the PA-innovations like audio randomly stopping for no reason at all until you restart the daemon. Meanwhile ALSA with an up to date default dmix configuration worked just fine.

lousken 4mo ago

... and it's not even written in Rust

greatgib 4mo ago

I don't know recently, but at the time that systemd was shoved through our throat, you could look at the source code and it was a giant ball of horse shit. Following bad practices, hard coding things, ... With absolutely strong tendency to not give a shit about feedbacks from others, and supporting anything except the highway case that is the only one that they cared about. And as anyone could have expected, systemd broke a lot of things, and sometimes very badly with their shitty code. Like this time that they wiped the nvram memory of laptop transforming them into bricks...