Debian Technical Committee Votes For Systemd Over Upstart 379
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."
Glad this is over (Score:2, Interesting)
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.
Re:Soooo.... (Score:2, Interesting)
You are not alone. It's been the same here for me. I had the karma maxed and now it's terrible.
Fuck you, Dice motherfuckers. I'll join the boycott in a few hours.
FUCK BETA
More information on the topic (Score:5, Interesting)
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... [debian.org]. The wiki does a good job detailing the technologies. Given the information, the choice of systemd is interesting.
Irrational Hate (Score:5, Interesting)
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.
systemd devs can go fuck themselves (Score:4, Interesting)
Their recent updates have broken udev so badly, that Gentoo decided to fork udev to retain the old design. Debian should pay attention.
Re:More information on the topic (Score:2, Interesting)
Which are filled with bad logic. For example:
Systemd is often said to be too big for the functionality of an init system.
However it is much more than init, and if you take into account all the functionality it can provide or replace, you’ll soon find out that it takes less lines of code than the alternatives, in a language (C) that takes less memory to execute.
This is not the point or benefit of the original UNIX and much of the Linux architecture. By doing small tasks well, a reliable toolchain can be built of those small tasks. *OF COURSE* a monolithic megamonster is going to have fewer lines of code than all the different components shoe-horned into it. And of course *it's going to get details wrong* in those individual components, but the monolithic megamonster may rely on those flaws or make debugging of them unreasonably difficult.
Been there, done that, have the bug reports. SuSE tried this sort of stunt with YaST for configurations, which blew, and Red Hat has more recently done it with NetworkManager, and Gnome tried it with Gnome 3. They were bad ideas then, they're *still* bad ideas, and I rip them the hell out as fast as I can for stability. Unfortunately, I can't just rip out the init system....
Re:Thank You Slashdot (Score:2, Interesting)
The problem is the drunk one is the barkeep. The patrons told him to stop before he wrecks to whole place, but there is no stopping him. Every day he gets drunk and wreaks half the bar. Soon he'll be drinking alone. And it all started with that damn game of Dice.
So leave. If the new redesign is as bad as promised, I'll leave when the time comes. No need to ruin Slashdot ahead of schedule.
Re:Soooo.... (Score:4, Interesting)
Well, I haven't been banned, but my regularly scheduled mod points have not appeared. All I did was mod up some of the more polite and reasoned anti-beta posts... The "Fuck beta" posts are anatomically improbable, and likely less than helpful, but I ignored them and left them where they were.
I am a late joiner (7 digits), but was an AC for a long time before I registered. I await the outcome of this situation. As far as I can tell, beta isn't being forced on us yet, and if it is, well, perhaps it is time I left /. behind anyway. It has been fun. :)
Re:Beware journald... (Score:5, Interesting)
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...
I was sceptical about binary log-files too in the beginning. However, I didn't have to play around with the journalctl tool before I realized that systemd's logging is far superior to any existing simple text logging.
stuff like "journalctl -b 2" (only show logs from previous boot) and "journalctl -F _SYSTEMD_UNIT" (show all systemd units that have ever written to the logs) are pure gold. The amount of tab-completion with everything is just so nice. Try "jou (TAB) -F (TAB)" and it will show all possible values.
You get logging info from much earlier in the boot process then previously, and with kdbus something that will get even earlier and later in the boot process and when shutting down.
journalctl works great with all the usual text tools like grep, just think of it as a super 'cat' with god-like sorting powers.
Forget what others sneers about Poettering and systemd, and give it a proper workout with a distro that supports it properly, like Fedora 20 or similar. Make up your own mind by actually using it.
This is a good starting point:
http://www.freedesktop.org/wik... [freedesktop.org]
To me it is clear that systemd simply is the future Linux plumbing system, and to me it is a quite brilliant solution as it is now.
Especially logging is a huge improvement. Novices can for the first time actually do usable filtering without knowing arcane programs and switches. A simple "journalctl -b -p err" will reveal much of interest for the novice trying to debug a problem. (shows all messages of priority levels ERROR and worse, from the current boot).
And because the log is structured in db form, there will be GUI logviewers that are actually useful, and that can do filtering and sorting by eg. error levels, monotonic timestamps etc.
Re:Beware journald... (Score:4, Interesting)
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.
That's disenheartneing to hear, considering how many times I have had to hack the hell out of my init scripts to kill avahi because I DO NOT WANT IT, and the fact that pulseaudio came in and made a mess where jackd was just starting to make things sane, and the time spent would have been better spent improving jackd.
But on the other hand, jackd had that unfortunate attempt to fork into a C++ reimplementation, and lost its (never fully supported) ability to run as a systemwide daemon so background daemons could use the soundcard, and pulseaudio has since turned an about face and started supporting a systemwide daemon, more RT features (AFAIK not quite yet up to snuff with what JACKd offered) and has been less of a general nuisance recently.
So, there's something to be said for software that starts out as inferior but due to the charisma and/or persistance of its proponents, eventually manages to get a larger development community, because that community will beat it into shape, and hopefully manage to shed as much cruft left over from the inferior design through a concerted deprecation effort. It's a hassle to us users, but works out eventually. It looks like this has happened and will continue to happen with systemd.
We could avoid that if the competent projects were somehow given an injection of participants, but people that write necessarily-complex code generally tend to spend most of their time doing just that, not glad-handing on mailing lists, whereas the authors of insufficient simplied solutions have more time to politic. The only part about that that stings is that the latter often uses the former as a cheat-sheet going forward and does not bother to give credit,
Good, because it's inevitable (Score:5, Interesting)
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.
Re:I see a lot of discussion about systemd (Score:3, Interesting)
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.
Re:Soooo.... (Score:4, Interesting)
Please, for FUCKS sake, can you guys please stop bitching over Beta? We all don't like it, but I guess /. got the message now.
Now, back on topic: Good choice Debian. Seeing Canonical ruins all projects it gets its fingers on, implementing Upstart would've been a baaaad idea.
Re:More information on the topic (Score:4, Interesting)
Just because you can point to one microkernel that doesn't really work, and one monolithic kernel that does, will not invalidate the perfectly valid points made about the benefits of modularization. Yours is just a logical fallacy:
eg. "I'm sure everybody that likes bicycles never drives a car..."
Except it's not valid points made about modularization in this context. It's a blanket statement that modular is better, for which a single counter example is sufficient to disprove. The AC's post didn't mention specific flaws with systemd, instead they asserted generalizations about how modular is better than monolithic. Just because there are potential benefits to a modular system over a monolythic system does not mean a specific modular system is better than a specific monolythic system, leaving the AC's post as little more than FUD.
Re:I see a lot of discussion about systemd (Score:4, Interesting)
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 [gnu.org] 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.
Re:Beware journald... (Score:4, Interesting)
I realized that systemd's logging is far superior to any existing simple text logging.
I accept that is the case, but the approach threw out the baby with the bathwater. They could have maintained first class support for plaintext data either alongside or indexed by their binary blobs. I have used journalctl and it does have theoretically useful features. I have to say that, in practice, I've never found myself in particular need for what journalctl has added and only have used it to see that I could do it. There wouldn't have been a downside. They would have had the capabilities and performance they wanted, and the cases where an utterly trivial to read chunk of data would still be preserved.
Re:I see a lot of discussion about systemd (Score:0, Interesting)
Systemd is a steaming pile of shit, but this is standard for anything coming from Poettering.
Re:Beware journald... (Score:5, Interesting)
Indeed. "Those that sacrifice reliability for speed will neither have reliability nor speed." --me
And all that for something irrelevant like boot times. What I do not get is why so many people are so stupid about this. Maybe the NSA is pushing for the worst possible system so they have plenty of places to break in? Or to push people away from Linux? The thing systemd reminds me of most is IPSec, which we are now know to have been deliberately NSA-sabotaged by increasing its complexity.
Re:Beware journald... (Score:4, Interesting)
Tab completion is largely a function of the shell (bash/zsh/etc.), not of the program being completed.