> People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].

I appreciate most of your post, but this line really bugs me because I hear it so often.

Relevant xkcd: http://xkcd.com/743/

Valuing open systems/ecosystems is about more than valuing "shit getting done." You also have to value _how_ it gets done, and people who do value how it gets done should not be dismissed as bloggers writing about "freedom of choice."

> People who favour systemd generally use it to get shit done [1], not write blog posts about 'freedom of choice' [2].

Exactly. Half of the complaints I see about systemd don't even bother to make any arguments against it other than wanting to move away from it. For instance, see the most recent round of discussion on debian-devel, in which someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them. The horror of this scenario clearly cannot be adequately conveyed in an email, or at least nobody in the discussion attempted to convey it.

"someone gripes that systemd has dared to take over the functionality of invoking fsck on disks at boot time before mounting them"

This is a good example of what the original article complained about: systemd is a step towards monolithic systems and a step away from the unix philosophy:

  "The Unix philosophy emphasizes building short, simple,
   clear, modular, and extendable code that can be easily 
   maintained and repurposed by developers other than its
   creators..."[1]

systemd is feature-creeping bloatware in the Windows mold and it's no wonder a lot of unix fans who value "short, simple, clear, modular, and extendable code" have a problem with that.

[1] - https://en.wikipedia.org/wiki/Unix_philosophy

This is a good example of a standard argument against systemd: a vague complaint about "monolithic" versus "the UNIX philosophy", with no response to the actual issue, and in particular nothing that could be put in a bug report. What's actually broken here? What doesn't work, or what feature or behavior is missing? What would the bug report subject be, "is systemd"?

Something needs to invoke fsck on disks at boot time before mounting them. With sysvinit, that was handled by init scripts. With systemd, that's handled by systemd units like systemd-fsck-root.service and systemd-fsck@.service. As far as I can tell, the complaint in this response is that systemd isn't sysvinit and doesn't use sysvinit's init scripts.

Note that systemd could be configured to invoke sysvinit's init scripts, and that would work exactly as well (or as badly) as it did with sysvinit.

The bug report would be along the lines of poor documentation, poor integration, poor testing, etc. Let's look at the man page for systemd-fsck@.service for a moment http://www.freedesktop.org/software/systemd/man/systemd-fsck... . So, what files does it look for in checking filesystems for checking. What values does it return? How can I change its behavior not to drop to emergency.target if certain filesystems don't fsck properly? The complaints of systemd being monolithic come from its utter lack of user serviceable parts; it's of little consolation that it's several dozen poorly documented black boxes that don't work in isolation instead of a single binary.

In most cases the opponents are mainly opposed because of Lennart, not technical reasons, not freedom of choice, but because of Lennart. Most of them will explain their reason with refences to technical or freedom of choice but once you get down to it, its just Lennart.

You know what your average user wants? A faster booting system. In most cases that will be systemd.

You couldn't be any more wrong. The average user has no idea that she is using Linux. The number of people using a Linux system that reboots frequently enough to be noticed is zero.

Are you talking about servers? Because it's not 2000 anymore; the idea of servers running single instances of Linux for months or years at a time and rebooting is so infrequent that an extra second or two is no big deal, is obsolete. The cloud is king, and in the cloud you want to have instances which can be started up and shut down quickly and safely. That means that systemd makes just as much sense on servers as it does on desktop and mobile systems, if not more.

My cloud instances already boot up quickly and safely, thank you. I don't need a mountain of technical debt and poorly designed architecture in order to increase the speed by two seconds.

I'm interested in seeing where those stats came from. Care to share?

do you disagree? Because essentially every phone, television, car, printer, appliance, sign, smart watch, web server, router, and modem uses Linux.

If, charitably, you give 2% market share to desktop linux, and then multiply that by worldwide PC shipments (~80mm last quarter, so assuming ~320mm annualized), you end up with 6.4 million. Not bad. But there were 918mm smartphone shipments in 2013, of which android was around 75%-80% market share, so 688 million or so. That's over a hundred times as many users just in phones alone.

Counting embedded devices in this discussion as part of the Linux population is questionable at best. There isn't an init system debate for embedded devices. I've not seen any indication that Samsung will be changing the infra based on the init system war, any more than GE is going to change my microwave.

All of those devices are linux, and all have init systems. Currently, there are two core systems they use: bsd-like init.rc systems (and busybox variants), and sysv.

Similarly with servers: essentially all the web servers and application servers in the world are linux, and they also don't need the sort of windows-style 'architecture' that systemd brings.

In fact, I would venture to say that boot speed isn't even in the top 50 concerns of a desktop linux user.

So it's not just the tail wagging the dog; it's a nonexistent, badly drawn picture of a tail wagging several billion dogs.

God save us from software that bends over backwards to help average users. The only thing worth doing with software is pushing it forward.

And that's why Windows enjoys such dominance in the server market!

In the enterprise server market, Windows handily beats Linux. Consistency, integration, and ease of administration are major reasons why.

And salespeople.