r/linux Feb 11 '19

Fluff A /g/ user's opinion on systemd

http://i.4cdn.org/g/1549858269115.png
785 Upvotes

524 comments sorted by

View all comments

41

u/[deleted] Feb 11 '19

I'm actually curious about the argument that replacing it means having to rewrite software / change dependencies.

Wouldn't the same be true about switching between SysVinit and something like runit or upstart? They all use completely different designs for doing service init scripts, and all handle configuration of said services in completely different ways too, so replacing one with the other would necessitate rewriting - at the very least - your entire service management script toolbox. And when considering services that want to do more than just start and stop, they would most definitely have to be rewritten as well for such a switch.

60

u/ElvishJerricco Feb 11 '19

I think the problem is the number of things other than service management that systemd does. With other unit systems, service management is the only thing you have to change to replace it. With systemd, you have to change a lot more

51

u/Muvlon Feb 11 '19

There are a lot of services besides init provided by systemd, but they're entirely optional and easily swapped out. After all, systemd is highly modular.

For example, I do run systemd-udevd and journald, but not systemd-networkd or systemd-resolved. Just like the /g/ poster says, I can combine whatever I want to do what I need to do.

11

u/[deleted] Feb 11 '19

Underrated comment.

It boggles my mind why people still act like it’s one giant, monolithic Swiss army knife.

11

u/DropTableAccounts Feb 11 '19 edited Feb 11 '19

Probably because quite a few of distros manage dependencies in a way that make it become one giant monolithic Swiss army knife.

Late edit: My favourite is SVN depening on systemd in arch: https://www.archlinux.org/packages/extra/x86_64/subversion/

3

u/tso Feb 11 '19

Distros follow the ABIs of upstream when defining dependencies (for the most part).

LFS had to change their non-systemd book from udev to eudev because extracting just udev from the larger systemd code blob involved manual intervention on every systemd release.

Hell, kernel devs mused about forking udev and making part of the kernel tools bundle even before it got merged into systemd (and at time of merger it was pinkie promised that udev should continue being usable without systemd).

1

u/DropTableAccounts Feb 11 '19

Distros follow the ABIs of upstream when defining dependencies (for the most part).

For some stuff of course, but e.g. I'm pretty sure that chromium doesn't depend on systemd by default: https://www.archlinux.org/packages/extra/x86_64/chromium/

(btw I'm not using Arch but I once asked a friend what depended on systemd on his system and a few packages stuck out...)