Systemd Is Now One Year Old; Why You Should Use It

[allquixotic]

D-Bus is absolutely not exclusively for the desktop! Please understand this. It's a data processing mechanism that runs as a headless daemon; or, more specifically, it's an IPC mechanism. The benefit of having it is that applications that need to talk to one another don't need to invent their own custom IPC mechanism (such as listening on a TCP port over a custom TCP or SOAP protocol; using UNIX sockets to send bytes back and forth; and so on).

So, we can solve all sorts of problems once and let programs reuse the functionality:
* Service / exclusive resource discovery (answers the question, "Is anybody else on the whole system using this resource?" -- such as a hardware device that can only be used by one process at a time, like an ALSA card). It's also easy to make this operation atomic, so that you can ask for resource availability, and if it's available, take it -- all in one operation -- so that it's impossible for two programs to query it, see that it's available, then both ask to claim it (that'd be a race condition).
* Bidirectional communication with a well-defined interface (answers the question, "What messages are there? What is expected of my program? What will the other program send me?"
* Asynchronous callbacks: Ask a remote server to let you know when it's done processing something, then continue doing something, then get the callback event and process it.

On Windows, there's WCF for something similar. And they (rightly) encourage people to use WCF not only for desktop applications, but especially for client/server communication and interprocess communication.

Anyway, if D-Bus becomes widely used by both client and server, it won't become just another annoying daemon; it'll be a central part of the operating system that everyone accepts. I'm not necessarily saying that we should convert existing applications' protocols over to D-Bus, but new applications are free to use D-Bus as they wish. And systemd does -- so what?

Another generalized IPC mechanism with some overlap with D-Bus is ZeroC ICE. Mutter uses that. While I think ICE is good, consider that if we use every IPC mechanism out there simultaneously, the combined library load on RAM is going to be much higher than if we just pick one. Since D-Bus has been around a long time and is fairly well-tested, standardizing on that would actually increase system performance and available RAM, not decrease it. (You can apply this same argument to any other IPC mechanism out there.)

BTW, systemd isn't just useful for fast booting, either. It has quite a lot of useful administrative functions that make it better than SysVinit for managing daemons. What do servers run? Daemons! Lots of them.

I don't know where anyone got the perception that either D-Bus or systemd are somehow geared for the desktop, designed for desktop use cases, designed for fast boot performance at the expense of bloat, or designed to benefit desktops while slowing down servers. All of that is unfounded. These two daemons are engineered primarily by Red Hat employees. Red Hat makes a majority of their income on selling server operating systems (RHEL is much less useful on the desktop than on the server due to its frequent obsolescence on the desktop. But many many corporations and governments buy RHEL support for servers.) Don't you think they have servers in mind just a little bit when planning out the core system utilities that will go into RHEL 7?

[roland]

Forget about Dbus on the server... Who cares about systemd on the server? It only has to boot once right? Nothing wrong with sysv.

[Chewi]

Forget about Dbus on the server... Who cares about systemd on the server? It only has to boot once right? Nothing wrong with sysv.

Yes but it's a lot of work to support more than one init system on a distro because each package then needs to have init scripts for each system.

[allquixotic]

Forget about Dbus on the server... Who cares about systemd on the server? It only has to boot once right? Nothing wrong with sysv.

systemd isn't just about booting! Ugh! When will anyone understand this?!

Even if your server has 2 years' uptime, the time will come when one of your services needs to be restarted. Let's say you change a core Apache setting -- whoops, restart! (or reload, as the case may be.) Let's say a daemon hangs and won't respond -- whoops, time to kill it and all its child processes! And if you deploy software that's anything less than 100% perfect, these situations can and do happen to everyone, even on RHEL or Debian Stable. Not to mention that upgrading packages from the package manager frequently requires a daemon restart or reload.

systemd provides facilities that make it easier to robustly support these kinds of configurations -- and you can even use systemd functionality to help your daemon provide a transparent restart!

Transparent restarts are already possible on e.g. Ubuntu, where a `restart ssh` will load an updated OpenSSH server without booting off any existing connections. This is fantastic if you are SSHed into the box to perform an upgrade, because otherwise you'd get disconnected as soon as the daemon restarts, possibly triggering a SIGCHLD in the update process, terminating the update early and maybe even preventing SSH from restarting, making the system inaccessible without direct console access.

But to pull off this transparent restart with SSH required some significant hacks in the SSH server and the scripting. By getting systemd to help you by specifically recognizing the need for this use-case, it's much easier to (for example) write your own in-house production application, and then get systemd to help you perform transparent restarts. Hopefully, other existing free software apps will buy into this, and within a few years we'll have all TCP/IP based daemons on GNU/Linux performing transparent restarts without disconnecting the live sockets (a huge inconvenience for users).

This is just one use case where systemd helps make server administration easier. Throw in the additional logging / reporting facilities; the optional GUI management; the excellent `systemctl' console command; and so much else -- and this project is clearly aimed squarely at servers!

Yes, there is overhead involved in the features I've mentioned. But it's two-thousand-freaking-eleven. If you're still running a Pentium 4 or earlier, it's time to upgrade. Seriously. Now. Go out to Best Buy and buy a system with a Core 2 or later processor. DO IT. You are living in the stone ages.

Linux hasn't been struggling for adoption (on the desktop or the server) for want of performance. Its main sticking point is the fact that, desktop or server, it's much more difficult to administer than Windows. The kinds of features we're just now getting around to with systemd have, to some extent, existed for a long time in Windows using the Windows Service subsystem and all the infrastructure associated with it (service accounts, the event log viewer, various MMC applets for most critical services, etc.) -- server sysadmins love this stuff.

Systemd, on the other hand, beats out Microsoft's performance by a long shot; doesn't require a GUI or remote X session; and even one-ups it on features (well, to be fair, it's hard to compare features when the core design of Windows and Linux are so dramatically different). But there's no question that systemd brings us a lot closer to feature parity than the stupid sysvinit that basically knows how to run shell scripts in a directory, and that's it.

But hey, if you absolutely insist on running your Pentium 66 MHz until the CPU is literally incapable of operating, go ahead -- but run something like Slackware, or RHEL 4.

It's an indisputable fact that the system requirements of successive versions of operating systems goes up with each release, because OS vendors assume that their customers are also on a hardware upgrade path. If you're running old hardware, no problem -- use an old operating system. If you can keep up with the upgrade curve, you can run the latest operating system. This is why you can't run Mac OS X on a Mac from 1990, or Solaris 10 on a first-generation, entry-level SPARC server with less than 128MB of RAM, or Windows 7 on a IBM PC originally designed to run DOS.

We on the free desktop have the advantage that our upgrade curve is rather less steep than the competition: even with hardware that would be considered quite old today -- something like a R300 based radeon graphics card and a Pentium 4 -- it should be possible to chug along on Ubuntu 11.04 with Unity. It won't be screamingly fast, but it gets the job done. You'll probably have a bit more difficulty with a 3dfx card and a 486, but we do reach much further back than the competition -- has anyone tried to run Windows 7 with a P4, R300 and 512MB of RAM? You won't get very far -- have fun with the "Basic" theme.

So basically, systemd is the future, because it provides critical features and functionality that have long been requested by system administrators (for servers) and desktop integrators (for desktop distros). Yes, it increases system requirements slightly by consuming RAM and/or CPU cycles, but if you'd rather not have the features, my guess is that CentOS 4 will be downloadable at least until the end of the CentOS project, or barring that, well into the 2020s. Have fun with that.

[roland]

systemd isn't just about booting! Ugh! When will anyone understand this?!

I don't usually use smilies but I would have added something sarcastic if I knew it would have prevented another article =) I agree with you.

[V!NCENT]

If your computer struggles due to a standardized IPC mechanism thembyou could be thinking about uhm... upgrading your early 90's tech?

And systemd is about managing, tracking, selfhealing processes, where d-bus is the key defence.

If it's broken by design, or rather not there at all; it should be fixed.

[elanthis]

dbus is wasting resources? only for desktops? it's being used in embedded devices as the core ipc mechanism more and more. if your server is choking on the ~1.5MB of memory that dbus is going to consume while my highly-resource-constrained phone can use it just fine with memory to spare then your server is a piece of shit and needs to be tossed in a river. you clearly aren't able to do anything else useful with that machine besides using it for an anchor.

[locovaca]

Transparent restarts are already possible on e.g. Ubuntu, where a `restart ssh` will load an updated OpenSSH server without booting off any existing connections. This is fantastic if you are SSHed into the box to perform an upgrade, because otherwise you'd get disconnected as soon as the daemon restarts, possibly triggering a SIGCHLD in the update process, terminating the update early and maybe even preventing SSH from restarting, making the system inaccessible without direct console access.

I don't disagree with what you said, but any admin worth their salary doing a remote upgrade over ssh will be running it through a screen session, which pretty much eliminates this use case.

[curaga]

Nice trolling everyone allquixotic, even more tl;dr than usual.

D-Bus is absolutely not exclusively for the desktop! Please understand this. It's a data processing mechanism that runs as a headless daemon; or, more specifically, it's an IPC mechanism. The benefit of having it is that applications that need to talk to one another don't need to invent their own custom IPC mechanism (such as listening on a TCP port over a custom TCP or SOAP protocol; using UNIX sockets to send bytes back and forth; and so on).

That be the exact point! There be many trusted, tested IPC mechanisms existing before dbus, that _don't_ require a fricking daemon. D-bus is NIH, and simply wrong in that it's a needless daemon.

And systemd does -- so what?

It's the _init_. It should _not_ depend on anything else, especially not another daemon.


As for all the ad-homs against fair hardware, carry on

[peppepz]

I hope it doesn't become another PulseAudio. I can live with a broken audio experience, probably not with a broken init subsystem.