They have fear of systemd becoming the mainstream init system. It's more easy for a project to become obsolete if we start to forget about it. Although sysvinit still has an chance to evolve.
I'm particularly excited about socket activation for my servers, as well as auto-remounting of network shares if connectivity is lost (my laptop on/off wifi or traveling, etc).
I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it". systemd is a collection of smaller tools, which is the UNIX philosophy (debunking that argument). It can be replaced as per this article and if software projects don't explicitly bake in hard-dependencies (but even then there are ways around it like shims and what-not that several people have built).
Distros are looking around at all the available init systems, and a large amount are deciding systemd offers something more than the rest, and then going with it. (you can review the debian debate for gritty and technical details). There really is no reason to be so angry at systemd.
systemd might be a collection of many small tools, but they don't compose well. Dbus isn't a substitute for piping little blobs of text between stdin and stdout of a bunch of different programs that are utterly agnostic of each other's existence.
And systemd might well be great. Aesthetically, I don't care much for it, but I'm using it with no problems, so I guess it's fine. But it's not "the Unix philosophy".
I'm guessing you want more then that though right?
But mostly, like I said, it's just ugly. D-bus? Binary logs? Sure, you can build a working system like that, but just ugh.
ForwardToSyslog=True
or
systemd.journald.forward_to_syslog=True on the kernel command line.
Is it just cool to not read documentation anymore?
Systemd components are NOT interchangeable with something else, so let's stop pretending they are. Please.
[1] CentOS and RHEL 7 ship with an earlier version of systemd, and I'm not sure if the packages have been patched in some way or not to fix this. If not, good riddance if you are a sysadmin trying to pass core dumps along to developers.
Theoretically my configuration would look like rsyslog linking in a compatibility library and having something like this small config snippet from /etc/rsyslog/rsyslog.conf of the future:
# Connects rsyslog directly into the innards of systemd
$ModLoad systemd
I wouldn't even have journald installed on my system, at all. No config file named /etc/systemd/journald.conf, none of that. Just rsyslog.
That's like saying HN website is composable with emacs because I wrote this on emacs and then cut and pasted it into the browser. Really being composable would imply meta-x post-buffer-to-hacker-news direct API on emacs.
It doesn't really matter to me because systemd is going to force me to convert my systems to freebsd. But if I was staying on linux, I'd like systemd to at least minimally cooperate with the rest of the ecosystem instead of spreading like a cancer.
In ISC DHCP (I don't know if systemd is handling dhcp or not), you can add shell scripts as pre or post configuration hooks. I set up a cluster where the local hostname is set from DHCP/DNS, rather than vice versa.
The argument is really that given that systemd as a project does a hell of a lot, it's actually really hard to replace bits of it - as people who are trying to are quickly finding out, there's a few dependency trees for various components which end up requiring that systemd manages most layers of the system. So you either use all of systemd, or as little of it as possible.
According to Lennart Poettering himself, udev is going to end up depending on systemd being the init system. udev! It'll be damn near impossible to replace systemd then. (And anybody who wants to use anything else, or even have the choice to use anything else, is a "systemd-hater".)
I also have a suspicion there is a more friendly way do what PolicyKit provides, which is not at all very transparent to an administrator. You could easily trust software with privileges without realizing it. There are also concerns about the hard dependency on these utilities for GNOME, but I don't use it myself so I don't know if the concerns are valid or not.
I believe however most of the criticism centered on how udev was dropped as a separate utility, despite concerns from other developers, and the way people who tried to keep feature parity in a stand alone fork was treated. They was basically told they were regarded as downstream developers.
This is mostly water under the bridge now of course, but it makes cooperation a lot harder than it should be.
http://lwn.net/Articles/512895/
And rsyslog can cryptographically sign logs too nowadays:
http://blog.gerhards.net/2013/05/rsyslogs-first-signature-pr...
That's not debunked. The small tools of the UNIX philosophy are supposed to compose well with others. If I want to replace systemd's init with that from daemontools (for instance) and keep the rest of systemd working, that should be possible.
Or let's suppose that I want to opt in to systemd's auto-remounting and socket activation (for instance), but for whatever reason I need to keep my syslogs as text on disc, so I can't use systemd's binary logs but need my legacy syslog system. Can I do that?
> I really don't get the systemd "hate" that is still floating around. It seems a lot of arguments against end up boiling down to "it's different and therefore I don't want it".
The arguments I've heard boil down to "it's badly designed and therefore I don't want it."
/etc/systemd/journald.conf ForwardToSyslog=True
I'll just say, a GNU/Linux distro has many components, but they're not monolithic because they integrate well, you can do ls|grep etc, you know this. But if we want to change one component of systemd, we can't do it! You see? A lot of components, but they comprise a blob and can't be separated or used individually.
I found a message that might shed some light on it:
"[...] Let me turn your question around: we swapped out one of the most central pieces of Linux systems, one of the pieces that is probably the most core of what administrators interface with every day. How could this change ever have gone without any noise?"
http://lists.freedesktop.org/archives/systemd-devel/2014-Oct... (read the whole message, it's quite interesting).
I don't get the hate, I love it.
You'd probably have some of the same people complaining if you tried to "evolve" SysV.
I guess things are pretty good right now in the Linux world if this is the thing to argue over.
Parallel boot, sure. But you can always drop runit or openrc or something similar on top and get it already.
socket based service start, (hardware) event based, pass.
Frankly the core of sysv, the init binary, does very little. It sets up virtual terminals and fires up one or more processes (that it will keep an eye on and maybe restart).
The latter processe(s), most commonly a shell script of some kind, are what do the actual starting of "services" and managing of runlevels etc.
This is a very flexible system, as most of the logic involved is easy to get at. It is housed in interpreted scripts rather than compiled C code.
you can even run the scripts directly in a root shell if you have the need to do so (or perform the scripted commands manually).
Basically the scripts do little more than what someone would do manually if they were presented with a bare shell after kernel boot.