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.
> 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.
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."
[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-...
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 :-)
