Linux Mint Will Continue To Provide Both Systemd and Upstart 347
jones_supa writes: After Debian adopted systemd, many other Linux distributions based on that operating system made the switch as well. Ubuntu has already rolled out systemd in 15.04, but Linux Mint is providing dual options for users. The Ubuntu transition was surprisingly painless, and no one really put up a fight, but the Linux Mint team chose the middle ground. The Mint developers consider that the project needs to still wait for systemd to become more stable and mature, before it will be the default and only option.
The pain isn't in the switch (Score:5, Insightful)
it's in trying to resolve problems later on, when you'll find that systemd helps you obscure the source of the trouble instead of resolve it.
Re:The pain isn't in the switch (Score:5, Insightful)
It's also in maintaining distinct management tools, configuration analysis, and configuration tools for DHCP, NTP, the new binary logging, space for logging of kernel booting, and whatever other components of the one man band have been added lately. systemd, and especially its core developer Lennart Pottering, are attempting to create a "stateless Linux", and the ramifications are spilling over into other parts of the system.
Quoting from the b log at http://0pointer.net/blog/proje... [0pointer.net]
> A Stateless System goes one step further: a system like this never stores /etc or /var on persistent storage, but always comes up with pristine vendor state.
That is a _huge_ shift in system management, and directly violates the file system hierarchy where host specific configurations are stored in /etc or persistent data in /var/lib. They're basically taking all the daemon specific parameters from /etc and putting them in /run, and they're going to run into most of the same problems but in unfamiliar layouts. Every component that stores history in /var/lib or configuration in /etc will have to be rewritten, including long-standing conventions such as /etc/hosts, /etc/resolv.conf, and /etc/nsswitch.conf.
Re:The pain isn't in the switch (Score:5, Funny)
a system like this never stores /etc or /var on persistent storage
including /var/log?? Well, I suppose that's one way to hide the fact that systemd's logs get corrupted.
Re: (Score:3)
That's not too far from the direction Linux has been going in general, though it's usually baked on top through the use of something like Ansible or Chef that does the factory-reset bit. As the post mentions, CoreOS is also aiming for something similar.
Re: (Score:3, Interesting)
As someone who has spent the last week plus upgrading his server to Jessie, I completely disagree that the pain isn't in the switch. It may very well be that more pain is coming but the switch itself has been quite painful and isn't over yet. How the fuck do you do a meaningful Google search on "systemd complains that starting Apache fails and shows the service as stopped but the process actually starts and Apache is working just fine, systemd apparently just doesn't know it?"
Re:The pain isn't in the switch (Score:4, Informative)
Re:The pain isn't in the switch (Score:5, Insightful)
The only behavior systemd "expects" is for daemons to talk to it either via dbus or libsystemd.
http://ewontfix.com/15/ [ewontfix.com]
Everything else have some kind of problem attach that is just waiting for the admin to tun his back on the rack.
Mod up (Score:2)
Short but actual useful advice. This should be modded up.
Re: (Score:2)
How the fuck do you do a meaningful Google search on "systemd complains that starting Apache fails and shows the service as stopped but the process actually starts and Apache is working just fine, systemd apparently just doesn't know it?"
I don't know. I can't even find your bug report.
Re: (Score:2, Interesting)
I'm on ubuntu 14.04 and a few times now, systemd of some kind (udev, I think) went cpu bound on me. my fan started spinning like crazy. kill -9 fixed that (the systemd proc). afaict, nothing else went wrong after I killed that proc.
its still not ready for production use. give it 2 years AT LEAST. if I was sysadmin at a place that needed reliable linux, I'd stay back on a non-sysd system for about that long, if not longer.
Re:The pain isn't in the switch (Score:4, Informative)
Re: (Score:2)
% ps auxw|grep -i systemd /lib/systemd/systemd-udevd --daemon /lib/systemd/systemd-logind
root 9394 0.0 0.0 51136 3480 ? Ss May04 0:00
root 18897 0.0 0.0 43456 2664 ? Ss Apr08 0:00
there are some systemd procs on my system. how did they get there, then? it may not be a full suite, but that udevd thing was what went cpu bound.
Re:The pain isn't in the switch (Score:4, Insightful)
Well for one thing by obfuscating system logs in a way that is likely (and expected) to fail.
Re:The pain isn't in the switch (Score:4, Insightful)
Rejected with reason: Delete the corrupted logs and move on
SystemD - works well when it works, fails spectacularly when it fails.
Re:The pain isn't in the switch (Score:5, Insightful)
SystemD - works well when it works, fails spectacularly when it fails.
Incidentally that is precisely the way Windows is. Windows is exceedingly structured and engineered (contrary to some beliefs), but as a a result when it fails... boy does it go down so hard that no one is going to bring it back. Not surprising many of the principles in Windows design match the design principles of many modern linux distros: Binary configuration files, binary log files, increasingly complex IPC schemes, and less and less friendly to simple scripts (though increasingly better for complex scripting).
Re:The pain isn't in the switch (Score:4, Informative)
dconf uses binary configuration files. As I've said many times, while systemd catches a lot of flak for messing with long standing conventions, it is far from alone in modifying the experience (dbus, dconf, systemd, udev all do interesting things, each component bringing interesting capability with varying degrees of drawbacks).
I think udev generally does a great job of delivering useful capability with minimal downside. Then dconf (most people don't even realize the binary dconf files exist, even when they poke dconf extensively). dbus starts going off the rails (many things that once were simple enough to explore/grep around for are now only possible through internet search of obscure dbus-send commands). systemd I actually consider less bad than having to do more and more dbus stuff.
I like how this got marked troll (Score:4, Informative)
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ [lwn.net] https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html [fedoraproject.org] It's a fact that systemd will only sometimes recover any part of its bullshit binary logs, and only any part after any error. So if journald truncates a file because it shits itself, which it has been known to do, then you lose the whole log.
Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions. Because you clearly have no idea what you're doing.
Re:I like how this got marked troll (Score:4, Funny)
Moderators, you might want to familiarize yourself with the festering pile of shit which is Lennart Poettering, as well as the pile of crap which is systemd, before you moderate any systemd discussions.
Please, tell us how you really feel! It's not clear to me from this sentence.
Re: (Score:2)
Please, tell us how you really feel! It's not clear to me from this sentence.
The way I really feel is that I'm currently building Linux From Scratch.
Re: (Score:2)
Re: (Score:2)
That's actually pretty cool. Why not use Slackware or something though?
I don't feel like Slackware offers me enough management to be useful over just raw Linux. Even it includes stuff I don't really feel I need. I could of course be using gentoo, and I'll probably take a look at that again soon. Last time I tried to follow the directions, and I'm pretty good at that mind you, I couldn't actually get the system built. I think that's because I added in a few too many flags, but if the selling point is that you get it how you want it, then the published USE flags should probably
Re: (Score:2)
It's a fact that the fix for corrupt logs, which systemd will often corrupt if you power-cycle your system, is to delete them and throw them away. https://lwn.net/Articles/621453/ [lwn.net] https://lists.fedoraproject.org/pipermail/devel/2013-July/185702.html [fedoraproject.org]
No, it's not a fact. If the log file is corrupt journald rotates it. It doesn't "delete it and throw it away".
Logs via network (Score:5, Informative)
SysD's binary logs have another, serious flaw: they are not designed to be sent over a network. This has been an intrinsic part of syslog for a looong time.
There are a few tools to send journald logs remotely, but they rely on tailing the binary log, then reformatting it and transmitting it over HTTPS to another tool on the destination system.
I found a feature request for journald/sysd/whatever to enable network logging, and the solution they are adding is to... tail the binary logs with basically the same tools.
Putting the disk in the middle and depending on file tailing is such a bad solution. Many things can cause this to fail; it's a total kludge.
I discovered this when investigating how to send journald logs to Splunk. The solution there is to... tail the binary logs with journald to a text file and have Splunk monitor the text file.
Now, this is not a fatal flaw. Journald could (I assume) be enhanced to natively send logs over a network. But, this shows that systemd is not enterprise-grade or production-grade, and was not designed with that kind of reliability in mind.
Re:Logs via network (Score:5, Insightful)
The real, fundamental problem isn't even having binary logging, they are free to do that in whatever miserably thought out bugfest they like. The problem is that they thought binary logging should be the primary means, and that is just stupid. I am all for a binary log... right next to the good old text log like we've always had. And if this was what they had done, then they would have got no argument on this issue. Instead, they threw away what we had, what was working, what all our tools were expecting, and replaced it with something that works sometimes.
Re: (Score:2)
No actually they are. Systemd has an export format and a JSON library you can attach to that produces a version of the log designed for combining. Systemd works far better with messaging clients than syslogd because it was written after messaging and networks.
Your specific example is also wrong. You just setup a Splunk forwarder: http://answers.splunk.com/answ... [splunk.com]
Re: (Score:2)
I wouldn't say converting all that metadata to text is great for the network. You have to parse all that JSON on the receiver end.
I guess you didn
Re: (Score:2)
You are right. I had your question backwards. But that makes the answer even easier:
journalctl -o short -f | ncat remote-destination.com 12345
As for the JSON on the receiver end, the receiver just links to the library and puts it into whatever logging format it wants. That's unavoidable unless you just want to dump the data structure as text for every entry.
As for converting to text, you can't advocate for syslogd and then object to text. You have 3 options:
a) Leave it in native binary format and le
Re: (Score:3)
Why bother with that rubbish when proper text logs are so superior and easy to handle?
unnecessary complexity, that's the flaw of systemd
Re: (Score:2)
What are you even talking about? journalctl -a -f will output the logs straight from memory.
Re: (Score:2)
Does it? If so, then it's not as bad, but needing to chain these commandline tools together to send logs over the network is still a kludge.
I'm not saying you're wrong, but do you have a reference for that?
Re:I like how this got marked troll (Score:4, Insightful)
Sincerely, all this hate towards systemd looks like pure zealotry.
Yeah, that's what they said about our love for Linux in the first place. Now that it's successful, and specific people are helping specific corporations gain undue control of it and at the expense of quality, they say it again about our desire to protect what made us care about it in the first place. We love Unixlikes which are actually "like Unix" ("The Unix Way", blah blah blah) not solely for aesthetic reasons, but for specific technical reasons which systemd compromises.
True, like any piece of software, systemd surely must have issues (binary logs seem like one) that should be fixed or parts that may be improved, but all this constant bashing from some members against it, is just purely irrational.
It's constantly being bashed by "some members" of the community because it's still a problem. It's not like we pointed out the problems and they were fixed, or the community rejected it. We pointed out real problems which were summarily ignored, and which are now becoming real problems for more people. This is not production-quality software. I am not in theory against everything they are trying to do, but I am absolutely against the way they are trying to do it, and who is trying to do it as he has proven both his incompetence and unwillingness to consider user feedback in the past.
In any case, normal users and readers of /. are sick and tired of your constant rantings about systemd.
Riiiiight, that's why we keep having these massive arguments about systemd, because you are all so tired of it. Just like you don't need the FCC to take things off the air because you can change the channel, you don't need us to stop discussing systemd and why it's literally both bad and wrong. You can just skip the discussion.
Re: (Score:3)
Just like you don't need the FCC to take things off the air because you can change the channel, you don't need us to stop discussing systemd and why it's literally both bad and wrong. You can just skip the discussion.
No, we actually can't. The problem is that you anti-systemd wackos can't just discuss it in places like this thread (where it's actually on-topic, a story about Linux Mint continuing to provide both systemd and upstart). Instead, you have to jump into every Linux discussion anywhere and ramb
Re: (Score:2)
We love Unixlikes which are actually "like Unix" ("The Unix Way", blah blah blah) not solely for aesthetic reasons, but for specific technical reasons which systemd compromises.
Then, why don't you create your own distro free of systemd? Nobody is forcing you to use it, and way smarted people than you, that actually create the most used distros, as well as the all mighty keeper of the Linux kernel, don't see a problem with systemd.
Re: (Score:2)
You just listed the same two groups twice. Ubuntu uses systemd because Debian chose to use it, and CentOS uses systemd because RedHat invented it. Ubuntu and CentOS aren't deciding independently; they're using what their upstream distro chose.
The pr
Re: (Score:2)
Ubuntu, RedHat, Debian, CentOS
Not really, like stated, it's Ubuntu, RedHat, Debian, CentOS, etc, etc, Linus Torvald and a lot of people the contribute a lot to the Linux community that don't see any problem in using systemd... versus a bunch of vocal people that keep complaining about systemd but that don't do much/nothing for the Linux community.
Re: (Score:2)
I'm tired of systemd being forced down my throat
Then go ahead and create your own distro free of systemd.
Re:I like how this got marked troll (Score:5, Interesting)
The issue is not with systemd corrupting the binary logs, or with the filesystem corrupting the binary logs, but with the fact that they are -binary- logs. A log file should be an ordinary text file. Nothing more, nothing less.
To say nothing about the very concept of systemd being a BAD IDEA. One daemon to rule them all and in the darkness bind them? Give me a break. It used to be that Linux was a fairly faithful UNIX-like operating system. And you know what makes a good UNIX or UNIX-like operating system? The tools, specifically those that are well-written and do one thing and do it well (with reasonable exceptions). Systemd is neither well-written nor does it do one single thing very well, well maybe corrupt your log files and crash very, very spectacularly.
By the way, if you're so worried about your filesystem getting corrupted, why use ext4 at all? It contains serious design and implementation flaws, specifically concerning the journal. XFS is by far a better journalled filesystem, with none of those issues. It is simply the best choice, especially if your concerned with the integrity of your data.
Re: (Score:2, Informative)
Systemd is neither well-written nor does it do one single thing very well, well maybe corrupt your log files and crash very, very spectacularly..
Systemd (the program) manages a dependency graph of "units" and triggers user-defined actions in the correct sequence when the system state changes.
That's the single thing it does. It doesn't do logging at all - that's a separate service journald that is usually packaged with and started by systemd but is not part of the same daemon. udevd and logind are also separate services. Clearly if you lump a bunch of related daemons together and insist they are all one daemon called "systemd" then that straw-man is
Re: (Score:2)
By the way, if you're so worried about your filesystem getting corrupted, why use ext4 at all? It contains serious design and implementation flaws, specifically concerning the journal. XFS is by far a better journalled filesystem, with none of those issues.
Not on Linux it ain't. I've had it eat my data before, and I am now leery of it.
Re: (Score:2)
you know what makes a good UNIX or UNIX-like operating system? The tools, specifically those that are well-written and do one thing and do it well
This link has a pretty good summary [catb.org]. I summarize the Unix way as "write good code."
Re:I like how this got marked troll (Score:4, Informative)
The issue is not with systemd corrupting the binary logs, or with the filesystem corrupting the binary logs, but with the fact that they are -binary- logs. A log file should be an ordinary text file. Nothing more, nothing less.
The glaring problems with flat file, unstructured text logs have been discussed for decades now. Plain text log files, like the original syslog(3) interface was simply bad ideas that Linux inherited. The main commercial selling point with any syslog implementation today is exactly that you can avoid several of these problems by using a DB.
An overhaul of the creaking legacy Linux logging system have been needed for a decade at least. Remember, the Rsyslog project was started exactly to fix such problems. They failed partly because distros and developers don't care about working together for a common goal and because there was no other central developer hub who would take the initiative.
systemd have finally fixed so many of the classic syslog problems. I don't care if you think syslog is perfect and never can be improved, and Rsyslog should be avoided for providing binary DB storing option, but please don't think that other people agree to this postulate.
And systemd's journald is designed to be 100% backwards compatible with syslog, so if your setup have legacy need, it is trivial to get a systemd distro to use legacy syslog text logs.
Re: (Score:3, Insightful)
bug report: /var/log/* corrupted, all text files replaced with zeroes from hard disk failure
Rejected with reason: Delete the corrupted logs and move on
For fucks sake, grow up.... ALL files types are liable to corruption and depending on the extent of corruption, you ain't gonna be able to read them, text or otherwise.
The operative words here are "depending on the extent of corruption".
You can read text logs with a sector editor if there's any possibility at all of pulling raw data off the hardware. For lesser damage - well, Linux is awash in text utility programs and if all else fails, put it on Windows and use the Wordpad program to read them.
Binary logs are a different matter. To read them at all, you need a matching decoding program. And the damage to the logfiles must be within the limits of the decoding program's a
Re: (Score:2)
Comment removed (Score:5, Informative)
Re: (Score:2, Insightful)
>For fucks sake, grow up....
He did, you didn't. Your argument is based on a strawman (the hard disk is at fault). Only a 5 year old would come up with such a nonsensical argument. The assumption in Bengie's comment is systemd didn't write valid data. One is because the init system sucked, the other is because you bought shit hardware.
Re: (Score:2)
The log file writing program might have bugs in it (I mean this in a general way, not to point the finger at systemd in particular).
Re:The pain isn't in the switch (Score:4, Insightful)
I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.
Re:The pain isn't in the switch (Score:4, Insightful)
I have contended with corrputed files plenty. If they are plain text, it's highly unlikely that a glitch leaves it such that a human can't piece together what is left. If it relies heavily upon common features of binary formats (compression, alignment to very particular addresses, section headers), it's quite easily unrecoverable. Basically the exact things that make them attractive (performance, efficiency, analysis) make them lose all meaning pretty quickly if part is missing or something.
But that's the problem: people who constantly rage against systemd and its binary logfiles are not AT ALL interested in knowing if they can read it, they never tried, they never looked at explanations of how it works or anything.
The fact is that you can actually use "strings" (the shell command) against your journal file and get A LOT of text logs with a lot more information than in a standard log file. Of course you lose all the semantic like the integrity of the text you're reading.
Which is because journald won't even compress small logs because it would take too much space. Only big log lines or blobs are compressed usually.
All this talk about systemd binary logs being unreadable is just plain lies and BS from detractors.
Of course, if you read your log with journalctl, it will get you all the extra benefits.
Re: (Score:3)
Re: (Score:2)
There's a simple solution for you: don't upgrade.
For Gnome, it's really easy: just switch to MATE. It's Gnome2 by another name.
For Windows, it's easy: just stick with 7.
For systemd, it's easy: just switch to Slackware, or use an old version of your preferred distro.
Re: The pain isn't in the switch (Score:2)
Re: (Score:2)
Using old versions isn't a viable option once security updates stop,
No problem, just do security updates yourself. You can backport fixes on your own, you don't need a distro to do it for you. Since you obviously know more than the distro maintainers (or else you wouldn't be disagreeing with their decision to adopt systemd), this shouldn't be a problem for you.
Slackware is not a option for a lot of scenarios (say running Oracle DB in the enterprise).
Then create your own distro.
And how many anti-systemd p
Re: (Score:2)
The obsurificationd service, integrated in systemd which locates any log entries related to the error you want to resolve in the binary log upon access - then translates them via google translate several times into random languages and back into English before presenting them.
Re: (Score:2)
Everybody good has moved to the BSDs. (Score:2, Interesting)
The reason that "nobody put up a fight" is because every intelligent Linux user has seen systemd for the disaster that it is, and they've moved to FreeBSD, PC-BSD, OpenBSD, NetBSD or DragonFly BSD months ago. The only Linux users left are the ones who'd be just as happy using Windows, which is pretty much what they get when using a modern GNU/Systemd/Linux distro.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
The reason that "nobody put up a fight" is because every intelligent Linux user has seen systemd for the disaster that it is, and they've moved to FreeBSD, PC-BSD, OpenBSD, NetBSD or DragonFly BSD months ago. The only Linux users left are the ones who'd be just as happy using Windows, which is pretty much what they get when using a modern GNU/Systemd/Linux distro.
So I'm a unintelligent Linux user that is happoy using Windows to you.
You should revise your hypothesis, as you're plain wrong in my case: I just can't stand using Windows, the latest one I've used is Win7 though, and I can't stand using it as it doesn't work correctly. I can assure you none of the Linux I use/make/administer are like Windows, I actually understand how they work far more than any Windows I ever used, and they don't crash like Windows.
Yeah mint! (Score:5, Insightful)
One more reason to use Mint.
That's the best they could do out of this situation.
Re:Yeah mint! (Score:4, Interesting)
Precisely. I can't get that everyone and his dog is rolling over and playing dead with this. They *ALL* remember what came of all of Lennart's OTHER projects. Stuff looking for problems to realistically solve. Stuff that's still not QUITE "right" and the man, rather than finishing the job, moves on to the next disaster. This is no different. This has no place in a "mission critical" space- and yet they're letting them do it. I question the sanity of Red Hat in bankrolling this travesty and then jamming it down our throats in the FIRST damn place. Just like with PulseAudio. No compelling anything, really, and the proponents keep thinking that network service on this little userland mixer feature (which should've been a service of the DRIVER layer for one piece, the mixer) is the greatest thing- when it's part of the latency problems with sound. First hint it's stupid...Android doesn't use it.
Re:Yeah mint! (Score:4, Informative)
So Lennart found something people needed, and built it. That's why people adopted it. You don't have to like systemd, but you should at least understand why it's been adopted.
Re: (Score:2)
The reason so many distros have adopted systemd is because it fills a need: it does something useful for them.
Like what?
Re: (Score:2)
Re:Yeah mint! (Score:5, Insightful)
One more reason to use Mint. That's the best they could do out of this situation.
The thing about staying neutral in a war of religion is that you run the risk of being branded a heretic by both sides.
Re: (Score:2)
Great quote, thanks.
With the exact same arguments (basically, I'm for the inalienable right of existence for Israel, but against colonialism and disproportionate strikes against civilians), I've been labeled a terrorist, an antisemite or a sionist, depending on whom I talk to.
so... (Score:2)
How long before they have to replace anything beyond the GNU stuff with something out of the 90s to avoid dragging in the systemd shoggoth via some dependency or other?
Re: (Score:2)
I'd guess about 5 years to you'll need to be on anti-systemd distributions that have hundreds of upstream packages they don't support or only support with lesser known (less supported) compile options. Upstream is aggressively putting systemd dependencies in, Linux software has chains of dependencies. So distributions like Crux and Alpine will have to become very aggressive about "no".
I hope they do this properly & publish the res (Score:3)
How many users choose Upstart?
How many users choose systemd?
How many users choose Upstart when it's not the default option?
How many users choose systemd when it's not the default option?
How many more downloads does this release get than a typical release (potentially indicating people switching from other systemd-only distros), if any?
Re: (Score:2)
I don't think that's terribly useful information regarding users. The question has never been which do end users support, end users mostly don't care. Among those who do care, you have a lot of traditionalist system admin types and those are probably substantially biased in the anti-systemd direction. Systemd breaks stuff they care about. The benefits won't be seen till years later and mostly will be experienced by people other than them.
What's important is not that. But rather as upstream packages d
Lennart Poettering is cancer on the face of Linux (Score:5, Insightful)
systemd is an abomination.
Linux's benefit for a long time now has been the ability to swap functionality out you don't like for other functionality that you do. I don't know who in their right mind thought it was okay to move critical system infrastructure systems (init, time, logging, etc) into the hands of an untested piece of software which clearly has very deep issues, written mostly by a developer who has a track record of making extraordinarily poor choices in software development and writing poor code.
What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system. What's even more stunning is that Lennart didn't stop them, realizing his code was not appropriate in production environments and doing the responsible thing, which is to say "We're far from ready". systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
Lennart likes to whine about how much the community hates him and how much people take it out on him personally. Reality is that outside of a few people who take it much too far, the reason people don't like Lennart is because he makes poor decisions with poor forethought and his advocacy and arrogance for his own approach have a seriously negative effect on a great many people, enterprises, and efforts. He likes to think he is a genius and we simply don't understand his vision, but for a great many people, his vision is the antithesis of what we like about Linux and Unix. Systemd developers don't understand the arguments of simplicity, composability, and small programs that do one thing well.
The truth is the fault doesn't rely totally upon Lennart and his team: Some of the blame can also be assigned to Linus for poor stewardship, but Linus has a set of complex motives and organizations that influence him. Linus should have killed this stuff much earlier.
I think in a few years, we'll realize what a mistake we made in giving Mr. Poettering any chance of credibility in operating system software development.
I hope it comes sooner rather than later.
Re:Lennart Poettering is cancer on the face of Lin (Score:4, Interesting)
Let me just point out, Oracle Linux 7 is systemd only. Oracle switched Jul 23, 2014. So yet another enterprise vendor that doesn't buy into the whole "systemd isn't mission critical ready" meme you all are pushing.
Re: (Score:2, Informative)
Oracle Linux is just rebranded Redhat. Oracle switched because Redhat switched (ditto CentOS and all the other Redhat-based distros), not because they saw any inherent superiority in systemd. (And guess who Poettering works for? Hint, their logo is a crimson fedora.)
Sure, Oracle is big enough they could have forked it, but then it wouldn't be 100% Redhat compatible, and they'd have to hire developers to actually write code rather just have a script that globally replaces Redhat trademarks with Oracle tr
Re: (Score:2)
The claim of the other poster is that systemd is not enterprise ready. I'd say Oracle's endorsement is a fairly clear refutation of that or at least strong counter evidence.
I'd agree that Oracle's Linux team didn't care much. They were following RedHat's lead but the fact that they followed RedHat's lead still means a lot. If they hated it, they would have picked a non-systemd choice for Oracle Linux instead of RHEL.
Re: (Score:2)
Still, I don't think I would hold up Oracle as an example of good judgement. They may be thinking, "as long as it's as stable as RedHat, we don't care."
Re: (Score:2)
Oh that makes sense.
Re: (Score:2)
Remember the OP's claim. Oracle had to agree to the switch. You don't get more enterprise than Oracle. So their failure to pull away means they didn't think systemd was a terrible idea.
Yes. That's the bulk of enterprise deployment.
Re: (Score:2)
What's stunning to me is that smart people in leadership positions in a variety of distributions have decided to support such an asinine system.
You don't understand why because you don't understand the benefits that systemd provides.
It makes writing an init script quite a bit easier, and since the distro leaders spend a lot of time doing that, systemd made their lives easier.
Re: (Score:2)
Sysvinit [is] simply inadequate.... The model of fork and exit without clear synchronization points is inherently racy, the boot model encoded into sysvinit doesn't reflect a modern system boot, and maintaining large and complex init scripts as conffiles has been painful for years. Nearly every init script, including the ones in my own packages, have various edge-case bugs or problems because it's very hard to write robust service startup in shell, even with the excellent helper programs and shell libraries that Debian has available. A quick perusal of /etc/init.d/skeleton and the complex case statements and careful attention
to status codes required for a proper init script makes this case clear.
Re: (Score:2)
systemd's position as PID 1 on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position systemd developers can take is "we're not ready, please don't use this even as a test in your released distributions".
So that everyone can see the level of BS of this user : "Linux's position as a kernel on Linux systems creates an enormous SPOF given the complexity of the code. The only sane position Linux developers can take is "we're not ready, please don't use this even as a test in your released distributions".
This is the level of discussion, it's pathetic actually.
For all practical purposes, the rapid and unseemly adoption of systemd means that many enterprises running distributions that now rely upon systemd have to make the decision to not trust their distribution any more if they consider their systems mission critical. This is going to make people move to FreeBSD, Oracle, Windows, non-systemd distributions, microservice/microkernels, etc in rapid fashion. It is going to literally kill Linux for the people who have not yet figured out how to deal with the loss of machines (the majority of the enterprise world). And that may be a good thing, in the sense that Linux has in many ways become indistinguishable and directionless in the sea of operating system options. It tries to be far too many things to far too many people.
The problem for you shills of proprietary OS vendors and appliances, is that Linux actually succeeds in being many things to far too many people (in your e
Thank you, Mint (Score:3, Insightful)
Seriously. Thank you for giving me a choice. If I want to try systemd and see if I run into issues with my particular use-cases, I can. If I want to avoid the possibility of conflicts and continue with the (admittedly crufty) sysvinit scripts I can.
False summary (Score:2, Interesting)
The summary (and the article it links to) have the situation backward. Ubuntu is the distribution which is offering users the coice of booting using Upstart or systemd. Under Ubuntu you can currently chose which init software to use (as of Ubuntu 15.04). Linux Mint does not do this, at least not yet.
Linux Mint has two primary branches, Linux Mint Main (which uses Upstart for init) and Linux Mint Debian Edition (which uses SysV Init). Which each branch you get just one init technology, you don'tget to choose
The mint team is doing a right thing. (Score:3, Informative)
Re: (Score:2)
That's not systemd. You should read the man page for fsck.xfs ( http://man7.org/linux/man-page... [man7.org]) which recommends you use xfs_repair.
And you can easily boot if a single non-boot partition is corrupted.
systemd vs. init appears to me like a petty issue (Score:3)
To be honest, I never got what all the rage is about. As with the foaming at the mouth because of Gnome 3.
I do 'get' init and runlevels and I like them. I can change them with a texteditor and they're all fairly neatly sorted in someplace below /etc or something (can't remember exactly, to lazy to check now). I haven't used runlevels in 9 years or so, I'm not an admin, but I know when they're useful and I probably could start editing and switching them within 5 minutes.
I don't know what all the systemd hate is about, but the shrill voices of nerds who don't have enough sex to remain cool irritate me. I can asure you that I'll chime in if I find out somewhere down the line, when I need runlevels or systemd's equivalent and there's no replacement to be found - some neat newfangled click-tool or equaly easy or better neat textfiles and directories to fiddle about with.
I know very well that systemd will die a very quick death if it turns out to be a shitty system in practice. It's FOSS folks - if it's shit and there's a better, working FOSS alternative people will move (back) to it faster than you can say "Mambo out, Joomla in". No reason to get all that worked up as if the world has ended.
AFAICT that won't happen. systemd is with all the new distros - apparently for the simple reasons that it boots faster. Well, it that appears to be a good enough reason for many people, so be it. New issues probably will be patched and the simple fact that systemd has most distros on its side probably is momentum enough to make init a thing of the past.
That aside, there are, IMHO, way more pressing issues plagueing Linux and it annoys me that no one seems to care about those.
Like for instance: Why is monodevelop the only dev-environment that does not crash on me after a regular installation?
Why do Anjuta, KDevelop, Codeblocks etc. crash on me on mint pure native Debian or Ubuntu linux installs when I attempt to compile something? Isn't the C family of languages our native turf?
Why do 49 out of 50 attempts to compile something downloaded in source from Github or SourceForge fail with obscure error messages? Does something like this still happen on software systems in 2015?? Color me suprised.
Why am I tempted to register with Apple, download XCode and be done with it? This doesn't feel right.
How about fixing or getting all worked up about that shit? It's a shame I can't compile native Linux software on Linux simply due to the fact that all the rest of the bunch aren't as disciplined as Linus Torwalds and get their fucking C/C++ pipeline in order.
The truth is, Linux will be going nowhere if we don't fix some basics, simple down a little and perhaps move towards open or at least fixed-standard hardware concepts. Wether some dude or distro thinks systemd is awesome or not shouldn't matter that much.
Re:Year of the Linux (Score:5, Funny)
Linux is merely the kernel used by systemd. The correct name of the operating system is systemd/GNU/Linux.
Are the "GNU" and "Linux" parts still needed? (Score:5, Funny)
I've been learning more about systemd lately, and I'm liking what I'm seeing. It's cohesive, yet it's completely modular. It's modern. Its binary log files make debugging easier. It's getting more and more critical functionality every day, and this makes my Linux system easier to use each time I update it.
The deeper I dig into systemd, and the more I use it, the more I question why we even need the GNU utilities and the Linux kernel.
I hope to see the most useful parts of the GNU toolchain and the most useful parts of the Linux kernel folded into systemd eventually. This way I don't have to install a Linux distro. I can just install systemd itself, and it will give me everything I need.
If my computer boots directly to systemd, and systemd provides the command line tools and the UI, then my boot time will be shaved down to almost nothing, and I'll get to use some really nice and modular command line tools. I won't have to try to remember awkward shell, sed, grep, and awk commands and their flags, because if systemd provided alternatives, I know they would be easier to use.
I've found that systemd is all about empowering me, as a user. It's about letting me get more done with less effort. GNU and Linux aren't always about that. They're about doing things for philosophical reasons, or for scratching an itch of their developers. Systemd is all about getting work done, which is why I've found it to be so useful. If it can do the things that the GNU toolchain and the Linux kernel are doing, but it can do them better, then I'd prefer just to use systemd directly.
Re:Are the "GNU" and "Linux" parts still needed? (Score:5, Informative)
Take note modern shitposters. This is what a good troll looks like.
If everyone who wants to derail a discussion would put in as much effort as this the Internet would be saved.
Re: (Score:2, Funny)
No. Systemd will integrate the GNU environment completely. Soon.
Re: (Score:2)
Not quite - more likely 2015 will be year of FreeBSD on the server instead.
Re: (Score:2)
What needs to happen first is for major software vendors to begin supporting it. That's when you'll see enterprises at least begin to consider it.
Re:But... (Score:5, Insightful)
because some software expects it and doesn't run without it.
shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
Re: (Score:2)
Re: (Score:2)
because some software expects it and doesn't run without it.
shit software, but software anyways.
that's whats bad about it, really. it's just not a startup replacement but one that aims to turn developers into developing software that can't work without it,, without trouble.
why would startup utility provide user authentication? to conquer everything of course.
You're right of course. Fortunately, the startup utility systemd (PID 1) doesn't provide user authentication, so you and I can sleep well at night while using systemd.
Some people will tell you that PAM is no better, but that's what most distribution use these days. But if you want and are knowledgeable enough, you can make a system without PAM for user authentication too.
Re:But... (Score:5, Insightful)
To be fair, Linux has always been multiple components that you can chose which one suits you best - whether its vi or emacs, gnome or kde, sendmail or postfix, apache or nginx, etc
This is a good thing, where you can swap out component A for B for any reason, and keeps the project competing with each other to get better and better.
If only you could swap out Systemd so easily, things would be great.
Re: (Score:2)
Yes and no. Certainly what you say is generally true. But there have been some components that were sticky. For example GCC was sticky and distributions had to pick a fork. Certainly EGCS vs. GCC2 was sticky and you couldn't swap without changing components. In the early days KDE and Gnome apps didn't run or didn't run well in each other's environments. There wasn't an easy way to swap on an individual level. Picking your example of Emacs one of the classic choices: X-Emacs vs. Emacs were not easy s
Re: (Score:2)
The better question is why bother supporting two sets of packages and scripts that accomplish precisely the same thing. Pick one and go with it. Given the support for systemd (by people who matter, not trolls), it seems the logical choice.
It's a good thing that they bother if they have the workforce, which they seem to have.
There's no problem with that, gentoo is doing the same thing.
As long as they are also going with systemd so that when the burden of initscripts is unbearable they're not stuck with an even bigger moutain to climb, it will go well. It will still be really painful for initscripts users though.
For now, the chasm isn't so big, it will really be huge when kdbus enters a Linux kernel release, even in experimental.
Re:Systemd detractors are like climate change deni (Score:5, Insightful)
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
Re: (Score:3, Informative)
Actually, it seems quite the opposite. We have the systemd crowd claiming that it's simpler even when there is a whole new level of complexity in systemd they don't even know about (hint, look for the systemd craziness in /lib). Like the climate change deniers, they believe that since they haven't personally seen a problem in their simple and vanilla system that there isn't a problem at all.
There is no "systemd crowd". There are systemd users that find it easier to use than previous solutions which have bugs which won't ever be fixed like Upstart. /lib/systemd or /usr/lib/systemd. I don't use every systemd utilities, but I caved in for a lot of them and threw away xinetd, my custom FS mount scripts, my custom ne
systemd is actually far less complex than using Upstart + countless tools and daemons with their configurations scattered all other the place.
I don't see the crazyness you talk about in
Re: (Score:3)
Right now the 'debate' is in full on 'no true scotsman' fallacy mode. No *real* users are complaining, so all people who *sound* like they are complaining need to shut up. If you complain, you must not be a *true* user.
Exactly (Score:2)
I don't know why this is moderated down, it is absolutely correct. Ubuntu provides and supports both upstart and systemd [arstechnica.com]:
It's worth noting that while systemd is the default in Ubuntu 15.04, all of the Upstart packages are still there, and you can in fact keep using it if you wish. If you want to switch back and forth, you can use Grub and select "Advanced options for Ubuntu," where you will find an "Ubuntu, with Linux ... (upstart)" entry. If you want to permanently switch, install the upstart-sysv package.
Mint is just following their lead, which makes sense given that Mint is based on Ubuntu. This is a non-story, fabricated because editors know systemd flamebait generates traffic.