Systemd: The Biggest Myths

http://0pointer.de/blog/projects/the-biggest-myths

by janerik • 13 years ago

131 114 13 years ago

mhurron2• 13 years ago

> systemd being Linux-only is not nice to the BSDs.

>Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it

systemd is not portable, it wasn't made to be portable, it relies on far too many linuxisms. Therefore the BSD's don't care about it. It is not 'the BSD's don't care about it so we didn't make it portable.'

mseepgood5• 13 years ago

They would never use a new GPL licensed project for their core OS.

diegocg3• 13 years ago

I disagree, I think that Lennart is right. Nobody really cares if systemd is not portable. Upstart was not portable to BSDs, and nobody cared. The traditional sysvinit system was, AFAIK, not portable until the debian/freebsd people bothered about it. Heck, the init scripts in Linux used to be not portable even between different Linux distros.

launchd (OS X) and SMF (solaris) weren't portable, either.

By the way, when was the last time a BSD operating system cared about making their init system portable to Linux?

I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.

4ad3• 13 years ago

You can write software ignoring how it will be started and you (or others) can write init scripts for various traditional systems. This is way harder if you use systemd; suddenly you need to care about the init system, and you might sacrifice init independence for pragmatic reasons (I want to support systemd, but I don't want to write this yet-another-abstract-wrapper-layer so that someone else might use it with other type of init system).

mhurron2• 13 years ago

> I'm not sure why systemd not being portable to other operating systems is suddenly a big deal.

Because software being written that has systemd as a dependency will be Linux only software.

jeltz7• 13 years ago

The only one greatly affected by systemd not being portable is Debian. Their BSD distribution uses the Debian version of sysvinit.

stox• 13 years ago

Pretty much a self fulfilling prophecy.

X-Istence5• 13 years ago

The BSD folks may not be interested in systemd itself, we are still interested in running various bits and pieces of software on top of the platform. When software starts requiring systemd just to run we have no chance what so ever at porting that software.

The same is true for a lot of Linuxisms. I have spent an awful lot of time getting software that states on the tin it is written for POSIX to run on BSD because its source code uses all kinds of Linuxisms.

The same holds true for people assuming that /bin/sh is bash, which may be true on certain Linux distributions but isn't so most other systems. I've started noticing the same issues with other things as well, such as the symlink from /bin to /usr/bin, /sbin to /usr/bin ... whereby software believes all software lives in /usr/bin when in reality that isn't the case for the BSD's.

cout• 13 years ago

I don't want systemd because I don't trust Lennart Poettering to be able to write reliable code.

chris_wot3• 13 years ago

Why the heck do people whale on him so much?

betterunix4• 13 years ago

Well, consider his response here:

https://bugzilla.redhat.com/show_bug.cgi?id=461546

First, he denies that this is something people need. Then, when he is told that people need it, he says that they are just doing things the wrong way. Then, when people point out that this is neither unusual nor the wrong thing to want to do, he just repeats that this is not what was intended so too bad. He offers no advice on how to do things the right way despite being the only person who seems to think that everyone else is wrong.

bitwize• 13 years ago

He's this decade's Ulrich Drepper.

jeltz7• 13 years ago

One reason is that pulseaudio broke audio for many Linux users (including me). Linux audio has long been problematic but had reached a point of stability when pulseaudio was adopted by some of the major distributions. I have no idea if the problem was that pulseaudio was broken, with distributors messing up, or with Linux audio drivers.

When a problem is easily solved by just an "apt-get remove X" it is easy to start hating the piece of software. No matter who was actually at fault.

donniezazen4• 13 years ago

Have you reviewed Systemd code and submit changes to make it more reliable?

nsmartt3• 13 years ago

Not everyone has time to contribute to every project that may be useful in some way. If something else works the way one wants, there's no call to put time and energy into a competing project.

4ad3• 13 years ago

Downvoting this post is unwarranted. Everything that Lennart Poettering has ever done was an unreliable clusterfuck[1] astray from the Unix philosphy. There's nothing that he has ever done that is considered "good" by a majority of Unix-derivative users.

[1] http://www.youtube.com/watch?v=ZTdUmlGxVo0

mseepgood5• 13 years ago

> http://www.youtube.com/watch?v=ZTdUmlGxVo0

Poettering has clearly the better arguments than this reactionary Draxinger die-hard.

kklimonda• 13 years ago

I remember watching this video and Poettering's argument were very sound and he has managed to repel most (if not all) Draxinger's points.

The problem with "it's not the UNIX way" argument is that a lot of people don't care about UNIX that much, they just want a good system. Poettering mentions in that video that all his, and his colleagues' work (pulseaudio, consolekit, udev into udisks/upower) has been done because there was an actual demand for those features. There is a reason why most distributions use their work even as people complain about them.

ben0x539• 13 years ago

> There's nothing that he has ever done that is considered "good" by a majority of Unix-derivative users.

Is there really anything at all that a majority of Unix-derivative users can agree on?

betterunix4• 13 years ago

Will they have the same attitude as the ConsoleKit/PolicyKit/_Kit people have when someone says, "I need to do something different, but this service is preventing me from doing it?" As an example, I want to set up my system so that one user can play audio even when a different user is "active," yet after hours reading through bug reports about that and mailing list archives, all I could find where these responses:

* "Not our fault, it's that other service."

* "We are never going to support that. You don't want it anyway."

* "Well that will be fixed with systemd"

* "You can add the user to the audio group, but that's wrong and you should not do it. You should instead do that thing that the other guys are telling you not to do and that they will never support."

* "This will be fixed with systemd!"

So, I guess now the question is, when someone comes along and says, "I need to do X, I used to be able to do X before systemd was in use and now systemd is stopping me, how can I fixed that?" will systemd maintainers respond with things like the above? Will there be useful and thorough documentation, so that users can fix things without having to bug the maintainers?

mseepgood5• 13 years ago

Most "arguments" I read are are either ad-hominem or ad-pulseaudionem attacks.

fosap5• 13 years ago

I don't see a single ad-hominem.

And ad-pulseaudionem is just like a ad-networkmanagerem or a ad-dbusiem: If your software design sucks and it does not work good enough that you don't have to care about this you will be told it sucks. And to me it seems that systemd is written in the spirit of dbus and nm.

zdw• 13 years ago

Given the title, I'll allow that most of these points are defensive and brusque. Unfortunately, this tends to be par for the course for the developer, and I think that turns people off.

Fundamentally, systemd tried solving too many problems at once, in a ways that inadvertently annoyed people. It replaced so much of the core infrastructure that upgrading systems resulted in an admin experience that feels alien. Giving people new tools to deal with things like binary logging != instantly changing every admin's CLI muscle memory.

I'm not saying that systemd doesn't solve valid problems (the issues it addresses are truly quite important) - it just goes about it in a dramatically jarring way.

diegocg3• 13 years ago

>Given the title, I'll allow that most of these points are defensive and brusque

Not really...

mseepgood5• 13 years ago

> most of these points are defensive and brusque

I prefer reading "This is wrong, because ..." over "This is right, but ...", since it's more honest.

jeltz7• 13 years ago

The myths are a mix of those that are correct but often misunderstood and those who just are plain wrong. Those which are plain wrong cannot be responded to with "This is right, but ...".

thaumaturgy5• 13 years ago

3. I don't understand the desire to trim seconds off of boot-up time (even assuming that systemd does this; it didn't for me). The goal should be to restart less often, not to restart more quickly.

5. The systemd documentation is indeed very good, and that's probably one of the biggest drivers behind its adoption. However, it is also difficult. A big part of the pushback from people over systemd is that it also replaced syslog, and did so with its own custom binary log format. To quote from a forum thread I started shortly after updating my old system to systemd, "Getting smbd/nmbd to work again was a real adventure. Like other users reported, it would just silently fail when starting it from systemd. No error message when issuing the start command, and only a vague "failed" in status. I ended up having to track down Lennart's blog post on "systemd for administrators" to figure out how in blazes to extract anything useful from that cussed binary log system he invented. My first half-dozen or so attempts to get anything useful out of the log journal got exactly zero results; I finally got lucky on another approach..." (I ended up abandoning that distribution altogether after that and a number of other frustrations, and the response from the forums.)

13. The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd, making that software difficult (or impossible) to port to BSD.

14. It seems weird to me to hear someone else decide for other people what is or isn't a "negligible" amount of work.

15. So ... systemd is in fact Linux-only by design. How does that jive with 13 again?

19. systemd may not "force" you to do anything, up until your distribution adopts it, pushes it as an update, and then you find yourself spending hours trying to figure out how to troubleshoot a problem that didn't exist before the update. Then it certainly is forcing you to do something.

Here's the problem in a nut shell as I see it: if systemd had been the default in Linux for the last ten years, probably the tool chain around it would be mature enough to meet everyone's needs, we would all be accustomed to the specific commands needed to control and interact with and debug systemd stuff, and if someone came along and proposed replacing everything with a syslog daemon and a pile of init scripts, there'd be rage and outcry. That is to say, I don't see anything inherently bad about systemd.

But, what is enormously frustrating is to have something that works, and be well adapted to it, so that if something breaks I know exactly where to look, and then have all of that be replaced by a foreign system that breaks old things in new ways and requires hours spent trying to figure out what the hell happened.

If the replacement system offers serious benefits over the old system, that offsets the pain slightly. In this case, I've yet to see what the actual benefits are; I have no idea what problems systemd is attempting to solve which are so severe, so immediate, so intractable that they require a jarring change to some of the fundamental parts of the operating system.

meaty3• 13 years ago

Regarding your last point, the main thing that systemd excels at is managing the mishmash of power events, other ACPI events, service management and integration with DBus (which everything seems to require these days).

However, I run Linux in three locations and here's where systemd fits for me:

1. Servers. No use whatsoever. There are two power states: off and on. None of this is really an improvement over SVR4 init. It's just another damn tool to learn.

2. Desktops: No use whatsoever. I run mine like servers simply because if I need remote access, trusting stuff like WOL and ACPI is just silly on Linux.

3. Laptops: No use whatsoever. This is simply down to the fact that the power management on Linux i.e. hibernate/sleep support is a bag of shit. I run mine as power states off and on, much as 1 and 2.

Regarding boot speed - my laptop boots in about 14 seconds (SSD). Who cares about making it faster?

I find that a shell script is far more useful i.e. it doesn't enforce constraints on you which have to then be added as features to systemd. Plus shell scripts are generic tools i.e. learning how to write them will be of more use globally than learning systemd guts.

So basically, screw it.

The problem that this outlines is that Linux's power management, event and ACPI state management is crappy. We don't need another layer of crap over the top of it to make it work properly.

jeltz7• 13 years ago

To me systemd looks mainly useful for servers. Some of the nice server features:

1. It is way easier to write a systemd unit for an in house application than it is to write a correct sysvinit script.

2. Everything runs in a cgroup making it easier to add resource limits and see which process is started by which service.

3. Easy to check which daemons are running and not.

4. Reduced startup time for containers.

TheCondor• 13 years ago

Learning new tools is bad?!

sophacles• 13 years ago

Regarding your response to 3: I agree that system stability is a very important goal. However, there are also plenty of use cases for faster boot times, so it shouldn't be disregarded as a valid pursuit in system engineering.

jmj423• 13 years ago

> The goal should be to restart less often, not to restart more quickly.

No! These are not mutually exclusive. The goal should be to restart less ofter, but restart faster when it is necessary. Systems have to restart. Well run/maintained/designed systems may not need to restart ofter, but they do need to restart.

Consider: Many moons ago I was responsible for (among other things) the company's CRM systems. These were a couple of mid-range Suns that were extremely reliable. On an anual basis, the business operations department issues downdown cost estimates for business critical systems (these were used to develop inter-departmental SLAs), and estimated that the CRM database server cost the company about $250K per hour of down time, or, almost $4200 per minute. Or read another way: a 10 seat license for our software in a saturated (niche) market.

The point is, outages happen (no you can not account for all possible failure scenarios), and startup times matter.

thaumaturgy5• 13 years ago

Sure, but given that developer time is a bounded resource, we can't really expect to get both fewer restarts and faster restarts. I sympathize with your example, but I would expect that you had already seriously optimized your startup process, and since systemd doesn't make services start more quickly (it only does a better job of parallelizing them), I doubt that it would have made a huge difference in your case. Assuming even a very generous 5-second startup difference, that would have only made a $350 difference per incident.

flogic• 13 years ago

While start up time is critical, how much time is being lost by imposing complexity on the humans? At least in my opinion that bit about binary logs makes the entire thing a no go. The absolute last thing I want in any sort of time critical situation is to complicate the process of reading logs.

astine• 13 years ago

As someone who's administered Solaris machines rather extensively, I find the SMF (the init system on Solaris which, in part, inspired systemd) to be much easier to manage than sysvinit. Specifically, it makes it easier to add new services than either writing new shell scripts or adapting old ones. It makes it easier to make services which depend on one-another. And it makes it easier to know which services are running and what state they are in.

I see other developers/sysadmins here saying that sysadmins usually have a template initscript which they can use to author new ones, but that's really still a lot of work if you want to do anything not covered by the template and it leads to duplicate code. (It's literal cut-n-paste programming.) Initscripts expose a lot of implementation details. Even worse, they're different for every Linux distro so the initscript for your application has to be different for every distro you want to be on.

I think the most telling thing here is, that the distro maintainers, who are the ones who write the bulk of the initscripts for Linux systems, are the ones pushing for the adoption. It's making their lives easier.

X-Istence5• 13 years ago

There is still a template for SMF stuff ... at least, I don't know how to make a new file from scratch, I have a template and use that ...

jlgreco• 13 years ago

> "The problem for BSDs isn't so much that systemd is or isn't portable to them; it's that some upstream software is beginning to require systemd"

See, to me this is just a "shit barometer". If upstream software requires systemd, then almost without fail it is shit and, at least outside the linux ecosystem, I am better off not using it.

lucian1900• 13 years ago

The intensity of people's hate for this guy is mind-boggling. Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues.

Even without such an impressive track-record, people should at least give him the benefit of the doubt.

Even a cursory look into systemd design debunks most of the "criticism" people have against it.

betterunix4• 13 years ago

"Most of the stuff he made is really nice, proven by the fact that it's being used widely without issues."

Without issues? PulseAudio is loaded with issues. The only time PA works correctly is when you are doing things the way Lennart thinks you should do them -- which is basically the way desktop Windows and Mac OS X users are expected to do things. Another way to put things is this: Lennart's software designs dictate how users should use their computer, to the exclusion of all other use-cases. Doing something cool or unusual with PulseAudio is like pulling teeth.

the_mitsuhiko• 13 years ago

Pulse Audio is not perfect but what before was. People were bitching about PA and wanted OSS back. I seriously doubt that many of those actually do anything reasonable with audio.

ragenz• 13 years ago

Myth 31: "I heard it was written by web developers."

sparkie• 13 years ago

No, that's Gnome-shell.

howeyc• 13 years ago

> 13. Myth: systemd being Linux-only is not nice to the BSDs.

> Completely wrong. The BSD folks are pretty much uninterested in systemd. If systemd was portable, this would change nothing, they still wouldn't adopt it.

> 15. Myth: systemd could be ported to other kernels if its maintainers just wanted to.

> That is simply not true. Porting systemd to other kernel is not feasible. We just use too many Linux-specific interfaces.

So what happens to software written for Linux that can be (and currently is) ported to BSD when it starts to require systemd?

nona2• 13 years ago

If it starts to rely on systemd, the question you should be asking, is: why does this program want to depend on systemd?

It's to interact with the lower plumbing - ie. set up hostname, locale, timedate, multi-seat etc.

If these interfaces are missing, the software should still work minus a few missing features. Applications could still #ifdef all they want to make things work on BSDs, no change there either.

Or the BSDs could make their own implementation of the plumbing interfaces. Lennart even provided a handy chart: http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...

Honestly, it's about time we standardize and stop wasting time on these low-level things. I'd rather work on software higher up in the stack, than wasting my time working around trivial differences between the Linux distros (bonus points if they get adopted on other the BSDs too). But that's just me.

ElliotH3• 13 years ago

Benefits to me as a desktop and laptop user of systemd.

1) Speed does matter. Fast boots are good. 2) The new journal is just better. Finding something in the logs is easier. 3) Service files are easier to write than init scripts and one can have more confidence they will work as intended as you need write very little configuration oneself. 4) Knowledge of dependencies means I never have to worry about starting dbus before gdm. It just does what is necessary to do the correct thing.

I personally want all of those things. I am really happy they came to Arch and Fedora. They both feel much more modern for it. Working on systems that use older init systems now feels archaic.

Let's move with the times. I remember the same set of complaints when we got NetworkManager. I remember the same complaints with PulseAudio.

Guess what? I now have systems with excellent networking and excellent sound.

thaumaturgy5• 13 years ago

NetworkManager is still popularly referred to as "NetworkMangler", and for good reason. I had serious problems with NetworkMangler on two completely different distributions over a period of two years. I finally solved the NetworkMangler issues by switching to Wicd; its interface is crude and ugly, but it damn well works. I haven't had to restart my laptop to get a working network connection since.

If NetworkManager is an example of how great systemd can be, then I just became vehemently opposed to it.

fosap5• 13 years ago

>I remember the same complaints with PulseAudio.

And this is perfectly the reason number two why i won't switch to systemd (reason number one is there is no need for it). PulseAudio does not work. It sucks. The irc channel is full of clueless (but trying to be helpfull) people. And nobody cares. I want my Alsa back. But now it's too late, i hope systemd will either be better (doubt it) or never be this popular.

And, I cannot lie, I don't want it because I don't want another dbus. freedesktop, stop turning my linux into a single user os. Next thing is they want to abolish x11. Sure it's about time for x12, but wayland? I just don't understand the community that surrounds Linux anymore.

bkor9• 13 years ago

PulseAudio works perfectly fine for me. It did have issues in the beginning, but for many years I didn't have a problem. You said elsewhere that you had issues, but that you still have issues I can see. Others, could be, no idea.

But I don't have any issues. I don't have high CPU usage. It just plain works since various years.

delinka2• 13 years ago

    6. Myth: systemd is not modular.

    Not true at all. At compile time you have a number of  ...

So it's only modular at compile time. This seems like a negative to me.

bkor9• 13 years ago

You can also disable various things during runtime. A->B does not imply B->A.

delinka2• 13 years ago

It's not assumption by implication, it's due to omission. I cannot assume a feature exists in your software, you must tell me it exists. As a contrived example, why would I expect your To Do List app to manage recipes?

Niten• 13 years ago

This article from last August hits the nail on the head with regard to systemd:

http://www.pappp.net/?p=969

"I’m not sure that this is a bad design, but it is most definitely not UNIX or anything like it."

bkor9• 13 years ago

The blogpost already addresses everything that above article gets wrong.

Systemd: The Biggest Myths

Related Stories