[cm3]

Most opponents of systemd are not against consolidation and standardization of linux system administration. What they object to is the development approach and happiness to introduce bugs and unbootable systems.

To add one more anecdote: give voidlinux a try at some point. It uses runit as its init system and boots at least twice as fast as a systemd-based arch linux system. As with startups, the idea is less important than good execution, and systemd only succeeded on the former (so far).

With all that being said, I do like that I know how to do common administration on both Arch Linux and RHEL and Debian without learning three toolsets.

[grubles]

> boots at least twice as fast as

Honestly, why is this important? I want a system that is fast once booted, not a system that boots quickly.

[jlgaddis]

I've never understand that argument either. I suppose it might make a difference if you are constantly (shutting down and) spinning up new instances all day long. Most of my hosts "boot up", at most, two or three times a year, though. An extra 30 seconds is not something that causes me pain.

[cthalupa]

Even in a cloud environment where you might be scaling dynamically based on demand, it's fairly trivial to set your scaling policies with just slightly lower tolerance to account for a couple dozen seconds startup time. If you're not scaling until you have an immediate need for that capacity, you're in trouble and your users are going to be encountering reduced performance or service outages anyway.

[cm3]

It's important because systemd boasts faster boot times and to show that systemd isn't really much faster than existing solutions. Boot times are important if you start on demand. See MirageOS's network initiated quick boot for one extreme.

[gillianseed]

>Most opponents of systemd are not against consolidation and standardization of linux system administration.

That's not my experience, in the discussions I've seen and taken part in, most (as in vast majority) of the detractors are opposed to systemd as a consolidation of a large array of core tools and services all under the same 'umbrella', which is exactly what the BSD's do at an even higher level as they are developed as full operating systems.

I'm not sure what 'happiness to introduce bugs and unbootable systems' refer to, I've been using systemd ever since Arch made the switch (~4 years ago). I've yet to have stability issues and I haven't read of any widespread problems in the Arch forums either.

There are (and likely always will be) distros which default to and promote alternatives (Gentoo comes directly to mind), but in the grand scope we're seeing a huge convergence around systemd across distros, which tells me this type of standardisation is something the Linux ecosystem really pined for overall.

[synchronise]

I think that the issue that a lot of BSD people have with systemd is the development model and consolidation of projects around systemd only APIs which are difficult to integrate into non-Linux platforms.

That combined with the systemd developers saying 'Systemd is a Linux-only project, we'll only be accepting patches for Linux and we'll only be supporting Linux. If this breaks on non-Linux systems, you're on your own.' Granted the community has adapted very well, as Gnome Shell running on OpenBSD demonstrates, but the non-inclusive attitude must have left a sour taste in a lot of people's mouths and you can understand why they feel bitter.

[cthalupa]

Personally, I'm a Solaris guy. I use BSDs when Solaris isn't practical. I'm fully on board with the consolidation of an array of core tools and services by a competent team.

I'm just not sure that I believe the systemd team is said team. Their behavior on mailing lists and bugzillas has been extremely disconcerting at times, such as when they screwed over kernel developers who used the debug kernel option and basically said 'Tough shit that we broke the existing standard workflow, we don't care' ( https://bugs.freedesktop.org/show_bug.cgi?id=76935 )

Whether or not you agree that reasons like that are enough to distrust the team, if I were to keep running Linux in production, and make my own personal choice about what I am using, I can no longer realistically do this. Extremely necessary things such as udev being merged into systemd (and being a large pain in the ass to compile and use without systemd) mean this is no longer something as easy as replacing one or two components.

I'm all for convergence. Hell, I don't even particularly like sysv init - if systemd was a product as refined as even SMF, I'd care a lot less. And, I like the ease of use of journalctl - I spend a lot less time mangling text with grep and awk and sed when going through logs when I'm not on a system where things are being sent to splunk or kibana.

Whatever happens in the Linux community, I'm not particularly affected. SmartOS and OmniOS already have things very similar to systemd because of their Solaris heritage, and they work well. The BSDs seem to be moving in that direction, and I expect they'll create a solid product. I'll use those and be happy to do so. When I have to deal with other environments where Linux is used, well, I've learned plenty about systemd and feel perfectly comfortable working with it. I won't particularly like it, but ultimately, it's not something I care about to do more than discuss it on the internet.

[cm3]

I've seen and I am seeing the following on Arch Linux:

- still unfixed shutdown errors from systemd - new shutdown errors from systemd - failed to boot or shutdown a system due to a systemd bug hence fixed - harder to fix if shutdown or boot fails compared to old init systems

My impression is that there isn't enough QA for the amount of churn they have in each release. Most bugs are very obvious and not someone using an obscure configuration for his sparcstation.

Standardization for a single common administration interface is a good thing but the resulting product is of sub-par quality thus far.

[cm3]

To clarify, I mean consolidation in terms of the admin interface and not necessarily putting everything into a single executable. Being able to use the same commands across most linux distros is the advantage.