DistroWatch QA: Distributions not adopting systemd
distrowatch.com
distrowatch.com
I get what the technical differences are between systemd and alternative solutions. That is not the problem. What I don't get is how the init system of anything can evoke such emotions. It all goes way beyond expressing preference. The flamewars and vitriol that have been spread are disgraceful, and people are seriously considering switching to different operating systems because of whatever package runs their daemons and their startup scripts. It's embarrassing.
As a frequent user of Linux, it completely mystifies me how changes in this can cause such emotions. I mean, I'm the kind of guy who did not prefer Fedora for such details as font rendering and certain package policies, so I'm not insensitive to distro differences in general. But I guess I'm ignorant about why so many people seem to cherish such very strong opinions about an init system.
What is it about init systems that causes this outrage? I really want to know!
There are some technical concerns, but a disproportionate amount of criticism is because the lead developer[0] of systemd also developed PulseAudio, which was adopted by distros too early and therefore caused a lot of problems for people.
People remember PulseAudio without much fondness, so they are bitter and take it out on systemd.
It doesn't help that he has a somewhat direct manner of communicating, which some people find off-putting.
So, to answer your question, a lot of it is personal, not technical. That's why you see much more vitriol than you'd otherwise expect for a somewhat technically controversial, low-level piece of software.
That said, Poettering's character is so distinctive that it's nearly impossible not to do a little jab against him.
You're saying that there are technical concerns, and that those are a large number of the concerns expressed.
I'm saying that his personality and previous history with PulseAudio are a reason that those technical concerns are expressed far more often (and with more vitriol) than they otherwise would be.
I just wish that Debian did not take systemd, that _really_ saddens me.
It's partly a hang-over from toxic communities and people ignoring all the evanglist advice. Linux had a lot of early discussion on Usenet. One feature of Usenet was robust discussion (often under people's real names) which could devolve into hateful flame wars. This was not limited to Linux discussion, but includes Vi vs Emacs, the pronunciation of gif, BSD vs GPL licences, microkernals, etc etc etc.
There are also people involved in this current argument who are difficult to talk to. These people have help create a totally toxic environment.
It's not limited to linux. There are several megabytes (doesn't sound much but don't forget it's just text) of arguing on Wikipedia over m-dash, n-dash, hypens and etc. and that place has rules to supposedly encourage collaborative behaviour.
I like systemd. It has shaven quite a few seconds off my boot time. I get that its modularity simplifies things for the developer. However, I understand some of that outrage. Linux systems have typically been mix-and-match. However, when systemd started gaining popularity, some packages have been written to depend on it, and it seems to be becoming difficult for people to choose not to have systemd. Given that systemd is built to make good use of Linux-specific features, it's also annoying for *BSD developers to get many software packages to build and run on their systems.
Look at the output from my own setup:
Required By : accountsservice bluez-utils chromium colord crda device-mapper lib32-systemd
libgusb libpulse libusb lightdm lvm2 media-player-info mesa mkinitcpio
netctl packagekit pcmciautils polkit procps-ng python2-pyudev qt5-base
qtwebkit rtkit spotify subversion systemd-sysvcompat udisks2 upower
xf86-input-evdev
Exactly the issue I think.
I'm wondering (not trolling) how many desktop people actually reboot the kernel (fresh boot or resume from hibernate) as opposed to using suspend to ram? Given the outrage the Gnome devs caused by hiding the power down function on early versions of Gnome 3 quite a few. I generally just suspend, but I've recently started using hibernate on one laptop with whole disk encryption just in case of petty theft/leaving it on a bus.
Do any sysadmins use automatic spinning up of instances of a small Linux to cope with traffic spikes? Is that something that is actually done? Boot time could matter then.
GNU/Linux represents choice and freedom. The abundance of distros is proof of that. You can choose your preferred init system, system logger, cron daemon, desktop environment, browser, etc.
Now, systemd is being forcefully pushed to all distros. For instance, by merging udev (a part of the Linux kernel) with systemd. We can't even build a distro anymore without downloading systemd. User choice is under threat.
In this situation, some people align with the forceful approach of systemd. Some prefer to choose what goes into their computers. This is similar to the inclusion of DRM in Firefox, there's no middle ground.
So the debate is really about competitition vs a walled garden provided by systemd.
I thought one of the advantages of udev (vs devfs) was that it was completely in userspace?
Why do you say that? That's what I don't understand. As far as I know, that's not true. You can run a Linux system without the udev daemon, or with one written by you.
But the thing is, you can't remove udev from the Linux kernel if you want to keep it calling Linux, as it'd be a fork.
But udev isn't in the Linux kernel! How can I remove it from there?!
A GNU/Linux system consists of several components. http://www.gnu.org/gnu/linux-and-gnu.html shows some examples.
If you remove udev from Linux, I see at least two problems. One of them is technical: programmers expect Linux to have udev, because that's what the Linux authors advertise. The other is legal: Linux is a trademark, and if you replace something and introduce some incompatibility, it's a bad idea to keep calling it Linux.
> But udev isn't in the Linux kernel! How can I remove it from there?!
I think here lies the misunderstanding, udev was previously in the kernel repository, now it isn't. Fair enough. But consider that GNU is also separated in a different repository, but it still comprises the GNU/Linux system as a whole. Imagine we could only download GCC (necessary to compile Linux) as part of Adobe Flash, don't you think I could say the same? That "we can't even build a distro anymore without downloading Adobe Flash"?
Yes, and udev would compose an hypothetical "Udev/Linux system". But Linux itself doesn't need udev.
GNU / GCC is different because you literally can't compile Linux without it. But if and when LLVMLinux succeeds, I don't think you could say the same.
Would it really work? I think you'd have to rewrite some parts of the kernel, but I may be wrong now, in the past or the future.
Anyways, we're arguing semantics here, it'd be better for all to separate udev from systemd. It's like Windows installers usually bundling the program with some crap, and I know most people don't appreciate that.
The internals of systemd consists of reams of repetitive string processing that should not even have been written in C, and lots of indirection which obscures control flow paths through the program.
The behavior of systemd is only completely specified only by its obtuse implementation, which was developed by some people who have no clue how to design that kind of thing (or to specify and document it).
Why I even know this is because I had to switch to source level debugging to figure out why systemd is or isn't doing something, and how to change it.
Background: I worked on substantial improvements of Linux's ability to support serial consoles on a USB-serial device. This required interaction with systemd. Part of the functionality is that you can plug a console in before booting or after, and get a prompt. Moreover, you can unplug a device with one kind of USB-serial chip, and plug in a different kind that uses a different driver, yet completely recover your existing session, which could be in the middle of a vi edit or whatever).
To get the behavior completely polished, I had to wrestle with systemd, which was killing the sessions in an obscurely mysterious way that made the USB-serial/TTY/console code in the kernel look like a walk in the park. I think it took me several days to figure out, after poring over the systemd source code. First I discovered it was systemd doing the killing by putting some printk's in the kernel. Reading systemd documentation was useless, so I had to crack open the source code and start instrumenting that. I think it took the better part of a week to finally get the behaviors ironed out.
I used systemd last year to see if it was any good, and it's terrible. Specially journald, well it uses a binary format, I see this file, about 250KB, I wanted to decompress it as a text file to use my tools. OK, I had a brand-new very powerful computer. After 1 HOUR, I see a 5GB file, the decompression still running!
Another bug, I needed to power off with (unix sysadmins will laugh at this):
sync; sync; shutdown -h now
So yes systemd is also technically bad. That's why *BSD, GNU Guix and other alternatives are gaining momentum.
[1] http://lists.centos.org/pipermail/centos-devel/2014-June/010... [and the many many subsequent replies]
[2] https://lists.debian.org/debian-devel/2014/08/msg00129.html [and the rest of the thread, and the other threads about the same issue]
I suspect this one has a lot to do with issues around the structure of the operating system and the way major components depend on each other.
It starts off with confirming that systemd is indeed the very baddest bad thing there is. And then later on mentions that "but, yeah, I don't actually have any troubles with it" at the very end.
I'm sure there are people who have their reasons for avoiding systemd, and for them a list like this is probably great.
But for those still on the fence, this reeks of scare-tactics.
Let's make on thing clear: Systemd does provide a sufficient amount benefits and I can say that without any particular source of my own.
Why? Because pretty much all the distros out there are moving towards systemd and you would be out of your mind to think they are putting in this effort to migrate to systemd if they hadn't done a technical consideration and decided it was a worthwhile thing doing.
"The PCLinuxOS distribution has not adopted systemd and, so far as I know, has no plans to migrate to the new init software. Slackware Linux, CRUX and Gentoo Linux are all Linux distributions which are unlikely to adopt systemd as their default init system for philosophical reasons."
The philosophical reasons being the centralisation of control over a key aspect of Linux to a group of developers that aren't universally trusted?
Gentoo is fairly large, but the others are niche.
The turning point was systemd breaking a fully functional system and forcing it into recovery mode which was simply broken and going in an infinite loop of displaying it was about to offer a recovery terminal which never came.
Not having log as text and useless info from systemctl and journalctl instead of the useful info I had in traditional logs played a significant part and the attitude and position of the systemd guys too.
This debian forums post sums it all:
From my (relatively short) experience with systemd as init I find that systemd (at least as packed in debian) is really far from being ready. Even the slightest unexpected (to systemd) configuration will make it break from all sides, and even the so-called emergency shell is painfully broken. Together with both the upstream and downstream (debian maintainer) attitude ("this is not a bug, fix your configuration so that it matches our expectations, which by the way change every day and we don't tell you about it" -- i.e. the exact opposite of Linus/kernel's attitude "we don't break userspace").
Systemd is mature and reliable and is running on so many servers it isn't even funny. I personally like it and it is much better for me to admin my services on servers.
This I can definitely agree with. Has debian said anything about replacing sysvinit on existing installs or will they just be using systemd as the default on new ones?
The latter would from my point of view be a reasonable compromise and shouldn't alienate anyone.
Honestly, these truly are authoritarian scumbags. Linux is finished. And it happened quickly too.
my experience with systemd on my arch laptop isn't one I would say is mature and reliable. When a service that used to work now fails to start and the only information systemd gives is that it failed to start, I find the only reliable things is that it fails to provide relevant information to allow me to get out of the situation the way I could with logs before systemd.
In the case of Gentoo, they already support systemd[1] as an alternative.
What I don't entirely understand is, systemd is an umbrella project with many sub-components[2] that are depended upon in many non-init packages now. As far as I can tell, none of the systemd devs care for anything other than Linux support [3], so any packages depending strictly on systemd components are unable to run/build on other systems, or have to now support two+ subsystems.
Gentoo provides support for alternative platforms such as OSX and BSD via the Prefix[4] project, so for them to switch to systemd (and its sub-components) as a default would be to make the Prefix project harder to accomplish.
Again, I don't know enough about the various components that comprise 'systemd', or how modular they are outside of Linux. If someone can clarify any misconceptions I have, I'd be grateful.
[1]: http://wiki.gentoo.org/wiki/Systemd [2]: http://upload.wikimedia.org/wikipedia/commons/thumb/3/35/Sys... [3]: http://bsd.slashdot.org/story/11/07/16/0020243/Lennart-Poett... [4]: https://www.gentoo.org/proj/en/gentoo-alt/prefix/
Yes, but avoiding risk is a valid argument for avoiding anything new. Avoidance of risk is why many people like Debian, so hearing that some users and developers of Debian are not in favor of systemd, even if only due to the fact that it's something very new and very different, seems quite reasonable.
Systemd does provide a sufficient amount benefits you would be out of your mind to think they are putting in this effort to migrate to systemd if they hadn't done a technical consideration and decided it was a worthwhile thing doing
To some people and some workloads, very much yes, systemd is a very good thing. To other people and workloads and system configurations, systemd doesn't help and sometimes even hurts. Really, to each their own.
But this really is the whole point of FOSS, there are other init systems besides systemd and other OS than Linux where the use of systemd has not been deemed to be worthwhile. If you feel similarly, use one of those distributions/OS and contribute to it so that it doesn't go away.
I'm not a fan of systemd. I run Debian stable. I'm not sure what I will do once Jessie becomes the stable release.
Debian is now in the enemy camp. The decision making process has been taken over by the systemd people. New authoritarians.
Wheezy is the last of the unix like era of the Linux "software stack". All that is needed is to patch security fixes sometimes, and/or run a grsecurity patched kernel. The software in Wheezy does everything desired.
It is the ideal. The ideal is being lost. Make sure you keep your source code DVDs.
Debian is now an enemy. Fork wheezy. Dump Jessie
"for them a list like this is probably great"
I wouldn't describe the article as great, because it strayed so horribly off topic and the answer is wrong.
By analogy it would be like asking a question along the lines of "please inform me generally about the marketplace for 3rd party iphone cases" and then instead of getting a survey of the iphone case marketplace, the response is a half dozen paragraphs about the relative superiority or inferiority of windows phone, and the philosophical implications of blind love of change vs blind avoidance of change, and the politics of blah blah and then at the end finally an answer like "Otterbox cases have a good reputation, and VLM on hacker news claims regardless of device mfgr, if he can put a device in an Otterbox case he puts it in an otterbox case, and (insert list of inferior competitors to Otterbox)"
The other aspect I don't like is the answer in small detail is wrong, there is no uncertainty, Ubuntu is just reskinned and 3rd party support of Debian, so obviously "some time" after Debian goes 100% systemd then Ubuntu will go systemd. Its only a matter of time, Debian being Ubuntu's upstream. I guess theoretically the only way for Ubuntu to avoid it would be Ubuntu switching to Gentoo as upstream (guess it could theoretically happen, however unlikely) or avoid the question entirely by going out of business (again afaik not likely).
Ubuntu has been using their own init daemon, "upstart", since 2006. After Debian announced their plans to switch to systemd, Ubuntu announced that they would follow suit instead of continuing to use upstart.
Finally, at the end of the day, most OEMs ship Windows. I think you're overestimating the distros a fair bit. Wide consensus doesn't always mean quality.
No, let's back up a step. Let's say you don't want to use GNOME3, but you do want to use Debian as a desktop system.
In that case, you would simply install KDE or XFCE or LXDE, or just have a display manager of your choice start the window manager of your choice. There are lots of choices and Debian considers them all first-class citizens. Nobody gets upset when you say "I don't like running KDE, what are the alternatives?" If you say "It looks like xterm has a new dependency on gtklib, what's up with that?" your bug report will be addressed.
But if you say "I don't want to run systemd, it seems to have been installed by mistake" what you get is:
systemd is the future, you should run it.
why are you so rude? systemd is the default init. Get used to it.
it's not that there are lots of people who object to systemd, it's all the same people being loud and repetitive.
it's all settled now, so any attempt to object is a flame.
I don't care for systemd (I've never even used it), but it doesn't shock me that some components are just core to the distro.
On the other hand, package managers are far more opinionated. Each distro has their own particular package format, guidelines and development practices that are made to form a coherent as possible experience. File system layout is important here, among many other things.
However, you certainly can. apt-get install yum is a thing. I'm not sure how reliable it is, though.
Even so, the answer is that yum and apt have already been packaged for Debian, so can install those, install alien, and then convert deb packages to rpm packages, build a repo, and work from that. Ask around, maybe other people are interested in doing that too.
As someone who is responsible for a fleet of various machines, I like that going forward I'm probably only ever going to have to hassle with one init system (at least until the next big init system enters the fray). I don't even really care which one "wins", but it's nice only having to write one style of init scripts/units. I especially don't care which package contains my dhcp client or ntp server. This is stuff that, for the most part, I don't need to touch after writing an Ansible playbook for tweaking.
On the desktop side, the various organizational and technical differences between distros (in spite of efforts like the LSB) make life harder for those writing distro-agnostic software. A good example is Steam. This is one of those potential "killer apps" for the Linux desktop, yet they're only able to officially support Ubuntu during the early goings because of the variations between distros. This may change as Steam for Linux matures, but it's telling that they picked a single distro to focus on initially.
systemd being adopted by the more popular distros is a win-win. The major, popular distributions get closer together for greater interop, while the fringe distros can cater to the vocal minority who actually cares about this. You'll always have the choice to choose other distributions and other software.
Qualified agreement.
In Debian Testing/Jessie, a simple wm on top of Xorg can be made init diagnostic
http://sohcahtoa.org.uk/osd.html
Something a little richer that is still init agnostic requires some management. Using --no-install-recommends when installing xfce4 for instance results in a functional desktop with nice fonts and compositing, but dbus insinuates itself but can't function, and there is no automounting of drives (I use pmount) and one is left to fall back on wpa_supplicant and roaming.conf.
Depends on what you need in a desktop
PS: my 'production' laptop will run a rich desktop but my carry-round laptop for wasting time in cafes will be some kind of debian-sysvinit frankenbox just for the lutz.
https://packages.debian.org/jessie/systemd-shim https://packages.debian.org/jessie/sysvinit-core
http://www.networkworld.com/article/2175826/softwareinus-tor...
It's also important to note that the issue was with Sievers specifically and not with systemd. As Linus said "[...] you don't fix problems in the code you write [...]".
eg, "[...] But I'm not willing to merge something where the maintainer is known to not care about bugs and regressions and then forces people in other projects to fix their project."
I can't talk about systemd, but I had to deal with pulseaudio issues as developer of a third party project and it wasn't a pleasant experience. Kay is not involved with PA in any way, but I remember PA developers blaming Ubuntu because of their PA integration.
Yes, it is probably me seeing things here as result of my own frustrations, but I wouldn't like to experience a similar situation with systemd.
At the philosophical level, does anyone not have mild concerns about the binding together of large parts of the underlying systems and the general loss of modularity?
At the coal face do any sysadmins really value the new logging and monitoring tools?
One metric might be the speed adoption of EL7 by those currently using EL6 and EL5. A high speed of adoption means general happiness (or just need for newer packages). A low speed of adoption means unhappiness (or just no pressing need to upgrade).
I didn't mean to suggest that the EL market would upgrade overnight, I was thinking of a profile spread over time and reflecting corporate schedules.
I have to agree. I am one of the main people to support Fluentd (an open source log collector https://www.fluentd.org), and a lot of people do forward rsyslog/syslog-ng to Fluentd for further processing/analytics. We've been trying to figure out a way to do the same with journald, and while it does seem possible, it will require a ton more work.
One of them has just jumped ship to Google mind you!
The only time I interact with systemd is when I'm running
it on a server, something the majority of people don't do.
I've had to interact with systemd on my desktop system rarely (but enough that it's frustrating for things that should be easy and obvious and just work) so what's on the desktop doesn't impact me that much. But I run way more server installations where things like boot-time and NetworkManager and multi-seat (I question how many people actually need this on the desktop anyway) and name-systemd-feature-of-week doesn't offer much advantage over the old system which seemed to be working fine, was mature, and everyone was sufficiently familiar with it (not to say it doesn't have warts, as everything does).
Have you tried systemd service files yet? They're quite nice to work with. I haven't written Upstart's equivalent, so I only know what those are like second-hand, but I imagine if ease of creating a service is a major factor you'll be pleasantly surprised by systemd.
I also notice it with the systemctl command line tool, which is actually really pleasant to use.
I'm not sure what would happen if this happened with other init packages.
A fork of linux is needed, both userspace and kernel.
I like using FreeBSD and Solaris, and all sorts of other OSes. SystemD makes it harder to do. For every system service, now were maintaining a systemd and a non systemd version of its init files.