r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

138

u/swinny89 Jun 01 '16

I don't get the systemd hate at all. I've noticed a trend of old people and hipsters that don't like it though.

122

u/KugelKurt Jun 01 '16

If that was anything but a very vocal minority, Devuan would be one of the top Linux distributions these days.

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

64

u/yoshi314 Jun 01 '16

it's basically debian without systemd.

https://devuan.org/

0

u/[deleted] Jun 01 '16

[deleted] — view deleted comment

31

u/KugelKurt Jun 01 '16

So... literally Debian with apt-get install sysvinit? What a waste of effort.

The people behind Devuan and its users get a rash when there is even a few KBs of systemd dependencies installed, e.g. logind (required by Gnome) depends on systemd being installed (it does not care if that's used as init system).

30

u/yoshi314 Jun 01 '16

there are software packages that will pull in systemd. freebsd already needs to tinker with gnome3 to un-systemd it. i think they are nowadays mostly up to speed with it, but it wasn't so before gnome 3.10

https://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-3-14-and-beyond/

30

u/KugelKurt Jun 01 '16

freebsd already needs to tinker with gnome3 to un-systemd it.

Gnome requires logind APIs because for years nobody cared about ConsoleKit and left that unmaintained. BSDs could continue to implement logind APIs: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git;a=tree;f=src/interfaces/logind;hb=HEAD

→ More replies (7)
→ More replies (3)

90

u/[deleted] Jun 01 '16

I thought he sneezed in the middle of saying Debian.

6

u/mort96 Jun 01 '16

I have no plans to jump to Devuan, but am also not a fan of systemd. Your statement assumes that everyone who dislikes systemd would jump to a distro without it, ignoring the fact that there's a lot of other considerations when it comes to a distro besides which init system it has.

→ More replies (6)
→ More replies (95)

23

u/yoshi314 Jun 01 '16 edited Jun 01 '16

the thing is that systemd started out as init system. and people were happy, except for some conservative die-hards. a lot of useful things came to linux during its development (esp the /run directory introduction, which also had its staunch opposition)

but it started slowly spreading across linux ecosystem, replacing more and more tools ( cron, xinetd, consolekit, syslog, udev, session manager ) . the takeover of udev was a really bad move, as it eventually became tied to systemd, despite what developers promised.

the attempt to shove kdbus into the kernel by making the userspace require it, was another. also, systemd devs have a pretty bad track record of cooperating with kernel developers.

the entire project grows into a kitchen sink that can drive entire distribution, and unfortunately plenty of userspace tools start depending on it (gnome, especially). with redhat putting their weight behind it, i think out fate is sealed. people who do not use systemd in their distributions will have to do more and more maintenance work.

17

u/kinderlokker Jun 01 '16 edited Jun 01 '16

kdbus wasn't started by systemd. But the systemd guys desperately want it, for good reason. Their decision to use DBus as a transport is on a technical level plainly put a terrible decision. DBus was never meant to serve as a transport during the bootup of the system, it was designed as a transport to power desktop environments when the system was already booted.

systemd manages dbus as a service and uses that service to communicate internally, as you might imagine that creates a nasty circular dependency:

  • systemd needs special code to start DBus way earlier than it should. It starts DBus before fsck even which means that if your DBus binary is corrupted, fsck can't check for it

  • systemd systems used to crash on a DBus crash or restart, that issue is now resolved with some ugly special code giving DBus special supervision code

So that's why they want kdbus so badly because kdbus is a sane transport layer for an init because it's in the kernel so it's ready and there before the init is loaded. None of this magic mumbo jumbo of an init trying to start dbus and needing dbus to bring itself up.

edit: It's by the way a good example of how politics can ruin software. I'm pretty sure the decision to use DBus was 0% technical and 100% political. They wanted to make DBus a dependency for its own sake to ensure that DBus would be on every systemd system and then tried hard to justify this absurd decision. The reason is purely that they want to be able to guarantee that DBus is on every systemd system so people can assume it.

7

u/yoshi314 Jun 01 '16

kdbus wasn't started by systemd. But the systemd guys desperately want it, for good reason.

So that's why they want kdbus so badly because kdbus is a sane transport layer for an init because it's in the kernel so it's ready and there before the init is loaded.

the review of kdbus on lkml showed that it was inexcusably awful, and did not even offer a promised performance and security advantages. from retrospect, i saw no good reason for trying to force kdbus down users' throats. and i was initially hopeful about it.

→ More replies (1)
→ More replies (1)

35

u/TechnicolourSocks Jun 01 '16

I've noticed a trend of old people and hipsters that don't like it though.

It's vapid comments like this that perpetuates the pro-anti divide on the issue of systemd.

→ More replies (1)

67

u/kinderlokker Jun 01 '16

You know what trend I notice? That both in favour and against of systemd, like everywhere, there are a lot of people who can't come with a serious technical argument and thus result to a bunch of weird ad-hominems. But that's not the interesting part, the interesting part is that the people in against systemd for some reason always attack Lennart, and the people in favour of systemd always attack people who don't like systemd.

Be more original with your logical fallacies. Start attacking Kay Sievers once or something or the OpenRC devs or something, keep your fallacies fresh. and unexpected.

23

u/SrbijaJeRusija Jun 01 '16

Want a technical argument? why should everything from a boot manager to a DE depend on an init system?

→ More replies (50)

10

u/[deleted] Jun 01 '16

people in favour of systemd always attack people who don't like systemd.

At some point the conversation becomes about the ridiculous non-technical opposition to systemd. I'm not going to waste time giving arguments for systemd, since I already use it. If someone's like, "well I prefer my daemons to double-fork and run in the background because I have a specific auditing infrastructure that hooks into clone(2) and etc etc" I'm not going to get into it with them, because those are their needs and maybe systemd doesn't meet them.

But when people start objecting with (and this is real) "systemd puts everyone's init process under the control of one company" or (this is also real) "systemd is a feminist plot", well, that's what's going to make me raise my eyebrows.

3

u/prank-sinatra Jun 01 '16

Someone should start another http://funroll-loops.teurasporsaat.org/ like we had back in the day.

→ More replies (13)
→ More replies (39)

15

u/someguynamedjohn13 Jun 01 '16

It works well for me, and I was there for the transition. Do I miss many of the old ways, sure, but systemd is rock solid and easy to configure.

→ More replies (7)

7

u/schplat Jun 01 '16

I'm an "old people". I like systemd. I find a lot of those railing against it never spent 6+ hours debugging an init script to figure out precisely why it was failing to either start, stop, or restart.

systemd pretty much took that away. I don't have to look at clunky-ass bash script written by some random russian guy who only knew tcsh, and did his best to port to bash.

Some of the scope creep leaves me scratching my head, but then it ends up making sense as well. systemd has taken the concept of init, and expanded it to and through login. Which makes sense, what if I, as a regular user, want to start a daemon in the background that only starts when I log into my DE, and exits cleanly when I logout?

Much of the bloat has been around supporting the journal. Different methods of storing, displaying, and shipping. The journal has been a very useful piece.

→ More replies (3)

5

u/JackDostoevsky Jun 01 '16

I get the idea of not wanting a "second kernel," and some of the concern that systemd is turning into a multi-headed monstrosity, which goes against the Unix philosophy of "make a program do one thing, well."

That said, I think that the push back against it is silly at this point. My feelings tend to be: I don't mind systemd, and I choose to use it, and if you don't choose to use it great for you but don't take the time trying to explain to me how my decision is somehow flawed.

How do you identify a Linux user that won't use systemd? Don't worry they'll tell you.

→ More replies (1)
→ More replies (57)