Systemd: The Biggest Myths

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.

You're right, it is mostly neophobia. I sort of tried to say that in my top comment; I don't think that systemd is technically inferior, I just can't yet justify switching to it.

But, I've been meaning to write about this for a while: I think neophobia is starting to become an unnecessarily religious article of faith in the technical community. I run a small consulting shop, we support (or try to support) just about everything under the sun. What this means is that every single time there's a significant hardware change, my hardware guy has to be on top of it; every time there's a new mobile device UI change, or platform, or service or software, he has to get to know it right away; every time PHP or MySQL or Linode or any of a number of aspects of Linux changes, I have to be on top it; every time a new operating system version is released, we have to be familiar with it.

And every single one of those little ecosystems assumes that you have the time to sit down and read and digest their documentation or play with their new way of doing things. And, if you don't, or if you miss something, you're chastised by the community (or, worse, by your customers).

It is exactly like being in college and having every one of your professors assign 3 hours' work each night and then wonder why you're making a big deal of it.

To make things worse, when something goes wrong, you know as well as I do that you rely heavily on familiarity. You don't want to be looking things up in a man page trying to remember the specific incantation for a particular thing while your budget shrinks by the second. I was lucky that the smbd/nmbd fault happened on my personal system; if it had happened to one of our clients, who has everyone using a centralized smbd share, then smbd failing to start would have stopped work for the entire company.

So, yes, it's true that I am not a fan of change for change's sake. Lennart argues that that's not what's happening with systemd. Maybe he's right. But, it is still another massive change in something that I use and support on a daily basis, that is going to irretrievably consume a little bit more time out of my limited life, that is going to force me to throw out all of the old familiar tactics ("hmm ... new client, their MySQL isn't starting, dunno where MySQL logs are on this system, let's start with `grep -R mysql /var/log/∗` ... oh wait, this is a systemd system, that doesn't work").

From that standpoint, I feel like the technical justifications in favor of systemd are a bit on the weak side.

Yep, we are better off now.

I remember trying to get bluetooth audio working in the alsa-only days. Or network sound with esd/ssh. Or figuring out how to route audio nicely apps. Or saving my laptop battery. Or many other features that were simply damn difficult to pull off.

People don't seem to remember how crappy the audio situation used to be, for users and for ISVs. I respect Lennart and the current PA maintainers a lot for tackling the problem head on – even if they didn't or couldn't do it perfectly – instead of just complaining about the sad state of Linux audio, especially in the face of all the criticism they got over it.

Yes, that bug discussion show very well what's wrong with Lennart and his software.

htop?

I'm not linux admin anymore, but I when I was, I used various service status software thingies only to find out whether the system thinks the service is running, because they tend to be wrong, and just annoy you (not starting crashed server because it "is already running" or something similar). I think debian doesn't even track service states, but I'm not sure.

Of course, with systemd it will be even more fun.