Debian Technical Committee Votes For Systemd Over Upstart 379
Posted
by
timothy
from the process-as-process dept.
from the process-as-process dept.
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."
Incorrect summary. (Score:4, Informative)
the default init system for Linux architectures in jessie
Re: (Score:3)
How is that misleading? The next release of debian is codenamed jessie, apparently.
Re: (Score:2, Informative)
How is that misleading? The next release of debian is codenamed jessie, apparently.
Nether Debian GNU/Hurd or Debian GNU/kFreeBSD are receiving systemd. Just Debian GNU/Linux.
Re:Incorrect summary. (Score:5, Insightful)
Re: (Score:2)
systemd was not a GNU project, so to suggest this is a GNU/linux distro is as fallacious as claiming that it's Poettering/Sievers/Linux distro.
What it is, is Linux. This particular project has some parts written by the GNU, and some parts written by Poettering/Sievers, and some other parts written by some other people. Stop trying to imply that the GNU is the be all and end all of user land software on Linux.
Re: (Score:2)
I need a term that differentiates things like android or my roku box from systems running glibc and X11 or wayland. I think GNU/Linux works for that.
Re:Incorrect summary. (Score:5, Informative)
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.
Soooo.... (Score:2, Informative)
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 mak
Re: (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
Re:Soooo.... (Score:5, Funny)
Your names going in the book, you quisling running-dog. You'll be first against the wall when the revolution comes.
Gee (Score:5, Insightful)
Who would have thought there would be consequences to spamming every article with whining and bitching?
Re: (Score:2)
It's just a news site. There are loads of others. Calm down.
Re: (Score:2)
There's only one Slashdot.
Re:Gee (Score:5, Insightful)
Maybe he was downvoted by all the people who actually want to use the site instead of having to dig through 1000 'boycott Slashdot' and 'BETA SUX0RZZ!!' messages, and this is an example of the moderation system working.
We get it. Everyone hates beta. I hate beta. However, I hate digging through the 'FUCK BETA!' messages nearly as much as I hate beta. By all means, boycott the hell out of site, but I'll just send feedback and if they don't listen I'll find some other site to read. Then I'll come back and have a peep every couple of months to see if they got the message.
Thank You Slashdot (Score:2, Insightful)
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.
Re: (Score:2, Insightful)
I fully support the rights of a bar to throw out the belligerently drunk
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.
Re: (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: (Score:2, Offtopic)
Hopefully your kids are going to take the same stance (ignoring the issue) when you start dying of cancer. Then after you die, they can find another dad.
Re: (Score:2)
The patrons told him to stop before he changed the wallpaper and took away the pool table, but there is no stopping him.
FTFY.
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: (Score:3)
If your using this sites comment system to try and destroy this site with a boycott, why do you expect to have good karma on this site ?
Re: (Score:2)
Because he expects the community to agree with him. Karma should reflect what the community thinks of his activity, not what the site's admin thinks, so it should be possible to have positive karma on this site even posting negative comments about it, as long as the community supports them.
So either the admin tampered with his karma against the community's intentions, or the community is not as impressed with his activity as he thinks.
Re: (Score:2)
If your using this sites comment system to try and destroy this site with a boycott, why do you expect to have good karma on this site ?
Then why's mgt. here (rant removed) ?
That reponse pretty much explains why your karma is burnt and your posting anon. Your post is not relevent to the story or the comment you replied to.
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.
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:Glad this is over (Score:5, Funny)
...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...
Re: (Score:2)
strongly preferred by a vocal minority who arrogantly THINK they represent the entire userbase.
FTFY.
Luckily they have now thrown in their own windows by acting like total assholes. Good riddance.
More on systemd... (Score:5, Informative)
Re: (Score:2)
Apparently this is the most important information, from the front page.
Spelling
Yes, it is written systemd, not system D or System D, or even SystemD. And it isn't system d either. Why? Because it's a system daemon, and under Unix/Linux those are in lower case, and get suffixed with a lower case d. And since systemd manages the system, it's called systemd. It's that simple. But then again, if all that appears too simple to you, call it (but never spell it!) System Five Hundred since D is the roman numeral for 500 (this also clarifies the relation to System V, right?). The only situation where we find it OK to use an uppercase letter in the name (but don't like it either) is if you start a sentence with systemd. On high holidays you may also spell it sÃstÃmd. But then again, SystÃme D is not an acceptable spelling and something completely different (though kinda fitting).
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.
Upstart is The Slashdot Beta of th init systems? (Score:2)
Or, the CLAs are the Slashdot Beta of OSS Communities?
I do not know, just keeping the flame alive... ;-)
Re:More information on the topic (Score:5, Informative)
You're looking at the upstart position document:
https://wiki.debian.org/Debate... [debian.org] and https://wiki.debian.org/Debate... [debian.org] represent broader parts of the debate.
Re: (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
Re: (Score:2, Insightful)
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.
I can only assume that all people who support this argument run GNU Hurd, as it's a microkernel, instead of that 16,000,000+ line of code "monolithic megamonster" known as the Linux kernel.
Re: (Score:3)
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..."
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.
Beware journald... (Score:5, Insightful)
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.
Re:Beware journald... (Score:4, Informative)
Essentially all important server distros have caved at this point. RHEL7 is systemd. Pretty sure SuSE and Mageia are (or soon will be) systemd, if there are any of those left. Arch for the server dangerous-livers is systemd. Now Debian.
I would call all of them lemmings (except Red Hat, which is the actual instigator), except realistically what were they to do? Get left by the wayside? The writing on the wall is clear. For me it's enough to pay a lot more attention to BSD.
Re: (Score:3, Insightful)
I too, lament the apparent impending demise of sysvinit shell script startup and plain text logging/process handling. Functional transparency in Linux booting was a good thing, and it will be missed. It seems more to me like these people arguing so hard over whether to replace sysvinit with upstart or systemd as though just leaving it alone was not an obvious option are more interested in changing the Linux init system to something inherently less secure and more obfuscated so that they can leverage it as
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: (Score:3, Informative)
As someone who does run Linux on desktops as well (and has been doing so for much longer than a week) I can tell you conclusively that if you think you need to become a Bash guru just to make "a few changes to network startup" then YOU ARE DOING IT WRONG probably starting with not reading the distro-specific setup instructions, and making the typical noob mistake of assuming that just because something seems evidently possible to accomplish without reading said instructions that reading the instructions wou
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)
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: (Score:3)
Just run syslog alongside journald, and you will have all what you are used to have. You even gain many benefits like earlier logging in the boot and other things. You can even turn of that journald uses any storage space or binary logs, but just let it forward everything directly to syslog.
Personally I don't find it needed, though I ran my Fedora desktop like that in the beginning until I weaned off my old fear of binary log files.
Re: (Score:3)
Heh, I would have phrased it a bit differently: "Until I threw my prudent caution about relying only on binary log files to the wind". But as long as I don't employ you in IT, it is only a preference. And hey, I don't rule out that I might evolve to the same preference.
Re: (Score:3)
For a long time I"ve told people that the difference between Windows And Linux is that then Windows there is a menu somewhere, and if what you want to isn't on it, you can't do it.
There's no menu for Linux, no limits. Till now. If Lennart hasn't thought of your use case, or doesn't care about it, then it's not going on the menu.
.
Re: (Score:3)
Can you elaborate on this? I am on Arch with systemd, typing in a bash cl, and tried exactly your "jou (TAB) -F (TAB)" example. Just as I expected would happen, the first tab filled in "rnalctl ". So far so good. Every arbitrary command has done this for years. And, just as I expected would happen, the second tab did nothing until I repeated it a second time, and then offered me a list
Re:Beware journald... (Score:4, Interesting)
Tab completion is largely a function of the shell (bash/zsh/etc.), not of the program being completed.
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,
Re:Beware journald... (Score:4, Insightful)
I think Pulseaudio was a great step forward for sound on Linux. Yes, it did uncover many sound card driver bugs, and bugs in Alsa back in 2004, but that also meant that those bugs got fixed. My internal sound chip was somewhat flakey before pulseaudio, and PA simply broke it completely, but that also meant, that when the bugs was fixed, the sound chip driver and Alsa layer worked perfectly ever since. I just used a popular and well supported SB compatible sound card instead while the bugs where fixed.
At the time, every other sound daemon was neither system wide, nor working properly. PA solved all problems in a rather elegant way, so for nearly a decade Linux have had an excellent and powerful sound deamon. Sound just work, and the "per application" sound volume is worth everything.
That PA is really good and actually solves real world problems, is evident by the absence of any serious competition to it. If PA ever was so bad as some people like to claim, why didn't alternatives spring up instead?
Sure, PA doesn't do low latency stuff like Jack, but it was never meant to. Instead PA works in perfect unison with Jack, in that it can suspend itself when certain programs need low latency sound operations, just like PA works on top of Alsa, not replacing it.
Re: (Score:3)
No, jackd and pulseaudio try to solve different sets of problems.
They don't compete even the slightest. If you think otherwise, you're completely off base.
jackd is not a generic sound server, doesn't want to be and hates anyone who thinks it should be one.
jackd is a virtual patch panel for audio. It let's you take audio sources (input hardware or applications) and connect then to audio sinks (output hardware or other applications). And it does so while striving for absolute minimum latency.
But it's ill suit
Re: (Score:2)
Instead of copying my post about this very thing elsewhere, I'll just link it here:
http://linux.slashdot.org/comm... [slashdot.org]
I really think this plaintext logfile business is overblown.
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.
sad. Now what is the alternative? Fork? (Score:2)
Upstart was unnecessary in Ubuntu. Systemd is not necessary in Fedora or Debian.
There are other ways to get fast boots, without create another monolithic do-everything daemon with spaghetti dependencies.
Basic software engineering principles (and Unix principles), should tell you that do-everything daemons, like upstart, systemd, hald are bad ideas.
With such complex, unmodular core Linux systems, Linux based OS's will grow increasingly more unstable and insecure.
Also, systemd and upstart make Linux much les
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: (Score:3)
"Forcing it on many systems so that it gets improved as to be more usable." WTF? Are we now cloning the MS business model as well? If this thing is not rock-solid, highly usable and in a final state, it has no business at all being a default init system, except in highly experimental installations.
Re: (Score:3)
I don't care if it's in a final state (no software ever is). However, I echo the OP's lament that pushing out software that does half of what the old software did, half as well, seems to be a common and distressing mode of operation among too many developers. KDE 4.0, Unity, Gnome 3, etc., would have been a lot more acceptable if it was at least as functional as what it replaced. The common pattern seems to be throw out beta software, spend two years sorting out the issues until most users are satisfied, an
Re: (Score:3)
Indeed, very true. Or the myriad of stable window managers (I use fvwm, one major update in the last 15 years), instead of trying to clone Windows with KDE and Gnome and never really reaching an usable, mostly stable state.
This may be a result from more and more commercial development going into Linux: These people have to justify their existence. With LaTeX, fvwm and other "stable" things, things get fixed when they are broken, not before. And if they are not broken, they just stay unbroken.
The other thing
Re: (Score:3)
It's not the dropping into a recovery shell that is the problem; that is something that I would expect to happen (and always happened under init, as well).
It's the fact that the systemd recovery shell is nonfunctional. It doesn't accept keyboard input. I had this happen under Arch Linux, then switched to Fedora, and had the same thing happen. And thus concluded that it's endemic to systemd since it's hard to believe that both Arch Linux and Fedora independently managed to screw up systemd's recovery shel
tried an true? (Score:2)
honestly, i would rather have something that is known to work in the long term and not need update to patch bugs or possible changes to the config file implementation. let's just use something that we know works.
on the other hand, couldn't it be an optional package (a package is required but there are multiple to choose from) with the default as systemd?
My biggest gripe with systemd... (Score:3)
...is that "systemctl" is a lot of keys to type, and the last four are all consonants.
At least "service" is an actual word.
Damn. Time to move away from Debian. A shame. (Score:4, Insightful)
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.
systemd is broken by design, (Score:3, Informative)
read more about it at: http://ewontfix.com/14/
Re: (Score:3, Insightful)
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.
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.
Re: (Score:3)
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.
I hear that argument a lot. The problem with it that systemd's approach likewise has "very little in the way of technical arguments". To the most questions you get blank non-responses which amount to "it is like it is".
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, [...]
systemd moves to C what was historically done by shell scripts. Admins and testers - people who deal with the init system more than anybody else - can't C but can shell. What's more, on a typical systemd system, literally all the gritty bits of initialization are hidden in the binaries. If you need to modify some aspect of their behavior - tough luck. Pottering is one of the proponents of the 100% configuration-less system: majority of the binaries do not even have any command line options to customize their behavior.
If PulseAudio example taught us anything, systemd has a chance at being something - only after Pottering is done with it and leaves the project.
P.S. Do not take me as a upstart proponent. I have installed both Fedora and Ubuntu in VM and have to say that like none of them. Or rather. I do not like the Fedora. (But heck, GNOME 3 desktop is hard to like and it sets the mood from the beginning. Dysfunctional Alt-Tab alone is worth dismissing the whole distro.) Ubuntu in that respect is much more palatable. But then, upstart plays there only a small, albeit important, role of starting up basic system services - rest, including service management, is done by the usual sysvinit scripts. Fun fact: Fedora boots about twice slower than the Ubuntu, despite systemd's promise of faster boot times vs. Ubuntu's reliance on the slower sysvinit scripts. In the end, I'd still take sysvinit.
Re: (Score:2)
Re: (Score:3)
I'm working in software development, so our needs - and admin's tasks - are different.
In fact, most of the tweaking is done by the testers (who being on the receiving end of the pre-release software) often end up being responsible for making the software working as a whole.
Init script tweaking incidents went down considerably, but still happen.
In the end, and as we are concerned, even *single* incident enough to justify the hard requirement for tweakable init system.
Though, to give a balanced perspe
Re:Irrational Hate (Score:5, Insightful)
Personally, I prefer the traditional init system from UnixV...but then I also prefer grub over grub2. I like to be able to edit my scripts easily, and not dig through several files and try to puzzle out the documentation. (In the case of grub2 my puzzling out the documentation hasn't been that successful...I frequently need several attempts to get a change that would have been simplicity itself in grub. OTOH, I've only got one machine that I can use, so any change is difficult. If I make a mistake, I may need to reinstall the whole system. I can't just look up an answer on the internet...because that requires the machine to be working.)
Re: Beta (Score:2)
Interesting...I prefer systemd over upstart and I know many others that do as well. So I know it is BS to day systemd is almost universally despised. At worst it is seen as the least of all evils.
It anything the debate is over retaining init.d scripts and systemd as upstart is somewhat of a single vendor stepchild. The main legitimate concern with systemd is its Linux-only implementation complicating the porting of packages to BSD and HURD based systems. The other might be a matter of taste but still worthy
Re: (Score:2)
you mean canonical has something else than alpha builds of some sw??
Re:I see a lot of discussion about systemd (Score:5, Insightful)
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.
Re:I see a lot of discussion about systemd (Score:5, Insightful)
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.
Re: (Score:2)
Those people want both Windows and Open Source. Maybe ReactOS would be a better match.
Re:I see a lot of discussion about systemd (Score:5, Insightful)
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.
Re: (Score:2)
Re: (Score:3)
'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?
Re: (Score:3)
'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 start
Re: (Score:2)
3 times. one was lennart, wan was kay - and 3rd was the designer of slashdot beta
Re: (Score:3)
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 in
Re:I see a lot of discussion about systemd (Score:5, Informative)
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.
Re:I see a lot of discussion about systemd (Score:5, Insightful)
"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/... [wikipedia.org]
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.
Re: (Score:2)
The point being that boot time is the most *visible* benefit and the rest of the benefit is dubious at best. It's interesting to see people create strawmen of complexity. In one case, they went through someone who got permission denied in error_log for apache and then understood to check permissions and selinux context. They then manufactured a straw man of someone confused by that doing service httpd status to see if it was running (who the hell get's http error 401 and wonders if the httpd service is r
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: (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: (Score:2)
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.
No, systemd didn't break anything. It is merely the messenger that tells that a separate /usr is a broken idea on a modern Linux. systemd works fine with a separate /usr, but your Linux distro probably doesn't. /usr.
Just use "initramfs" if you actually have a real need for a separate
Look here for more information:
http://freedesktop.org/wiki/So... [freedesktop.org]
Re: (Score:2)
... 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.
Anybody without a proper rescue boot media is up shit creek when a system is so broken that the binary tools doesn't work any more, be it journalctl or grep or cat. And frankly, working directly on system with a RW filesystem where fundamental tools doesn't work is simply bad practise anyway.
With a boot media it is a piece of cake to read the journald log files. You can even merge them with the boot media's log files to compare the boot processes. systemd and journalctl are designed to work with multiple l
Re: (Score:3)
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 r
Re: (Score:2)
>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.
As long as the logfiles are standardized, this shouldn't be a problem. Do I worry if I need to look at a .zip file or a .tar.gz or .tar.bz2 file? Of course not, because any Linux system has the tools available to view these archives. The only real problem is if I want to view something like a .tar.gz on a Windows system, but ev
Re:I see a lot of discussion about systemd (Score:5, Insightful)
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.
Re:I see a lot of discussion about systemd (Score:4, Insightful)
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.
Re: (Score:2, Troll)
Obviously, there's been a big push across the board by many various distros, but what are the real benefits of systemd? Is it better for average end-users (Easier? Faster?) or those more technically inclined (more stable, uses less resources, more configurable)? Or is this simply a case of it just being non-Canonical?
First, sysvinit sucks. All other Unix'es have abandoned it years ago. Only lethargy and lack of real improved Linux init-systems kept Linux on this sinking boat.
Linux distros have historically been extremely fragmented with no commonality between them for doing even simple things. It is impossible to make a simple distro agnostic gui that shows what the distro is called, or how to set time, or change the network values. There are probably 20 known different places that distros hide their name and release nu
Re:Die, Ubuntu, Die (on topic = marginal) (Score:4, Insightful)
Ubuntu used to be good before they destroyed themselves around 2011.
Mint is an Ubuntu fork after all...
Re:Die, Ubuntu, Die (on topic = marginal) (Score:4, Informative)
Re: (Score:2)
For some reason I expected the next sentence to be "We could fight them with conventional weapons, but that could take years and cost millions of lives".
Re: (Score:2)
Really? In my head I heard " we shall fight on the seas and oceans, we shall fight with growing confidence and growing strength in the air, we shall defend our island, whatever the cost may be. We shall fight on the beaches, we shall fight on the landing grounds, we shall fight in the fields and in the streets, we shall fight in the hills; we shall never surrender"
Followed of course by the first bars of Iron Maiden's "Aces High".
Re: (Score:3)
An earlier post by another proponent of OpenRC said that it was still too beta to be adopted, even though he regretted it.
Re: (Score:3)
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?
wtf is wrong with people? (Score:3)
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.
Re: (Score:3)