What “technical” concerns do I have with systemd?(blog.lusis.org) |
What “technical” concerns do I have with systemd?(blog.lusis.org) |
But that doesn't mean that there aren't better alternatives. My personal preference is runit[1], which is based on djb's daemontools[2] and gives you all the dependency management and speed gains of systemd without the monolithic architecture and without the complicated shell scripts of sysvinit, as well as cool features like service management trees for non-root users. (In fact, runit doesn't need to be run as init—you can run it as a non-root user and provide service management even if you use another init. It just happens to make a nice init.)
The tests I've seen show that a minimal system with runit boots roughly as fast as than a minimal system with systemd. That doesn't mean runit is the end-all solution to "which init"—it's perfect for my needs, but maybe not yours—but it does mean that the choice is not a choice between systemd-but-fast versus sysvinit-but-slow. The field of choices is much, much broader.
Now, systemd the package is getting pretty bloated. For instance, there is no reason why stuff like networkd couldn't be in a separate package that depends on systemd. But that's not really an architectural issue, and not much of a problem for users. (For instance, you can disable networkd just fine.)
"Modular" only means that a system is factored into components that address logically separate concerns. "Monolithic" means that your modules are tightly coupled.
For example, the Linux kernel and X.org are both modular and monolithic, as is systemd. Coreutils, by contrast, is modular and NOT monolithic.
There seems to be a distressingly high amount of people lately who can't seem to tell that monolithic and modular software aren't mutually exclusive, and that you can be both. Lennart seems to propagate this idea lot that being modular automatically makes you non-monolithic.
S6 apparently solves this: http://skarnet.org/software/s6/index.html
Unintegrated desktop linux is painful, and the fixes for it so far have mostly been hacks. Systemd actually attempts to create some kind of modern cohesive system which is a good thing.
Maybe you don't see the downsides to the lack of integration because you're just used to putting up with them.
If Gnome requires systemd, lets drop Gnome.
Boot times may be important for cloud instances, though; the faster you can spawn more nodes to accommodate a load spike, the better. But cloud instances are usually pretty stripped-down, and often get spawned form pre-configured images where much of the discoverable stuff is hardcoded.
Slackware is an example of this. They removed Gnome almost a decade ago.
I'm a beginner sysadmin, and therefore not really knowledgeable about the recent changes in Linux -- however I've seen FreeBSD in production(ish), and it was indeed a more pleasent experience. Paths, configuration, the package system, the documentation (!) all felt nicer.
I could be wrong on this, though. Just my thoughts.
Tighter coupling with rapid integration in functions and therefore changes in glue makes it harder to work piecemeal. Distributions have very different time lines. Pity the packager stuck trying to back port patches to an earlier version of the system when the upstream project(s) is(are) pushing out security updates based on the current versions and their current glue/api.
Of course it will work and work well. Redhat are betting their major product on this set of modules. The problem will be the load on other projects working around this.
"I have to provide a system that runs reliably and can easily be reasoned about and yet I have to build it on distributions created by people who consider how long it takes to get to the fucking GDM login screen and if shutting the laptop lid will cause the system to hibernate properly or not."
There have been "better init" options for many years, none of which gained much traction. So most of us figured the community as a whole wasn't very bothered. IMO systemd has only achieved "popularity" by using some very underhanded tactics.
How'd PulseAudio get stuck in so much stuff? Is this a pattern?
Removing systemd might have consequences for GNOME, but that's not a concern on servers. There is a significant enough anti-systemd contingent in Debian (not to mention Debian also supports kfreebsd, where systemd doesn't run) that I'm confident sysvinit will remain a viable option for servers and non-GNOME desktops on Debian. Even GNOME desktops may work on Debian without systemd thanks to the work being done on systemd-shim.
Well I gather that is the intention but there are a few bugs at present around that and an ongoing issue about upgrade from Wheezy to Jessie changing the init system silently. See Debian-devel for gory details.
I like to think that a knowledgeable neckbeard suggested PortAudio and the info got mangled in transit :-)
> Linux is becoming the thing that we adopted Linux to get away from.
It's just true in many more aspects than the one where this sentence is placed.
Maturity: it certainly feels rushed that in less than four years systemd went from nothing to the default init system in most Linux distributions (if I'm not mistaken). For something so basic and important you'd think a good amount of testing and bugfixing should happen before that. We are taking our time with btrfs and Wayland, so why the rush with systemd? We certainly could endure some more years with the previous init systems. And this comes from an Arch Linux user, I like my software as fresh as I can I get away with, but it still seems odd.
Compatibility: this troubles me the most, you see hard dependencies appearing like what we currently get with Linux, systemd and GNOME. When people talk about this they are usually referring to the BSD family. That's a legitimate concern, but think about this: if in the future appears a brilliant programmer who designed a free kernel which runs circles around Linux, what will we do if everything is so tightly coupled? We have to consider the possibility that we won't be running the Linux kernel forever and be prepared to switch if something better appears.
Maturity should not be confused with age. There is certainly positive correlation between the two, but it's not necessarily that strong. A piece of software that has been around for four years and been used by everybody will be more mature than software that has been around for ten but was only used by a small community.
There is also a chicken-and-egg problem here: software needs get widely adopted _before_ it can become mature.
You don't need systemd to solve that, though!
[Citation needed]
From where I stand, systemd is what I always wanted on a server.
I do not want parallel non-deterministic booting on a server. If it works I don't care because I don't reboot daily/hourly/for fun. Its a linux box not Windows. If it doesn't work then non-deterministic behavior makes race conditions and error messages very confusing.
There is an inherent architectural / philosophical violation where flexibility is considered "unix"ish yet it is forbidden under systemd domination. If you disagree with the above paragraph for init system on a server, thats OK, I think someone with that has the wrong opinion but I respect an honest disagreement. Under a unix-ish philosophy there have been about ten alt-inits over the past couple decades that'll parallel / non-deterministic init, so go ahead friend, more power to you, give one a try until your fingers get burnt. Sysvinit (or BSDs init) will be waiting for you when you return. This flexibility, this compatibility, is philosophically forbidden under systemd.
You will do it the systemd way, because we won the political battle, not for technical reasons (god knows systemd is not the first attempt at this architecture). Or you will be forced to leave. Well OK then. The future is looking very freebsd to me. So long and thanks for all the fish!
"I’m going to state up front (and people are free to disagree with me) that I believe you cannot provide a distribution of Linux that is both designed for the 'server' and the 'desktop' and provide a product that is worth using on either."
I, uh, what? Someone let everybody know that, as I'm pretty sure all the popular server distros (I guess not CoreOS, but that's pretty new) work just fine as desktops. Heck, Ubuntu is a very popular server distro[1], and it's certainly a desktop distro. And it's not like sysvinit wasn't used on both the server and the desktop.
http://www.openstack.org/blog/2013/11/openstack-user-survey-...
CoreOS is basically ChromiumOS minus the GUI. It'd be pretty easy to make a "desktop CoreOS" distribution by adding ChromiumOS components.
Slackware is a major distro. So I expect everyone who opposes systemd to migrate to Slackware, and I'll get even more slackbuilds to browse through on SBO, right?
And it's very sad: Linux won, thus Linux becomes everything it stands against.
Let's restart the cycle for the next 30 years. Maybe FreeBSD this time? Or is it time for a plan9-like system?
By your line of reasoning, the GNU Hurd is a monolithic OS, because most Hurd servers live in the same source tree and send messages to each other at runtime.
Another criteria is whether you can swap out one component without breaking the whole. You can't do this for journald, for example. You're forced to keep it by reducing it to a sink that redirects to your syslogd of choice. On the other hand, replacing parts of the GNU coreutils with those of 9base or sbase, for instance, won't break the rest (though it will break programs that depend on the GNU coreutils' extended options, of course).
I think a little while ago there actually was some work done on making kernel panics display a QR code but I doubt it'll ever be merged in if it's even done.
Areas of responsibility are implemented by standalone mechanisms that compose to create the larger integrated system and can:
1) Run in isolation from their upstream dependents.
2) Be replaced individually.
And seriously, systemd isn't one single daemon either. It's a collection of daemons running that communicate over a common protocol. It isn't all-or-nothing, either. Only a few of the daemons are considered "core" and the rest are optional. And, because they use a common documented protocol, even the core components can be replaced. You don't hear about alternatives because nobody has really written any, but it doesn't in any way prevent you from doing it.
I think the legitimate concerns about systemd are things like losing portability of stuff like Gnome to BSD and systemd's short history, but it isn't one giant monolith executable or anything like people say.
What common protocol? Mac OS X doesn't have dbus. It recently acquired XPC, but XPC is NOT a system bus -- it's simply an IPC library. It's neither required, nor universally used, nor is it terminally glued to the remainder of the OS.
> You don't, for example, just replace launchd with some other init system.
You don't? Says who? All launchd does is serve as an inetd/cron-esque daemon. The system daemons themselves continue to vend standard sockets and mach ports, and launchd itself does not pervade their externally vended interface.
> You don't just say "hey, screw Aqua I want to use something else."
Actually, you can. The display stack is driven by IOKit; XDarwin can run directly atop said stack.
Likewise, none of the "Mac-like" features that you want -- for example, automatic network configuration -- rely on any sort of centralized entity that pervades all daemons. There's a seperate system -- SystemConfiguration -- that provides that functionality, abstracted through a set of well-defined APIs and modular and distinct from the remainder of the system.
> * It's a collection of daemons running that communicate over a common protocol.*
Hence it's really rather monolithic, because to play in the systemd universe, everything has to conform to systemd's tightly coupled design.
Yes and no. It's true that OSX uses a variety of separate daemons, that run in different pids.
However they are all "required", "packaged together", "part of one source tree" and "shipped by a single vendor". In this respect they are a lot like systemd.
In fact it is arguably a lot more integrated. Both Python and Ruby are OSX dependencies. systemd isn't even close to that much of a power-grab.
MacOS is quite tightly integrated, it's what Apple does. Darwin is a bit different, as it's much more BSD-ish; with that I agree. But MacOS is a lot of stuff on top of Darwin and replacing any part of that would require tons of very MacOS specific code to do. Apple most definitely does not intend for their users to be able to replace logind or Aqua or pretty much any core service.
Probably a better way to phrase it would be to consided how much effort it'd take to run Aqua on BSD. You'd have to port basically everything that is MacOS. To me, that is what a monolithic system means.
For me, it's a combination of things:
1. Proper dependency management, where I specify dependencies as they are, rather than flattening the dependency graph.
2. Proper service supervision. I've had upstart lose track of running processes, which is silly - you had one job!
3. Ability to decouple the init system's view of "process is running" from "process is ready/live". This is nice if you want to await liveness by letting the system supervisor tell you if the service is live or not, rather than writing a bunch of external scripts or checks.
4. A single place to modify the way system services are run, and unified config for e.g. resource limits, and tools for working with them.
5. Simple exploration and interleaving of logs from various communicating services via journalctl, which is insanely helpful for debugging things in a distributed system. You can see the calls come in from the network and bounce between services, and see exactly where something goes wrong. You could do this with other solutions, but I get this out of the box with journalctl, and I can look in more detail at any of the services, or when I'm checking a service's status.
It's true that many of these things could perhaps have been done in other ways, but the fact is that the systemd developers did the work to make it happen and now I can focus on my product, rather than on learning a bazillion pieces of plumbing to enable me to ship product. I'm fine adapting a few things to run via unit files instead of shell scripts if it means I can ship more correct and more reliable product in less time.
systemd is not reliable, unlike eg daemontools, the developers are busy adding new features and don't care at all about old bugs. They say if you're not using one of the latest kernels, tough luck. So you're continuously debugging systemd "modern innovations" instead of focusing on your product.
If you're using Ubuntu, let's hope that by the time it gets adopted, systemd has evolved into a functional, dependable component. I wouldn't bet my product on that, though..
What old bugs are you talking about? the only old bugs I can find are fixed or non-systemd bugs that weren't cleaned up
>They say if you're not using one of the latest kernels, tough luck.
Where recent means at least 3.7, or 3.8 if you want Smack support.
>certain problems with systemd will take down the whole system, and make it unbootable too!
>you're continuously debugging systemd "modern innovations" instead of focusing on your product.
[citation needed]
I've been using systemd and systemd user sessions since Arch switched over and the only issues I've come across have been my own fault.
Granted I could choose something better than monit, but then why add another layer to hide brokenness, when we have the capability of doing it correctly in the first place.
Arch is bleeding edge, if you've never seen a bug, you haven't been paying attention. So, again, you've never suffered a problem with systemd. Now do a web search, and in less time it takes to write "[citation needed]", you'll see that this is real. Sorry, but systemd has bugs, just like every other program, but by being so intermingled with the kernel, the consequences are much worse.
WHAT? I thought systemd was flawless by virtue of being the creation of god-emperor Poettering. /s
>asserts that there are critical bugs that make the system unbootable
>asserts that changes to systemd break everything
>refuses to provide source
Why should I look for data to support your assertions? If there is any data supporting your assertions you should know where to find it already.
I'm just feeding a troll or someone who is really ignorant, but here I go.
No it isn't, and no you don't. Systemd is closely tied to some Linux-specific features, but it generally isn't part of the kernel. And you don't have to update the kernel in sync with systemd. Systemd lives in userland, by definition.
It does impose a minimum kernel version in order for systemd to work, which is something like 2.6.39 (May 2011 vintage). They have bumped up the minimum version a couple times as they needed new features, but you don't have to upgrade both together. I routinely upgrade one or the other separately on multiple systems and distros.
And it bears repeating again... systemd is not one single executable or process. And not all of the components are required, you can turn all but a few core ones off. And the core ones could be replaced if you wanted to, because there's a documented interface that you can implement.
Also, Vi, Python and Perl aren't "required" for GNU/Linux. They're common, but definitely not required. Vi is required if you want to comply with the Single Unix standard, but that is not the same thing. GNU/Linux just refers to pairing the Linux kernel with GNU userspace utilities; it doesn't necessarily dictate any specifics. There are further standards like LSB that attempt to do so but again not relevant. On top of that, Vi, Python and Perl aren't even GNU projects, which is true of a ton of other programs common in Linux distros, which is one reason I personally find the term "GNU/Linux" a bit onerous.
Quote from http://lists.freedesktop.org/archives/systemd-devel/2014-May...:
> > You update systemd but you don't update the kernel? How does that make > > any sense?
> > systemd and kernels are updated in lockstep (Lennart)
And it bears repeating again... systemd is not one single executable or process
https://news.ycombinator.com/item?id=8364318
Also, Vi, Python and Perl aren't "required" for GNU/Linux.
By that definition nothing is ever required. There's the same argument in my comment history, someone said, udev is not required for GNU/Linux. technically, chromium doesn't "require" blink. It's not required, you can use chromium and receive raw html, right? But in that case OSX doesn't "require" Python either, just delete the files, done :)
So again, I'm saying, I want a GNU/Linux system. (Yes, it's not required, I can install MS-DOS, HURD, HP-UX or Android.) That means POSIX, LSB... That's what 99%+ of programs targeting GNU/Linux expect.
The second point has some validity, but is a distortion. Of course you couldn't plug ConsoleKit in as a replacement for logind, because ConsoleKit was never designed for that. What you can do with logind is implement a simple compatibility layer with the standard systemd interfaces and then use it; this is what Ubuntu is doing. What is mandatory to use systemd's services is to implement its protocol for communicating between the services. This is why some of the services are "core" ones- because they're implementing the basic functionality common to the other modules. They can still be replaced, as long as the replacement obeys the same interfaces. This is however a problem for BSD, as the easiest way to use the systemd components is to implement the interface, but that does require features that are only present on Linux.
> By that definition nothing is ever required.
And yes, that was exactly my point. The term "GNU/Linux" is meaningless and doesn't require anything specific. What you might want out of a GNU/Linux system is probably totally different than what I do. You might want Emacs, but I'm a Vi guy. I don't want Emacs and you might not want Vi. How do we settle this? Committee vote? Mud wrestling?
Do you have a source for this or is it FUD?
http://lists.freedesktop.org/archives/systemd-devel/2014-May...