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."
the default init system for Linux architectures in jessie
Having been a well behaved, not overly vocal member of the slashdot community for many years (10? more?), today, I found myself banned by ip. and my Karma (which has always been neutral) reduced to "terrible".
I had posted 10 times over the last 48 hrs, in support of the slashdot boycott. Most sensible debate, some houmour.
You know once the powers that be need to silence those who gently disapprove, that it's all gone terribly wrong, and those pushing for change that damages everyone are too weak to even make a sensible argument.
Oh Dear.
It's a shame to see a bunch of Canonical shills on the Debian Technical Committee though. This should have been strictly between OpenRC and systemd, 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.
But no worse than systemd, which is near universally despised by system administrators.
Does slashdot have Leonart Poettering on the design team, by any chance? It would sure explain a lot.
...here.
Finding God in a Dog
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?
Justice is served. Keep up the bans and let's get rid of the deadwood.
I fully support the rights of a bar to throw out the belligerently drunk - that's not censorship, it's called caring for your customers. None of us are here to read moronic posts about website style changes. We are here to read insightful commentary on technical stories and if you can't handle that, you do not and should not belong.
"There is more worth loving than we have strength to love." - Brian Jay Stanley
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.
systemd versus upstart is mostly anti-canonical sentiment coming home to roost. Canonical has made it clear they don't want to play nice with the wider non-canonical community, and now that's going reciprocal. In a way, systemd and Wayland should be grateful. A non trivial amount of the increased urgency behind migration to those schemes are driven by a distaste for canonical as they push upstart and Mir.
systemd versus sysv init most visibly leads to faster boot (by providing a richer dependency model and avoiding spawning as many processes through skipping shell scripts a lot). The downside should be clear in general, the philosophy leaning more toward compiled modules over shell scripts means it's harder for a lay person to dig in and follow things and understand how they work. If you dig deeper you'll notice that the number of getty processes is lower for most people by skipping spawning such things until the VC is active and other similar things. These are things that really don't meaningfully add to the experience in 99.999% of cases, but it's the sorts of little awkward/arbitrary things that systemd aspires to be a bit more fancy about managing. If a distribution fully embraces systemd philosophy (e.g. Fedora), no more plaintext logfile to peruse. You get tools to do some more sophisticated things to log files, but if you find yourself with the data in a place without ready access to those tools, you will be out of luck.
XML is like violence. If it doesn't solve the problem, use more.
Ubuntu used to be good before they destroyed themselves around 2011.
Mint is an Ubuntu fork after all...
The problems with it include an obsession with APIs
Incidentally, this also means they align more closely with Microsoft thinking than traditional Unix thinking. At some point I wish these people would just accept they want Windows and go with Windows and leave Linux alone.
XML is like violence. If it doesn't solve the problem, use more.
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.
Their recent updates have broken udev so badly, that Gentoo decided to fork udev to retain the old design. Debian should pay attention.
You do know your pretty flagrant racism makes your opinions automatically much less sound, right?
"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.
...is that "systemctl" is a lot of keys to type, and the last four are all consonants.
At least "service" is an actual word.
systemd is Roko's Basilisk.
I'm an old school user and absolutely hate SystemD because it absolutely violates the LFSH standard by requiring /usr to be part of the root file system. This is the primary complaint against SystemD in regards to the Gentoo community and I'm sorry to see that Debian has fallen for breaking the KISS principle.
Mod me up/Mod me down: I wont frown as I've no crown
Those people want both Windows and Open Source. Maybe ReactOS would be a better match.
The Tao of math: The numbers you can count are not the real numbers.
With a boot media it is a piece of cake to read the journald log files.
My boot media doesn't have journalctl and such. You may say 'just make new boot media', the point is that's yet another requirement driving evolution of something that has historically not needed much touchup. Because Lennart pushes a new toolset, now downstream projects that focus on recovery images have to spin, and users of those projects have to be aware and pick up updates. I don't think they have promised forwards compatibility, meaning journalctl might have to rev or else be completely unable to render the files on some updated version of a distro. It creates a scenario where more specific match between diagnostic and runtime is made a more hard requirement.
It just makes sense that diagnostic data to the extent possible should be readily available in a format that really *anything* can read without particular tooling. The false dicotomy presented is that it's either unstructured plain text logs or unreadable structured binary data. The machine friendly structured binary data could have been managed alongside text representation of that data.
I personally *hate* that if I'm using a linux system to look at a windows system, there really isn't a good way to get 'eventviewer' sort of data. This is presenting the exact same scenario.
XML is like violence. If it doesn't solve the problem, use more.
Actually, I would complain if the currently active log file were gzipped. It's a needless impediment to read the files. Besides, once a developer has said 'gzip' the files, then they decide 'well, I can bzip them', then later 'oh, well, .lzma is good', then 'oh, use xz'.. This is the sort of situation that systemd sets up: a treadmill where diagnostic environments must match runtime environments or else.
When Linux systems all
This language sounds like the sort of language MS would use to justify eventviewer. "All editions of *windows* will have it and that's all that matters". We've had inter-operable logging formats and facilities for decades in the *nix world, and now systemd systems will break from that strategy.
Just because you *can* do something doesn't mean it should be done. Just because this is one way at getting to more sophisticated log analysis infrastructure doesn't mean there is not a better way which would have made everyone happy.
XML is like violence. If it doesn't solve the problem, use more.
The worst part is that systemd existed about ten years ago: GNU Daemon Managing Daemon, written in Scheme. It has recently been resurrected as the init system of GNU's Guix distribution... instead of ini-files (which have gotten out of control already in systemd and have transformed into an absurd little programming language with awful syntax and undefinable semantics) you extend it using Scheme modules which can be loaded without recompiling the entire daemon. New functionality is implemented as classes, methods, and plain old functions (better than shell pseudo-functions and "well just add a new ini key in C").
I'm not sure why we're reverting to an init system written in a barely-typed static language that doesn't have garbage collection (I really like it when a process I can never kill has any chance of leaking memory), can segfault with nothing more than a small typo, requires new releases to add even minor new features, and has an upstream that is ... difficult (I mean come on, rejecting patches to support not-Linux? Even when an offer to maintain the other system comes with the patch?), ... especially since Debian has (except for the whole GFDL is non-free spat) been pretty closely aligned with GNU.
HAL 7000, fewer features than the HAL 9000, but just as homicidal!
use binary formats that only Linux/Unix systems can easily read, and which Windows systems (among others) cannot. We call these binary formats "plaintext", but they're not, they're a binary format that uses ASCII encoding, with a particular end-of-line standard which is different from that on Windows
Dealing with \r\n versus \n is *totally* different scale than this. Given the workaround in windows is as simple as literally using *anything* other than notepad (get-content, wordpad, really *anything* but notepad understands '\n' by itself implies '\r'). EDBDIC is a good example of how IBM has certain things screwed up in mainframe world, so I don't think holding that up as a shining example of what works for justifying a proprietary format.
And on modern systems, xz is commonplace as well.
My point is today 'xz' is modern place on 'modern systems'. 6 months from now, there is something else that will be 'commonplace' and therefore might as well make it a hard requirement. It's churn without sufficient benefit to justify it.
No, you won't be able to easily copy these files to a Windows system and work with them there (without installing extra tools), but that's no different from today (and why would you want to do that anyway?).
I might want to pop a drive from a failed system into an external enclosure attached to my CentOS 6 workstation. I still would be in a fix despite having all the filesystem and block device wrangling required to get at the files.
XML is like violence. If it doesn't solve the problem, use more.
'uniform Linux plumbing system' ?
Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?
'uniform Linux plumbing system' ?
Last I checked, KDE ran on Open/Net/FreeBSD and even Windows and OS X. Gnome, which seems to be largely a Red Hat driven technology these days, couldn't give a rat's arse about portability but why should other desktop environments be steered to Linux-only?
Yes, that is true last time you checked, and next KDE edition (KDE SC 5/Plasma 2) will of course also run on *BSD. But with reduced functionality on all non-systemd systems, compared with the systemd version.
This is not because of some sinister conspiracy, but because systemd offers easy use of many nice features that KDE and Gnome (and LXQT etc) would like to use, and non-systemd systems doesn't provide.
The point is exactly, that systemd is a very nice uniform Linux plumbing system, and that DE's are starting to take advantage of that.
You are thinking server. Linux is also about the desktop.
Are you kidding?
How many servers run Linux?
How many Desktops?
Who cares about Linux (who is the "audience" for Linux)?
My main machine is actually a Linux notebook. It's a pretty miserable desktop, but it's OK for what I do, and I have the comfort of a real shell, and real keyboard with all the keys, and can try out sonme server stuff on my notebook. But I could replace it with a Mac or Windows notebook if necessary.
Where I really care about Linux is on servers. Headless servers, with neither Gnome nor KDE installed.
Until now, I heard that systemd would boot faster. Maybe it has some other benefits for servers, but boot spped is certainly not one of them. The servers spend much more time in the BIOS screens than booting the OS, and they reboot about once a year or less. So to convince me, it will need much more than a few seconds of boot speed...
An earlier post by another proponent of OpenRC said that it was still too beta to be adopted, even though he regretted it.
I think we've pushed this "anyone can grow up to be president" thing too far.
I am not putting a convoluted, megalomaniac-spawned and KISS-violating atrocity like systemd on my systems. The binary log-format alone is a faux pas to severe as to invalidate the whole thing. Are there any good server-distros left that stay away from systemd or that are at least commited to maintaining a different init system longterm, preferably the classic SysV init?
Of course systemd will fail eventually (once enough people realize it is a bad clone of what Windows does and makes things worse, not better), but I am unwilling to wait that long or tolerate all the disadvantages this thing brings in the meantime.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
And that shows just how _wrong_ this all is. A GUI has no business in hell depending on an init-system. This is all very un-UNIX, KISS-violating, bloated, Windows-like. Why do so many people not see what incredible amount of things they are breaking with systemd?
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
as a debian user i am puzzled by why this monstrosity was chosen instead of something that adheres to the 'do one thing and do it well' philosophy. why are we slowly turning gnu/linux into windows?
Zawinski's law: Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.
i propose we include an email client functionality now and be done with this horrible one-thing-breaks-all thing.
read more about it at: http://ewontfix.com/14/
If you think being a nerd is about doing things the most awkward ass-backward way possible, you're an idiot. Easy things shouldn't be difficult. Make easy things easy, and spend the time recovered on less pointless fuckwittery.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.