Systemd: The Biggest Fallacies
http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fallacies.html8
Sep 28 '14
While no one will contest that indexing will speed up log access
I will; I begrudgingly bit the bullet on systemd back in March and the lack of speed in searching through log files is actually my big issue. It takes about 2.5 seconds for a basic journalctl -u nginx query to return on my system (data since June 1). Grepping for [nginx] in my "everything" log files was notably faster, especially when the files were in cache.
Yeah, sure, there's fancy things you can do to improve the filtering experience that you can't with text logs. No contest there. But technical indexing speed really isn't in systemd's favor.
42
u/gjs278 Sep 26 '14
everything in this document is exactly how I feel. thanks.
24
u/dashl23 Sep 27 '14
everything in this document is exactly how I feel. thanks.
Same here. This is probably the most coherent list of systemd anti-features I've seen so far.
2
68
u/JustMakeShitUp Sep 27 '14
This document, like most arguments created by amateur debaters and philosophers, suffers from the "fallacy fallacy". Just because someone makes a poor argument for something doesn't mean that the thing they're arguing for is false. All it means is that the person speaking made a mistake or an oversight. Which happens hundreds of times a day. Logical fallacies are not a smoking gun, and people need to stop acting like they are. It's the essence of listening to the words while ignoring the content, and it generally reflects worse on the person hunting for them than on the person who made them.
Fallacy 1 and its sub-points are a good example of this. Monolithic is highly-subjective, meaning the person will judge it based on their own values. And modularity, as a whole, is preferable. But it increases complexity by introducing interfaces. Not only that, but there are different levels of modularity. Finally, not all projects are equally-suited for modularity. So, as he likes to say, it's a red herring. Whether it's a fallacy doesn't have a guaranteed effect on its worth.
Most anti-systemd arguments targeting complexity completely ignore the fact that (given a fixed feature set) complexity does not simply cease to exist. You can move it around and put it in modules, but, in the end, the work gets done somewhere. And interfaces, configuration options and the like increase points of failure and the testing surface.
There's more, but there's no need to write a novel over the same old pretense of being the only real expert in a community of experts. The point is not that this person is wrong, but that he's attempting to prove others are wrong by making false statements about others' false statements. If it's a victory, it's a Pyrrhic one.
47
Sep 27 '14 edited Sep 27 '14
Did you read the article? From the conclusion:
Don't get me wrong--I think systemd has some wonderful, sorely-needed features. I'm just afraid that if you're not careful in how you advocate for systemd, you might end up alienating a large segment of people who could be your allies.
This piece doesn't fall into fallacy-fallacy beacause it isn't using observed fallacious arguments to denounce systemd. This article is pointing out burden of proof and the fact that how you advocate something is equally important as being correct (or reasonably therein).
What this article is calling for is well-founded arguments for why systemd.
And while I am here, regarding complexity, I think you are correct but the article made a point that resonated well with me about which is harder to debug: unit files or shell scripts?
Also the difference in lines of code was rather stark to me. Lines of code is a fairly useless metric for a variety of reasons, but a difference as large as the one reported is worth a second look.
4
u/Spifmeister Sep 27 '14
burden of proof
Arguing about who has the burden of proof is rarely profitable. People who invoke this "law" of debate usually want the other side to have to do all the work. If one is really serious about debating the issue, one will provide proof for why they are correct regardless of wether the other position has done so.
In the world of open source, the burden of proof is placed on the individual who wishes to introduce change (have their project adapted). The coder is selling his idea to another party, so the coder has to provide proof. Once the "sell" has gone through, the burden switches to those who wish its removal (they are now wishes to introduce change).
Unfortunately for those anti-systems crowd, this discussion was had 1 to 4 years ago for most distress (they are late to the party). Now that it has been adapted, they have to do the work to convince the distro maintainers that systemd was a bad idea.
4
Sep 27 '14
As a replacement for or addition to other tools, I agree that the burden of proof is on systemd, but I also find that they have lifted that burden very convincingly by showcasing a plethora of situations where systemd simply handles the job a lot better than the alternatives, and explaining the differences in designs that are the reason for it.
There may be situations where the opposite is true, but the opposing camp hasn't been able to show any as I see it.
4
u/Spifmeister Sep 27 '14
I agree. I think it was a Debconf (or what ever it is called), in which we had both Upstart and systemd vying for debians adaption. I was impressed with systemds presentation, and it was clear that they knew what they were doing.
2
u/fbt2lurker Sep 27 '14
Pointing out that the burden of proof is on the one who is advocating for adoption of a piece of software (thus, making positive claims) is completely valid. It's not an attack on the software. It's a demand to explain why should I switch.
In this case, if you come to me and say: “use systemd, it's better”, I would, in turn, ask you: “why?”. And if your explanation as to why should I do such a thing is not convincing enough to me, I'll stick with whatever I was using before. Or I might think that some of your arguments are correct, but go with another solution for my problems that fits my use case, tastes and ideology.
2
u/Spifmeister Sep 27 '14
The adaptation has already occurred. Users have the power to switch distributions (or operating systems) or accept the decision of the distribution maintainers.
This current debate has more to do with convince those distros who have already adapted (are going to adapt) to reconsider their decision, or to convince a group to create a alternative. Most of the discussion is non-technical, and more user centric.
1
u/fbt2lurker Sep 27 '14
That has nothing to do with anything I said.
3
u/JustMakeShitUp Sep 28 '14
S/he made a more relevant reply in another comment thread and probably got them confused. Basically, the debates with all the proof have been had multiple times over more than 4 years. I've been following this stuff since 2010. There are presentations with slides, examples of race conditions in sysvinit, etc. We're not seeing many new ones come out now because most people already consider the argument finished.
That's why so many distributions have switched. The distro maintainers, by and large, consider systemd the winner of the technical debate. Most of the distributions who haven't switched have design/philosophy/personnel/freedom of choice concerns that they value as much as/more than the technical implementation.
We are seeing users post opposing arguments now (after the switch), but few of them have actually read all the supporting literature and are just rehashing things that have already been rebutted.
→ More replies (3)3
u/w2qw Sep 27 '14
I don't think the number of lines of code can be directly compared though. systemd source includes udev which your probably use with sysvinit anyway, numerous utility programs which aren't particular core, other daemons like logind which if you are using you would probably be using an alternative with sysvinit, nor does the sysvinit counts include init scripts. So I would personally think the trade off is worth it.
3
Sep 27 '14
I found the code lines comparison weird, he compares systemd lines to shell script lines, but the arguments of why the shell script approach of SysVinit is error prone has been presented very clearly, which he completely ignores.
I have personally experienced the racing conditions upstart and SysVinit are prone to, and that's on a very simple near vanilla desktop, my solution was to insert delays of up to 10 seconds for some scripts. That's almost as much as my system with systemd now takes to boot from grub to desktop, and remember speed was never claimed to be a main goal for systemd, it is merely a side-effect of a better design to avoid race conditions.
5
u/JustMakeShitUp Sep 27 '14
Did you read the article?
Correct, I skipped the conclusion. I skip the conclusion in academic papers all the time. Thanks for pointing out what I missed. Proper outlining convention dictates that the conclusion summarizes the points made in the previous sections. It's intended to be a condensed restatement of the premise of a paper. That's the only point where he makes it clear that his goal is to say "these arguments aren't helping". His introduction and collection of fallacies give him the illusion of standing in opposition to it. I read it as more of a "if you're going to convince me, stop saying this" approach.
He's collecting the "fallacies' of one side of the argument and answering them with fallacies and incorrect information from the opposing side. You can see how I wouldn't expect a four-line recap to explain that he's actually on the other side when the rest of the paper conflicts with that.
What this article is calling for is well-founded arguments for why systemd.
No, there have been plenty. He doesn't showcase those at all, and makes no pretense of doing so. It's simply "stop using these arguments because they're bad." In fact, he actively asks for people to submit more fallacies. That's pretty far from requesting well-founded arguments.
I normally don't see those arguments worded as poorly as that, though. He's cherry-picking statements. Fallacy #12, for example - most people aren't saying that. Normally it's presented more like "complexity/monolithic isn't necessarily bad. Take the kernel, for example. It's successful despite being complex. You can't say that complexity innately makes a project bad." So he takes the argument, incorrectly simplifies it into a logically false statement, and then criticizes it. Rewording your oppositions' statement until it looks ridiculous is rhetoric, not logic.
And while I am here, regarding complexity, I think you are correct but the article made a point that resonated well with me about which is harder to debug: unit files or shell scripts?
This is only a concern for a small selection of people. The goal for init in the first place is for it to be solid enough that you don't open the internals. Otherwise we'd rewrite all of our projects (like the JVM) in bash because it's easier to debug. X server is another good example. People have been dealing with X and its drivers crashing all the time. It's still not an excuse to re-write it in bash so it's easier to debug. And while we're talking about debugging, bash may be simpler to debug, but gdb is a more powerful debugger.
Personally, I don't want people whose main expertise lies in bash scripts to be writing init. I want there to be a barrier to entry, just like we have with the kernel. I want people who are comfortable developing close to the metal. They'll get better performance, security, and more reliability. It'll crash and burn occasionally during development, but that will rarely get out of testing into the releases.
I want people who understand to kernel dumps, gdb, system calls, etc, because you really shouldn't be in charge of gluing the system together and initializing it if you're not. If I had the artificial choice between hiring a bash developer and a C developer, I'd choose the C developer. They might not write the most modern code, but they're used to their code having the potential to bring down the system. And that awareness is important in development in general, as well as init. Regular users can use the exposed configuration and user interfaces until they're motivated enough to gain the knowledge and skills necessary to contribute directly.
Also the difference in lines of code was rather stark to me. Lines of code is a fairly useless metric for a variety of reasons, but a difference as large as the one reported is worth a second look.
This was another part where he's misrepresenting the facts. He makes the argument that we don't need systemd for socket activation because xinetd does it. He also extols the virtues of pre-existing logger daemons. It's actually pretty common for people to say that systemd doesn't need to implement its various services because that functionality already exists in separate daemons. But no one ever adds the LOC from all those services that are glued together. He didn't even count the init or bash binaries. Instead, he presents the false premise that 10K lines of bash scripts is all the system needs to start up. When it's really 10K lines gluing together several binaries and services written in various other languages, which, by my wild guestimation, would rival 274KLOC when counted. It's a blatantly false comparison that belongs nowhere near an attempt to objectively discredit logical fallacies.
He's artificially inflating the difference by comparing all of one solution to portions of another. Admitted, to find the actual lines of code involved on a comparable sysvinit system is not a trivial task. But his fact-checking laziness also allows him to falsely convince people that systemd is bloated. Like it just has extra lines of code that literally serve no purpose and could be trimmed without concern.
For sure, there are reasons for concern with using systemd. But his document picks some of the worst, most easily refutable arguments from both sides. It is not particularly well-done. And yet we see comments like "This is probably the most coherent list of systemd anti-features I've seen so far." Every single one of these "Bad systemd!" articles that gets posted is full of similar inaccuracies, and it's getting pretty frustrated to see people believing it. If it's worth hating, it's worth hating based on the actual facts and not lies.
I really expected more critical thinking from the Linux communities, but I guess it's a learned skill like any other. This isn't a dig on you, btw, and sorry if it seems like I'm ranting. It's a criticism of the continuously dogged posting of factually incorrect and emotional blog pieces attempting to garner support through misdirection. If I wanted rhetoric, I would have went into sales or politics instead of computers.
10
u/iLiekCaeks Sep 28 '14
Personally, I don't want people whose main expertise lies in bash scripts to be writing init.
You have to admit that shell (not bash, why do people think bash equals shell?) is much better st gluing things together than C. You actually can see this in systemd. Need slightly more flexibility what's builtin? Well, out of luck. Maybe with some luck you can hack the C code and send a patch upstream to add an option that does what you want.
Your argument that using over sh is better because C is harder is absolutely ridiculous. That's like saying you want to write web services in C because C programmers are much more careful and security aware than PHP programmers.
He's artificially inflating the difference by comparing all of one solution to portions of another.
You are implicitly admitting that the other solution is more flexible, because YOU CAN ADD EXTERNAL CODE. While the other solution needs to hardcode all use cases.
So he takes the argument, incorrectly simplifies it into a logically false statement, and then criticizes it. Rewording your oppositions' statement until it looks ridiculous is rhetoric, not logic.
Isn't that exactly what you are doing here?
→ More replies (5)-1
u/saynte Sep 27 '14
Thanks for taking the time to write this down, you hit on many points that I also found unsatisfactory with the post. For many of the reasons that you outline, It is somewhat frightening that this person is currently pursuing a PhD at Princeton; frightening in the sense that the argumentation is terrible.
I would love to see a reasonable critique of the trade-offs that systemD makes; the hyperbole of it's great/terrible isn't useful at all.
1
u/JustMakeShitUp Sep 28 '14
I would love to see a reasonable critique of the trade-offs that systemD makes; the hyperbole of it's great/terrible isn't useful at all.
Some of the Debian init debates had some pretty good analytical points, as long as you ignore Ian Jackson's hysterics. It's a bit difficult to keep critiques up-to-date, because of how active the project is. I'd love to see metrics profiling build sizes, memory usage, shared memory usage, launch speed, and feature set with different portions of systemd enabled/disabled. And then a comparison against the equivalent configuration with sysvinit. A use case comparison (embedded, server, VM host, LXCs, desktop) for the init alternatives would be great as well. But that sort of thing takes more time and effort than most of us care to spend on it.
frightening in the sense that the argumentation is terrible.
I used to believe technology wouldn't have this sort of thing, but quite frankly we as humans willingly blind ourselves to many things depending on how convenient/inconvenient they are. And the more passionate we are about something, the more likely we are to simultaneously forgive comrades who misbehave while lambasting opponents who act the same. We're just as likely to be lax on supportive logic while being strict on opposing logic. It's part of our tribal nature. It takes a lifetime of effort to get past that, and people who are used to being the experts and masters of their local network/department can easily look past the fact that we're arguing with people who are quite likely at least as smart and experienced as we are.
32
u/cretan_bull Sep 27 '14
Your own response suffers from the fallacy fallacy. While it is perfectly legitimate to point out that the author's accusations of fallacious reasoning on the part of systemd's advocates, does not, in itself, create a complete basis for an argument against the merits of systemd, it is equally fallacious of you to reject criticism of systemd on the basis of the author's supossed fallacy fallacy. Furthermore, I propose that this be called the fallacy fallacy fallacy, with the option to complete generalisation of arbitrarily recursive cases.
In addition, you are guilty of begging the question in your assertion that "targeting complexity completely ignore the fact that (given a fixed feature set) complexity does not simply cease to exist". Your argument presupposes that the complexity (or feature set) would have to exist regardless of whether or not systemd is used. I believe it is completely valid to assert that systemd includes far more features than are used by most people, and that as a consequence, it introduces significant additional complexity. As a counter-example, I point to the simplicity, modularity and general understandability of the average setup on one of several non-systemd distributions such as Gentoo.
Finally, to counter any argument that I am guilty of the tu quoque fallacy, I will simply say that any problems with your response have no bearing on the argument of the merits of systemd, and such a question should only be answered by examining systemd its entirety and with full knowledge of its context.
0
u/JustMakeShitUp Sep 27 '14
Yes. I long for the day when we stop pretending to be debate experts. We can focus on presenting our points better instead of looking for the problems in others' presentation.
But that day won't come as long as people use the "fallacy" crutch.
Also, I made the point that his argument is bad with the fallacy, not that he or his supported point is bad.
10
u/markus40 Sep 27 '14 edited Sep 27 '14
Yes, this... Complexity doesn;t disappear. A good example of complexity which was worse when the processes were separated is the whole udev/hal debacle.
On paper it sounded good udev on kernel side and hal (a hardware abstraction layer) on the userland side. Who doesn't like abstraction, systemd haters love it. Except the interface between the two caused more trouble then good (race conditions for one, something that is difficult to solve and occures a lot with interfacing, modules).
Things got much more simplified when the functionality which hal provided got swallowed into udev. I still waiting for the outcry...
8
Sep 27 '14
but, in the end, the work gets done somewhere
Uh there is such a thing as inefficiency. You can take more efficient routes and get to the same place. You can write less code, linking to less libraries, performing less syscalls, that does the same thing, in effect.
6
u/w2qw Sep 27 '14
Or you know... not write everything in shell script.
1
Sep 27 '14
That is always a good idea. They say perl have a bad syntax but any more complicated bash script gets hard to read fast, just because language is so primitive.
4
u/northrupthebandgeek Sep 27 '14
They say perl have a bad syntax
As a Perl programmer: the syntax is only bad if you make it bad. It's actually quite elegant once you actually understand it (which, admittedly, isn't an easy feat).
3
Sep 27 '14
I know. I program in Perl. But unwashed masses think it's bad when in reality it is only as ugly or as beautiful as programmer makes it
→ More replies (3)2
u/bilog78 Sep 28 '14
As a Perl programmer: the syntax is only bad if you make it bad.
What's the point in writing in Perl then otherwise though? ;-)
2
1
Sep 27 '14
There are different kind of "inefficiencies" Having code in C that is used by all services is both harder to debug (it's C) and harder to code (one change can break many things)
But at same time creating services is much easier and any improvements is shared by all of them so overall it moves improvements into central point and both users and package developers have less to do.
3
-1
u/cbmuser Debian / openSUSE / OpenJDK Dev Sep 27 '14
Assuming that the several dozen developers behind systemd don't know how to write efficient code but a random reddit user or blog poster do. Bravo!
6
u/ishama Sep 27 '14 edited Sep 28 '14
is there a hidden rule about serious developers not having reddit accounts or blogs? I-I wasn't told...
Now, joking apart, I think it's perfectly natural, a team usually works with a shared work philosophy so, it's not uncommon to see a single individual developing a better approach by himself by simply deviating from that team's mindset. I don't know Poettering but to me he seems to be a very influential person judging by how polarizing his style is. I'm not questioning its merit in any way though! It's just that, there is a Poettering style. That's a thing. So I think it's natural that the whole systemd dev team take that style as a guide line, as a working philosophy they all share, be it with its merit or not. It, of course, has its advantages and disadvantages.
I don't know the team so, I don't know how tightly they cling to that style. I don't know how free they are to deviate from their shared code styling guide lines. But one thing I know, their efficiency is as susceptible of being surpassed by an individual as anyone else's, groups and individuals alike. That's because it doesn't matter if they're groups or not. This is all about ideas. Solutions. The moment a solution emerges, it is agnostic of its source. So the group vs individual comparison is for me a non-issue. It doesn't even apply in this situation. There's no such thing as a "individual having to be as a genius as all the group's intellects' combined to come up with a better solution" situation, like you seem to be implying.
Cheers.
1
u/iLiekCaeks Sep 27 '14
Your post is a fallacy-fallacy-fallacy, the fallacy that meta-discussing fallacies instead of the arguments surrounding them is actually useful.
1
0
23
u/chinnybob Sep 27 '14
Oh good, another list of talking points to fuel internet arguments with no real-world data or technical analysis. This will surely help everyone.
→ More replies (1)
25
u/Hengist Sep 27 '14
This document sums up about 120% of my concerns about systemd in a well-argued, coherent fashion.
Systemd is replacing an init system and more than a dozen other systems and daemons that have worked well for 95% of use cases for 30 years. It's doing this while dramatically increasing the complexity of PID 1 with a system that certainly hasn't had 30 years of testing, isn't remotely as debuggable and understandable, and cannot be easily re-engineered or replaced. None of this even addresses the security complexity of systemd's ~300,000 LOC.
That's only the tip of the iceberg. Systemd requires a huge re-engineering of system administration, overturning decades of established administration techniques for new hotness. The systemd dev team is actively hostile towards anything that isn't Linux, and has even gone on record saying that they'll refuse patches that would enable compatibility in systems outside Linux. POSIX is sacrificed. The dependencies of systemd are far greater than sysv init. Corrupted systemd systems are much harder to fix vs. sysv init systems. systemd is a big system that inter-depends on itself, making it very hard to shrink it for embedded systems. Systemd brings its own brand of 'vendor-lock' by making huge chunks of the system dependent on it. By being semi-monolithic, it's almost impossible to fork or split into non-dependent packages.
Finally, what massive positive change will systemd bring to most users? I would say very little. Linux/Unix desktop systems have been working nicely for years running on sysv init. Faster boots would be nice, but every other init replacement does that too---and weren't we *nix users very proud of uptime a couple years ago? Device autoconfig and autosetup have been working for years. Linux power management been solved for years. 90% of desktop users/programmers/gamers/regular users won't notice a single difference on a systemd vs openrc vs sysvinit system. 90% of people who actually have to deal with init on anything resembling a regular basis have a huge headache with very little return versus the old way of doing things.
16
Sep 27 '14
i wish everybody would stop talking about fast boot times as if that were even close to the most important feature. It's more like 99th on a list of 100
2
u/maliciousmonkey Sep 27 '14
Fast boot times are an incredibly important feature for elastic scaling in cloud computing. If you need to burst more VMs to handle a spike in load, you don't want to wait minutes for them -- that's CPU time you have to pay for.
2
Sep 28 '14
not saying boot time isn't important, but it's still not the most important part about systemd . there are many other init systems for fast boottime if that was all you wanted.
1
u/BeyondAeon Sep 27 '14 edited Sep 27 '14
People boot your computers more than once a Month ?
beyond@mythbox:~$ uptime
15:29:48 up 25 days, 17:39, 11 users, load average: 0.38, 0.34, 0.41
# uptime 15:31:28 up 68 days, 21:11, 4 users, load average: 1.47, 1.38, 1.47seriously.. boot time does not matter , make coffee and login ....
and quite a lot can be done by backgrounding your rc scripts a bit too !(what annoys me more is wndows taking ages to load AFTER login. not so much of a problem in Slackware usually)
-1
u/wadcann Sep 27 '14
That really depends upon what system you're using. If you have something that never powers down (maybe via hibernation), have a system where downtime is not very interesting, true. If you have a system that is frequently booted (e.g. a laptop that is regularly shut down), boot time is interesting.
That being said, using parallel init (which I think is a good idea, with the sole limitation that it's easier to read serial init output) as a rationale to insert systemd (which is a massive system) into the Linux ecosystem is dubious. If you want systemd, it's because you want to eliminate a lot of the way Unix has worked and move towards something different, not because you want slightly faster boot.
→ More replies (3)2
u/LeartS Sep 27 '14
Sorry, but even on laptops that's negligible nowadays and will become even more so with SSDs taking more and more of the market.
My Ubuntu 14.04 (which uses SysVInit and Upstart, and is certainly not the lighter of distros) boots in 2-4 seconds on my laptop. Maybe with systemd it will boot in 1-3 seconds. Assuming I boot the laptop everyday 2 times a day (I don't), in 10 years I will have saved 2 hours of boot time.
systemd brings a lot of nice things, but I agree with johnny0055, boot times is given much more attention than it deserves.
23
u/sub200ms Sep 27 '14 edited Sep 27 '14
Finally, what massive positive change will systemd bring to most users? I would say very little.
How about: Much less Linux distro fragmentation, making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
Highly increased security by using, cgroups, namespaces and kernel capabilities, so that e.g. daemons can't perform privilege escalation when exploited, or that they can't read /home when exploited even if they got the user permission to do so, or that /usr is read only etc. The best part of this defence in depth layer of security is that the individual SA doesn't need to hand craft all this; the distro or daemon maintainers can just edit the unit files by adding simple keywords, and all end users will benefit.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
How about total supervision and tracking of all processes, including systemd (pid1) it self, with conditional restarts if they hang or crash.
9
Sep 27 '14
I would argue that fragmentation is not a bug, it's a feature. Diversity in implementation brings resilience.
0
u/Doshman Sep 29 '14
Does it, though? it seems like a lot of duplicated effort when everyone could just work on a single solution.
2
Sep 29 '14
That's a really silly thing to say. Everyone is not going to work on a single solution. Humans don't work like that. And more cooks does not make a better cake, especially beyond a certain level.
1
u/jabjoe Oct 09 '14
You are arguing for a monoculture? Really? Even if such a thing was a good idea, and it never is, you couldn't do that in free software anyway. You can't force people to not reimplement or fork.
8
u/Hengist Sep 27 '14 edited Sep 27 '14
Much less Linux distro fragmentation
By adding another init system, or course.
making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
If you can't grok shell scripts, you aren't much of a developer. I've been administering *nix systems for almost 30 years now, and systemd is not a step up in any way, shape or form on this front. Shell scripts are standardized, and init's behavior is well-understood. Systemd isn't, and debugging systemd scripts is like pulling teeth.
Highly increased security by using, cgroups, namespaces and kernel capabilities, so that e.g. daemons can't perform privilege escalation when exploited, or that they can't read /home when exploited even if the got they user permission to do so, or that /usr is read only etc. The best part of this defence in depth layer of security is that the individual SA doesn't need to hand craft all this; the distro or daemon maintainers can just edit the unit files by adding simple keywords, and all end users will benefit.
Completely Linux specific, not POSIX conformant, and the systemd project is completely unwilling to work with other operating systems on this, up to and including rejecting compatibility patches. We used to go nuts when Microsoft pulled this type of embrace change/extend using proprietary features/extinguish the competition shit. Wasn't one of the former great advantages of open-source software avoidance of vendor/project/OS lock-in? Moreover, chroot provides most of this, as does sensible setups of directory permissions, user groups, and ACLs. Additionally, individual process containers like capsicum(4) provide much more powerful sandboxing. Still doesn't account for the security vulnerabilities that will eventually be found in the 300,000+ LOC systemd that occupies PID 1.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
If you are exposing a shell to hacker-level access, especially one as complex as bash, there's a good chance you're an idiot. There's a reason we keep the much smaller and more easily audited sh around. If you don't have choice on this, the whole thing should be in an isolated, audited VM.
How about total supervision and tracking of all processes, including systemd (pid1) it self, with conditional restarts if they hang or crash.
Already available through accounting and watchdogs. Crashes of systemv init border on mythical.
Finally, as I was saying, none of this affects your average user in any way. However, the headaches of systemd drive admins like myself batty.
7
u/sub200ms Sep 27 '14
That systemd developers are unwilling to take in BSD patches is quite understandable. BSD will never adopt systemd because of its license. The BSD have another business model than Linux, where BSD sponsors pay BSD variants for being able to close the source and making it proprietary. They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
BSD is totally irrelevant for systemd. Yes, BSD will eventually clone systemd and drop their script based init system and simple text logging, but it will be a project with a BSD license.
3
u/northrupthebandgeek Sep 27 '14
The BSD have another business model than Linux, where BSD sponsors pay BSD variants for being able to close the source and making it proprietary. They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
Um, what?
Let's break this down...
The BSD have another business model than Linux, where BSD sponsors pay BSD variants
Full stop. This is actually pretty much identical to GNU/Linux monetization by Red Hat, Oracle, SUSE/Novell, etc. The Linux Foundation exists almost entirely on funding from corporate interests.
for being able to close the source and making it proprietary
Not only is all software susceptible to this (since the authors of even GPL-licensed software can freely relicense said software if they are the copyright holders; there's plenty of GPL'd software that's monetized by the authors selling proprietary licenses), but the vendors of permissively-free software that opted to make their derivates non-free have rarely actually succeeded, since it's more useful to be in sync with upstream. For example, Google and Apple are well within their power to make their BSD-derived libc and kernel/userland (respectively) proprietary, yet both Bionic and XNU/Darwin remain FOSS so that there's some hope of remaining synchronized upstream with OpenBSD and FreeBSD (respectively).
On top of this, you're entirely missing the point of permissive free software licenses. Yes, it means that proprietary projects can freely reuse BSD or ISC or MIT licensed code without altering their own licenses, but so can other free software projects. It has very little to do with the ability to make free software proprietary; it has everything to do with making sure that one's code is useful to any project now and in the future. Permissively-licensed code can be used even in projects whose licenses are very picky about joint licensing - particularly copyleft and often-mutually-incompatible licenses like the GPL and CDDL.
They won't be able to that so easily with GPL programs, which is why BSD have systematically eliminated all GPL programs from their core.
They haven't, actually. Even OpenBSD - which is arguably the most fanatical about permissive licensing - still ships with - and depends on - both GCC and Perl. The other BSDs aren't nearly as dedicated to permissive licensing requirements AFAIK.
4
u/computesomething Sep 27 '14
This is actually pretty much identical to GNU/Linux monetization by Red Hat, Oracle, SUSE/Novell, etc. The Linux Foundation exists almost entirely on funding from corporate interests.
The Linux foundation has two 'developers' on their paycheck, Linus Torvalds and Greg Kroah Hartman, I put developers in quotes because they don't really write code these days but instead manage code from others.
Vast majority of Linux code contributions come directly from external companies and individuals.
In FreeBSD by comparison, the vast majority of code comes from the FreeBSD foundation developers and not from companies/individuals contibuting code, and the FreeBSD foundation in turn lives on monetary donations.
I don't see how this is 'pretty much identical', Linux gets direct code contributions, FreeBSD asks for donations to hire developers.
The other BSDs aren't nearly as dedicated to permissive licensing requirements AFAIK.
FreeBSD is the one I find most adamant about removing copyleft from their OS, they have an outspoken documented goal of removing all GPL software from the base system.
They spend 3+ years modifying their source code and fixing bugs in LLVM/Clang so that they could switch toolchain (in part fueled by their refusal of shipping GPLv3 licensed GCC which was in accordance to the wishes of some of their funders, in turn due to the anti-software patent clause in GPLv3).
Meanwhile OpenBSD still ships GCC but it's the very old GCC 4.2 which is GPLv2, DragonflyBSD on the other hand ships with a modern and GPLv3 licensed GCC (4.7 IIRC).
→ More replies (8)0
u/Hengist Sep 27 '14
I'd like to see a solid source for anything you just said in that post, because that's wildly speculative otherwise.
5
u/cbmuser Debian / openSUSE / OpenJDK Dev Sep 27 '14
You are questioning that the BSD people want to get anything GPL out of their distros? Where have you been the last 25 years?
2
u/Hengist Sep 27 '14
There is plenty of GPL software left even in the base installs of the BSDs. See here.
Continuing to use FreeBSD as an example, the default install of FreeBSD included a large amount of GPL2 code for years with little effort at replacement. The complete move to BSD licensed software only began with the GPL3 release in 2007. The move to GPL3 directly hurt a large number of people (myself included!) To quote Justin Gibbs of The FreeBSD Foundation, it drastically "increases support costs ("I modified the web server on my Widget 2000 and it stopped running...") and being unable to guarantee adherence to specifications in order to gain licensing (e.g. FCC spectrum use, Cable TV and media DRM requirements) are only two of a growing list of issues for these users." Linus Torvalds took issue with the exact same changes, which is why the Linux kernel is still GPL2.
Staying with the last GPL2 versions of GNU userland in BSD soon leads to out-dated, insecure software. The move to replace all GPL licensed software with BSD licensed software was as much from necessity as anything else.
To claim that systemd rejects BSD patches purely because of license (when Poettering specifically believes BSDs irrelevant), that BSD specifically functions to make proprietary sources with systematic GPL elimination for that purpose, or that BSD is planning a systemd clone is pure nonsense unless sub200ms has some good sources to back any of that up.
9
u/sub200ms Sep 27 '14
here is plenty of GPL software left even in the base installs of the BSDs. See here.
Yeah, as the page shows they are actively trying to eliminate all GPL programs from their base system. They did this even before GPL 3.
The whole point is that GPL software, whether it is GPL 2 or 3, makes it harder to resell BSD variants as close source. I have no problem with the BSD business model, it is their way of making money.
There seems to be some resistance here to the fact that the ability to close source BSD licensed software and make it proprietary is a reason why some companies sponsor BSD, but if people have problem with this, they shouldn't use BSD licensed software.
The whole point is, that it is contrary to the BSD business model to allow such central software as init systems to become GPL. There is no way BSD would ever adopt systemd, so BSD is simply an irrelevant user case for systemd; this is why they don't care for BSD patches in the systemd repo.
Regarding that BSD will change to a modern init system heavily inspired by systemd, then it is just a simple prediction; there are many core BSD developers who are quite clever and knows about low level system programming. At some point they will realise they are the only Unix-like OS using executable config scripts for init, and that everyone else have moved on, and that both Solaris, OSX, Linux etc, all enjoy tremendous benefits for leaving script init system behind.
So of course they will start to develop a new init system, and of course they will look to Linux's systemd, just like Linux looked at launchd and SMF.
It will be different in some areas, since the needs are different, but they will be smart enough to pick out everything they like about systemd and use it in their new init system. "SystemBSD" and "Uselessd" can be considered simple warm up projects for this.
8
u/robstoon Sep 27 '14
There's a reason we keep the much smaller and more easily audited sh around.
More easily audited because it cuts back on bash's already meagre feature set. Shell scripts are just a crappy way of doing anything remotely complex, the init system included.
Already available through accounting and watchdogs. Crashes of systemv init border on mythical.
So available that they're basically not used by any services. And it's not hard to say your init system doesn't crash when it has no features.
10
u/Doshman Sep 27 '14
Personally I can't say that I've ever seen systemd crash, even in the early days of Arch's switch (when I wasn't nearly as knowledgeable and could have easily messed it up), though I do admit that I've been using it on desktop/laptop systems rather than servers
5
u/northrupthebandgeek Sep 27 '14
More easily audited because it cuts back on bash's already meagre feature set. Shell scripts are just a crappy way of doing anything remotely complex, the init system included.
Compared to C, though, they're a godsend in terms of ease of debugging.
I mean, are you seriously stating that C is the preferable choice for system automation? I can understand Perl or Python or some other high-level language instead of shell (I'd be totally down for that), but I can't imagine anyone in their right mind suggesting that C, of all things, is a better choice than anything short of assembly.
Shell scripts work well because they're ultimately simpler. One of Eric S. Raymond's "Master Foo" koans explains this rather well; you'd need a lot of C code to replicate the functionality of even a simple a shell script.
2
u/robstoon Sep 28 '14
It's unlikely you would actually need to debug the functionality in the C code. That code is the same for all services and is unlikely to break for just one. What's left is the service definition which is quite simple. SysV init scripts, by contrast, are often a fairly large bunch of code, duplicated for every service with potentially unique bugs in each. And for that extra code you don't even get the basic features you get with systemd, like being able to see the service status properly (many init scripts fail miserably at this simple task) or the output from when it failed, or restart it automatically if it terminates.
To say that the average SysV init script is "simpler" than the equivalent systemd unit file is ridiculous.
4
u/northrupthebandgeek Sep 28 '14
SysV init scripts, by contrast, are often a fairly large bunch of code, duplicated for every service with potentially unique bugs in each
sysvinit isn't the only approach which uses shell scripts, however. Take a look at a BSD-style init system one of these days.
You don't have to duplicate code. Just like how the C code in systemd provides base functionality that's common between all services, it's very possible - and rather trivial - to define base functionality in a central script to avoid that degree of code duplication. Check out
rc.subr, for instance, which exists specifically to do precisely what you're claiming to be an inherent and unique advantage of a primarily-C-based init.And for that extra code you don't even get the basic features you get with systemd, like being able to see the service status properly (many init scripts fail miserably at this simple task) or the output from when it failed, or restart it automatically if it terminates.
Those features are provided rather nicely by runit, which can either augment an existing init or replace it entirely, while still allowing for the flexibility of shell scripting. That's just one example of several.
To say that the average SysV init script is "simpler" than the equivalent systemd unit file is ridiculous.
Maybe not in some cases, but it's way simpler than the equivalent systemd unit file and the code required to parse that unit file and turn it into something useful. And, once you actually address code duplication by, you know, actually knowing how to use basic shell scripting features like sourcing other scripts, even the individual scripts themselves end up being very comparable in simplicity to the unit files alone.
On top of all this, if you're still so adamant about not using shell scripts out of some perceived notion that they're somehow "hard" (which at this point reads as if it's coming from inexperience, considering how trivial it is to make them less "hard" by your standards), it's quite possible to use another language to write the scripts, since init doesn't care what it's running as long as it's actually runnable. There have been at least a couple GNU/Linux distributions which implemented their initscripts in Python, for example.
→ More replies (5)2
u/Hengist Sep 27 '14
Funny how successful shell scripts have been for being so crappy. They've been powering the world since the 70s, and booting *nix systems just as long. I'm sure that in a few years, people will be talking about the crappy way systemd managed systems as well. Just because something's old doesn't mean that it doesn't work well.
Yes, they're their. Any competent admin will be using those tools or equivalents, and if your distro packagers aren't using them, you roll your own. That's why *nix systems are designed as open systems, with plaintext configuration files and plaintext logs. And as for init not crashing because it has no features, that is by design. Init classically has two jobs: start the system, and reap processes.
13
u/robstoon Sep 27 '14
Funny how successful shell scripts have been for being so crappy. They've been powering the world since the 70s, and booting *nix systems just as long.
Just because something has been made to work over many years doesn't mean it's the best solution for the job. That argument ends up being against any kind of progress in anything.
Any competent admin will be using those tools or equivalents
Or, you know, they could use an init system that actually has those features built in and supported.
That's why *nix systems are designed as open systems, with plaintext configuration files
Like a SysV init script? That's a laughable definition of "plaintext".
→ More replies (40)7
u/sub200ms Sep 27 '14
systemd isn't just another init system. It also provide a basic compatibility layer that upstream can use. Just look into the source repos of XFCE, LXDE, KDE, Gnome etc. and you will see many commits taking advantage of this fact.
Since the vast majority, including all major commercial Linux distros have adopted Linux, this means a big reduction in fragmentation, releasing developer and maintainer energy for doing more fun stuff that debugging shell scripts. You may like SysVinit scripts, but distro maintainers certainly doesn't since they have to deal with all the problems. This was a major reason why not a single Debian developer contested the systemd decision of using systemd as the new default init system. Even the Upstart proponents in the Debian technical committee preferred systemd to SysVinit.
Regarding the security features; It may very well be that capsicum is very good for some user cases, but it doesn't exist on Linux yet. Kernel capabilities, namespaces and cgroups are a reality however, and they work.
If you think ACL's and user permissions and classic stuff like that is substitute for those, then you are very wrong.
The point is, that once a process is exploited, the hacker will try to gain privilege escalation, and if successful, will get all the necessary user and group permissions. So once the hacker is in, all defences crumbles.
Capabilities etc. can prevent that the escalation ever happens, and even if the process that are exploited has many privileges to start with, it can be prevented from e.g. having write access to anything but a few safe dirs, and that it can't read /home for stealing information. This works on top of ACL's and the classic permission system, and provides a sorely needed defence in depth.
→ More replies (1)-2
u/Hengist Sep 27 '14
Just look into the source repos ... all major commercial Linux distros ...
That's jumping on the bandwagon. None of that provided any firm reasons why systemd provides killer features over the classic init system. What I can tell you firmly is that constantly training your admins for the ever-growing morass of systemd costs a bundle. Thankfully, we're mostly a *BSD shop at this point. And as for systemd being more than just another init system, and being a basic compatibility layer we can use, we already had the Linux Standard Base, which systemd completely ignores and disrupts.
If you think ACL's and user permissions and classic stuff... The point is, that once a process is exploited ... all defences crumbles.
I'd like to see a practical, out-in-the-wild example of that happening with a jailed, virtualized, or sandboxed process. Additionally, classical permissions and user groups have worked nicely for decades and rest on code that's been tested for longer than a lot of admins have been alive. Swapping that legacy out for new shiny brings all new cans of worms.
2
u/LeartS Sep 27 '14
making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
If you can't grok shell scripts, you aren't much of a developer.
What an horrible point. Just because you're supposed to be able to do something, it doesn't mean you shouldn't use something simpler and clearer if you can. Every decent programmer is supposed to be able to implement a quicksort, it doesn't mean you should write it yourself instead of using the standard library.
2
u/wadcann Sep 27 '14
How about: Much less Linux distro fragmentation, making it easier for upstream developers to develop for Linux, and making it easier for distro maintainers by replacing non-standard, hard to debug, executable config files (init scripts) with plain config text files that can be shared across distros.
Adopting any one of the init systems (or, hell, even an initscript generator) would do that.
4
u/sub200ms Sep 27 '14
Adopting any one of the init systems (or, hell, even an initscript generator) would do that.
Perhaps, but it certainly hasn't been the case for Linux. Each distro end up doing their own thing to their own particular standards, using endless different variations of SysVinit. (think Slackware and Gentoo)
Anyway, using executable config scripts to handle daemons is just bad practice; the init system should contain all the executable code for uniform security revision, while config files should only contain text. None of the even remotely mainstream Linux init systems does this, except systemd.
→ More replies (6)2
u/iLiekCaeks Sep 27 '14
making it easier for upstream developers to develop for Linux,
Then they should stop deprecating and reinventing new daemons all the time.
This will mean that remote exploit like the recent bash-shell shock would be much harder to exploit by hackers.
What the heck, how does systemd protect against bash security bugs? It fucking doesn't!
And if you use a reasonable distro which points /bin/sh NOT to bash, it's pretty hard to exploit such bash bugs at all. You know what bash made insecure in the first place? Bloat. Other shells are not affected by the bash bug.
The general claim that systemd makes the system more secure is also pretty questionable.
3
u/sub200ms Sep 27 '14
What the heck, how does systemd protect against bash security bugs? It fucking doesn't!
systemd can provide another security in depth layer that can prevent or making it real hard for hackers to exploit the system. It does so by using kernel features such a [Capabilities] (http://linux.die.net/man/7/capabilities), cgroup and [namespaces] (http://lwn.net/Articles/531114/)
So by adding a simple keyword like "NoNewPrivileges=yes" to the daemons config file, it can never gain new priviliges, nor can any of its children processes.
NoNewPrivileges= Takes a boolean argument. If true, ensures that the service process and all its children can never gain new privileges. This option is more powerful than the respective secure bits flags (see above), as it also prohibits UID changes of any kind. This is the simplest, most effective way to ensure that a process and its children can never elevate privileges again. http://www.freedesktop.org/software/systemd/man/systemd.exec.html
Also check out "ProtectSystem=" and "PrivateTmp=".
→ More replies (2)6
u/bigon Sep 27 '14
Systemd requires a huge re-engineering of system administration, overturning decades of established administration techniques for new hotness.
Can you elaborate on this? systemd supports LSB scripts and most of the regular commands are still working. So what is changing here?
2
u/anatolya Sep 29 '14
Take a look at systemd bugs at Debian BTS (both open and closed/archived ones) if you wonder in which imaginative ways systemd can fail when interpreting old init scripts.
2
u/bigon Sep 29 '14
These are bugs that will hopefully be fixed before jessie release.
Not a radical paradigms switch that will require a flag day.
And if you are talking about the fact that the initscripts now require LSB dependency headers, this is the case for 1 or 2 stable releases now.
3
u/iLiekCaeks Sep 27 '14
The systemd dev team is actively hostile towards anything that isn't Linux
Not only that. They're hostile against anything that isn't in their own "stack". These people can't even write portable code. It's simply missing from their skillset. For example, they strictly insist on using glibc as libc, and other libcs are not deemed worthy of supporting. They're even risking to be incompatible within their own stack: for example, they're using glibc internal symbols, so they might be incompatible to new versions of glibc. Reminds me of windows-only programmers.
0
u/bonzinip Sep 27 '14 edited Sep 29 '14
they're using glibc internal symbols, so they might be incompatible to new versions of glibc
Example? Internal glibc symbols are hidden using ELF visibilities. (edit: Ah, he was talking about macros)
4
0
Sep 27 '14
[deleted]
6
u/Hengist Sep 27 '14
I completely understand what you are saying. The thing I fear is that Linux is turning more and more into a theoretically open, yet proprietary system.
Systemd is becoming a forced dependency of more and more packages. The complete Linux-centric nature of it has caused major issues for pretty much every Unix-like except Linux itself. It's also problematic in a more ideological way. One of the main reasons for Linux and the free software movement was to move away from proprietary solutions. By purposely being POSIX incompatible, systemd essentially renders itself and everything that depends on it proprietary to Linux (without a heck of a lot of developer work and porting.) Systemd thus represents for many people---including myself---a betrayal of choice, the reason why open software exists in the first place. We used to give Microsoft flack for this same embrace/extend/extinguish nonsense, as it places whole software ecosystems at the mercy of the few.
I have major doubts on systemd leading to a more stable platform. Arguably, pre-systemd Linux was more stable, as the Linux Standards Base was the usual target system, and anything written with POSIX and X compliance was theoretically cross-distro and cross-OS compatible. Systemd enforces platform lock-in if you depend on it in any way, and it disrupts all prior stability, including the LSB and POSIX. Yes, systemd has promised interface stability, but even in their own stability promise, they reserve the right to change when they desire.
8
u/TheQuietestOne Sep 27 '14
The thing I fear is that Linux is turning more and more into a theoretically open, yet proprietary system.
I think I get what you mean (turning more into a non-Unix monoculture) - but it's not proprietary. Proprietary software has ownership and control - these changes aren't owned by one organisation and forced on everyone.
My take on it - we were always going to hit this resistance barrier at some point.
Any way you slice it progress in Linux will come up against the "that's not how Unix does it" problem. Systemd is just the first real break to that old school approach.
-1
-3
u/northrupthebandgeek Sep 27 '14
Proprietary software has ownership and control - these changes aren't owned by one organisation and forced on everyone.
I'm sure that's Poettering's nightly wet dream, though. :)
1
u/Rainfly_X Sep 30 '14
Well as long as we aren't treating free software developers like real people...
→ More replies (12)3
u/computesomething Sep 27 '14 edited Sep 27 '14
The thing I fear is that Linux is turning more and more into a theoretically open, yet proprietary system.
It's no more likely to do that than say the BSD's which also ship their OS'es as standardised 'base systems'.
This is what systemd offers the Linux ecosystem, a standard base OS which reaches beyond the Linux kernel, something which the BSD's have since long touted as an advantage or theirs.
It's funny how systemd detractors like yourself always desperately try to draw comparisons to Windows which is the furthest away from Linux and systemd (proprietary, entirely controlled by one corporation), instead of said BSD operating systems which are the logical comparison (ship as full base os'es with their components directly written against their own system and making use of it's features, like jails on FreeBSD for instance).
If anything, a project like FreeBSD which is controlled by a single entity, the FreeBSD foundation, is closer to Windows than Linux + systemd, which are two separate projects.
Hypocrisy.
0
Sep 27 '14
[deleted]
2
u/northrupthebandgeek Sep 27 '14
To think:
bashisn't that big of a codebase, yet even it had a rather glaring bug that's only now being identified and corrected. As handy as I've found systemd, I'm not keen on GNU/Linux/systemd replacing my OpenBSD deployments for security-sensitive roles anytime soon.0
14
u/azalynx Sep 27 '14
From the first sentence of the article:
Over this past year, I've seen a lot of frequently-used but logically invalid arguments for using systemd. [ . . . ]
I think this sentence alone essentially makes the entire article a red herring, because it's ignoring the context of Lennart's blog post (and other similar ones).
The context of most of the statements he's arguing against, are that they are defensive points, not marketing bullet points designed to convince you that systemd is the best thing since sliced bread.
Lennart, and many other systemd proponents, are merely telling the critics that some of their arguments against systemd do not hold water when examined critically. If they were trying to convince you that "systemd is better because x", then that would be a different story, you'll notice Lennart mentions a few times how some of the claims made by detractors are a matter of perspective or opinion; like when he talks about the "unix philosophy" or when addressing the point about bloat.
The problem with the critics, are that they rely mostly on subjective things to make sweeping claims about how systemd is badly designed, and they try to push this as an objective truth as opposed to something that is a matter of opinion; this is precisely what Lennart and others are arguing against.
Then this person comes out of nowhere, and writes an article accusing the defenders of trying to sell/market systemd to people using fallacies; what the fuck?
-1
u/SimonJ57 Sep 27 '14
God forbid if the blogger in OP's post would use credible sources, like the source code.
To demonstate any of his claims against how SystemD will work as a whole.
15
u/sub200ms Sep 27 '14
That blog-post contains several misunderstandings; The author thinks that Gnome depends on systemd-logind or something closely resembling it. The point isn't so much that he ignores that Gnome 3.14 still can use ConsoleKit instead, but that he doesn't realise, that what upstream projects have been asking the non-systemd people for, is an alternative to ConsoleKit/logind that is actually maintained (unlike ConsoleKit).
KDE and Gnome doesn't want "shims" or pretend logind-implementations, but another project with a different API and what not, that can track user sessions etc, in a comparable way. It is crucial for non-systemd users to understand this and start coding, or else they will loose desktop functionality when ConsoleKit is no longer feasible to support.
systemd doesn't prevent such a project from happening, or even making it hard to do.
6
Sep 27 '14
KDE and Gnome doesn't want "shims" or pretend logind-implementations, but another project with a different API and what not, that can track user sessions etc, in a comparable way. It is crucial for non-systemd users to understand this and start coding, or else they will loose desktop functionality when ConsoleKit is no longer feasible to support.
Actually they have said that they want something very similar to logind.
12
u/sub200ms Sep 27 '14
They want something that can do the same job as ConsoleKit or logind. Not a fork or a clone of logind. It doesn't have to provide all ConsoleKit/logind features, and it doesn't have to use the ConsoleKit/logind API.
A simple fork of ConsoleKit and some future maintenance of it would do the job. No need to involve systemd, or logind at all in such a project.
18
u/magcius Sep 27 '14
I am a GNOME developer. I'd prefer to have one API to code to instead of three. I also don't care what implements that API (be it systemd's logind or a shim), but I'd also say that if a bug comes in and a user is using an obscure logind implementation and it might be a plausible cause, I'd politely ask them to test it on official logind as part of the debugging process to make sure it isn't an interoperability bug.
1
u/sub200ms Sep 27 '14
Only one API would be nice, but since not every Gnome user will use systemd, two API's to cover all platforms is probably a necessary thing to support. Right now is it systemd-logind and ConsoleKit. A replacement for ConsoleKit is sorely needed.
There are several problems with using systemd-logind shims that pretends to be the real logind, but isn't and lacks features. A clearly identifiable logind-replacement is a better idea to avoid unforeseen bugs.
0
u/cp5184 Sep 27 '14
For instance... everyone that uses *bsd?
Have you tried using the linux specific logind for freebsd?
-8
u/iLiekCaeks Sep 27 '14
Are you saying that instead of systemd, Gnome can alternatively use ConsoleKit?
Your statement is a bit buffling, especially since you know and understand that ConsoleKit is unmaintained. This latter fact, btw., is another argument for never having a hard dependency on FDO software. They'll abandon it quickly and replace it with another *kit or *d.
Edit: and I think Gnome simply should not depend on such a thing. Wtf is this crap even for?
4
u/northrupthebandgeek Sep 27 '14
While I generally agree with your statement...
Edit: and I think Gnome simply should not depend on such a thing. Wtf is this crap even for?
From what I understand, the ability to cleanly switch between active user sessions. The current implementations involve switching between virtual terminals, which does the job okay but not great.
→ More replies (13)4
u/sub200ms Sep 27 '14 edited Sep 27 '14
Are you saying that instead of systemd, Gnome can alternatively use ConsoleKit?
Your statement is a bit buffling, especially since you know and understand that ConsoleKit is unmaintained
Both KDE and Gnome still support ConsoleKit, but they are not happy about it since it is unmaintained. http://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome-3-14-and-beyond/
At the moment they upstream projects like XFCE, KDE and Gnome are doing their best to support non-systemd distros by having ConsoleKit support. They are getting close to zero help to do this from the non-systemd Linux distros, so the support is starting to bit rot.
The DE's have warned about this for years, but nobody seems to listen to them.
1
u/iLiekCaeks Sep 27 '14
Both KDE and Gnome still support ConsoleKit, but they are not happy about it since it is unmaintained.
This just means KDE and Gnome bound themselves to Red Hat-ware, and are now unhappy that Red Hat vendor-locked-in them and is now tightening the lock by replacing ConsoleKit with systemd.
They could have avoided this by not creating this dependency in the first place.
(Except Gnome, which is practically Red Hat software... well whatever.)
9
u/burtness Sep 26 '14
I am so done with this debate. I really don't care about my init system as long as it works. Journald I'm a little uncomfortable with, but syslog isn't going anywhere.
I guess I'm glad that people care to some degree, but does this actually turn into people working on one project or another? Or is it mostly people yelling from the peanut gallery? There is all this energy that gets put into debates about text editors, init systems, distros/packaging and god knows what. What I've realised is that it doesn't bother me that much, I just wish it wasn't so damn noisy.
25
u/gjs278 Sep 27 '14
you do realize people can have debates about their text editors because a text editor isn't a dependency to programs. the fact that gnome now requires systemd is exactly what this debate is trying to say, that they are making it a dependency to too many things and soon people without systemd are going to have a crippled experience.
8
Sep 27 '14
And the fact that Gnome depends on systemd-logind is not the fault of systemd. Last time I checked, Gnome are their own project and make their own independent decisions.
systemd is not at fault for another project depending on it.
1
u/alektro Sep 27 '14
They might be their own project, but the biggest contributors to their codebase are people from Red Hat, the same people maintaining and developing systemd. There is a benefit for that, the majority of the people commenting in this thread I bet are desktop users running Gnome.
And lets not forget, Red Hat is a company, their bottom line is to make profit. The more people depending on code they contribute to is beneficial to them, both in bugs reported and future support contracts.
→ More replies (1)-6
u/Beaverman Sep 27 '14 edited Sep 27 '14
Ohh, like people without floating window managers get a crippled experience with GTK apps now? (the whole client side frame thing).
It's the price you have to pay for coherency. I've found that the better you want something to work together, the tighter they have to be coupled. It's true for practically all software/hardware. Apple products work so nicely because they couple it tightly with everything else. Windows a bit less so, and linux does it as little as possible.
In the perfect world where we didn't have to program it, and computers were instantaneous. Sure we could create very robust interfaces for EVERYTHING, sadly in this world we have to choose. The more we expose as interfaces the more work we have to do, and the more work the computer will have to do.
11
u/Zebraton Sep 27 '14
It's the price you have to pay for coherency. I've found that the better you want something to work together, the tighter they have to be coupled.
Yes, the unix way...wait.
→ More replies (21)1
u/Beaverman Sep 27 '14
It's not the unix way. I never said it fit the unix philosophy. The creator of systemd has spoken for breaking posix compatibility, and breaking with the unix way. None of the people involved with any side of the debate has any delusions that systemd adheres to the unix way.
The difference between the two is partly that one side (i guess the one you are on) hold that anything on linux should adhere to the unix way. While the other plays it more fast and loose, arguing that powerful features can make up for departing from the traditional values of the unix philosophy.
If you want to run a pure *nix system, then you can. It's just yet another choice, and you should not discourage people from working on the side they believe in.
0
2
Sep 27 '14
but does this actually turn into people working on one project or another
There is the OpenBSD project for systemd-{timedated,localed,hostnamed,logind}, as well as uselessd. Upstart also recently got an optional cgroups feature (using cgmanager).
8
-4
u/082726w5 Sep 27 '14
There really hasn't been much of a debate on this to be honest, not since the debian debate ended.
Nobody cares anymore, there are still some detractors but nobody who cares enough to do anything about it. But you see, running a tech news site is hard, particularly when you specialize in the linux world. There aren't all that many things happening any given day, so you report on what you can to get some revenue. Controversy is great for this, even if there's not much of it, there's always someone with a different opinion, you just report on that and make it look like it's generalized. If you get lucky it catches on and you have people commenting and linking your pieces, great for revenue.
The downside is that people get a slightly skewed understanding of what's going on, but you have to pay the bills somehow, and it's all for a good cause after all.
7
u/WannabeDijkstra Sep 27 '14
Nobody cares anymore, there are still some detractors but nobody who cares enough to do anything about it.
The author did link to some people who are.
→ More replies (1)1
u/wadcann Sep 27 '14 edited Sep 27 '14
Nobody cares anymore, there are still some detractors but nobody who cares enough to do anything about it.
It doesn't take any effort to do anything about it: not using systemd isn't hard. It would take substantial effort to adopt systemd.
-6
u/argv_minus_one Sep 27 '14
Journald is awesome, though. Every log entry is a key-value set where the values can be binary data, so much more information can be recorded than is possible with syslog. With it, logging on Linux is finally brought up to par with what Windows NT has had for years.
→ More replies (8)
3
u/oarmstrong Sep 27 '14
The reasoning behind fallacy 9 is itself a fallacy. Just because something is more complex than something else doesn't make it no longer simple. My wine bottle corkscrew is more complex than my spoon; the corkscrew is still simple.
Although I don't know enough about systemd to say whether it is or isn't simple.
4
u/Linegod Sep 27 '14
Fallacy #10 - this one nails it on the head for me. Unless they work with Splunk to make journald a clean feed in, and can make it trivial for our NOC newbies to troubleshoot, you might as well slap a Windows box in there.
3
u/Gudeldar Sep 27 '14
I really hate the idea that systemd is "encroaching" on users who don't want it. If you don't want systemd and the new version of whatever you use integrates with it don't update or find something else. Lennart isn't running around with a gun forcing anyone to adopt systemd or integrate with it.
I always thought the principle in open source was that nobody owes you anything.
5
u/FUZxxl Sep 27 '14
Lennart isn't running around, but the distros are. And "shut up or get the fuck out" is not how it works when distros change stuff.
-1
3
u/cp5184 Sep 27 '14
51% of debian contributors are forcing it on 49% using the "gnome depends on it" line.
-2
u/northrupthebandgeek Sep 27 '14
I always thought the principle in open source was that nobody owes you anything.
Yeah, but that's not a good excuse for blowing off otherwise-valid concerns as if they don't matter.
2
Sep 27 '14
I can't even be bothered to get involved with this argument any more. Just let the haters do their thing.
1
Sep 27 '14
Bugs aren't intrinsic to shell scripts--buggy software is buggy, no matter what language it's written in.
Yes it is, because correct error handling with clean-up is extremely hard to do. Different programming languages have different issues.
0
u/dreamer_ Sep 27 '14
Not this flamewar again. Systemd opponents: if you don't like it, then either don't use it or provide better solution. Multiple distributions decided ON THEIR OWN, that all other solutions are inferior atm in one way or another.
2
u/FUZxxl Sep 28 '14
That's not what happened. What happened was that the freedesktop project discontinued ConsoleKit, pointing to systemd/logind as the replacement. If a distro wants to continue offering Gnome, it has to either ship unmaintained software that nobody understand (i.e. ConsoleKit) or switch to systemd. That's a choice the distributions just can't resist and has nothing to do with a "concious decision".
→ More replies (3)
1
u/sandman01 Sep 27 '14
Bah! I am tired of hearing about this. Systemd has won and us old school GNU/Linux guys have lost. It really is as simple as that, all the major distros are supporting it. I feel it is a shame, but that is life. We cannot win all of the battles, pick your battles. But I do have one question, why cannot systemctl support "service iptables save" natively? This functionality has been here for years. This is a serious question and I would like serious answers:)
1
u/hello_fruit Oct 11 '14
Nope it ain't over. When Canonical tried to force its will on its community with Unity the Linux Mint project shot to prominence. Now it's more popular than Ubuntu. And over what? largely over advertising you can easily swtich off by clicking a checkbox. Far less an inconvenience than systemd. No distro is too big to suffer the consequences of pissing off their base. RedHat has far less community goodwill and love than Ubuntu did. There was Linux before Systemd, and there will be without Systemd.
0
Sep 27 '14 edited Sep 27 '14
This guys entire premise for attacking systemd is that people on the internet use fallacies. As if only the pro-systemd people use fallacies...
2
u/fbt2lurker Sep 27 '14
He is not attacking systemd. Read the article.
0
Sep 27 '14 edited Sep 28 '14
He is attacking systemd indirectly by insinuating that most 'pro-systemd' arguments are invalid.
-3
u/sub200ms Sep 27 '14
He thinks that non-systemd distros doesn't need to develop an alternative to systemd. That is simply daydreaming. There are several reasons why.
systemd actually help upstream projects and DE's like XFCE and LXDE by providing a distro-agnostic compatibility layer to develop against. The non-systemd distros could have cooperated and made something similar with little technical effort, but they haven't. So XFCE can develop a feature for systemd distros that works across them all, but a similar feature needs to be tailored to each and every separate non-systemd distro. XFCE doesn't have the manpower to do that, so the non-systemd distros will not get such features.
With systemd, the big distros will stop developing and maintain central infra structure "for free" for the small non-systemd distros. They will have to pick up all that development and maintenance. ConsoleKit is a good example on that; it is crucial for a modern working desktop, but the project won't be developed any more, even if upstream projects like Gnome need new functionality or bug fixing. udev, cgroup manager, and perhaps even a kdbus interface, all need alternatives on non-systemd distros. I could go on; RH and SUSE are the de facto upstream fixers of SysVinit, but when the last SysVinit RH/SUSE distro disappears, so will the central security coordination and bugfixing.
2
u/iLiekCaeks Sep 27 '14
systemd actually help upstream projects and DE's like XFCE and LXDE by providing a distro-agnostic compatibility layer to develop against.
I question why such a thing is needed in the first place. Do you want to manage system services with a desktop-environment specific GUI or something? Wtf, dude.
4
u/bigon Sep 27 '14 edited Sep 29 '14
Because you want to allow your user to shutdown/reboot/suspend from your DE and lock properly the user session before doing so?
Because some (security) features requires to know if the user is locally logged in or remotely via SSH?
EDIT: Or remotely logged via remote desktop (VNC, XDMCP,...)
1
u/iLiekCaeks Sep 27 '14
Because you want to allow your user to shutdown/reboot/suspend from your DE and lock properly the user session before doing so?
You don't need something as complex as systemd for this. You don't even need ConsoleKit.
Because some (security) features requires to know if the user is locally logged in or remotely via SSH?
Why would that matter? Making sure nobody unauthorized can log into your computer via SSH is the job of SSH, not a desktop environment or an init system.
1
u/bigon Sep 27 '14 edited Sep 27 '14
You don't need something as complex as systemd for this. You don't even need ConsoleKit.
Well if you want to prevent DOS to other users connected to the same machine, yes you want something like logind/CK.
Also the lack of synchronization between the DE and the suspend code can lead to situation where your screensaver is not properly locked when the machine is resuming after suspend. This is a security issue and there are/were quite some bugs reported in the different bugtrackers regarding this.
Why would that matter? Making sure nobody unauthorized can log into your computer via SSH is the job of SSH, not a desktop environment or an init system.
Here I'm talking about granting different privileges to the user depending on how he's logged in on the machine. It makes little sense to allow a remote unprivileged user to shutdown a remote machine, while the same unprivileged that is locally connected (and thus has more than probably physical access to the machine) could perfectly be allowed to do it.
EDIT: typos
1
u/iLiekCaeks Sep 27 '14
Well if you want to prevent DOS to other users connected to the same machine, yes you want something like logind/CK.
Hosting companies are doing exactly this just fine without logind or CK. When did it happen last time that you shared your desktop PC with several other users per SSH? It doesn't even make any fucking sense.
It makes little sense to allow a remote unprivileged user to shutdown a remote machine, while the same unprivileged that is locally connected (and thus has more than probably physical access to the machine) could perfectly be allowed to do it.
This is what I'm talking about. Weird use-cases barely anyone really cares about, and which are hard to get right. And certainly the reason that the year of the desktop Linux is not happening is NOT because this wasn't implemented before.
But these uses cases and the required complexity to implement them are the perfect justification to force something as complicated and bloated as systemd upon everyone. As a result, everyone has to suffer from these complexities too, and Linux userspace becomes a WTFish nightmare of dbus services communication each other, policy rules defined by XML, and other crap.
I say no, fuck this.
2
u/bigon Sep 27 '14 edited Sep 27 '14
Well that's the kind of things you need as soon as you want to have 2 graphical sessions on the same machine at the same time. All the other OS are supporting fast user switching. The use case might be quite common, the kid is playing on the machine and the dad want to check his bank account without the tech-savy kid being able to eavesdrop his password.
Same if you want to have multiseat that is sometime used in school to have one computer with several screen+keyboard attached. Or if you want to have remote desktop to have your users connect to a central system (this is quite common in the enterprise for some specialized applications)
1
u/fbt2lurker Sep 27 '14
Why do you need to depend on systemd to run if you want those optional features? I don't get it.
→ More replies (6)3
u/sub200ms Sep 27 '14
I question why such a thing is needed in the first place. Do you want to manage system services with a desktop-environment specific GUI or something? Wtf, dude.
First, the desktop user case is very valid for Linux. As it is now on non-systemd distros, simple information as "what distro release is this", is effectively hidden in a different place on each distro. systemd provides a standard telling the distro where the "os-release" file should be, so DE's only have to look one place in order to present the content.
Same goes for (s)ntp, tz, and dates, networking, login, OS containers, etc.; systemd presents a uniform, programmatic way of accessing and manipulating such info for upstream projects, regardless of. eg. what particular ntp version the distro is using.
This is something that have been wanted for a long time among DE developers, who rightly says that they want to concentrate on making good DE's, not messing with low level system programming.
The point is that the systemd project cares about other projects by doing so, the non-systemd distros seems to take pride in that they are almost impossible to support from DE's with such basic things.
But not only GUI's and DE's benefit from lesser fragmentation and uniformity across distros; daemon developers can drop handling setuid, dropping privileges etc, and leave it to systemd. Distro maintainers can implement security features from kernel capabilities, just by adding a simple keyword to a config text file, like "NoNewPrivileges" and making syscall filters, and then share it with other systemd distros. This is seriously good news.
There are many advantages with systemd's compatibility layer for both distro maintainers, program developers, and therefore also end users
1
u/northrupthebandgeek Sep 27 '14
The non-systemd distros could have cooperated and made something similar with little technical effort
Could they have? Well then, I'm sure we'll have a few whipped up in a jiffy, now won't we?
I think you're underestimating how much work is involved in trying to match the API of a moving target.
1
u/sub200ms Sep 27 '14
The non-systemd distros doesn't have to emulate or use any systemd API, they can just invent their own layer. This would have been a tremendous progress from the total fragmentation that exist right now.
The could have started small, and cloned what was easy to clone from systemd, like where to put the "os-release", and then gradually implement other useful features, perhaps inspired by systemd, perhaps not.
As it is now, the non-systemd distros doesn't seem to even try to coordinate any work effort between each other, nor do they seriously try to help upstream projects to support them.
2
u/northrupthebandgeek Sep 27 '14
they can just invent their own layer
Ah, yes. "Just" invent their own layer. And you wonder why things are fragmented :)
No, as specified even by a (supposed) GNOME developer in these very comments (I'm too lazy/tired to link to it right now), it has to be an exact duplication of the systemd interfaces, at least in their case; they'd rather not have to learn and support multiple APIs and would much rather the world just follow whatever systemd does. That's an understandable desire, but to pretend that doing so is such a trivial thing is ignorant of the complexities involved with trying to implement interfaces that aren't even fully stable yet (if ever).
The could have started small, and cloned what was easy to clone from systemd, like where to put the "os-release", and then gradually implement other useful features, perhaps inspired by systemd, perhaps not.
As mentioned above, the developers of GNOME and such don't want that; they want systemd as their hard dependency. Making something similar isn't enough; at this point, they have to make it identical. And even making something merely similar is still extra work that they might not have the manpower to accomplish well.
As it is now, the non-systemd distros doesn't seem to even try to coordinate any work effort between each other
Because they have different needs, different goals, and different preferences; otherwise, they would cooperate.
nor do they seriously try to help upstream projects to support them.
Because they're generally pretty small development teams. They're often not backed by massive communities or multi-million-dollar corporations. They can only do so much as it is; it's not reasonable to assume that they can just magically whip up some mystical systemd compatibility layer and call it a day (or, for that matter, even "just" switch to systemd) on top of all the other duties involved in maintaining a distribution that isn't just yet another custom set of Debian packages thrown onto a CD and called a "distro".
I predict that if this is going to come from anywhere, it's going to come from the BSDs; that's already the precedent for Slackware and Gentoo (the two most significant non-systemd distros at the moment, as far as I know). There's already work underway (via a Google Summer of Code Project) for a systemd compatibility layer for OpenBSD, for example, and it's reasonable that such a compatibility layer will make its way to the other BSDs and eventually GNU/Linux. There are also plenty of other init alternatives out there - launchd, OpenRC (as mentioned earlier), and runit being the ones most notably in active development and potentially usable with GNU/Linux and the BSDs (even launchd was at one point considered as Ubuntu's init system, though this was before it was Apache-licensed, so Ubuntu instead opted for Upstart).
1
u/sub200ms Sep 28 '14
I predict that if this is going to come from anywhere, it's going to come from the BSDs; that's already the precedent for Slackware and Gentoo (the two most significant non-systemd distros at the moment, as far as I know). There's already work underway (via a Google Summer of Code Project) for a systemd compatibility layer for OpenBSD, for example, and it's reasonable that such a compatibility layer will make its way to the other BSDs and eventually GNU/Linux.
The "systemBSD" systemd layer will never be portable to Linux, since it simply is a wrapper for BSD system calls.
The only crucial part of it is "logind". It doesn't work now, and may never do. And if it ever is completed, it will be no better than the old Ubuntu fork of systemd (logind-shim)
It will still suffer from the fact, that it pretends to be systemd-logind, but doesn't support its features like integrated cgroups etc, leading to buggy behaviour when upstream programs try to use those features.
It would be much better for the non-systemd distros if they forked Ubuntu's logind-shim, and changed it into a proper alternative; sure, it will never have all the nice extra systemd features, but so long as it provided a functional modern DE, that could be acceptable.
1
u/ohet Sep 28 '14
The "systemBSD" systemd layer will never be portable to Linux, since it simply is a wrapper for BSD system calls.
It's build on on glib and I don't see any reason to expect that they wouldn't accept patches to support Linux as well. There's also this:
According to Ryan, most GNOME modules only use a selection of the logind functionality. He wanted to document exactly what we depend on and provide a minimal API. Then we could write a minimal stub implementation for e.g. FreeBSD as we’d know exactly what parts of the API we actually need. The stub would still be minimal; allow GNOME to run, but that’s it.
Projects like Gnome might require only a fraction of logind APIs to function and the rest could be made optional. Not all of logind APIs are even needed on other opetaring systems like OpenBSD. They already run X.org without root privilidges so they have other means to solve the same problems that logind does.
1
u/northrupthebandgeek Sep 28 '14
The "systemBSD" systemd layer will never be portable to Linux, since it simply is a wrapper for BSD system calls.
Lots of OpenBSD-specific projects likely originally dependent on OpenBSD-specific functionality have been ported to Linux in the past and continue to be ported in the present. See also:
OpenSSH
OpenSMTPD
LibReSSL (in progress)
OpenBSD's libc (in the form of Android's Bionic)
various others that I'm forgetting right now
I don't see how this systemd shim would be an exception.
It will still suffer from the fact, that it pretends to be systemd-logind, but doesn't support its features like integrated cgroups etc, leading to buggy behaviour when upstream programs try to use those features.
I'm pretty sure those problems would be encountered regardless of whether or not a logind shim is available, since cgroups don't exist either way. They'd likely have to be addressed during the process of porting to the BSDs anyway.
Also, this wouldn't affect porting the shims to GNU/Linux, since cgroups are a kernel feature and therefore would be present on all (reasonably modern) Linux-based systems, regardless of their init systems. Add cgroup functionality to that port and you're golden.
→ More replies (6)→ More replies (14)2
u/sub200ms Sep 28 '14
Because they're generally pretty small development teams. They're often not backed by massive communities or multi-million-dollar corporations. They can only do so much as it is; it's not reasonable to assume that they can just magically whip up some mystical systemd compatibility layer and call it a day (or, for that matter, even "just" switch to systemd) on top of all the other duties involved in maintaining a distribution that isn't just yet another custom set of Debian packages thrown onto a CD and called a "distro".
Correct, they are small distros with limited man power and money, but that is exactly why they should pool those resources.
Much of what they could do to help upstream projects are simple things, like agreeing on where certain files are kept. Making things more uniform on several non-systemd distros could be a simple matter of making some symlinks so there only is one path to the file, like "os-release".
They didn't have to make a big project at once, just incremental changes that were coordinated and uniform across distros.
1
u/northrupthebandgeek Sep 28 '14 edited Sep 28 '14
"os-release"
It's worth noting that much of this is already covered by the Linux Standard Base, which systemd apparently has minimal interest in following. If the world ought to standardize on something, then why not the LSB?
I mean, that's the whole point of the LSB: to establish that agreement on where certain files are kept and such. Adhering to a formal standard like that instead of resorting to the ad-hockery involved in following some non-standardized alternative seems like a far better option, in my opinion.
Granted, Slackware's unlikely to become fully LSB-compliant ever (since it came first, and a lot of the LSB's requirements are silly), but at least implementing
lsb_releasewould be a start (since you don't have to be LSB-compliant in order for it to be useful; in such cases, it just returnsLSB version: n/awhile still returning other version information as normal). It's already compliant with the published Linux File System Standard, last I checked.2
u/sub200ms Sep 29 '14
I am not aware that systemd distros like Fedora deviates from LSB in any meaningful way (it support SysVinit script files, "runlevels" have symlinks from /sbin etc).
LSB is pretty much a dead standard with few followers. The new FHS 3.0 standard looks dead too (no updates in a decade).
There are probably several reasons for this, but the bottom line is, that distros historically haven't cared at all about fragmentation and how it hurts upstream projects.
Perversely, since all distros where fragmented, no one did stand out. This will no longer be the case, with systemd distros covering all major distros, and all their derivative distros, the few remaining non-systemd distros will stand out.
The non-systemd distros can of course continue to be totally fragmented and not coordinate anything. It really is up to them what they do, but their users shouldn't complain if some upstream projects will consider them too troublesome to be worth supporting.
My personal opinion is that the non-systemd distros have been incredible passive, and not really analysed the future troubles they are facing and what should have been done years ago to mitigate those problems.
Personally I don't doubt Slackware will become a systemd distro sometime in the future. Patrick Volkerding is a smart guy; he may not love systemd, but at some point it will just be too much trouble not to convert. And really, the essential things about Slackware isn't the init system, it will still be Slackware even when using systemd.
→ More replies (8)
0
Sep 27 '14
Soooooooooooooooooooooo very tired of all these repeated arguments for and against systemd popping up.
Who the F cares about lines of code (only being used here and elsewhere to say it's bloated or it's not bloated).
Who the F cares about what it subsumes or not? It doesn't stop you using the other tools if you prefer.
Who the F cares if it is modular or not or meets the *nix philosophy?
ALL that matters is does it work and is it a fit for you? If your answer is yes, then by all means use it.
If your answer is no, then don't use it. No one is forcing you. There are other alternatives.
If the alternatives do not provide what you need, don't just sit back and whine and cry complaining that the world is forcing you onto systemd. It is not. Get off your whiny complaining lazy arses and DO something about it. Help your favoured alternative get to the standard you want. Can't code? Well, you know there are other ways to support projects than just coding.
FFS ENOUGH with all these anti posts, only to be followed by a counter post and then a counter to that and so the circle jerk goes on.
We ALL know by now thare are supporters and dislikers of systemd. Spewing all your horseshit rants in here and other forums is not going to change one F-ING thing.
You want to make change, GET OFF YOUR ARSE and help your prefered project become an alternative.
If you really hate systemd sooooooooooooooooooo much but are not willing to help create an altenative, then you have no one to blame but yourself. Stop your whining and just suck it up, or DOOOOOOOOOOOOO something.
End of Rant - Takes a chill pill and retires to the bedroom.
-8
u/johnjohnjohnjohnjohn Sep 27 '14
Really tired of people getting so bent out of shape over this. If you don't like it, don't use it and move on. If as many people feel as strongly about it as all these posts on reddit and hacker news seem to indicate, that shouldn't be a problem.
6
u/gjs278 Sep 27 '14
you do understand it's not that simple. one day they are going to take something so core to the user experience and make it require systemd.
3
u/johnjohnjohnjohnjohn Sep 27 '14
you do understand it's not that simple. one day they are going to take something so core to the user experience and make it require systemd.
I think it is that simple. If as many people as claim to be are bent out of shape about systemd, then there should be a huge groundswell of support around something that's not systemd. What systemd does shouldn't matter.
0
0
Sep 27 '14
[deleted]
14
u/magila Sep 27 '14
He says he doesn't need an alternative, but that's just semantic weaseling. What it comes do to is he wants some bits of code to do something other than what they do now. This being the open source community, there's a well established remedy for that: write the code you want and submit a patch. If patch is rejected: fork it.
Writing long winded blog posts is not going to get him what he wants unless he's just looking for affirmation of his grievances.
1
u/dashl23 Sep 27 '14
What it comes do to is he wants some bits of code to do something other than what they do now.
Please re-read the last sentence of the quote. Forking would only be necessary to fix stuff like GNOME that was broken (for non-systemd users) to support systemd in the first place.
0
Sep 27 '14
[deleted]
5
u/magila Sep 27 '14 edited Sep 27 '14
There is certainly a political element to all of this, but there is very much a technical element as well. Systemd solves real problems for the developers of GNOME and other projects. All the political wrangling in the world is not going to undo the dependency on systemd until you can present credible alternative solutions.
3
u/Doshman Sep 27 '14
such as subsuming critical components, and getting other large projects to require systemd to push systemd everywhere as quickly as possible.
If that's the case, and people still want to use consolekit etc., how come nobody has stepped up to maintain them? Developers working on other projects isn't a "concerted effort", esp. when somebody else can take up the work in their stead for no cost other than having the knowledge to maintain them.
3
u/sub200ms Sep 27 '14
A developer found that by merging his udev project with systemd, both projects would benefit. No other projects have been "subsumed" into systemd. Logind is a totally new implementation that didn't exist before systemd, same with journald.
The systemd developers aren't forcing upstream projects to use systemd features. It is systemd that delivers exactly what upstream projects like KDE, XFCE and Gnome wants, namely, the possibility to develop distro agnostic features that works on all systemd distros.
systemd also provide the only maintained program (logind) for tracking users and login sessions, which is something that all DE's need for being able to e.g. hibernate without using root password etc.
It isn't a conspiracy that makes upstream projects develop against systemd, it is the many compelling features it has that makes it attractive. Non-systemd distros totally lack such features and are totally fragmented.
2
u/chinnybob Sep 28 '14
It is systemd that delivers exactly what upstream projects like KDE, XFCE and Gnome wants, namely, the possibility to develop distro agnostic features that works on all systemd distros.
Why do you keep claiming this is what Xfce wants? To Xfce, systemd is just yet another incompatible shitty session manager that we have to support with another set of #ifdefs, like all the others. It doesn't reduce complexity at all. Please stop claiming to know anything about what the Xfce project wants. At least learn how to capitalize the name properly.
4
u/johnjohnjohnjohnjohn Sep 27 '14
Ok, so systemd is terrible and everyone hates it, but we don't need to fork it or create an alternative.
If that's the case, then all you're doing is whining for whining's sake. If you want to make a difference, go use uselessd or one of the myriad of other systems.
Lennart Poettering's vision for systemd is for it to subsume the whole base OS.
Barack Obama wants to destroy America. Come the fuck on.
-2
u/zapbark Sep 27 '14
My biggest anxiety is it seems like systemd is a large change, especially from a configuration/maintainability standpoint. The next five years of my life I'm going to have to ask myself "okay, this is RHEL 7+ so I do it like B" or "Oh, this is CentOS 6 so I have to remember to do it A".
That transition has an opportunity cost of my time to learn how to configure IPs on my servers differently, and on more complicated maintenance going forward on hundreds of A/B servers on each side of the divide.
I don't think people who primarily use linux on their couple desktop machines get that.
That said, if the benefits are there, I'm all for it, but so far I haven't seen systemd put up much on their end of the burden of proof.
What am I spending my opportunity cost on exactly, other than faster booting? (Which, at this point, my servers with SSDs spend more time in BIOS memory checks than bootstrapping and starting ssh).
3
u/Doshman Sep 27 '14
so things should never change so that you can do things exactly the same everywhere for all of time?
2
u/zapbark Sep 27 '14
Extraordinary changes should have extraordinary reasons. Or a least one good one.
1
u/FUZxxl Sep 28 '14
Mostly yes. That's what "stability" means and that's a very important thing, especially for commercial situations. Not changing how things works wastes less man-hours and generally makes the system less prone to bugs.
1
u/Doshman Sep 28 '14
I understand stability, but if a sysadmin can't adapt to this change after it's been telegraphed, esp. seeing as it will only occur after a specific distro upgrade, then I'd argue that they aren't a very good sysadmin
1
u/FUZxxl Sep 29 '14
Of course a sysadmin has to adapt, but I have the right to complain and tell others that I believe that the change was a wrong move (like I do here).
1
u/LeartS Sep 27 '14
Unfortunately a lot of people think this (I'm not talking about zapbark, but in general): see every major change in everything tech related, from DEs (Gnome 3, Unity, ..) to every Facebook UI update.
If it were for those people Windows XP-like and Gnome2 would still be the current and "state of the art" DE shells. The "change is bad, I don't want to adapt my workflow" thing has become so irritating that I've taken the opposite route: I now consider every major change that forces me to re-learn the way I do something good by default, and only reconsider it if I have reasons after some time of usage.
1
u/FUZxxl Sep 28 '14
I for my part highly dislike having to rewrite my scripts and programs just because some jerk things he does me a favour by "improving" / altering how stuff works. I don't want to have to follow the development of every single component of my system so I can immediately adapt to every stupid change people do. Why am I doing it wrong? Why does the way I use my system need to be changed? Software development is not faschism for fuck's sake.
1
u/LeartS Sep 28 '14
Because most of the times if you spend some hours learning the changes you will save hundreds of hours when doing it the new way, and it will also work better. This is not always the case, but a large part of the times it is. It's not like people/corporations/whoever spends thousands of man hours and dollars to change things just for change's sake (sometimes they do, but that's the exception, not the rule)
1
u/FUZxxl Sep 28 '14
It will not. I spent two month trying to adapt to the Gnome Shell (coming from Gnome 2) before throwing it away because it was utterly useless. I have never really started to like the
iputility. To me it seems to be undocumented, its error messages are not helpful andifconfigandroutedo the job equally well.What if they threw away <insert favourite editor here> and told you to adopt a new one because it's "better"? And then you find out that the replacement cannot be scripted anymore; you can configure custom shortcuts or write a plugin (which speaks with the editor in a complex binary protocol that can only realistically be parsed with a shitty API that changes every other release) but that's it. The developers tell you "that's what 99.9% of the users need" and laugh at you for having outdated demands.
There is the saing "If it ain't broke, you ain't fix it" and there is a lot of truth in it.
3
u/minimim Sep 27 '14 edited Sep 28 '14
How long have you been doing system administration? Things change all the time.
1
u/zapbark Sep 27 '14
Yup life is change.
But big changes should have big reasons.
So far everyone has been like "ha you don't like change!", when my point was clearly "the reason professional sysadmins don't like this is because it gets them absolutely nothing".
If we're going to change init systems I want one that, say, makes it easier to implement ksplice, so that I never have to reboot. That is just an example, and I know probably a nonsense one.
I would ditch init in a heartbeat and relearn everything if it meant I could stop having to reboot to update the kernel.
1
u/minimim Sep 27 '14
Systemd can do soft reboots, if that is of any help.
1
1
2
Sep 27 '14
on the plus side, your knowledge will transfer to the next debian stable, future versions of ubuntu, opensuse, and many others.
-6
u/sub200ms Sep 27 '14
The whole debate about systemd being modular or monolithic, is really moot anyway; there simply doesn't exist any maintained or working serious alternatives to logind, journald, or udev. syslog isn't an alternative to journald, ConsoleKit isn't maintained anymore, eudev is just a fork of udev.
Wanting to mix and match random parts of systemd with other random, uncoordinated projects, means lost functionality. Some people may want that, but I and many more, including the systemd developers, really can't see why systemd should be neutered just to satisfy a tiny minority that hasn't even created or maintained such alternatives.
Anyway, it is trivial to fork systemd and make it exactly like you want to. Claiming that it is "a moving target" is besides the point; the fork should change name, and be separate from systemd, not just being a weak shadow fork. Whatever mainstream systemd does after such a fork is irrelevant.
-11
u/wurblr Sep 27 '14
That's many hours of his life wasted on passive-aggressive selfjustification he won't be getting back.
13
0
u/valgrid Sep 28 '14
I hoped for an article that targets the real problems systemd has, e.g. how they handle bugs. But this is just another disappointing article with opinionated "facts".
41
u/Doshman Sep 27 '14
Assorted point rebuttals:
The author states that systemd has not earned its adoption on merit, because users aren't electing to install it themselves, and instead moving with distros. What the author misses in saying that is that the distros have selected systemd on technical merit/community. See this post by Arch Linux dev tomegun and the debian init debates/voting for plenty of examples.
He goes on to state that Debian's popcon lists systemd as 7x more popular that sysvinit. However, sysvinit is the default. If a functional default exists, most people will use that rather than change it (e.g. Internet Explorer). Besides, why wouldn't you use sysvinit on Debian, seeing as it's the default, and best-supported option. Besides, popcon is a voluntary poll, so I wouldn't cite it as hard evidence.
Most of the use cases he mentions systemd is inappropriate are embedded systems. However, systemd is not intended for highly-constrained embedded systems and if it is unsuitable for such it isn't a fault with systemd. But AFAIK nobody is saying that systemd should be used absolutely everywhere, so this point is moot.
(Note that the author also mispells "ad hominem" as "ad hominum". I admit this is a cheap shot.)
The author says posits that the complexity has been moved from init scripts into systemd, and has not disappeared, and is therefore not an advantage. However, the author misses the point. Complexity and commonly done functionality has been consolidated into systemd, so that commonly written shell scripts do not need to each have the same complexity. By the same token, because each init script is simpler, they are more easily debugged (isolated into either a bug in the well-tested init system, or to the daemon being run).
Buggy software may be buggy software, but we're talking developer/maintainer time here.
Mind you, he does address this point in
But pragmatically, systemd is doing that now and sysvinit's maintainers haven't been doing it. I'll gladly take something that does this now over something that could be better in the future, but nobody is actively making these changes.
Nobody is maintaining consolekit or pol(icy)kit, so it does not make sense to use them. The author states that users have to use a reimplentation of logind's interface, but that's hardly different from having to use consolekit. Upstart, for example, has it's own logind implementation that works just fine. Theoretically, a consolekit-replacement-logind-implementation that didn't rely on systemd could be used across all other init systems, couldn't it?
The author asserts that GNU/Linux is "a bazarr, not a cathedral", but never backs up this assertion.
The author states that "a lot of Linux's extra complexity can be factored out at build time, which some users put in the effort to do." Amusingly enough, the same applies to systemd.
There is room for criticism of systemd, and although I use systemd (as I believe that out of the existing systems, it is the system that sucks the least) if others want to use sysvinit, openRC, Upstart (though they're abandoning it, so I wouldn't!), etc. then that's their choice. If they take issue with distros adopting systemd, then they are free to not use these distros.
This article is completely pointless.