Hacker News Reader

> What is it about init systems that causes this outrage?

I like systemd. It has shaven quite a few seconds off my boot time. I get that its modularity simplifies things for the developer. However, I understand some of that outrage. Linux systems have typically been mix-and-match. However, when systemd started gaining popularity, some packages have been written to depend on it, and it seems to be becoming difficult for people to choose not to have systemd. Given that systemd is built to make good use of Linux-specific features, it's also annoying for *BSD developers to get many software packages to build and run on their systems.

Look at the output from my own setup:

    Required By    : accountsservice  bluez-utils  chromium  colord  crda  device-mapper  lib32-systemd
                 libgusb  libpulse  libusb  lightdm  lvm2  media-player-info  mesa  mkinitcpio
                 netctl  packagekit  pcmciautils  polkit  procps-ng  python2-pyudev  qt5-base
                 qtwebkit  rtkit  spotify  subversion  systemd-sysvcompat  udisks2  upower
                 xf86-input-evdev

I don't understand why many of these packages need systemd.

"I don't understand why many of these packages need systemd."

Exactly the issue I think.

I'm wondering (not trolling) how many desktop people actually reboot the kernel (fresh boot or resume from hibernate) as opposed to using suspend to ram? Given the outrage the Gnome devs caused by hiding the power down function on early versions of Gnome 3 quite a few. I generally just suspend, but I've recently started using hibernate on one laptop with whole disk encryption just in case of petty theft/leaving it on a bus.

Do any sysadmins use automatic spinning up of instances of a small Linux to cope with traffic spikes? Is that something that is actually done? Boot time could matter then.

In general, this is not about the merits of systemd as a program.

GNU/Linux represents choice and freedom. The abundance of distros is proof of that. You can choose your preferred init system, system logger, cron daemon, desktop environment, browser, etc.

Now, systemd is being forcefully pushed to all distros. For instance, by merging udev (a part of the Linux kernel) with systemd. We can't even build a distro anymore without downloading systemd. User choice is under threat.

In this situation, some people align with the forceful approach of systemd. Some prefer to choose what goes into their computers. This is similar to the inclusion of DRM in Firefox, there's no middle ground.

So the debate is really about competitition vs a walled garden provided by systemd.

udev (a part of the Linux kernel)

I thought one of the advantages of udev (vs devfs) was that it was completely in userspace?

You're correct, but that's not the point. Some device drivers run in userspace, even the Linux kernel itself can run in userspace!

How is it not the point? You said "we can't even build a distro anymore without downloading systemd," due to the implication that udev was embedded in the kernel, but that's not true. You can build a distro - just don't use udev.

udev is a necessary component of Linux. You could say just use a fork like eudev. Fine (for the time being). But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.

udev is a necessary component of Linux.

Why do you say that? That's what I don't understand. As far as I know, that's not true. You can run a Linux system without the udev daemon, or with one written by you.

But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.

But udev isn't in the Linux kernel! How can I remove it from there?!

> You can run a Linux system without the udev daemon, or with one written by you.

A GNU/Linux system consists of several components. http://www.gnu.org/gnu/linux-and-gnu.html shows some examples.

If you remove udev from Linux, I see at least two problems. One of them is technical: programmers expect Linux to have udev, because that's what the Linux authors advertise. The other is legal: Linux is a trademark, and if you replace something and introduce some incompatibility, it's a bad idea to keep calling it Linux.

> But udev isn't in the Linux kernel! How can I remove it from there?!

I think here lies the misunderstanding, udev was previously in the kernel repository, now it isn't. Fair enough. But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Imagine we could only download GCC (necessary to compile Linux) as part of Adobe Flash, don't you think I could say the same? That "we can't even build a distro anymore without downloading Adobe Flash"?

But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole.

Yes, and udev would compose an hypothetical "Udev/Linux system". But Linux itself doesn't need udev.

GNU / GCC is different because you literally can't compile Linux without it. But if and when LLVMLinux succeeds, I don't think you could say the same.

> But Linux itself doesn't need udev.

Would it really work? I think you'd have to rewrite some parts of the kernel, but I may be wrong now, in the past or the future.

Anyways, we're arguing semantics here, it'd be better for all to separate udev from systemd. It's like Windows installers usually bundling the program with some crap, and I know most people don't appreciate that.

The codebase was part of the Linux kernel for a long time, however. That's what the OP probably meant.

For me, it is about the merits too, or lack thereof.

The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program.

The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it).

Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it.

Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever).

To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.

I feel your pain. I expect the badly-documented bug-and-vulnerability-ridden unmantainable mess aka systemd to collapse as abandonware in the future. That's what happened with similar projects before.

I used systemd last year to see if it was any good, and it's terrible. Specially journald, well it uses a binary format, I see this file, about 250KB, I wanted to decompress it as a text file to use my tools. OK, I had a brand-new very powerful computer. After 1 HOUR, I see a 5GB file, the decompression still running!

Another bug, I needed to power off with (unix sysadmins will laugh at this):

    sync; sync; shutdown -h now

otherwise systemd (systemctl poweroff) would randomly delete files in my home dir!

So yes systemd is also technically bad. That's why *BSD, GNU Guix and other alternatives are gaining momentum.

If systemd was just an init system, there wouldn't any problem. It's the fact is now includes about 30 other very non-init features that's the problem. Things like an NTP client, a network config tool, a boot firmware management tool, a login system, and a lot more.

Well, part of the emotions are probably caused by feelings of helplessness. How would you feel when someone says they won't fix a bug?

https://bugs.freedesktop.org/show_bug.cgi?id=64116

WONTFIX is a common enough response that many bug trackers have it in their default list of responses. WONTFIX is very much a valid response.

That's a terrible response to corruption of a key system utility. "Oh, corruption happens, deal with it." System logs are much too important of a subsystem to have such a blaise attitude when things break.

> What I don't get is how the init system of anything can evoke such emotions. It all goes way beyond expressing preference. The flamewars and vitriol that have been spread are disgraceful, and people are seriously considering switching to different operating systems because of whatever package runs their daemons and their startup scripts. It's embarrassing.

It's partly a hang-over from toxic communities and people ignoring all the evanglist advice. Linux had a lot of early discussion on Usenet. One feature of Usenet was robust discussion (often under people's real names) which could devolve into hateful flame wars. This was not limited to Linux discussion, but includes Vi vs Emacs, the pronunciation of gif, BSD vs GPL licences, microkernals, etc etc etc.

There are also people involved in this current argument who are difficult to talk to. These people have help create a totally toxic environment.

It's not limited to linux. There are several megabytes (doesn't sound much but don't forget it's just text) of arguing on Wikipedia over m-dash, n-dash, hypens and etc. and that place has rules to supposedly encourage collaborative behaviour.

Not just init systems. Try version numbers[1] or choice of default desktop for a release [2]. The default mark you, not removing any of the many alternatives.

[1] http://lists.centos.org/pipermail/centos-devel/2014-June/010... [and the many many subsequent replies]

[2] https://lists.debian.org/debian-devel/2014/08/msg00129.html [and the rest of the thread, and the other threads about the same issue]

I suspect this one has a lot to do with issues around the structure of the operating system and the way major components depend on each other.

> What is it about init systems that causes this outrage? I really want to know!

There are some technical concerns, but a disproportionate amount of criticism is because the lead developer[0] of systemd also developed PulseAudio, which was adopted by distros too early and therefore caused a lot of problems for people.

People remember PulseAudio without much fondness, so they are bitter and take it out on systemd.

It doesn't help that he has a somewhat direct manner of communicating, which some people find off-putting.

So, to answer your question, a lot of it is personal, not technical. That's why you see much more vitriol than you'd otherwise expect for a somewhat technically controversial, low-level piece of software.

[0] http://en.m.wikipedia.org/wiki/Lennart_Poettering

Not as much as you'd think, actually. A large part of concerns are technical, sometimes abstract though still quite valid (Rob Landley's take on it was good).

That said, Poettering's character is so distinctive that it's nearly impossible not to do a little jab against him.

Just so you know, what you are saying doesn't contradict what I am saying.

You're saying that there are technical concerns, and that those are a large number of the concerns expressed.

I'm saying that his personality and previous history with PulseAudio are a reason that those technical concerns are expressed far more often (and with more vitriol) than they otherwise would be.

I happened to work in parallel with Rob a while ago and could not agree more with him on his systemd opinions.

I just wish that Debian did not take systemd, that _really_ saddens me.

Another part of the problem is that people feel that systemd is being forced on them (more so than the usual "my distro switched to X, so I'm stuck using X"). The major issue right now is systemd-logind, a replacement for the unmaintained ConsoleKit daemon which is used to manage login sessions. logind provides functionality that is necessary for modern desktop environments, but it's designed to work only with the systemd init daemon. GNOME in particular has been talking about adding a hard dependency on logind, and once that happens the only choice of init system for people running GNOME will be systemd.