Slashdot Mirror
Debian Technical Committee Votes For Systemd Over Upstart
sfcrazy writes "Bdale Garbee,chairman of the Debian Technical Committee, called for a ballot from the TC to chose the default init system. The votes are in systemd is the clear winner here. Bdale himself voted for systemd."
I didn't really know much about systemd being a ubuntu user, but found this giving more background on the story: https://wiki.debian.org/Debate.... The wiki does a good job detailing the technologies. Given the information, the choice of systemd is interesting.
Who would have thought there would be consequences to spamming every article with whining and bitching?
I don't think I have much qualm about systemd as it relates to the init process. However, the people behind systemd push *hard* that text format logging is some anachronistic evil and that files on disk should just be binary. They do some pandering to the crowd by saying to run something like rsyslog alongside systemd, but that seems pretty counter to the other areas where there is an emphasis on running as few processes as possible (ambition to replace at, cron, change from running static number of getty on VC specified by inittab to on demand spawning of getty as auto detected). It's clear they regard users valuing plain text data with some disdain. There is plenty of opportunity to achieve the gains whilst concurrently providing a plain text stream to peruse natively, but they have *zero* interest in trying to pursue such paths.
This is also the brainchild of Lennart Poettering, who has had a track record of getting stuff widely into distribution critical usage path before it's ready (avahi and pulseaudio have given me lots of headaches). Also trying to get DBus into the kernel, which seems absolutely bonkers.
In general, distributions embracing this become increasingly opaque to admins. Distribution behavior flows through an increasingly complex labyrinth of crap that it approaches Microsoft level BS. I'm somewhat disheartened at the possibilities here.
XML is like violence. If it doesn't solve the problem, use more.
The biggest thing that pushed adoption was when it absorbed udev. You can still run udev without it, but it's plastered with systemd branding and building udev without also building systemd (and then having to manually strip udev out, if you want to run it standalone) is difficult. Beyond that, Gnome 3.8 made it (almost) a hard requirement. Strictly speaking you can run Gnome without, but, as I understand, it loses almost all of the power/disk/device management.
People like it because it's obsessed with boot times (which is apparently a really important thing to people who don't actually run a real-world system, where boot times of 10 seconds vs. 5 seconds are meaningless), has a few useful features (often, subjectively, questionably implemented), and has really good PR. The problems with it include an obsession with APIs (Unix, everything is a file -> systemd, everything is an API), an everything-and-the-kitchen-sink approach (NIH: write their own binary-formatted logging daemon, their own cron daemon, their own implementation of dbus, ...), and a horrid misunderstanding of what an initsystem really needs to do for servers (LP: "Control groups of course are at the center of what a modern server needs to do." -- which, really, what it needs to do is serve things, not shuffle processes around various metaphorical boxes). The project is, as a result of including the kitchen sink, also extremely monolithic -- everything is stuffed in a single git repo, a single tarball, and is heavily interconnected.
Two of the primary developers (Lennart Poettering and Kay Sievers) are also notoriously hard to deal with if you ever suggest they've done something incorrectly. You can find a lot of examples of this, largely to do with LP's attitude towards anything that isn't systemd, and Sievers' regular breaking of udev over the past few years.
No, it is loathed by a small, vocal, percentage of system administrators, who have very little in the way of technical arguments at their disposal. This vote may be considered evidence in that respect.
There is very little to recommend init scripts. I dismiss arguments that they are any easier for any average mortal to deal with than any other piece of code, and there is very little justification for wasting CPU time on a non-interactive process. Additionally, this will merely be a default -- those who want slow boots, or think cgroups are evil, can go ahead and install systemv-init and purge systemd. Or, since systemd, d-bus, pulseaudio, and wayland are evidently the future of Linux, the malcontents can install BSD -- it comes with a free chip for your other shoulder.
Those who advocate genocide deserve every protection afforded by law, and none afforded by common human decency.
Linux architectures, not GNU/Linux. In this context it's not about the whole operating system, it's about the kernel itself. Aside of Linux architectures there are also kFreeBSD architectures in Debian - with "k" added to make it clear that it's about FreeBSD kernel, not OS.
Don't try to fix other people when you don't know what them (and in turn you as well) are talking about.
...but the Canonical shills were trying to push Upstart even though it's a buggy piece of shit that is inferior to systemd in every way.
So wait, you're saying that narrow corporate interests were trying to push their own inferior solution in place of a technically superior system strongly preferred by the userbase? There seems to be something vaguely familiar about this scenario, but I can't quite put my finger on it...
"systemd versus sysv init most visibly leads to faster boot".
That was the original marketing. systemd of course is much much more than boot.
Systemd touches every part of the OS.
https://en.wikipedia.org/wiki/...
Upstart was bad. Systemd is worse. Both were born as boot/init systems and are unconstrained in scope.
Any program unconstrained in scope will grow into a monolithic mess.
This is good because it will get systemd onto even more systems, which will hopefully be a forcing function for improving it so that it's more usable.
The introduction of systemd into my distros of choice (I was a heavy Arch Linux user until this year, when I switched back to Fedora after a ~8 year absence) has caused me more problems that any other single change to any part of the Linux operating system in my history of its usage (and I've been using Linux since 1994).
I'm at the point in my life where I just want things to work; and I found that systemd has in many places not worked well. I wholly believe that the problems are generally due to the implementation of the individual services, and not bugs in systemd itself, although I suspect that the 90 degree turn taken by systemd and its associated complexity are the genesis of the problems in the individual services themselves.
In particular, I've found that systemd on Fedora cannot properly start up an NFS server. I have a post-start up script that I run manually to start NFS because no matter what I do, it does not seem possible to force systemd to start all of the requisite NFS services. systemds tools for figuring out what could be going wrong are, I am sure, complete, but very impenetrable to a person who wants to understand the minimum necessary to fix a problem.
Additionally, it seems to be easy to break systemd's boot scripts in a way that prevent systemd from being able to boot the system (it's happened to me over and over again through what seemd like innocuous user actions), and I have never successfully gotten systemd to boot into its recovery shell. I can get to the recovery shell but I can never type anything into it, it seems like there's something borked with the way it handles keyboard input somehow.
In summary, systemd is much less mature than init ever was, which, combined with its tendency to reimplement everything and thus de-evolve much of what used-to-work into no-longer-works-easily, has resulted in whole system failures at a rate that I have never, ever experienced before under Linux.
All that being said, it's pretty clear that lots of Linux distro maintainers are more excited by the few advancements that systemd makes over the old init system, than they are put off by the lack of maturity and quality of systemd; therefore, systemd is an inevitability, and I'm glad that debian is taking it now, because it will mean even more developer effort towards fixing its problems.
In short: more pain for other people, making them more likely to fix my problems for me. So I'm happy that debian is doing this to their users, for my benefit.
The problem for Gnome and KDE is, that systemd is vastly superior to anything out there, and that it will help them dump loads of hard to maintain code, and give them easy access to make powerful distro-agnostic programs.
systemd provides a a common, uniform Linux plumbing system that makes life easier for all user program developers. So of course Gnome and KDE will start to take advantage of systemd, why shouldn't they?
The main problem with those who for some reason or another doesn't like systemd, is that they are incredible lazy. Instead of actually getting together to make an alternative development stack to systemd, they rant against Poettering and spew empty platitudes about "UNIX philosophy".
The most pathetic example of this anti-systemd laziness, is of course "ConsoleKit". It has now been unmaintained for +1½ years, but it is a crucial piece of infra-structure for any Desktop. But instead of either maintain it or make an alternative, anti-systemd people just rant against Gnome for no longer making it a priority to support this piece of abandonware. All rant and no work.