1) lennart's quote about eventually removing non-systemd support which got blown WAY out of proportion.
2) the commit that broke module loading for certain devices. Which if you actually delved into the mailing lists from lkml...the change made sense. It just broke things in process which pissed Linus off because of his "Dont break shit!" rule (a good rule) and then the udev guys made a fairly "Meh whatever" response to Linus, pissing him off more. BUT, the change they did, the re-ordering of the process for module loading that they did, made sense and was reasonable once you read the discussion and figured out what exactly happened.
I'm just gonna pick a few things at random that systemd does, this isnt meant to be comprehensive.
Hostname support: does systemd NEED be the hostname controller? No. But its such a simple thing (set HOSTNAME) I dont really see a problem with it.
Control login: Interesting idea, and im not against it mainly because of cgroups and the fact systemd tracks processes on a per-user basis no matter what (no double forking). It lets systemd properly follow what exactly started a process and by who to keep everything in line.
Rudimentary power management (Sleep, hibernate): Interesting idea, systemd controls modules being loaded and therefore it can ensure that everything is offloaded and reloaded properly.
The journal: Lennart was right about one thing: you can edit plaintext logs. (This isnt meant to be a binary vs plaintext log fight) and anyone can forge logs. Since systemd keeps absolute track of services, and processes it kind of makes sense that it would handle their logging too. The beauty here is that journal doesnt take exclusive control, I've got journal and syslog-ng running simultaneously. Journal takes messages from processes, makes its log, then forward the same messages onto syslog and then syslog does its thing.
Timezone handling: (See hostname)
Hardware clock: (see hostname)
Cron: This is one that I don't really see the point of, but as long as you can still run your own cron daemon if you want to, i dont really care lol.
udev: This is the one I'll get fought on, I know, but I'm gonna say it anyway. Systemd controls module loading as well as module logging, hardware is useless without drivers (modules), systemd also does hotplugging (multiseat) which means udev and systemd are going to be working hand in hand ANYWAY. Until such a time that Upstart, OpenRC, and SysV are all dead (AND you dont see a new competitor on the horizon) you won't see udev become hard-dependent on systemd... so whats the big deal? You can still build udev solo, you can still use it without systemd.
Side note: Every feature I mentioned except process handling (obviously) and the journal are all configurable via compile-time configure switches OR run-time configuration file values so don't jump down my throat about bloat or not being modular. Systemd has the ABILITY to do more when so desired just as it has the ABILITY to do less when so desired, which is only possible if its modular. And if its modular, then it cant be bloated because bloated implies that things are forced. Is the kernel bloated?
https://lkml.org/lkml/2012/10/2/194 I think its the 3rd email from Linus that he starts ripping into systemd/udev developers for breaking stuff. What it comes down to is should the firmware be loaded when the hardware is probed or when the module is actually loaded? if I remember correctly.
I can't find the link myself but there's more info in a gentoo forums thread talking about eudev (the gentoo hosted fork of udev v187 or v189)
Major distros who are using SysV?
Gentoo, Slackware, Debian (Im leaving RHEL + its clones out of this because RHEL7 uses systemd)
Major distros using Upstart?
Ubuntu, (+derivatives, but basically Ubuntu.)
Everyone else? systemd
Debian wants to be able to swap out kernels so theyre stuck with sysV. If and when systemd removes non-systemd support from udev they'll probably switch to eudev.
Gentoo lets you swap out components anyway. The users who want to use systemd will use mainline udev. The users who dont want systemd will use eudev.
Slackware.... who the hell knows what those guys will do.
Ubuntu...I really hope will adopt systemd but I'm not holding my breath. They're basically in the same boat as debian/gentoo. If they dont want to use systemd they'll use eudev, if they do want to use systemd then its a non-issue.
If you tie systemd to udev, you're effectively forcing everybody who uses the Linux kernel to use systemd. Since there is a non-empty set of people who are interested in running Linux without running systemd (full disclosure: I'm one of them), it was no surprise that when udev and systemd were merged some voices were heard of people fearing that they would be pushed into using systemd.
On that occasion udev and systemd developers reassured everybody thay "nothing would change", as it was merely a matter of "sharing code". It turned out that no, in fact things would change, as udev changed in an incompatible way when it was merged; another change was that now you have to build the full systemd package in order to obtain the udev binary (which also changes name into "systemd-udev", and gets moved to another location upon installation) and manually rip it out of the built package. Building the systemd package has many more requirements than udev, and some of them can't be cleanly cross-compiled (just one of them: Python). Not to mention the fact that installing udev changed from a matter of "configure / make / make install" into a much more complicated job. Patches to allow udev to be built separately from systemd were rejected.
The blog post says that people are free not to use systemd because "free software isn't Mafia" ; well, the reader will decide what kind of behaviour it is to push people into using systemd by making their life noticeably harder if they don't.
Anyway, after we discovered that, unlike was promised, things would indeed change for non-systemd users of udev, we finally got an official announcement by the systemd lead developer stating that they dislike having to support non-systemd users, and that they look forward to the day when they'll get rid of the "inconvenience".
Now, it doesn't matter if his dreams of Linux domination will become true in 2013, in 2014 or in 2020. This statement is of extreme importance now, because:
(1) the use of udev is for all practical purposes required in order to fully make use of the Linux kernel;
(2) the udev maintainers are claiming that they are working to stop supporting udev without systemd in a somewhat unspecified future (and, as anyone can see, in the meantime they are already behaving as if non-systemd users of udev were second-class citizens, and are publicly stating it in order for it to be well known);
from (1) and (2) we get that non-systemd users are friendly advised to either stop using the Linux kernel, or prepare themselves to develop and maintain an alternative to udev. Or, much more conveniently, switch to systemd.
No you can't. Try to do it and tell me your experience.You can still build udev solo,
You still can, but it's a pain in the ass, which it wasn't before the udev-systemd merger, and most importantly, it's a use case with an expiration date. Which is unacceptable.you can still use it without systemd.
Please forgive me for this rant in a systemd thread, but hearing people say that non-systemd users of Linus exaggerate or are paranoid when they say that they're being pushed into using systemd, means having insult added to the injury to me.