The Grumpy Editor's guide to surviving the systemd debate
In the end, it comes down to this: it just is not that important. It is just a system initialization utility. There is plenty of experience by now to show that Linux systems still work when systemd is installed; indeed, they are still even recognizable as Linux systems. The distributions that have moved to systemd have not been destroyed or rendered less useful; many would argue that they have been improved by the change. But even if systemd turns out to be a wrong turn in the end, the current level of anxiety and heat is not called for.
Some of us will remember the multi-year dispute over the devfs filesystem, which was perhaps the first serious attempt to deal with the failure of static /dev directories to deal with contemporary hardware. After numerous heated discussions, some of which made the systemd debates look calm indeed, devfs was merged into the 2.3.46 kernel. Some distributions adopted it fully, others held back. Over time, devfs turned out to not be the best of ideas, but, by then, it had worked its way deeply into the kernel. The patch set that removed devfs required 22 individual patches touching over 200 files in the kernel tree; we'll never know how much work was required to wean user space away from devfs. The removal took some time and effort, but, since we had all the code and sufficient will, we achieved it.
If systemd turns out to be an equally bad idea, it can be removed in the same manner. It is entirely possible that we'll eventually look at it the way we look at devfs — as an experiment in the wrong way to solve a problem. Or perhaps it will be seen more like sendmail: the best solution available at the time, but one that few of us wish to deal with now. However things turn out, if it becomes clear that there is a better solution than systemd available, we will be able to move to it.
Of course, it could also happen that systemd works out well and becomes just another part of our software mix.
With this in mind, your editor would like to venture forth with some humble suggestions for the people involved in the systemd debate. Starting with the systemd developers themselves: things are going for now, systemd has been adopted by most of the major distributions out there. Please try to be gracious in your success and to take into account the concerns felt by those who are not fully on board with your vision. Working harder to accommodate those who want a more loosely coupled plumbing layer — or, even better, encouraging them to join your community to make that looser coupling work better — would be a good thing. Avoiding "not our problem" responses when things break would be helpful.
And, it should be said, postings like this can easily be viewed as trolling. It should be possible to celebrate one's successes without being snide.
For those who are not systemd fans, it would be good to get away from the siege mentality that many of you seem to have adopted. This is not the final battle to save Linux from the depredations of the evil systemd empire. Nobody is forcing you to put systemd on your computers; they are simply offering you distributions using systemd that you are free to not install. This is not a conspiracy by any group to destroy Linux as we know it.
It is a group of developers with a vision for where they would like to improve Linux going forward. Linux has always moved quickly; these developers are simply continuing that tradition. The difference, arguably, is that we are long past the days of trying to catch up with other systems and are, instead, exploring new paths with little to guide us. It is natural that there will be more disagreement in this phase, and more mistakes too. Perhaps systemd is a mistake, but, if it is, we'll survive it, just like we have overcome our mistakes in the past.
It would be better if we all could assume that the systemd developers are acting in good faith to try to make a better Linux. If some of their ideas seem misguided to you, there are (at least) a couple of useful ways to respond. One is to join their community and work to push things in new directions; that is how free software works, and the systemd community seems to be reasonably inclusive. The alternative is to show a different solution that works better. Note that talking about such things tends not to impress people in this community; working code is the way to demonstrate a better idea.
For the trolls out there who seem to delight in trying to stir up systemd flame wars, we could ask you to go away but we know that's a futile request. Meanwhile, the rest of the community has, for the most part, been doing an admirable job of ignoring the inflammatory emails, comments, "songs," and more. Keep up the good work, please.
There will come a day when we will wonder what all of the fuss was about.
Systemd will either be established and successful, or it will have been
replaced by something better. Either way, we will be unable to comprehend
why we subjected ourselves to so much stress over an init system; it
couldn't possibly be as important as the battle over (say) choice in C
libraries or Wayland compositors that we might be fighting at the time. If
we can all relax a bit, we'll figure this one out without tearing our
communities apart. We are, after all, still working on the same goal:
producing the best free operating system we can. We'll never all agree on
the best tactics to get to that goal, but we don't have to; it all tends to
work out in the end.
Posted Nov 13, 2014 2:52 UTC (Thu)
by bferrell (subscriber, #624)
[Link] (145 responses)
It's a whole lot easier to adopt the view point you've requested if working tools (our systems) weren't being broken by this new system that someday will make the system better.
We aren't being offered a choice we can make. We've been told this is what we're going to do... Use it or go away.
Early in the cycle, the comment was seen on the mailing lists that if this wasn't the way, then perhaps sufficient testing would never be done and this new vision might never see adoption.
In the beginning, both init (with sysV style shell scripts, sometimes BSD style scripts) and systemd were offered. Almost universally, people opted for init.
When we chose init over systemd, the choice for init and script style startup was taken away... Unless we chose to laboriously put it back in. When methods have been found and shared to disable systemd, those methods too have been removed or disabled.
Please keep in mind, replacing the simple binary (init) that has a single, simple configuration file (/etc/inittab) has required an extraordinary amount of work and the effort to press this vision into the world even more.
The community reactions you feel so unreasonable would not exist in the face of choice. This is the crux of the matter and this you do not address.
Posted Nov 13, 2014 3:32 UTC (Thu)
by jonnor (guest, #76768)
[Link] (21 responses)
Almost universally the people working on init and related plumbing have chosen systemd. A core tenent (for good and bad) of open source is that those that do the work, get to make the calls.
You have a wealth of choices. Sticking only to the constructive ones that does not involve using systemd, you can: use and support distros which does not mandate systemd (like Gentoo, Slackware), you can volunteer to maintain sysvinit support in your favorite distro (for instance in Debian), or support those that do this type of work already, or you can create your own GNU/Linux distribution (or support those that do), or can use another free operating system like *BSD.
It is not a human right to tell others, who are doing work that you can benefit from without cost, what to work on or or how to do things.
Posted Nov 13, 2014 6:01 UTC (Thu)
by bferrell (subscriber, #624)
[Link] (11 responses)
init, the binary, has exactly ONE configuration file. The other files and directories are consulted by other programs that init may or may not call.
Yes, inittab defines what occurs at different run levels. Those run levels, conventionally, have certain sets of processes. and sometimes it directly maintains them... Not often in modern systems.
What init DOES do is to call a very flexible process management system that works correctly and doesn't have "odd corner cases" that will be fixed somewhere in the future.
In this case, people have in fact offered to perform the necessary maintenance. I personally have done so and been met with thundering silence.
No one has claimed a "human right". That bit of hyperbole is yours. Those of us who have been using, testing and supporting Linux for decades are not the leaches you attempt to paint us.
There are individuals who have a new vision. There is nothing wrong with vision, and has been pointed out, sometimes a new vision fails or is not well thought out.
The correct response to "how do I do ..." is NOT "why do you want to do that?". It is "You can do that this way, but you may want to think about this" or to simply ignore the question.
The first response is in effect saying "I am better than you and I know more than you so just shut up and do what I tell you". This is the crux of this entire debate because the response to questioning of the new vision is it's equal and that rankles!
Without the legions of people who use, test and advocate for OS freedom, you people of vision would have nothing to have a vision of.
Posted Nov 13, 2014 8:42 UTC (Thu)
by rvfh (guest, #31018)
[Link] (1 responses)
You do know this is incorrect right? You do understand that what you are saying does not make sense, and that although the old init *program* uses only inittab, the init *ecosystem* needs all those scripts to be really useful?
Or are you just trolling?
Posted Nov 13, 2014 9:01 UTC (Thu)
by peter-b (subscriber, #66996)
[Link]
I went back and re-read his post, and this sentence stuck out:
>> What init DOES do is to call a very flexible process management system that works correctly and doesn't have "odd corner cases" that will be fixed somewhere in the future.
I think he's just trolling.
Posted Nov 13, 2014 15:39 UTC (Thu)
by jonnor (guest, #76768)
[Link]
Thank you for ignoring the point that you do have a number of constructive options available.
Posted Nov 13, 2014 16:11 UTC (Thu)
by smurf (subscriber, #17840)
[Link]
Granted.
>> that works correctly and doesn't have "odd corner cases"
ROTFLBTC.
sys5rc definitely does NOT work correctly in quite a few cases which some people (not only systemd proponents) deem to be rather important.
Posted Nov 13, 2014 17:12 UTC (Thu)
by mmeehan (subscriber, #72524)
[Link]
Actually, "How do I do X" isn't always a useful question. This is called the XY Problem [1] and comes up very frequently in Q&A style support forums [2], to the point where it's a Q&A antipattern [3]. This is why you hear:
> "why do you want to do that?"
It's not because
> The first response is in effect saying "I am better than you and I know more than you so just shut up and do what I tell you".
...that's your projection. It's really about "X doesn't have a direct analogue, and frankly it doesn't make sense in the way you phrased the question. Maybe you want feature Y, but it has somewhat different semantics. I need to know more what you're *really* trying to do, in a broad sense (because it turns out you need Z instead)."
If you intend to ask questions, you must be prepared to answer questions asked of you. Questioning your use-case is not a personal challenge!
[1] http://mywiki.wooledge.org/XyProblem
Posted Nov 13, 2014 18:53 UTC (Thu)
by Seegras (guest, #20463)
[Link] (5 responses)
Bah. I didn't like SysV init when we changed to it (yes, I am one of those people whose first Linux distros had BSD init), and while it definitely is rather more flexible than BSD init, "works correctly" isn't what I would use to describe it. Rather: "A mess of shell scripts that work most of the time".
So systemd is a (another; I think I tried about all of them) replacement for SysV init, hopefully a better one. We'll see.
Init-systems are not a cause for flamewars anyway (unless you run emacs as init; then you need to be flamed).
Posted Nov 13, 2014 19:36 UTC (Thu)
by bferrell (subscriber, #624)
[Link]
And yes, if you run emacs as init, flamed is probably not needed... But you MIGHT get a darwin award
Posted Nov 17, 2014 23:41 UTC (Mon)
by nix (subscriber, #2304)
[Link] (3 responses)
One shouldn't write init systems in Lisp anyway. They have not enough pros and far too many cons.
Posted Nov 19, 2014 22:04 UTC (Wed)
by cesarb (subscriber, #6266)
[Link] (2 responses)
In case anyone didn't get the joke: https://en.wikipedia.org/wiki/cons
Posted Nov 19, 2014 22:29 UTC (Wed)
by neilbrown (subscriber, #359)
[Link] (1 responses)
thanks for pointing that out!! I would have missed it otherwise and that would have been a shame.
Posted Nov 25, 2014 22:11 UTC (Tue)
by nix (subscriber, #2304)
[Link]
It doesn't really seem like sufficient recompense...
Posted Nov 20, 2014 17:41 UTC (Thu)
by toyotabedzrock (guest, #88005)
[Link] (8 responses)
Without them you might as well contribute to dev/null
Posted Nov 20, 2014 22:13 UTC (Thu)
by wagner17 (subscriber, #5580)
[Link] (7 responses)
Posted Nov 22, 2014 17:51 UTC (Sat)
by thedevil (guest, #32913)
[Link] (6 responses)
Quote?
Ok, this isn't fair, because I know you can't - you probably
Posted Nov 22, 2014 19:45 UTC (Sat)
by dlang (guest, #313)
[Link] (5 responses)
The systemd people claim that they are not forcing anyone to use it, but at the same time they state that their goal is to be the plumbing layer for all of Linux so that they can change all distros by just changing systemd.
These two worlds (where you can avoid using systemd by just picking a diffent distro and where they can change every distro by just changing systemd) are mutually exclusive.
So which statement should we believe?
Posted Nov 22, 2014 19:59 UTC (Sat)
by filipjoelsson (guest, #2622)
[Link]
Posted Nov 22, 2014 20:04 UTC (Sat)
by rahulsundaram (subscriber, #21946)
[Link] (3 responses)
Posted Nov 22, 2014 21:20 UTC (Sat)
by mgb (guest, #3226)
[Link] (2 responses)
They tried that and failed. Approx 1% of Wheezy users replaced sysvinit with systemd, compared with e.g. approx 30% who replaced exim4 with postfix.
Most serious Debian users - users serious enough to replace the default mail system - do not want systemd.
So for Jessie we see plan B - you don't have to use systemd but they broke a whole bunch of stuff so it won't work without systemd.
Posted Nov 22, 2014 22:41 UTC (Sat)
by gracinet (guest, #89400)
[Link]
I think that using these statistics light that might be very misleading. I don't know if I'm representative, but taking my case as an example :
- Systemd support in wheezy seemed just not ready for prime time to me [1]. The couple dozens of wheezy servers that I manage still run sysvinit. OTOH, I started running systemd (including as PID 1) on the few jessie systems I have immediately (laptop and home jukebox).
- Most of my wheezy systems are installed from an OpenVZ template that comes with postfix, whereas I was much more familiar with the default exim4. Turns out that on most of them I don't want anything more complicated than sending alerts to root, so I don't care. But I didn't switch to postfix myself.
[1] maybe I was wrong thinking that, that's not the point.
Posted Nov 23, 2014 18:53 UTC (Sun)
by njs (subscriber, #40338)
[Link]
This has been debunked approximately 1000 times -- even Ian's GR text explicitly notes that Jessie works just fine without systemd.
At some point it becomes hard to believe that this is a good-faith mistake on your part. Unfortunately, the only alternative I can see is that you're deliberately lying in an attempt to mislead people. If you're right, then surely you can convince people of that using actual facts?
Posted Nov 13, 2014 3:37 UTC (Thu)
by mgb (guest, #3226)
[Link] (26 responses)
Then they came for your beloved kernel, Jon --- and there was no one left to speak for you.
This debate is not about technology. There's nothing even remotely new about dependency based boot, daemon management, and utility libraries.
This debate is about control. This debate is about freedom.
Posted Nov 13, 2014 3:52 UTC (Thu)
by jonnor (guest, #76768)
[Link] (2 responses)
Posted Nov 22, 2014 18:34 UTC (Sat)
by thedevil (guest, #32913)
[Link]
Sometimes fear is justified.
I fear the next US national election, because I have lived long enough
Posted Nov 28, 2014 5:43 UTC (Fri)
by blujay (guest, #39961)
[Link]
A common refrain of the systemd advocates in Debian is, "You can't force people to do work they don't want to do." Yet here a systemd advocate seems to be complaining about other people not doing work they don't want to (have to) do.
> unwillingness to take responsibility.
Responsibility for what? Fixing breakage caused by systemd?
Perhaps I misunderstand you, but this seems like hypocrisy. If systemd worked constructively with existing software and other distros, and if it took responsibility for fixing things it breaks (instead of, "This is your wake-up call: fork it, reimplement it, or have no more udev. Good luck."), we wouldn't be having such vehement arguments.
Posted Nov 13, 2014 12:15 UTC (Thu)
by motk (guest, #51120)
[Link]
Not really. Sheesh, overreach.
Posted Nov 13, 2014 12:55 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (21 responses)
Posted Nov 20, 2014 1:35 UTC (Thu)
by ksandstr (guest, #60862)
[Link] (20 responses)
In the absence of an answer, I'll assume that you're utilizing an excuse not to engage, though it is a weird thing to do as a first post in a thread. However there are worse readings, so I'll go with this best-faith one.
Posted Nov 20, 2014 1:59 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link]
Subscribers at the "professional hacker" level and above have had access to a simple "filter all comments from this list of users" feature for quite some time now; the addition of the feature was announced in an LWN article at the time. A list of filtered users looks a lot like a killfile to me.
Posted Nov 21, 2014 0:53 UTC (Fri)
by flussence (guest, #85566)
[Link] (18 responses)
It's the human equivalent of a "too many errors, aborting" message from the compiler.
A message like that *is* snippy and rude on the surface, but it gives the plonk-ee at least the courtesy of knowing they've gone off-course far enough to provoke such a reaction, and leaves them an opening to do better in future.
It's more than a throwaway remark, IMHO. Staying to face someone down and tell them why they've screwed up badly enough to end up on one's killfile — under the aggravation that leads to that kind of decision — can be quite a lot harder to do than simply throwing them on there and being done with it.
Posted Nov 28, 2014 6:14 UTC (Fri)
by blujay (guest, #39961)
[Link] (12 responses)
The accuracy of the principled argument is made quite clear by LP's "wakeup call" to Gentoo about udev. Whether or not they are actively trying to take a dominant position in the Linux "ecosystem" to force changes downstream, the end result of their "we broke it, you fix it" attitude is the same.
And I'm mystified as to why so many people don't understand this. Without a cooperative, you-scratch-my-itch-and-I-scratch-yours attitude, the whole free software ecosystem and community falls apart, or at least splinters into incompatible sects.
What is the underlying issue? Is it a fundamental lack of respect for others, a selfish refusal to accommodate others' needs and desires? That's how it looks to me, and if so, it will eventually come back to bite these people when they have conflict among themselves, when they eventually have divergent needs or desires.
Another possibility is a simple lack of patience. How long have distros been using non-systemd tools successfully? Why do these changes which so many people oppose have to be forced through NOW? The "we have to do SOMETHING, and we have to do it NOW" attitude is responsible for a lot of conflict and mistakes and problems throughout history.
It strongly resembles politics: people suddenly get the idea that "something must be done," and so they try to ram something through before they run out of political capital (or before their party is out of office), even if it's not a good solution or if many people are opposed to it.
And it resembles politics so much that I think it strongly suggests that, behind the scenes, this whole conflict is primarily not a technical one. Good technical solutions sell themselves, especially in FOSS. For this to be forced through in spite of such opposition suggests a lot about the motives of those pushing it through.
Posted Nov 28, 2014 13:52 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (10 responses)
And they feel like this has been done already with no change whatsoever.
> The accuracy of the principled argument is made quite clear by LP's "wakeup call" to Gentoo about udev. Whether or not they are actively trying to take a dominant position in the Linux "ecosystem" to force changes downstream, the end result of their "we broke it, you fix it" attitude is the same.
I read that as more of "we aren't going to maintain this old code [netlink] anymore, it are going to use kdbus instead; if this bothers you, do something about it".
> Why do these changes which so many people oppose have to be forced through NOW? The "we have to do SOMETHING, and we have to do it NOW" attitude is responsible for a lot of conflict and mistakes and problems throughout history.
They don't have to be done now; Debian is already 3 years behind other distros in adopting it. But waiting *another* 3 or 4 years to do it is probably not in their interest either. If Debian does find issues in it, don't you think it'd be easier to change now than in 2017 when other distros have had 6+ years of experience with it?
As stated before, there has been no active breakage of non-systemd init systems (at least that anyone has bothered to point out rather than just handwave about it) and as long as folks who don't want to use it contribute patches so that things still work (who are also best to get such things anyways), nothing is stopping you except, apparently, that you think the maintainers should have to keep N installs to test their packages with their init systems. *That* is forcing work on maintainers.
Posted Nov 28, 2014 22:06 UTC (Fri)
by dlang (guest, #313)
[Link] (9 responses)
> I read that as more of "we aren't going to maintain this old code [netlink] anymore, it are going to use kdbus instead; if this bothers you, do something about it".
Well, that's a large part of the problem. Deliberately breaking existing users because you don't want to bother maintaining the code any longer.
This is the opposite of the stable external API guarantee that the kernel team maintains where they only remove something if nobody is using it or if it's got serious security holes they can't fix.
This is the attitude towards compatibility that makes people grumble and declare that Linux will never be a serious desktop.
Posted Nov 28, 2014 22:40 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (8 responses)
Is udev's netlink-based communication protocol actually part of an "external API" of udev? Or is it essentially an internal implementation choice, the sort of thing a kernel developer would feel free to change at very short notice if any? Which non-udev programs make use of it?
Posted Nov 28, 2014 22:47 UTC (Fri)
by dlang (guest, #313)
[Link] (5 responses)
On the other hand, if you ignore the claims about systemd being modular and consider udev just an internal component of systemd, and users have to go all-or-nothing with systemd, then it could be an "internal API" of systemd.
But that would make the claims that systemd isn't forcing you to use everything a lie.
Posted Nov 28, 2014 23:05 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
I think Lennart called out Gentoo because they forked udev (IIRC mostly
because they didn't like that the udev and systemd repositories were merged). AFAIK the netlink-based interface is what the kernel uses to talk to udev, so once that is replaced by kdbus then the Gentoo version of udev will also have to start using kdbus (either by adopting the userspace kdbus binding that is part of systemd, which does not force you to take on anything else from systemd, or by implementing another kdbus binding), or else the Gentoo people will need to maintain their own version of the kernel side of things, too.
I don't think that systemd's degree of modularity has anything to do with the problem at hand. Udev is really quite independent of systemd, and AFAIK the netlink-based communications protocol is used by udev but by nothing else in systemd. As long as this is only used by udev and the kernel, it remains an internal interface, and it is reasonable to change it if that makes technical sense. Hence my question whether anything outside of udev uses it (and Gentoo's udev fork doesn't really count).
Posted Nov 29, 2014 0:39 UTC (Sat)
by mgb (guest, #3226)
[Link]
Will your proposed kernel changes break eudev?
Posted Dec 10, 2014 16:32 UTC (Wed)
by nix (subscriber, #2304)
[Link] (2 responses)
Posted Dec 10, 2014 20:53 UTC (Wed)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Dec 11, 2014 17:04 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Nov 29, 2014 0:10 UTC (Sat)
by viro (subscriber, #7872)
[Link] (1 responses)
These days any kernel developer who would even try to pull off something like that would get painfully educated on the reasons why You Don't Fucking Do That(tm).
It doesn't matter how many programs use it. One boot-critical is more than enough. Quite a few of us avoided udev for years after that stunt, exactly because it made our lives very, very unpleasant *and* udev developers tried to pull off that kind of indignant "but it's just a private API, how can you say that we don't get to change it at whim?" shit, making everyone suspect that they fundamentally didn't get it.
We can keep several kernel images and boot one of them. Easily. We can not do the same with the userland programs. And you don't get to assume that your Great! Shiny! Change! renders all previous history instantly obsolete and uninteresting.
Posted Nov 29, 2014 3:15 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Nov 28, 2014 15:58 UTC (Fri)
by foom (subscriber, #14868)
[Link]
Well, debian was patient -- and therefore skipped the whole upstart dead end. At some point the advantages of the new system outweigh the desire to wait and you take a risk with moving.
I've been waiting for a less sucky init system since I became aware of the possibility of something better when launchd came out in 2005. Isn't it time YET?
Posted Nov 28, 2014 15:15 UTC (Fri)
by ksandstr (guest, #60862)
[Link] (4 responses)
However, the original plonker up there only came, plonked, and then vanished. No reason was given, not even a cursory "I disagree, but cannot articulate my reasons"; and clearly there's at least one poster, you, reading it in some other way.
>(...) and leaves them an opening to do better in future.
That's exactly what a killfile doesn't do.
>Staying to face someone down and tell them why they've screwed up badly enough to end up on one's killfile — under the aggravation that leads to that kind of decision — can be quite a lot harder to do than simply throwing them on there and being done with it.
And a throwaway display of passive-aggression is more difficult and time-consuming than simply plopping them in there and being done with it, sans comments. Minimization of effort is clearly not the goal here, and neither is avoidance of posting under aggravation -- anyone can go cool down for about an hour anytime they've got occasion to be reading LWN comment chains.
Posted Nov 28, 2014 22:24 UTC (Fri)
by mgb (guest, #3226)
[Link] (3 responses)
SD believers have been ad-homineming the post you refer to as a plonk for more than two weeks now without actually addressing the issues.
It has been fascinating watching you echo each other but why should any of us experienced software professionals waste LWN bandwidth responding to you?
http://lwn.net/Articles/620159/
Posted Nov 29, 2014 16:29 UTC (Sat)
by ksandstr (guest, #60862)
[Link] (2 responses)
The short version: because failing to respond displays an outright absence of professionalism regardless of supposed degrees of experience. Every reader can confirm the former with his/her own eyes, whereas the other is a matter of taking someone's word for it.
The long version: assuming that it's at all possible, the anti-systemd concerns can be answered with a reference to a FAQ document where previous answers are listed. If those concerns aren't in the FAQ, an answer should be written and then added to the FAQ. Doing this would take as much time and effort as answering someone who isn't supposedly a nobody, and makes the pro-systemd position more solid. If it isn't possible to answer a particular anti-systemd concern, then there must be a proper argument for why that is so. The definition of proper argument excludes Mr. Pöttering's "systemd myths" page, his "claim to sacred victimhood" G+ posting, and various journalistic threat narratives concerning the Devuan (nee debianfork.org) project.
This'd move the argument into one of dueling FAQs, so I'll jump the gun on the next salvo with this <URL:http://judecnelson.blogspot.fi/2014/09/systemd-biggest-fa...> list of fallacious pro-systemd arguments and the counterarguments demonstrating them as such. Note that the document was first posted in September 2014 which makes it two months old at this time.
However instead of a civilized discussion we've seen various forms of playing to the crowd, ad-hominems, discussion-stoppers, and outright playground-style sneering. "Neener-neener, aren't you just a butt-hurt neck-beard troll! Ban his stupid ass. I'm being victimized by white males in their 30s and 40s, and I'm not going to engage in any further discussion about this post. lololo." On the pro-systemd end there are people, even Debian developers, who'd rather be publicly seen throwing their toys out of the pram than engage criticism at a level that excludes dogma.
It's my sincere opinion that this discussion must move forward regardless of the non-arguments in their various forms that we've seen so far, and especially despite the "this matter has been decided, please disperse, move along nothing to see here, go back to your homes" theme of article seen in e.g. the LWN headline two weeks ago. As it stands right now the discussion is lagging the impact of systemd and its tentacles by about three years: even commenters on a cutting-edge Linux news site such as this right here will rehash "just an init system", "socket activation makes it worthwhile on its own", "modular architecture means it isn't monolithic", and other demonstrably ill-founded quips.
I'm not one to put my faith in credibility games; they only exist to make perceived truth conform to the best player's ideology and not to empirically verifiable reality and logically equivalent derivatives therefrom. However, when open source luminaries such as Bruce Perens are getting on systemd's ass about not just technology but also communication, then it's certainly time to stop, take a deep breath, and consider just what the hell's going on outside of the pre-chewed conclusions which the pro-systemd camp is offering.
Posted Nov 29, 2014 16:49 UTC (Sat)
by mgb (guest, #3226)
[Link] (1 responses)
The opportunity for preventing harm to Debian has passed. It is now time to code around the systemd blockage - whether in blends or derivatives or forks or Gentoo/Funtoo or the BSDs.
And exploring the various technical alternatives is *much* more interesting than trying to convert systemd believers.
Posted Nov 30, 2014 1:43 UTC (Sun)
by dlang (guest, #313)
[Link]
I don't think anyone is trying to convert systemd believers to prefer anything other than systemd.
The only think I am seeing is people asking the systemd believers to be more accepting to other users, including ones who don't want to run systemd, or who have a need to not always run the latest (which includes kernel developers who are developing the next, because they need to compare to older versions)
Posted Nov 13, 2014 3:45 UTC (Thu)
by rahvin (guest, #16953)
[Link]
Nobody is forcing you to do anything unless you have a completely different definition of force.
Posted Nov 13, 2014 17:12 UTC (Thu)
by cdmiller (guest, #2813)
[Link] (32 responses)
IMHO, the real systemd debate will be an ongoing conversation between developers and customers, and it's going to last a while.
Someone in these debates made a statement to the effect, if systemd is really too problematic systems administrators would appear with torches and pitchforks (kind of amusing as it's usually admins facing the pitchforks of their users). Well guess what? Seasoned systems admins are voicing legitimate technical complaints. There are some bug or anti-feature reports being ignored with snide attitudes. Recently there are a few grousing sessions on LOPSA IRC. Within my own team we now have occasional discussions about what to do systemd wise (journal appears to be a current focus, along with stunned disbelief and sarcasm about some anti-features). At the extreme do we stick with RHEL 6.5 and it's extended support cycle for some of our systems? We have 4 years left on Ubuntu Trusty LTS server edition. Almost sounds like waiting for the next Windows Desktop version and that's pretty sad.
In my view experienced sys admins are generally slow and cautious in response to major system changes rather than an unruly pitchfork wielding mob. We are primarily users, with occasional patches or bug reports and internal glue code as our contributions to free and open source. If legitimate complaints from the most prolific customers of linux are brought up and ignored over a sufficient period of time, some fracturing of the community will eventually occur. Linux is dominant in the server and cloud space and doing well in embedded. Vendors and projects who ignore or attempt to quash the requirements of those environments will eventually suffer the consequences.
Philosophically, about freedom, bferrell is correct. One reason we choose free and open source in my shop is freedom of choice. Being able to choose from a plethora of tools to find the best combination for any given job has been a boon for free software acceptance. If that changes to an Apple like vendor lock-in attitude other solutions will be sought or created. We will eventually route around systemd *if* it appears too unusable for our needs. The next year or two will tell how well it will eventually work out in our purposely heterogeneous shop.
The real systemd debate is going to last a while. In fact, in the systems admin space, it's barely getting started.
Posted Nov 13, 2014 17:36 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link] (21 responses)
Posted Nov 14, 2014 4:20 UTC (Fri)
by cdmiller (guest, #2813)
[Link] (20 responses)
Posted Nov 14, 2014 9:10 UTC (Fri)
by niner (subscriber, #26151)
[Link] (19 responses)
Lennart Poettering 2014-10-08 20:27:49 UTC
Journal files are mostly append-only files. We keep adding to the end as we go, only updating minimal indexes and bookkeeping in the front earlier parts of the files. These files are rotated (rotation = renamed and replaced by a new one) from time to time, based on certain conditions, such as time, file size, and also when we find the files to be corrupted. As soon as they rotate they are entirely read-only, never modified again. When you use a tool like "journalctl" to read the journal files both the active and the rotated files are implicitly merged, so that they appear as a single stream again.
Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.
Now, of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access.
Hence: journalctl implicitly does on read what a theoretical journal file fsck tool would do, but without actually making this persistent. This logic also has a major benefit: as our reader gets better and learns to deal with more types of corruptions you immediately benefit of it, even for old files!
File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.
I hope this explains the rationale here a bit more.
Posted Nov 17, 2014 23:45 UTC (Mon)
by nix (subscriber, #2304)
[Link] (5 responses)
Meanwhile, the format it's replacing, if corrupted, well, let's see -- you lose a line of syslog. Maybe you lose a bunch of other lines. But recovery from that is automatic; you only lose a line of syslog data around that touched by the corruption. You certainly don't lose a whole file. You *certainly* don't just rotate it away and, oh, I guess we should hope it wasn't an important log then.
This is not a sensible attitude to log data unless you consider log data fundamentally unimportant -- and in that case, why on earth are you recording it at all?
Posted Nov 17, 2014 23:59 UTC (Mon)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I've also had a similar experiences (albeit with NTFS on Windows).
Posted Nov 20, 2014 2:58 UTC (Thu)
by raven667 (subscriber, #5198)
[Link] (3 responses)
Maybe I misread but isn't that what journalctl does, skip invalid records and start back up at the next valid record, without touching the original file so you always have a pristine copy with the corruption intact? Logs are different than filesystems in that they are write once, read many, you never want to rewrite history, even if that history is corrupt due to a bug.
In fact if it were me, if you detect corruption on reading a journal log I would want to immediately kill journald and let systemd restart it, on startup the new copy can start a new log file Treat it like a microkernel server, die and reload quickly on error.
Posted Nov 20, 2014 3:47 UTC (Thu)
by dlang (guest, #313)
[Link] (2 responses)
As for killing journald when you _read_ a bad message, that sure isn't the right thing to do because you can read the same message many times, and do it years after it was written. killing journald when you read a message that's written a significant time in the past is the WRONG thing to do.
Posted Nov 20, 2014 4:28 UTC (Thu)
by raven667 (subscriber, #5198)
[Link]
I don't know if that's how it actually works, that's just my first idea of how I think it should work.
Posted Nov 21, 2014 9:15 UTC (Fri)
by zlynx (guest, #2285)
[Link]
People tend to forget that text files ARE A BINARY FORMAT. You have your 7-bit ASCII message terminated by a new-line character.
You could also have an array of 4 byte little-endian unsigned integers, terminated by 4 bytes of zero. It would be just as easy to find the start of the next message as it is in text.
We're pretty spoiled these days and don't have to worry about our messages getting off by a bit or two. I recall modems where if you weren't using parity (or was it stop bits) you might lose sync and anything could happen.
Anyway, there might be valid complaints about the particular design of journald's binary format. But just because it is binary doesn't necessarily make it unusually hard to recover or read.
Posted Nov 17, 2014 23:47 UTC (Mon)
by nix (subscriber, #2304)
[Link] (9 responses)
Posted Nov 18, 2014 0:07 UTC (Tue)
by rahulsundaram (subscriber, #21946)
[Link]
"of course, having corrupted files isn't great, and we should make sure the files even when corrupted stay as accessible as possible. Hence: the code that reads the journal files is actually written in a way that tries to make the best of corrupted files, and tries to read of them as much as possible, with the the subset of the file that is still valid. We do this implicitly on every access."
Posted Nov 18, 2014 0:15 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (7 responses)
No, it doesn't end up empty.
In my experience, a corrupted journal file is still completely readable and searchable, except for its final entry. Since the tools don't expose how individual journal files are being accessed, this corruption simply appears as if you'd lost a single log message.
Yes, it's possible some header corruption could mean an entire file is unreadable. I haven't personally seen that, but I can imagine that it's a concern for some people. You can limit the damage by ensuring the files get rotated frequently. There's {System,RunTime}MaxFileSize config options available; perhaps corresponding {System,RunTime}MaxRotateInterval might be useful. Worst comes to worst, you could just SIGUSR2 the journald process regularly from Cron or a timer unit.
Posted Nov 18, 2014 0:59 UTC (Tue)
by dlang (guest, #313)
[Link] (6 responses)
Posted Nov 18, 2014 2:34 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (5 responses)
But it sounds like something easily detectable by the libraries that read the journal files (so other apps, not just journalctl, would get the fix), and it still wouldn't result in an "empty" journal.
Posted Nov 18, 2014 4:03 UTC (Tue)
by dlang (guest, #313)
[Link] (4 responses)
This is one of the problems with binary logs
Posted Nov 18, 2014 5:04 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (3 responses)
Look, I'm not denying that there are bugs that can corrupt the logs or lose large numbers of log messages. But the original claim -- that corruption yields an "empty" journal that can only be made non-empty through the use of "special commands" -- is patently false.
Posted Nov 18, 2014 11:59 UTC (Tue)
by notninjaz (guest, #99725)
[Link] (2 responses)
This thread has brought out some of the tradeoffs, though, such as a recommendation to rotate the log frequently to minimize the impact of possible corruption. For the servers I administer, I would prefer logging to a text file and risking loss of a fraction of a second of logs if an entry is corrupt instead of rotating a journal hourly and potentially losing 59 minutes should there be corruption.
Posted Nov 18, 2014 13:14 UTC (Tue)
by mchapman (subscriber, #66589)
[Link] (1 responses)
Maybe that was what it was referring to. At any rate, it's just not true. When a journal file is rotated (whether that be because journald has detected corruption in it, or because it's reached its maximum size, or because the admin has simply asked for it by sending SIGUSR2 to the journald process), its contents are still read automatically by journalctl when searching and iterating through the logs.
The journal is not a single file; it is the sum total of *all* journal files. As far as I know, the only way to create an empty journal is to literally remove all of these journal files.
Posted Nov 18, 2014 14:51 UTC (Tue)
by notninjaz (guest, #99725)
[Link]
I meant to express a design preference rather to critique any particular software with regard to text vs. binary logs.
Posted Nov 18, 2014 22:52 UTC (Tue)
by cdmiller (guest, #2813)
[Link] (2 responses)
According to one post below, interesting defaults are being set for logging configuration in RHEL7. The configuration described looks like a band aid to side step this and possibly other issues.
Posted Nov 19, 2014 0:35 UTC (Wed)
by rodgerd (guest, #58896)
[Link] (1 responses)
Posted Nov 19, 2014 11:07 UTC (Wed)
by mchapman (subscriber, #66589)
[Link]
The official answer to that can be found at http://thread.gmane.org/gmane.comp.sysutils.systemd.devel....
I have read through the journal file format specification [1] and the code that implements it [2], and from what I can tell it looks reasonably straight-forward. I have no doubt bugs will be discovered. That is inevitable with any non-trivial code. But there's really no reason to believe that these bugs will go unfixed. It's not as if it's "new" code, anyway -- people have been using it now for years.
[1] http://www.freedesktop.org/wiki/Software/systemd/journal-...
Posted Nov 13, 2014 20:01 UTC (Thu)
by notninjaz (guest, #99725)
[Link] (9 responses)
For a medium-term strategy, I have been looking pretty hard at SLES 11 SP3. It addresses some of the major shortcomings in RHEL 6 - it ships with pacemaker, has KVM image locking via virtlockd, includes XFS at no additional cost, and is certified for Oracle 10/11/12
Posted Nov 14, 2014 5:14 UTC (Fri)
by cdmiller (guest, #2813)
[Link] (8 responses)
For your misfeature request I'll focus on a short list for the journal. These are already well known and discussed. The themes however are telling and appear to exist in other portions of the systemd space.
Binary log format.
The binary format of the journal is an unnecessary non feature. When we want binary format we already ship to a central server and a proven database of some sort, with a web accessible interface. At the very least the journal could use an existing vetted database back end. At the point of origin venerable grep friendly text files are usually enough. A structured format is great but in the end it's application dependent, binary or not. Having to run two logging daemons to ship logs for anything started under systemd is a poor design. Adding non features like the web accessibility while treating the rest as non issues due to band aids existing is unfortunate. These items truly need to be fixed, time will tell.
Posted Nov 14, 2014 11:24 UTC (Fri)
by pbonzini (subscriber, #60935)
[Link]
Are you aware that on RHEL7 the binary format is just in-memory? The on disk persistent log uses syslog.
> Having to run two logging daemons to ship logs for anything started under systemd is a poor design
journald aggregates log from the services's stdout/stderr, and keeps it in memory for fast access in "systemctl status" (one of my favorite systemd features). syslogs persists it. "Do one thing, do it well".
> Web access to log files.
Not mandatory, and a separate component from journald. Again, "do one thing, do it well".
Posted Nov 14, 2014 14:15 UTC (Fri)
by notninjaz (guest, #99725)
[Link]
I had the same feeling about the approach to log reporting - we solve it in a different place, too, using kibana/td-agent/fluentd from a central location with the logs also kept as text. I remember situations, though, in shops without that kind of setup wanting to look at e.g., 15 minutes around a SAN or network event on a number of servers with the benefit of a pipe to egrep to get rid of known background chatter. So, keeping an indexed binary copy of the log isn't a dealbreaker for me as long as syslog is directly written to as well. I see it as similar to having find and locatedb - I wouldn't want to have to depend on locatedb not being corrupt, but locate can be handy to find a file more quickly than find or ls alone.
The main thing I am concerned about with a dependency-based init is having a situation where a service that isn't critical for the server's purpose ends up blocking a business-critical application from being started due to failed dependencies. I suppose that could be worked around by marking the dependency as non-critical as we do with clusters, but vendors tend to have a way of declaring "UNSUPPORTED!" the moment any distribution-maintained stuff is changed.
On the other hand, one might instead simply go through service-by-service and make a service depend on only the 20 out of 140 services it actually needs (as someone else replied on a thread here about NetworkManger: rather than using simple text files / udev rules to start the network, one might simply make NetworkManager depend on the em1 interface using the dependency-based init system... yikes!), but that starts making what was an easy thing require quite a bit more work.
Posted Nov 21, 2014 16:28 UTC (Fri)
by Wol (subscriber, #4433)
[Link] (5 responses)
As a database guy myself, I consider this about the most stupid option possible!!! By all means use a database to INDEX the log file, but the log itself should be a streaming write - any other choice is !insane!
I know there's argument about what journald does, but the reason for doing it is sound - to maximise data retention in the case of a problem, and minimise the possibility of data loss. To store the log data itself in a database is simply ASKING for trouble.
Okay, I can only speak for Pick-like databases, but every log message would need to be allocated a sequential or GUID key. On a multi-CPU system collisions are almost inevitable. I can't imagine a Pick system keeping up under the load, and given that they kick seven bells out of relational for speed, no relational engine would stand a chance.
Then there's the matter of actually writing the data. Step one is to write a transaction log entry. Step two, hash the key and append the record to the appropriate block. Step three, is the table overflowing, and if so expand it, logging that as you do so. Step four, close off the transaction log and commit.
Now how many opportunities are there in that database write for a screw-up to happen? That's even before you give the OS level and the disk subsystem the opportunity to screw things up for you! Even worse, step three presents a marvellous opportunity for trashing old log messages as the database block gets split into two. I don't know how other DB engines handle it, but they're not going to be any better at it!
At the end of the day, the ONLY way that makes any sense is to stream the messages straight to disk. You're still relying on the OS and disk not to screw you up, but there's no way round that.
Cheers,
Posted Nov 25, 2014 22:24 UTC (Tue)
by nix (subscriber, #2304)
[Link] (4 responses)
Now how many opportunities are there in that database write for a screw-up to happen? That's even before you give the OS level and the disk subsystem the opportunity to screw things up for you! Even worse, step three presents a marvellous opportunity for trashing old log messages as the database block gets split into two. I don't know how other DB engines handle it, but they're not going to be any better at it!
Unfortunately these things slow everything down, quite a lot, and in the end you end up writing everything at least twice (once to a log of some kind, once to the DB) and taking noticeably more space to do it. I concur, writing syslogs to a database if you don't have a reason to do it (e.g. streaming structured logs there for later querying) is nuts.
But, then, existing projects like syslog-ng have been able to do this for many years. So this too isn't a justification for journald.
Posted Nov 25, 2014 22:37 UTC (Tue)
by dlang (guest, #313)
[Link]
> But, then, existing projects like syslog-ng have been able to do this for many years. So this too isn't a justification for journald.
Rsyslog will let you insert a bunch of messages at once (batch mode), which does wonders for the performance of inserting logs into databases.
But it's generally not the right thing to do because of the performance overhead (both inserting and retrieving)
Posted Nov 26, 2014 20:36 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (2 responses)
You're confusing DATA CORRUPTION with DATA LOSS. Yep, a database promises you won't get data CORRUPTION. In order to provide that guarantee, it also pretty much guarantees you WILL get data LOSS.
A database guarantees that if you have problems with the write, the database is ROLLED BACK to a consistent state. Which is totally at odds with the requirements of a logging system. If your computer hits a crash-state, a database guarantees that all your "in flight" log entries (ie the ones you are most interested in) will be THROWN AWAY.
A simple streaming write is the best way to ensure the information you actually want makes its way to disk before everything goes pear-shaped. The reason I explained how Pick would save the record is to stress the point that ANY problem, at ANY stage of the process, that causes a write failure, will cause the corresponding log entry to be thrown away!!! NOT what is wanted!!!
The only thing that's going to screw up a streaming write is corruption in the kernel or a screwed-up disk. Those will also affect a database, but there's a far bigger window for those problems (and other problems too) to screw up a database. And I repeat - the time at which you most need logging to successfully save log entries, is exactly the time at which a database is MOST likely to GET screwed up, and throw "writes in flight" away in the name of data CONSISTENCY.
Use a database for INDEXING the logs, not for storing them. Oh - and as for sqlite's vaunted robustness, I believe Firefox uses it. Why oh why then does my wife's Firefox give me so much grief with data issues? (She has mental health issues, and her login session gets a lot of abuse ...) My Firefox, on the same system, doesn't give me grief at all.
Cheers,
Posted Nov 26, 2014 20:41 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (1 responses)
Cheers,
Posted Nov 26, 2014 23:36 UTC (Wed)
by dlang (guest, #313)
[Link]
so there is no data loss once the database acks the transaction.
Posted Nov 13, 2014 22:13 UTC (Thu)
by valhalla (guest, #56634)
[Link] (61 responses)
This, in Debian, is just false: it is still possible to run Debian (jessie) with sysVinit: you only have to take care not to install the systemd-sysv package (and you can find practical metapackages that conflict on it, floating around the internet).
Right now it does get installed as a dependency for some packages, but as long as you are willing to use a DE that is not GNOME none of those packages are required.
I've been doing it for a few months, now, and while there have been a few bugs, they have all been prompty fixed, and my system is just working as it was before systemd became default.
Posted Nov 13, 2014 22:21 UTC (Thu)
by dlang (guest, #313)
[Link] (60 responses)
Posted Nov 14, 2014 0:26 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (59 responses)
These people are free to submit patches to ensure that packages support the non-systemd init system of their choice, and package maintainers should be encouraged to take these on.
Of course what “people” really want is to not have to do the legwork, but instead to have the package maintainers themselves come up with support for various non-default init systems on their behalf. Hence Ian Jackson's GR that tries to enforce this.
Also note that the GR is not about not having to install systemd, it is about not having to run systemd's PID 1 process. Even if Ian's GR is accepted, it will be perfectly fine for packages to depend on systemd as long as running systemd's PID 1 process is not mandatory (e.g., because you're using systemd-shim, which presumes the presence of systemd-logind, which on Debian is part of the systemd package).
Posted Nov 14, 2014 0:52 UTC (Fri)
by mgb (guest, #3226)
[Link] (46 responses)
All Debian packages worked in Wheezy without systemd. If systemd proponents had merely added support for systemd without breaking Debian packages then there wouldn't be a problem.
But systemd was never about technology. Systemd was always about control. And so systemd proponents broke support for non-systemd systems.
Systemd proponents broke Debian packages. Systemd proponents should repair the damage they caused to Debian.
Posted Nov 14, 2014 4:03 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (45 responses)
*plonk*
Posted Nov 14, 2014 6:06 UTC (Fri)
by mgb (guest, #3226)
[Link] (37 responses)
As a matter of fact precisely one of us does have long-term memory. I remember answering your question and I see down thread that you then acknowledged my answer: https://lwn.net/Articles/619599/
TL;DR Systemd developers broke stuff that was working in Wheezy. Nobody cares about Gnome3 being tied to systemd. The policykit-1 breakage is the most serious. There are several other broken packages and more will likely be broken if the GR fails to stop them.
Posted Nov 14, 2014 7:19 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (36 responses)
Are these packages not working properly without systemd?
Posted Nov 14, 2014 7:53 UTC (Fri)
by mgb (guest, #3226)
[Link] (34 responses)
They won't even install without chunks of systemd.
Posted Nov 14, 2014 7:55 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (33 responses)
Does booting Debian with SysV init or upstart somehow stops these packages from functioning?
Posted Nov 14, 2014 17:39 UTC (Fri)
by mgb (guest, #3226)
[Link] (32 responses)
Posted Nov 14, 2014 17:41 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (31 responses)
Posted Nov 14, 2014 18:03 UTC (Fri)
by mgb (guest, #3226)
[Link] (30 responses)
There are many cases of software working better on Windows than on Linux. I use Linux instead of Windows because of freedom, not ease of use.
I oppose systemd's regression to 1970's technological lockin because it is important to retain the freedom for us and future generations to innovate.
Most servers in the world came to run Linux because pre-systemd Linux was a great platform for innovation. Most GUIs in the world run Android because pre-systemd Linux was a great platform for innovation. The FreeDesktop crowd never got anywhere and forced adoption of their bad ideas will seriously harm Linux.
Posted Nov 14, 2014 18:21 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (26 responses)
Please explain how “post-systemd Linux” is less conducive to innovation than “pre-systemd Linux”.
Posted Nov 14, 2014 18:53 UTC (Fri)
by mgb (guest, #3226)
[Link] (25 responses)
Systemd is not portable to other OSs so it loses synergy. Systemd is so tied to RedHat's business goals that they explicitly reject portability patches.
Systemd uses marshalled internal communications. We learned the advantages of text streams for all but the lowest levels (e.g. TCP) in the 1980's. Look at the successful protocols - HTTP, SMTP, POP3, IMAP, FTP,, NNTP, .... Look at HTML, CSS, and JSON. D-Bus is like a 1970's mainframe come back from the dead.
But the most serious problem is the monolithic entanglement. This drastically raises the barrier to innovation in every area systemd absorbs. Making it harder for you and me to innovate is very bad. Making it harder for the next generation to innovate is totally unacceptable.
In short, systemd is the sort of monolithically entangled software I might have designed in the 1970's before we all learned better.
Posted Nov 14, 2014 20:37 UTC (Fri)
by johannbg (guest, #65743)
[Link] (6 responses)
By all means elaborate what you mean by this.
Posted Nov 14, 2014 20:45 UTC (Fri)
by mgb (guest, #3226)
[Link] (3 responses)
Why is RedHat trying so hard to force adoption of 1970's systemd technology?
"If we adopt new technology and incorporate it into our products, and competing technology becomes more widely used, the market appeal of our products may be reduced, which could harm our reputation, diminish the Red Hat brand and result in decreased revenue." [Redhat Prospectus]
Posted Nov 15, 2014 1:32 UTC (Sat)
by johannbg (guest, #65743)
[Link] (2 responses)
I did not ask you for ignant 1970's metaphor so under the assumption you dont have shit for brains clarify how you came to that assumption or conclusion that systemd is being somehow run by or tied to RedHat's business goals.
Somehow you came to that conclusion and I ask how.
Posted Nov 15, 2014 15:54 UTC (Sat)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Nov 15, 2014 17:10 UTC (Sat)
by johannbg (guest, #65743)
[Link]
If you required some confirmation about my mood then you simply could have asked and I would have answered that it's like the Icelandic weather if you dont like it just wait a minute...
Posted Nov 17, 2014 23:51 UTC (Mon)
by nix (subscriber, #2304)
[Link] (1 responses)
I'm not really sure why this is objectionable, mind.
Posted Nov 18, 2014 1:10 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Especially if said init system is freely available for all other Linux distributions to use, and is governed by a diverse developer community that includes representatives from practically all distributions.
Posted Nov 14, 2014 21:29 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (12 responses)
In the realm of init systems there seems to be little demand for synergy. Every single Unix derivative is doing its own thing these days. It would be nice – from an abstract POV – to have something that is usable on several platforms but the interest doesn't really seem to be there among the people who are really doing the work and making the decisions. This is not a systemd-only phenomenon.
You're still at liberty to innovate all you want. Feel free to come up with something that is notably better than systemd. People will love you for that kind of innovation.
Your problem, though, mgb, is that you don't actually innovate like the systemd people do. You don't have it in you. There is no way in hell that you could make something that ends up only half as good or as popular as systemd, even if your life depended on it. So instead you spend your time dissing the actual innovations of people whose discarded printouts you're not worthy to carry to the wastepaper bin. Disagree? Prove me wrong. Write something new that other people will want to use, and that two years from now will be part of all mainstream Linux distributions. Then you get to moan about how terrible systemd is for innovation, and maybe somebody will take you seriously.
Posted Nov 14, 2014 21:54 UTC (Fri)
by mgb (guest, #3226)
[Link] (7 responses)
Given the advances in software engineering in the last forty years, one would have to try really hard to design a plumbing layer as harmful as systemd.
Posted Nov 14, 2014 23:12 UTC (Fri)
by pizza (subscriber, #46)
[Link] (6 responses)
Please enlighten us with an example of "a modern component architecture".
Heck, while you're at it, I'd love to see an example of an actual "component architecture" *designed in the 70s*.
Posted Nov 14, 2014 23:26 UTC (Fri)
by dlang (guest, #313)
[Link] (5 responses)
a modern component architecture would be web services or RESTful interfaces where you define the API but the implementations are independent of each other.
a "throwback to the 70's" would be window's all-in-one where you have lots of separate components, but they all have to be exactly the same version and there are no alternatives to any of the components.
Now, I think the 70's is probably a bit early, but the 80's or early 90's seems very appropriate.
As a somewhat relevant side note, there's a reason that the respected standards bodies require multiple independent implementations of something before they consider it for a standard
Posted Nov 15, 2014 5:46 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (4 responses)
> As a somewhat relevant side note, there's a reason that the respected standards bodies require multiple independent implementations of something before they consider it for a standard
Posted Nov 15, 2014 5:52 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link] (3 responses)
Ooh, nice. Linky please? :)
Posted Nov 15, 2014 5:54 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Nov 15, 2014 6:06 UTC (Sat)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 11, 2014 3:03 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 28, 2014 6:39 UTC (Fri)
by blujay (guest, #39961)
[Link] (3 responses)
Posted Nov 28, 2014 13:29 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Nov 28, 2014 13:48 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
Posted Nov 28, 2014 19:11 UTC (Fri)
by viro (subscriber, #7872)
[Link]
Posted Nov 20, 2014 20:04 UTC (Thu)
by horsethief (guest, #99889)
[Link] (4 responses)
For anyone that doesn't understand, I've put my art skills to work and made a simplified diagram: http://i.imgur.com/kowKXoc.png
Posted Nov 20, 2014 21:13 UTC (Thu)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Nov 21, 2014 9:25 UTC (Fri)
by zlynx (guest, #2285)
[Link] (2 responses)
Posted Nov 21, 2014 17:26 UTC (Fri)
by mgb (guest, #3226)
[Link] (1 responses)
Posted Nov 21, 2014 20:29 UTC (Fri)
by peter-b (subscriber, #66996)
[Link]
* systemd
Seems reasonable.
Posted Nov 14, 2014 18:29 UTC (Fri)
by rahvin (guest, #16953)
[Link]
Posted Nov 16, 2014 15:02 UTC (Sun)
by robclark (subscriber, #74945)
[Link] (1 responses)
lol.. you have not actually looked at an android userspace have you?
Posted Nov 16, 2014 15:08 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
Considering that he doesn't appear to have looked at systemd either, that wouldn't come as a huge surprise.
Posted Nov 14, 2014 8:48 UTC (Fri)
by dlang (guest, #313)
[Link]
Posted Nov 14, 2014 8:47 UTC (Fri)
by dlang (guest, #313)
[Link] (6 responses)
The entire fuss in Debian started because Gnome required systemd.
Since then, there have been patches accepted that eliminate this requirement, but the whole fuss was exactly because DD decided to make a package only work with systemd.
Posted Nov 14, 2014 9:45 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (5 responses)
I was under the impression that upstream GNOME was changed to use systemd-logind rather than the obsolete and unmaintained ConsoleKit. It is reasonable for a Debian package maintainer to go along with this, especially given that systemd is the designated default init system on Debian, and that GNOME, while it serves as Debian's default desktop environment, is essentially an optional feature.
The proper way of fixing this is for those people who want GNOME to work without systemd-as-PID-1 to figure out a way to make this work, and that in fact happened even in the absence of a GR. “The whole fuss” is about forcing this work on the original package maintainers, which is against the Debian constitution. (There are people who would like Debian to work on a FreeBSD kernel or the HURD rather than Linux, but they're doing the required work themselves – they don't go for a GR compelling all Debian developers to do extra work to ensure that their packages support those systems, so why should non-systemd init systems be special in that respect?)
Posted Nov 14, 2014 10:28 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
"Changed" is perhaps too strong a word. As I understand it the code to use systemd was *added*. I'm pretty sure the code that uses ConsoleKit still exists in GNOME (or at least most of it). As an example, https://git.gnome.org/browse/gnome-session/tree/gnome-ses... still exists.
However, I would expect this code to bitrot over time. I suspect none of GNOME's core developers use ConsoleKit any more. Downstream developers (be that end-users or distribution maintainers) could contribute and keep it operational.
Posted Nov 14, 2014 10:33 UTC (Fri)
by ovitters (guest, #27950)
[Link] (3 responses)
That's not entirely accurate. GNOME was changed to use logind, but it is not a "rather than". ConsoleKit support is *still* there. After using logind, the cgroups change resulted in logind relying on systemd. Due to other changes, not using logind and some related (but way easier) daemons will result in reduced functionality. Too reduced for Debian.
Ian (GR proposer) asserted that changes happen due to "marketing".. urgh.
Posted Nov 14, 2014 10:45 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (2 responses)
Thanks for clarifying that.
This doesn't detract from the fact that basing Debian's version of GNOME on systemd is a reasonable call on the part of Debian's GNOME maintainers given the upstream's policy, and that people who would like GNOME in Debian to work without systemd should be expected to make the requisite changes, not Debian's GNOME maintainers themselves – with Debian's GNOME maintainers being encouraged to take up reasonable-looking and technically sound patches to that effect. Such patches would obviously be expected to contain conspicuous documentation explaining the loss of functionality, if any, incurred when running GNOME on a non-systemd system, to create informed consent on the part of users.
This does not require a GR.
Posted Nov 14, 2014 18:54 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
This is reminding people that this whole debian systemd debase started from the debian gnome developers deciding to make gnome require systemd
I agree that the Gnome developers should be free to do so, but it's only up to them alone if Debian doesn't use Gnome as it's default GUI
If the Gnome DDs want freedom to do anything they want with Gnome, with nobody else questioning them, then the answer is to have a different GUI be the default that takes the rest of the system into account and coordinates with everyone else.
The position of being the default package brings a lot of users, but it also brings limitations on what it's reasonable for the maintainers to do.
using an example from a different field, there's nothing at all wrong with a company becoming a Monopoly by providing better product at lower prices than their competitors, even if the competitors go out of business as a result. It's only a problem when a company that's a Monopoly uses the power of that Monopoly in bad ways.
These ways explicitly include:
1. blocking the entry of new competition.
2. leveraging their Monopoly in one area to force their way into another area.
Back to the topic. Using the position of being the default to force changes elsewhere in the system is a problem. It's a problem if Gnome does it to force systemd into the system, or if systemd uses it's position as the default init to take over other functions (logging, cron, etc)
Posted Nov 15, 2014 11:00 UTC (Sat)
by micka (subscriber, #38720)
[Link]
Posted Nov 14, 2014 8:45 UTC (Fri)
by dlang (guest, #313)
[Link] (9 responses)
This is exactly what people are asking for as part of the Debian GR.
Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time, and have talked about refusing patches that would allow for it to work without some of it's existing requirements or on non-linux systems because they think that the complication of the codebase is more of a problem than the benefit of supporting other systems.
Posted Nov 14, 2014 9:32 UTC (Fri)
by anselm (subscriber, #2796)
[Link]
How many of these “too many people” are Debian developers?
You're re-stating the position of the systemd core team. This has precisely no bearing on what the maintainers of unrelated packages in Debian (those which might or might not come with upstream systemd or sysvinit support) ought to do. In particular, the systemd core team can't be compelled to do or not do something by Debian passing a GR. On the other hand, if package upstreams decide to avail themselves of systemd-specific features, it is unreasonable to expect that the Debian maintainers of such packages develop support for other init systems on the off-chance; it is much more reasonable to expect that those people who actually want to use the package in question with another init system should do the work, and that the Debian package maintainers simply propagate the outcome for the benefit of other users. (If the Debian package maintainers do decide that they don't mind doing the extra work themselves then that is of course also fine.) This appears to have worked in the GNOME case even in the absence of a GR.
Finally, taking outside patches for extra feature support isn't actually unusual in the Debian ecosystem, and it is safe to say that the vast majority of Debian developers – who are generally reasonable folks – will welcome that kind of assistance. If the Debian developer in charge of a package is adamantly opposed to accepting a sensible-looking and technically sound patch simply because they don't like what it does, there are ways of resolving such impasses that do not involve project-wide GRs. So far in the systemd case this hasn't happened; we have had the opposite case where a maintainer didn't want to take on a patch that contributed systemd support for their package because they didn't like systemd – but as I said there are easier ways to sort this out.
Posted Nov 14, 2014 18:57 UTC (Fri)
by rahvin (guest, #16953)
[Link] (6 responses)
Every constitutional grouping of people eventually faces a challenge where a group of constituents eventually tries to get a rule passed through one of the rule making bodies or by direct vote that is directly contrary to the basic rules of the constitution. Not all of them survive this attempt. I fear for Debian when one group of people tries to force another to do something.
Posted Nov 14, 2014 19:06 UTC (Fri)
by mgb (guest, #3226)
[Link] (5 responses)
Posted Nov 14, 2014 19:10 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
is making Gnome depend on systemd done to force systemd to be installed? because the person doing it didn't realize they did it? or because it's the only way to get something done that they think is more important than running on systems without systemd?
patches and text communications are a horrible way to try and figure out what the intent of the person was, especially if there is any suspicion that they are not being open about their intent
Posted Nov 28, 2014 6:47 UTC (Fri)
by blujay (guest, #39961)
[Link]
Posted Nov 14, 2014 19:49 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (2 responses)
This is really really boring now.
https://mail.gnome.org/archives/distributor-list/2012-Jan...
Anyone serious about putting in effort of forking now over the systemd dep that has come up through logind as a replacement for consolekit, could have really made a difference in 2012 when consolekit became a dead project upstream. You so could have made a positive impact for your chosen cause in 2012. Could have really made a difference and made sure consolekit was still a viable upstream project...in 2012.
Back in 2012, there was an expectation that people interested in consolekit, specifically Ubuntu, would be stepping up forking it and maintaining the fork. That anticipated fork didn't actually happen and Ubuntu actually moved to logind. No idea why Ubuntu didn't stick with CK. There's no real discussion on that.
Seems a bit of wasted energy to get mad 2 years later about projects choosing to no longer depend exclusively on an unmaintained codebase, and have moved on to use something that is actively maintained.
Would you like to borrow my time machine and go back to 2012 and fork consolekit when it was a timely option?
Posted Nov 14, 2014 20:26 UTC (Fri)
by mgb (guest, #3226)
[Link] (1 responses)
I think you must be talking about Fedora which is indeed a lost cause.
Debian still has consolekit.
Meanwhile Erik Koegel forked consolekit2 so Debian will not have to continue maintaining FreeDesktop's software.
Posted Nov 14, 2014 21:23 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link]
The fact that Debian still has consolekit as a package doesn't change the fact that it has a dead and unmaintained upstream and other maintained projects should be relying on it.
And honestly it doesn't look to be actively maintained as a package in debian either as there are provided patches sitting in the debian bug tracker for years now.
yes indeed consolekit2 is an interesting development. Officially made public in October 2014, commit log suggests work started on it in feb 2014. Either way 2+ years after upstream died to announce the fork. Its existence now does not change the decision making leading up to October prior to it being known to exist. And it too late to make the jesse freeze without special consideration. So it doesn't even really change the situation for maintainers in the jessie release timescale either.
Really too bad it took 2 years for that fork announcement to happen. One has to wonder on the delay there. Like maybe if Debian had announced the intent to switch to systemd earlier, the fork would have happened earlier as well and there wouldn't have been a 2 year delay like this.
I mean seriously the consolekit2 fork was almost too late, even projects being run by maintainers who have previously voiced concern over systemd dependency. For example Lightdm was ready to drop CK support this month because of a lack of a maintained CK codebase.
Ref:
http://lists.freedesktop.org/archives/lightdm/2014-Novemb...
Once consolekit2 shows up in deb packaging, that will be an interesting discussion.
Posted Nov 15, 2014 12:32 UTC (Sat)
by ms_43 (subscriber, #99293)
[Link]
Posted Nov 22, 2014 18:46 UTC (Sat)
by thedevil (guest, #32913)
[Link] (1 responses)
Encouraged by whom?
Posted Nov 23, 2014 23:03 UTC (Sun)
by anselm (subscriber, #2796)
[Link]
Debian distribution policy. Works for most other things in Debian.
Posted Nov 13, 2014 3:09 UTC (Thu)
by timtas (guest, #2815)
[Link] (19 responses)
Posted Nov 13, 2014 3:49 UTC (Thu)
by jonnor (guest, #76768)
[Link] (1 responses)
* well, were; systemd project has fixed a lot already
Posted Nov 14, 2014 11:39 UTC (Fri)
by johannbg (guest, #65743)
[Link]
Right and too give an practical example we started to deploy RHEL/CEL 7 instances for clients and most if not all of them use IBM's TSM as their prefered backup solution.
Now RHEL 7 is supported by the 7.1.1 client without Journal Based Backup and SLES 12 does not seem to be supported et all [1].
Installing the package quickly revealed that the latest tsm client does not ship native systemd unit files so IBM is not getting with the program and generally what's happening on the 21 century ( like their lack of proper 64bit support in plethora of their applications shows ).
Looking at the initscript one can see the legacy sysv crap is 115 lines long
cat /etc/init.d/dsmcad | wc -l
Full of distribution spesific bits like...
if [ -f /etc/redhat-release ]
And supports only RHEL and SLES...
else
5 mins later after migrating the legacy sysv initscript you can see the unit file reduced the legacy sysv initscript by 102 lines! and comes with an automatic restart on failure which would have required additional bash script or some other daemon monitoring tool.
cat /etc/systemd/system/dsmcad.service | wc -l
An unit file that is self explanatory and usable by --> all <-- systemd based distribution
### dsmcad.service ###
[Unit]
[Service]
[Install]
Just save the above in /etc/systemd/system/dsmcad.service and run systemctl daemon-reload and you are good to go on *any* systemd based distribution until IBM start's shipping it's own.
Unfortunately IBM only ships rpm packages for it's TSM client and only supports RHEL/SLES leaving every other distribution with "Best Effort support" and Debian ( and any non rpm based distribution ) out in the cold package wize [2].
* Note for Debian-based distributions (Debian and Ubuntu): The TSM Linux x86_64 client is made available in RPM package format. Third party tools can be used to convert the package to Debian format for installation. IBM Support will not accept calls related to package conversion or installation of converted packages.
If "Revisiting How We Put Together Linux Systems" comes widely accepted ( or something similar ) that might change as well and companies like IBM could provide a single installation package and thus provide the same level of support for all systemd based distributions regardless what they are called.
1. http://www-01.ibm.com/support/docview.wss?&uid=swg210...
Posted Nov 13, 2014 4:03 UTC (Thu)
by jonnor (guest, #76768)
[Link] (12 responses)
Posted Nov 13, 2014 4:10 UTC (Thu)
by jonnor (guest, #76768)
[Link]
Posted Nov 13, 2014 8:28 UTC (Thu)
by timtas (guest, #2815)
[Link] (9 responses)
Posted Nov 13, 2014 8:48 UTC (Thu)
by rvfh (guest, #31018)
[Link] (5 responses)
Common, grow up! A lot of us in this community are 40+ years old with at least 10 years of Linux use/dev behind us, and because we like systemd's features better you call us fanboys?
I installed systemd on my Raspberry Pis as a try and it turns out it just works, makes them slightly faster to boot, and make the service file for my daemon short and clean. FWIW I have also written the upstart service file so I could understand both systems.
This is not being a fan, this is being pragmatic.
Posted Nov 13, 2014 18:06 UTC (Thu)
by bronson (subscriber, #4806)
[Link] (4 responses)
Posted Nov 16, 2014 11:22 UTC (Sun)
by jonnor (guest, #76768)
[Link] (2 responses)
Posted Nov 17, 2014 12:37 UTC (Mon)
by peter-b (subscriber, #66996)
[Link]
Posted Nov 17, 2014 13:41 UTC (Mon)
by rvfh (guest, #31018)
[Link]
I also run the upgrades on that one to make sure things don't break before upgrading the rest :-)
Posted Nov 17, 2014 13:46 UTC (Mon)
by rvfh (guest, #31018)
[Link]
Seems I did not commit the upstart one but I can do if that's of interest to somebody (I'll have to test it first though...)
Also, I am not sure the sysvinit one is on par with the systemd one, as systemd restarts my daemon if it disappears for any reason...
Posted Nov 13, 2014 16:00 UTC (Thu)
by jonnor (guest, #76768)
[Link]
* Since free operating systems became prevalent at least.
Posted Nov 13, 2014 16:45 UTC (Thu)
by pgoetz (subscriber, #4931)
[Link] (1 responses)
Reading your comments gives the strong impression that you don't know very much about systemd. Lots of words, very little relevant content.
Posted Nov 13, 2014 18:13 UTC (Thu)
by bronson (subscriber, #4806)
[Link]
And often it was. :)
Posted Nov 13, 2014 8:40 UTC (Thu)
by Felix (subscriber, #36445)
[Link]
But I think we all should just calm down and let's see what happens. Debian developers will have their GR, numerous upstream developers will either rely on systemd functionality (or not) and many many distro packagers will spent their time as they see fit.
The systemd developers will continue to do their stuff as they are doing it now. Let the code speak for itself! I personally will try to abstain from any systemd debate for at least a couple of months and I guess in 2-3 years we'll know how everything played out.
Posted Nov 13, 2014 9:47 UTC (Thu)
by imitev (guest, #60045)
[Link] (3 responses)
wow.
IMO there's a little bias towards systemd from the editors on LWN, but how is it possible that disagreeing with an *opinion* article makes you revoke your subscription ? Corbet is not the only editor here, nor dictates you what to think/use, and systemd related articles are the minority.
I've been a linux user for as much time as you, fellow sysadmins/programers categorize me as "guru", so I arrogantly think I have a pretty good knowledge of linux as a whole: internals, development style, evolution/history, ... But unlike you I couldn't care less about the whole systemd debate, and I can't understand how people get so emotional about it. Just like any new stuff I'll have to learn how to use it and that's pretty much with it. I suppose I'm part of the silent majority but you may disagree.
Posted Nov 13, 2014 10:03 UTC (Thu)
by timtas (guest, #2815)
[Link] (2 responses)
Aside from that, systemd technically makes some decisions I strongly disagree with, but that alone would never make me so upset. I have disagreed with things before and then just didn't use them and never engaged in any emacs vs. vi or GPL vs BSD license flamewars.
Posted Nov 13, 2014 10:27 UTC (Thu)
by luya (subscriber, #50741)
[Link]
UNIX system virtually abandoned sysvint knowing a core part like init or specifically a system management have to be designed for their own kernels.
Posted Nov 13, 2014 19:53 UTC (Thu)
by rahvin (guest, #16953)
[Link]
Posted Nov 13, 2014 3:37 UTC (Thu)
by notninjaz (guest, #99725)
[Link] (2 responses)
People of different roles being able to work together, I think, is what is really at play here. Until the Debian GR was announced, the idea of consulting stakeholders outside of a relatively small group of insiders appears to have been avoided.
I don't see it as much of a long-term technical matter for server use. As others have pointed out, I would look forward to being being able to log directly to syslog. It sure would be nice to have the default for viewing logs changed to show the entire line instead of abbreviating with "...", too.
In my experience with SMF, though, it doesn't seem to have gotten much reaction either way from users of Solaris. The main difference from the sysadmin perspective being that it makes boot-time troubleshooting a little weirder.
Otherwise, I haven't encountered an SMF manifest being supplied by a piece of software that wasn't written by either Sun or Veritas. As with the current round of systemd-enabled Linux distros, /etc/init.d scripts still work. Even nine years after the release of Solaris 10, they are still what I have seen in standard use on that platform by 3rd party applications and sysadmins. Of course, both generally had to maintain (non-SMF) Solaris 9 configurations for much of that time, just as enterprise Linux server admins will have to maintain older enterprise Linux releases for a number of years.
On the topic of new functionality for Linux, snapper/btrfs looks really nice. Something like LiveUpgrade is what I had been missing after migrating servers from Solaris. :-)
Posted Nov 13, 2014 11:16 UTC (Thu)
by mezcalero (subscriber, #45103)
[Link] (1 responses)
It already has been changed in more recent versions of systemd.
Lennart
Posted Nov 13, 2014 20:20 UTC (Thu)
by notninjaz (guest, #99725)
[Link]
Btw, thanks to whomever came up with the name rsyslog.service. I really like it much better than svc:/system/system-log
Posted Nov 13, 2014 4:08 UTC (Thu)
by vkoul (subscriber, #75277)
[Link]
Posted Nov 13, 2014 4:09 UTC (Thu)
by neilbrown (subscriber, #359)
[Link] (25 responses)
To me, this seems to miss the point. One could equally say "There is plenty of experience by now to show that Intel-based systems still work when MS-Windows is installed".
It isn't about whether it works, it is about what it is like to work with.
> But even if systemd turns out to be a wrong turn in the end, the current level of anxiety and heat is not called for.
This, on the other hand, is spot on. All the heat makes is very hard to address the other issues coherently.
Posted Nov 13, 2014 8:56 UTC (Thu)
by rvfh (guest, #31018)
[Link] (2 responses)
OK, but most user don't work with the init system, right? It's just a few developers that are affected, and far less people than are participating in discussions, right?
> So some important issues are complexity, transparency, familiarity, learning curves, etc.
OK, but as was said before, the learning curve for the old init or even upstart, when starting from scratch (not your case I suppose) is less steep with systemd... At least that's my personal experience after recently writing the service file for my [very simple] daemon for sysvinit, upstart and systemd.
I would go as far as to say that your voice would probably be one of the most useful, but maybe it gets buried in the noise...
Note: I used to maintain a Slackware-based distribution for a private company about 10 years ago.
Posted Nov 14, 2014 22:39 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
I wonder if that is true. I don't have any data - do you?
It isn't just developers that might need to work with an init system, it is also sysadmins, and many hobbyists serve as their own sysadmin.
You've probably heard the quote:
With systemd, lots of simple things really are simple. It has very focussed domain-specific "knowledge" and does many of the things that you often want very easily. This makes the initial learning curve very gentle as you suggest.
But simple things aren't really all that interesting - of course those are easy. The complex things provide a much better test for what a system is like to work with. That is where the learning curve gets interesting.
With init.d scripts, most people will have been exposed to shell programming already so there is an opportunity for skills transfer. shell is undoubtedly a horrible language, but it is a powerful and flexible language and you can usually achieve what you need to. It is easy to add tracing (echo, set -x), easy to add special cases. Possible to address ad-hoc problems with ad-hoc solutions.
systemd is much better in terms of core functionality and over-all structure. But is it not a complete language. It seems to deliberately avoid being a programming language in the normal sense (witness the odd syntax for conditionals). So if you want to do "normal" things, it is very easy. But as you deviate from "normal" the learning curve gets very steep. When I do, I start to feel like I am fighting against it instead of working with it.
I've had two non-normal issues with systemd recently. They *should* be easy - but I didn't find them so. In one case I think I cobbled together a solution, but I don't really like it. Maybe the fact that the "obvious" approach didn't work is just a bug. For some reason, I just don't feel like trying to find out if it is.
Posted Nov 21, 2014 17:56 UTC (Fri)
by Wol (subscriber, #4433)
[Link]
> OK, but most user don't work with the init system, right? It's just a few developers that are affected, and far less people than are participating in discussions, right?
Except you're making a major mistake that far too many IT workers make. You're assuming that systems have a sys-admin.
How many systems are like mine? I have a home network - two gentoo PCs, a Windows 7 laptop, a bunch of Android phones ... yep, I may be a sys-admin, but I'm a sys-admin merely because I'm a user and I'm the only person to admin my systems.
I want an init system that is simple to use, and SysVInit most certainly is NOT. Currently (while I may not be able to blame it on the init system, I can certainly blame it on the lack of time to trouble-shoot) I have a system with broken raid and nfs. I don't want to add init weirdos to the rest of my boot-time cussing ...
Cheers,
Posted Nov 13, 2014 9:35 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (21 responses)
In that department systemd runs rings around the traditional setup (possibly not as far as “familiarity” is concerned but then again it hasn't been around that long). Remember that the traditional setup consists of components from diverse sources that have been cobbled together with lots of duct-tape but no overarching design and little interaction. Between init, the init scripts, /etc/fstab, inetd/xinetd, cron, and friends, no two configuration file formats are the same, and the components don't talk to one another except on the most basic and accidental level. (Even within sysvinit the components don't really talk to one another; the PID 1 process doesn't know or care whether service daemons are running or not, so you need more components and more duct-tape to retro-fit service management.) As far as complexity is concerned, the bulk of the configuration files in a sysvinit-based system are shell scripts. How much more complex can you get? Especially if 90% of every init script is basically boiler plate (but possibly with subtle and undocumented tweaks) but that boiler plate is different from one distribution to the next.
It turns out that systemd is really rather easier to work with than the traditional setup simply because it is much more consistent with itself and has been designed with maintainability in mind. For example, with systemd there is a clean separation between default configurations that the distribution provides and local changes. This makes package upgrades a lot easier since you don't need to go in and manually reconcile your own changes to a configuration file with the changes to the same file that the distro made in the meantime.
It would also help if many of the systemd detractors would stop to learn at least a little bit about the ideas behind systemd (and their implementation). Much of the systemd “criticism” is really not based on actual systemd but on some straw-man version postulated by detractors. Many people who were initially opposed to systemd found out more about it and then rather liked what they saw.
Posted Nov 13, 2014 18:10 UTC (Thu)
by skorgu (subscriber, #39558)
[Link] (3 responses)
I decided NetworkManager was the Future, made my peace with the capitalization choices, read some docs and tried to use it. No dice, as far as I could tell the networkmanager service started but NetworkManager-wait-online.service didn't which caused kdump to determine there was no network which prevented the multi-user.target from being reached.
Ok. Let's look at the wait-online.service.
ExecStart=/usr/bin/nm-online -q --timeout=30
Great! I run nm-online and it hangs for 30 seconds before failing. What criteria is it using to check that the network is up? --help is useless, "nmcli networking connectivity" says "full" and I have no idea where to look next. strace and looking at the code upstream led me to the conclusion that it's doing something via dbus but to understand what exactly would require me to understand a good chunk of the NetworkManager/dbus codebase.
Fine. Let's try the init script way. Hm, doesn't work, looking at the logs (journalctl is good, why isn't -l the default though?) shows me that udev was renaming eth0 -> em1 at the same time as the network was trying to bring up em1, classic race condition. I wonder if there's a delay I can add?
grep -i delay /etc/sysconfig/network-scripts/*
Bam, add LINKDELAY=10 to the ifcfg-em1 file and move on with my life.
Is the problem here systemd? No, it's clear that this specific case was networkmanager's fault and systemd was faithfully executing what it was told to. However the /model/ of reducing complexity by tighter coupling, dbus and C instead of files and shell scripts, monolithic entities instead of loose components made this much harder to debug.
There's no reason to foam at the mouth and cancel my LWN subscription, we're all adults here and should be able to say "hey this isn't great" without going off the rails. I have no doubt that in a few years these bugs will have tripped up enough people and been fixed, better tools will exist or simply be more widely known and it'll be fine, probably better than the old world.
However we *are* all adults here and shouldn't pretend that systemd is just PID 1 and not also a central and highly visible component of a fundamental change in how linux systems are built and operated or that there aren't tradeoffs in discoverability and debugability being made.
Posted Nov 13, 2014 19:33 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Posted Nov 14, 2014 18:59 UTC (Fri)
by skorgu (subscriber, #39558)
[Link] (1 responses)
Though I'm not sure it would have actually helped the NetworkManager case since the network-online target /never/ came up, even when the system manifestly had connectivity (and even nmcli agreed).
Posted Nov 14, 2014 19:03 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Also, can you file a bug for this? It's clearly an issue that should be fixed.
Posted Nov 14, 2014 6:07 UTC (Fri)
by ploxiln (subscriber, #58395)
[Link]
I was very excited when I read Lennart's first blog post about systemd, years ago, it was just about the socket-activation model. That's pretty cool.
But then you thrown in excessive use of cgroups, journald, logind (and the discontinuing of consolekit), udev in the same repo! dbus! tempfiles! cron! block devices, filesystems! all this stuff really doesn't need to be coupled to init, it really really doesn't. Setups in arch linux or gentoo or slackware or plain debian were super simple in all of these areas. Yeah it sucked that services weren't properly managed, processes not properly tracked and restarted, but that was really it.
Now, if you want to use arch linux or fedora or more and more other distros, you have to do a shitload of work to avoid systemd's huge web of stuff.
Systemd used to have a config option to not use some cgroup controllers on the cgroups it created, like the memory controller. I used that option. It went away. Now I have to compile a custom kernel with those controllers disabled.
Systemd failed to shutdown (shutdown!) multiple times for me over the past couple years (I've been using arch linux, they switched quite a while ago).
Worst of all, for me, the output of "systemctl --all" is ridiculous, like 300 lines, of which maybe 20 are interesting. All sorts of stuff is enabled by default, there are services without actual unit files in the system, loads of virtual filesystems I haven't used and probably won't use anytime soon are mounted, and seriously cluttering up /proc/mounts, it's more than twice as long and twice as wide as it was before. I mask loads of stuff when I set up a new system. I have to unmount some stuff in a late-running rc.local because some stuff isn't even a virtual "unit" or whatever.
This is the ubuntu/windows model that I used (other) linux distros to get away from. Loads of crap by default, then I have to clean it up, if I want to end up with a system that I understand and fully control. And now all this systemd stuff comes together, I can't trim or simplify pieces.
I've used initscripts, daemontools, systemd, upstart, both personally and professionally. I can deal with it. But I don't like it being suggested that I'm backwards and closed-minded for not being happy about it.
Posted Nov 14, 2014 23:36 UTC (Fri)
by neilbrown (subscriber, #359)
[Link] (15 responses)
There are different sorts of complexity, or at least different locations for it.
You have have a very simple engine with very complex configuration, and you can have a very complex engine with very simple configuration.
sysvinit leans towards the first, systemd leans towards the second.
My preferences is generally towards having a simple engine (which is probably why I like coding in C). It is certainly appropriate to add functionality to a simple engine, but it is best if it can be kept simple (well-defined, uniform, orthogonal)
systemd is excellent in terms of functionally. I'm less convinced that it has maintained internal simplicity.
Posted Nov 15, 2014 1:24 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (7 responses)
“Simple” is generally a good idea, but there is such a thing as “too simple”. The sysvinit “engine” is really too simple for what it needs to do, which is why it is not particularly good at what it is doing, so people need to tack on important functionality by way of shell scripts. Note: If your engine uses a hundred shell scripts which are all substantially the same, this might tell you that perhaps some functionality could be usefully added to your engine such that your configuration does not need to be quite that complex. Also for the longest time even the complex configuration of sysvinit needed considerable ad-hoc human expertise to manage; in the history of sysvinit over the last 30 years or so, the automatic management of dependencies between services hasn't been around all that long, and that is one area where a little more complexity in the engine would really have been quite helpful.
Also, if one considers not just sysvinit but the whole “basic plumbing” that systemd replaces (including such beauties as the distribution-specific boot scripts or inetd/xinetd), then any claim of simplicity goes right out the window. The individual components on their own may be pretty simple but their totality isn't (and distribution-specific design choices figure into it, too, so if you have figured out how distribution X does its thing, that may or may not apply to distribution Y), and in spite of all the complexity they don't really form a coherent system that works well together. Systemd is a lot more advanced in that respect.
Which is not to say that systemd is the epitome of internal simplicity – but the systemd developers do care about things like code reuse, and facts like that all the configuration files use the same format (and presumably share the same parser) do suggest that systemd isn't the most complex piece of software in existence, either. It is probably a lot simpler internally than, say, the Linux kernel, or for that matter the sum total of sysvinit and friends.
Posted Nov 15, 2014 1:44 UTC (Sat)
by dlang (guest, #313)
[Link] (6 responses)
Posted Nov 15, 2014 5:42 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And if you do try to add them, then scripts become even more incomprehensible. Witness, the Gentoo's BIND initscript as an example: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/n...
Posted Nov 15, 2014 19:04 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (4 responses)
Possibly. On my Debian system, many of the shell scripts in question still are more than 100 lines long (sometimes considerably so), still contain mostly boilerplate, and still don't do various things one would reasonably wish to be done when a service is started. There are ways of reducing the amount of repetition but they do not appear to have caught on in most mainstream Linux distributions. I for one am looking forward to these scripts being replaced by systemd unit files that for the most part will fit on one screen.
Then there is the fact that these shell scripts are impossible to change and adapt to local preferences without running the risk of having to do it over and over again whenever the distribution issues an updated version, or having to prevent the distribution from installing and activating its version of the script in addition to the one the local administrator provided under a different name. Systemd solves this in a much more elegant manner by cleanly separating the distribution-provided default from any local changes.
Posted Nov 16, 2014 21:39 UTC (Sun)
by rgmoore (✭ supporter ✭, #75)
[Link] (3 responses)
There's also the general point that writing configuration files as programs in a Turing-complete programming language is a gross violation of separation of policy from mechanism. I would probably lump it in with things that count as design anti-patterns.
Posted Nov 17, 2014 1:46 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (2 responses)
Is it?
TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.
If your configuration language supports substitution or conditionals - or maybe even just sequencing - then you probably want to start looking at a real language, because iteration probably isn't far away.
The line between "policy" and "implementation" is very real, but it is in your mind, not in the computer. And that is where it should be enforced.
Posted Nov 18, 2014 0:07 UTC (Tue)
by nix (subscriber, #2304)
[Link] (1 responses)
Are they all gross violations?
Posted Nov 18, 2014 2:40 UTC (Tue)
by zlynx (guest, #2285)
[Link]
In best practice JSON is non-executable.
Posted Nov 15, 2014 9:07 UTC (Sat)
by fandingo (guest, #67019)
[Link] (6 responses)
Your last comment further up talks about two distinct problems that you recently experienced. Why did you omit the details? To be honest, this sort of thing is used by systemd detractors all the time. The (unintentional) subterfuge masks either their lack of knowledge or fraudulent purpose. I'm not saying that you're arguing in bad faith, but if you're going to detract from something, it's only reasonable to provide enough details so we know what you're talking about.
Continuing about this comment, I assume that your metaphor is about mechanical engines. Are you really suggesting that more primitive engines are better? Should we all desire steam engines despite the fact that would make air travel impossible? Sure it's more straightforward to understand "dump the water in there and shove the coal into the fire," but to continue the metaphor the drawbacks are preposterous. Again I hope I'm getting the metaphor right, but it seems like the piston-driven airplane and jet engines are perfect corollaries to sysV and systemd. The engineering level of a piston engine is quite a bit lower and has far lower tolerances. The jet engine, on the other hand, is both far, far more powerful and efficient, and it is also substantially more reliable and requires practically no maintenance.
But anyways, init systems are not engines. It's pretty useless to talk about technical things in metaphors. We can shoehorn in whatever exemplary or derogatory metaphor we want without actually talking about anything.
Posted Nov 15, 2014 12:02 UTC (Sat)
by viro (subscriber, #7872)
[Link] (1 responses)
Off-topic, but... Jet engines getting "practically no maintenance" are the stuff of which the nightmares are made... Ever seen the effects of fatigue crack in the wrong place that has grown past the critical length due to inadequate inspections? Gets _really_ unpleasant when e.g. the shaft fails, separating compressor from the turbine and leaving the latter with no load...
There's a whole lot of failure modes in those puppies and airlines trying to save money by cutting down on maintenance ended up with serious trouble after a while. Including a lot of dead bodies...
Posted Nov 15, 2014 12:56 UTC (Sat)
by pizza (subscriber, #46)
[Link]
There are far fewer failure modes in Jet engines -- due to many fewer moving parts and much much much much lower vibration, thanks to the lack of reciprocating mass. Consequently, they require considerably less ongoing maintenance than piston engines.
(But only a fool or airline execs would consider them maintenance-free)
OT, yes...
Posted Nov 17, 2014 0:57 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (1 responses)
I didn't think I was. I thought "engine" had a fairly well defined meaning in the software world - it is the bit on the inside that does all the work. It might be a game engine or search engine and you suggest, or a physics engine or an inference engine or a database engine or... whatever is required.
You can often think of a software system as having an engine and an interface.
No, I don't think a more primitive engine is better. I think having core functionality that meets the need is very important and systemd has a lot of that - which is good. I want a sophisticated engine, but I don't want a complicated engine.
I think 'git' provides a valuable contrast. It is in some ways a new and different thing, much like systemd. It uses some well established ideas and combines and presents them in a way that adds a lot of value. And there are people who seem to hate git too - though not as much as systemd it seems.
A key part of the design of git is that core functionality (the so-called plumbing) is directly available if you want to use it. On top of this more friendly interfaces are provided. Originally this was just shell scripts combining the core parts, though I think that over time more and more is being converted to C. This is sophisticated but not too complicated. Core functionality is well defined and directly accessible. This depends on having a rich language for combining the components: shell.
systemd has a lot of valuable core functionality too. But it is not always exposed in a way that provides direct access. The configuration language is extremely simplistic. Quite a few of the directives provided are composites of core functionality - so they set an agenda ("set combinations apply") rather than provide raw functionality.
To be more specific, there are mechanisms for interactions between different units. In upstart (if I remember correctly), such interactions involve "signals" and I think there is full low-level control of signals.
"Requisite" is a requirement with no signal
There is more subtlety to the interactions - there is a "reload" signal and maybe a "restart" signal, though that might have requirement implications. There are inverse requirements (conflicts).
But the configuration language doesn't provide access to the core features - I'm not even entirely sure what all the core features are precisely. It just provides a number of directives that pre-combine these features in ways that seem to be useful.
So I do want a sophisticated engine - I want socket activation and process group monitoring and timeouts and auto-mounts and device triggers etc etc. I think all that is great stuff.
Things become "complicated" when you don't have direct access and so need to work around limitations and do things in no-obvious ways just to get access to the bits you want.
(I'll reply about the examples separately).
Posted Nov 17, 2014 18:58 UTC (Mon)
by cebewee (guest, #94775)
[Link]
Posted Nov 17, 2014 1:33 UTC (Mon)
by neilbrown (subscriber, #359)
[Link] (1 responses)
Sometimes too much detail can distract people from thinking about the point you are trying to make. So including it at the wrong time might not help. But I'm happy to share.
These are two issues that I recently hit. They are *not* examples which try to say "systemd is horrible and doomed can never work", they are meant as examples that say "systemd does have some real complexity, does have steep regions on the learning curve, isn't entirely transparent". It could be that they are problems for me only because I haven't learned enough yet - which just points to the learning-curve issue.
Firstly, I really like that using systemd makes it a lot easier for upstream packages to provide the start-up config file: providing init scripts in upstream was always problematic.
systemd *has* alias functionality using syslinks. If you create "food.service" as a link to "foo-daemon.service" then you can "start" and "stop" and "reload" and request "status" using either name. Which is great.
So I created 'food.service' as a separate service with (hopefully) enough "Requires" and "PartOf" directives pointing at "foo-daemon.service" that systemd will make sure they are either both running or neither are.
Secondly, I had some fun with dracut (not that dracut is much fun ... I find it particularly difficult even remembering what it is called!! Whose idea was it to name key system software after towns in New England? And will they please stop it!?!)
Dracut uses systemd (which seems appropriate) and has a bunch of shell scripts which are run by a queue manager (I can't decide if there is something ironic about that.... can systemd not manage the queue? should it?).
Anyway in a particular circumstance an md/raid array will *not* be assembled when all the devices have appeared, and this is correct. There needs to be a timeout to give up waiting for more devices - then the array is assembled. If that array contains an LVM volume and the LVM volume contains the root filesystem, then dracut needs to:
all of which it does correctly. During this time, systemd is waiting for the root device to appear.
If I increase DefaultTimeoutStartSec to 120 .. it still doesn't work. 130? No. 300? Yes. Now it works.
I'm sure there is a good explanation for this. It might even make sense. But "simple" "transparent" "gentle learning curve" aren't the words I'm focussing on just now.
Maybe I need to enable some tracing somewhere.... old habits of adding "echo" or "printk" as just going to have to change...
Posted Mar 13, 2015 0:37 UTC (Fri)
by neilbrown (subscriber, #359)
[Link]
When you "systemctl daemon-reload", systemd will remove everything from /run/systemd/generator and then re-run all the generators. As rootfs-generator.sh only created files in that directory the first time it is run, a subsequent 'systemctl daemon-reload' will revert the effect of that generator.
The key effect of the generator is to disable systemd timeouts on the device which holds the root filesystem - as dracut has its own timeout mechanism. So a 'daemon-reload' will re-instate the default timeout.
When dracut does timeout waiting for the md array to assemble, and forces the assembly of all degraded md array, it also runs "daemon-reload" (as part of giving up on resume-from-disk). This will cause systemd to give up on the root device immediately, typically a second or so before it is actually ready.
Does that make sense? Anyway, the primary problem was not a problem with systemd ... except...
The real goal of dracut here is to generally disable the systemd timeouts which wait for devices. Lots of systemd is configurable at runtime using systemctl, but this thing isn't. It can only be configured in /etc/systemd/system.conf before systemd starts. 'daemon-reload' doesn't reload system.conf.
So dracut has this complex (and buggy) code to over-ride timeouts that systemd doesn't let it configure in a sensible fashion. So maybe systemd is partly to blame, after all...
Posted Nov 13, 2014 9:47 UTC (Thu)
by tialaramex (subscriber, #21167)
[Link] (5 responses)
Some of the trolls will burn a paid account on this particular topic, which can only help to keep LWN's lights on. And once the fuss has died down some of them might come back and create real - unsullied by froth flecked rants - accounts, and pay for those too.
A few people might use real accounts to troll, and stain their reputation accordingly. In some cases they might even learn a useful lesson that way.
The only downside is that some regulars might get dragged in, become demoralised and quit LWN, or the community itself, as we've perhaps begun to see happen for Debian. If you believe this might happen to you, look away now.
Posted Nov 13, 2014 10:12 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (1 responses)
It's subscriber-only until someone uses the "free link" functionality, or one week passes, whichever happens first. I already saw one "guest" upthread.
And I'm not opposed to that; Jon's plea for peace on this holy war should be spread far and wide.
Posted Nov 17, 2014 22:06 UTC (Mon)
by eean (subscriber, #50420)
[Link]
It didn't come soon enough. :/
Posted Nov 20, 2014 2:59 UTC (Thu)
by ksandstr (guest, #60862)
[Link] (2 responses)
In the systemd discussion we've consistently seen the pro-systemd side undertake extraordinary contortions to categorically not engage the systemd-critical crowd. From an outside perspective it's as though systemd was couched in iron-clad dogma and that all arguments requiring analysis outside that dogma cause a significant emotional response in systemd apologists, giving rise to calls of troll and predictions of administrative exclusion from discourse. As you yourself do right here with your talk about "burning a paid account", as though LWN were some ban-happy crypto-authoritarian Internet septic tank.
It is my experience that when one side completely fails to engage in even the most civilized forms of debate then that side is knowingly in the wrong, but figures that by digging in and holding on they'll prevail by inertia. In the systemd civil war this side has always been the pro-systemd one from the top down; for a simple and clear example one need only look at Mr. Pöttering's "systemd myths" posting where he can only answer his own strawmen by side-stepping his own caricaturelike reformulations of their arguments! Further along the same pattern we have Pöttering's G+ post in the "I'm a victim of white middle-class heterosexual men" theme, aiming to stop critique in its cradle with the "victim-blaming" canard if not by design then certainly by effect.
This argument, and many others, could be comprehensively done with and gone by next week if the anti-systemd concerns were addressed lucidly and in good faith. It's been this way for years now. It follows that either the rising volume and virulence of the anti-systemd crowd isn't leaving as many jimmies rustled as the toys-from-pram episodes of various Debian luminaries would suggest (given how technical arguments are quicker to write for one in the know than e.g. Russ Alberry's recent "fraught" tirade), or that varyingly theatrical public complaints about it are seen as the way to go instead. The former casts those Debian developers as engaging in synchronized dishonesty, or acting on outside orders (a mild conspiracy theory right there); but the latter is merely consistent with the continuing theme of the systemd developers' willful failure to engage their critics.
In conclusion, the systemd project doesn't address the critique leveled at it because it is unable to do so. Their reasoning is only consistent with unstated (and therefore unexplored) dogma, which in its obscurity cannot be justifiable by anything besides tribality, faith, and other forms of irrationality. Combined with the numerous displays of authoritarian aggression (outlined in my second paragraph) in this thread and many others, seemingly exclusively from the pro-systemd side, the evidence strongly suggests that an orchestrated take-over of the GNU/Linux userspace is afoot.
Posted Nov 20, 2014 14:04 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Posted Nov 20, 2014 14:05 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 13, 2014 10:38 UTC (Thu)
by cesarb (subscriber, #6266)
[Link] (8 responses)
I'm not as knowledgeable on upstart (I never quite got the hang of it), but from what I have read, the original systemd developers looked at upstart, saw a few problems with it, and decided to go in a different direction. But they didn't start from scratch; they had in mind where upstart went right, and where upstart went wrong.
From what I recall, the same thing happened with devfs: it opened up an unexplored field, and by looking at where it worked well and where it didn't, the udev developers could make udev better than what it would have been otherwise.
But I also believe that what we have now in systemd is not the "Linux init system"'s final form. I believe there will be a further init system (perhaps a newer release of systemd, perhaps a new init system) which will fix systemd's shortcomings, while keeping its strenghts. But that will only be possible because the current systemd is there as an example, showing the new system's developers what to do and what to avoid.
In particular, I believe there will someday be a "systemd lite" which keeps only the bare minimum (cgroups and process supervision), for the "small embedded system" use case (which tries to cram as much as possible in 4 megabytes of flash).
Posted Nov 13, 2014 11:46 UTC (Thu)
by luya (subscriber, #50741)
[Link]
GENEVI, Angstrom and other embedded companies already applied similar method above. Also take a look at:
Posted Nov 13, 2014 12:10 UTC (Thu)
by csamuel (✭ supporter ✭, #2624)
[Link] (1 responses)
http://uselessd.darknedgy.net/
"a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism".
Posted Nov 13, 2014 22:30 UTC (Thu)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 13, 2014 16:41 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link] (2 responses)
Also, and IMO critically, they didn't restrict their inspirations to other Linux init systems. They also looked at newer inits from other Unix-like systems, most notably launchd. Far from being some experimental, NIH project, systemd tried hard to copy ideas that had been shown to work on other systems.
Posted Nov 13, 2014 17:34 UTC (Thu)
by johannbg (guest, #65743)
[Link] (1 responses)
Solaris devs have done great things in the past then came oracle so why not learn from their effort and history copy what other OS have done well and try to improve and or integrate that directly into the core/baseOS stack of Linux?
Posted Nov 13, 2014 22:26 UTC (Thu)
by eean (subscriber, #50420)
[Link]
Posted Nov 21, 2014 10:16 UTC (Fri)
by horsethief (guest, #99889)
[Link] (1 responses)
The problem, is that in order to do that, we'll have to scrap everything and re-write userspace from scratch (hopefully with a component-based architecture this time) and then re-implement the things that we can improve upon. If systemd had just taken the component-based architecture from the get-go, this whole war/dispute would have never happened.
Posted Nov 21, 2014 12:34 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Nov 13, 2014 12:01 UTC (Thu)
by dps (guest, #5725)
[Link] (5 responses)
The main beef I have with systemd is that it is very hard to fix things which are not working than it was with older and simpler solutions. I also don't like the dependencies of dbus, udev and other things which are a really bad idea on paranoid firewall systems.
My firewall has neither dbus nor udev, does not support kernel modules and a read only separate /usr partition. The fact that systemd can't cope with that suggests to systemd stuffs too much into init.
Posted Nov 13, 2014 14:10 UTC (Thu)
by anselm (subscriber, #2796)
[Link] (2 responses)
Paranoid? If the init process on your firewall does anything more than set up networking and iptables and then exit, then you're not paranoid enough. Who needs userspace processes on a firewall at all when a properly configured kernel on its own will do everything that's necessary?
Posted Nov 13, 2014 14:49 UTC (Thu)
by JGR (subscriber, #93631)
[Link]
Posted Nov 13, 2014 20:15 UTC (Thu)
by dlang (guest, #313)
[Link]
Posted Nov 13, 2014 15:35 UTC (Thu)
by jonnor (guest, #76768)
[Link] (1 responses)
Posted Nov 13, 2014 20:17 UTC (Thu)
by dlang (guest, #313)
[Link]
It's not as if the shell scripts are being provided by the attacker or handling any data provided by the attacker.
Posted Nov 13, 2014 15:20 UTC (Thu)
by p2290 (subscriber, #39950)
[Link]
Posted Nov 13, 2014 15:39 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (15 responses)
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Or you can complain that you don't like any of these choices, and put the responsibility onto someone else for the situation.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
[2] http://meta.stackexchange.com/questions/66377/what-is-the...
[3] http://www.catb.org/esr/faqs/smart-questions.html#goal
The Grumpy Editor's guide to surviving the systemd debate
> that works correctly and doesn't have "odd corner cases" that will be
> fixed somewhere in the future.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
And this is a community. Not a business, you cannot dismiss users or people who contribute to other parts of the Linux ecosystem.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
remember some other article or one of the other comments. So
I'll help you. You want to say "slackware or gentoo". I have
been using Debian for about 15 years now, sometimes contributing
patches and packages under the sponsor system. Switching to
another distro now, with my energy drained by age and time
depleted by $DAYJOB, is just about impossible. So, in fact, no
choice.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
to see a trend (and not just a statistical trend but a trend in the
opinions of people I talk to). My fear of systemd and projects
associated with it is somewhat similar. The similar aspects include the
fact that nominally I can influence the outcome in both cases (by voting
or contributing code), yet my influence will make no difference in the
face of the trend, with a 99.999% probability.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
I didn't think there were killfiles on LWN.
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
well, if it's used by things outside of udev, then it's an "external API", and since LP is calling out that Gentoo is going to have to change things as a result, it sure seems like things other than udev are affected
On the other hand, if you ignore the claims about systemd being modular and consider udev just an internal component of systemd, and users have to go all-or-nothing with systemd, then it could be an "internal API" of systemd.
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
Nobody expects the spanish plonk squad!
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:
The Grumpy Editor's guide to surviving the systemd debate
Now, our strategy to rotate-on-corruption is the safest thing we can do, as we make sure that the internal corruption is frozen in time, and not attempted to be "fixed" by a tool, that might end up making things worse. After all, in the case the often-run writing code really fucks something up, then it is not necessarily a good idea to try to make it better by running a tool on it that tries to fix it up again, a tool that is necessarily a lot more complex, and also less tested.
I can't believe anyone thinks this argument has any merit at all. You could use the same words to argue that filesystems (a complex mass of binary data frequently written to which can suffer corruption) should never be repaired, because you can never get a fsck that always repairs all problems and never makes anything worse. Instead, we consider a filesystem sans fsck to be substandard.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
File systems such as ext4 have an fsck tool since they don't have the luxury to just rotate the fs away and fix the structure on read: they have to use the same file system for all future writes, and they thus need to try hard to make the existing data workable again.
This is, of course, a fallacious argument too. File systems such as ext4 have a fsck tool because it would be an appalling implementation which said, oh, the FS is corrupted, we'll hit you with an empty one and let you get at the old one with some special commands! Which is more-or-less what systemd's journal does.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
[2] http://cgit.freedesktop.org/systemd/systemd/plain/src/jou...
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Custom binary log format.
Lack of log shipping.
Log corruption.
The requirement to run multiple log daemons.
Web access to log files.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Wol
The Grumpy Editor's guide to surviving the systemd debate
Then there's the matter of actually writing the data. Step one is to write a transaction log entry. Step two, hash the key and append the record to the appropriate block. Step three, is the table overflowing, and if so expand it, logging that as you do so. Step four, close off the transaction log and commit.
Oh yes they are. Non-corruption under conditions of power loss and -ENOSPC is routinely tested in any half-competent database system (hell, even sqlite. Perhaps especially sqlite, their test harness is awesome).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Wol
The Grumpy Editor's guide to surviving the systemd debate
Wol
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Systemd is not portable to other OSs so it loses synergy.
Making it harder for you and me to innovate is very bad.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
And that perfectly describes DBUS.
And DBUS has multiple independent implementations. I have my own small version in pure Rust, for example.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
MikeeUSA is a notorious and blatant troll, and I wouldn't take any of his positions except the whole "fulminating misogynistic racism" bit as being sincerely held.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
* systemd-journald
* systemd-logind
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
but the whole fuss was exactly because DD decided to make a package only work with systemd.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
> use systemd-logind rather than the obsolete and unmaintained ConsoleKit.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
http://lists.freedesktop.org/archives/lightdm/2014-Novemb...
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The organization of the systemd project, as a cross-distro, cross-company and cross-component collaboration is probably a bit of a reaction to that.
Maybe this is not the right approach, time will show. But there is no evidence that I have seen that supports that being intrusive is a goal.
The Grumpy Editor's guide to surviving the systemd debate
115
then
. /etc/init.d/functions <-- needless deviation between distro's
...
elif [ -f /etc/SuSE-release ]
then
. /etc/rc.status <--- needless deviation between distro's
...
echo "This distribution is not supported"
exit 2
fi
....
13
Description=IBM Tivoli Storage Manager Client
Documentation=http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1....
After=network.target
Type=forking
GuessMainPID=no
ExecStart=/usr/bin/dsmcad
Restart=on-failure
WantedBy=multi-user.target
2. http://www-01.ibm.com/support/docview.wss?uid=swg21417165...
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
I was actually talking about the intrusiveness of systemd and in that respect Linux generally alwas played along nicely with the unix ecosystem: it just does what a kernel is supposed to do and nothing else. And kernels naturally have to be a bit platform dependend on the inside, as they talk to hardware, you know. Yes, the internal abi for drivers is unstable, but the API of a kernel is called syscalls and while Linux has added a few over time (we're talking about more than 20 years here), it always made life easy for software developers to support the standard ones up until now. And believe me, that was sometimes quite a fight, but Linux always stuck to the principle: once an api has been in use by software, it is a regression to change it and a no-go. Now that's hardly comparable to systemd's approach of apis, systemd for instance just broke rtkit because Lennart decided to throw something out and the response is not: sorry, I put it back in, but it is of course: oh, we might just integrate rtkit into systemd as well.
And about the 10 mio lines of code: a large part of it is drivers for the tons and tons of sometimes buggy devices Linux supports, by working around their bugs so users like you and me can run Linux on all sorts of hardware. Now, if Lennart would have written a kernel, it would have of course never supported buggy hardware, which probably means it had supported scsi disks from two vendors, no ide, because it's obsolete shit anyways, one graphic card, one soundcard and two nics. Like Apple does. But there people that chose Linux, because it is not like Apple, you know.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
In general I'd recommend not installing the package which replaces /sbin/init until working with init=/bin/systemd has been confirmed. Its just good practice.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Example of SysVinit and SystemD configs
* hnet is the sysvinit script
* hnet.service is the systemd service file
The Grumpy Editor's guide to surviving the systemd debate
The only major difference I can see in terms of "intrusiveness" is that the Linux kernel has always* been there and worked this way, whereas systemd is a change to how things were currently done in the base system plumbing.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Believe me, I'd like to join the silent majority and stop caring about all that systemd stuff, and I really often ask myself why I also get so emotional about this stuff. But, as there are a lot of people like me, I asked myself, why exactly this debate about an init system gets so heated. And my response was the result of my soul-searching, the invasiveness and the betrayal of Linux's roots by systemd (interchangeability, portability) is what gets me so upset.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
But, as there are a lot of people like me, I asked myself, why exactly this debate about an init system gets so heated. And my response was the result of my soul-searching, the invasiveness and the betrayal of Linux's roots by systemd (interchangeability, portability) is what gets me so upset.
IMO there aren't that many people opposed to systemd. The ones that are opposed are highly vocal and tend to continually repeat the same arguments even in the face of ample contrary evidence. My experience discussing it with the ones that remained civil is that very very few have actually used systemd and the vast majority of the hate for systemd is hatred of Pottering and anything he's involved with, not particularly systemd the software. When individual features of systemd are discussed many approve and think it's a good idea up until the point where you involve the name systemd.
The vast majority of Linux users are like the person you replied to. Which is ambivalent about systemd. I'm in that camp and thought Jon's article was highly appropriate, after all it is JUST an init system. Those of us that have experienced a sysv "breakage" have horror stories to tell and they are common enough that a simple google search for "sysv problem" has a quarter million hits. With sysv being the standard by which to judge it would be difficult to be worse IMO.From what I've read systemd encompasses many features I would have given an arm and leg for when I've had sysv problems. And it accomplishes this while providing new features that are highly desirable that people have been trying to implement for 20 years.
Like most people 40+ I don't particularly like change that requires me to relearn how to do something. I'm skeptical of big changes and the impact they will make on what I already know how to do. But I also trust the people that have been building the distributions and the kernel. They make mistakes but eventually the ship will be righted when the mistakes become apparent. By all appearances systemd has very good support within the community of developers that encompass the kernel and distributions. If I don't like systemd when I eventually end up deploying it (probably with jessie providing Ian doesn't destroy Debian with his crusade) nothing will stop me from moving to another distribution that doesn't use it and I have no doubt in my mind that if it is bad software that it will be eventually removed and replaced.
IMO the biggest negative against those opposing systemd isn't that they fear it will fail and cause instability and problems, it's that they fear it will succeed and that other software will come to rely on it. That is not a rational objection. Systemd will succeed for fail on it's merits, not on the irrational hatred of a person involved in it's development.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
So some important issues are complexity, transparency, familiarity, learning curves, etc.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
> Simple things should be simple, complex things should be possible.
In the other case systemd was behaving very strangely w.r.t. timeouts. I found a work-around but I still don't understand why it wasn't simple. Maybe I will if/when I try harder.
The Grumpy Editor's guide to surviving the systemd debate
Wol
The Grumpy Editor's guide to surviving the systemd debate
So some important issues are complexity, transparency, familiarity, learning curves, etc.
All the heat makes is very hard to address the other issues coherently.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
My preferences is generally towards having a simple engine
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
What if your policy is algorithmic in nature, or is more complex than the designers of the config file imagined?
Are they all gross violations? (I almost added PHP to the list, but that might hurt my argument....)
The Grumpy Editor's guide to surviving the systemd debate
TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.
Further, at least two of these (Lua and Tcl) explicitly started as ways to write, well, Turing-complete configuration files: configury and program in the same language. Javascript didn't, but then it grew JSON, which is, well, exactly the same thing.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
systemd designers deemed that signals were not sufficient (Which is probably correct) and provide something else. What exactly? It seems to be a combination of signals and requirements.
"Wants" is a signal with no requirement
"Requires" is a combination of the two.
But I want direct access to all of it. I want to be in control (yes - I'll admit to being a control freak). I want to be able to access the different functions in ways that the designers never envisaged.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
But if a distro has a pre-existing practice of using a particular name for a service, and upstream chooses a different name, then there is an issue to be resolved. I would like to support both names, at least during a transition period. That means we need an effective alias, so "foo-daemon" and "food" can be used interchangeably.
But you cannot "enable" food.service. Is this by design or is it a bug? From what I know of systemd I cannot really decide and the documentation only seems to mention aliases in asides - I cannot find a section "how aliases work".
1/ wait the timeout
2/ assemble the md array
3/ activate the LVM volume
How long does it wait? According to "systemd.unit", "JobTimeoutSec" defaults to zero - except for devices units. It doesn't tell me what the default is for device units :-( It turns out to be 90 seconds - DefaultTimeoutStartSec in /etc/systemd/system.conf. But the timeout in step '1' above in 120 seconds. How can this ever work?
I'm not entirely sure, but it does is most cases. In the above case, systemd times out between steps 2 and 3. So if the md array contained the root device directly it would work. If not, it doesn't because systemd doesn't wait the extra second it takes to activate the volume.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
http://lwn.net/Articles/621003/
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
On devfs and udev
On devfs and udev
http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/
http://lccoelce14.sched.org/event/2b63b9b5ab23a133c8c2a62...
On devfs and udev
On devfs and udev
On devfs and udev
I'm not as knowledgeable on upstart (I never quite got the hang of it), but from what I have read, the original systemd developers looked at upstart, saw a few problems with it, and decided to go in a different direction. But they didn't start from scratch; they had in mind where upstart went right, and where upstart went wrong.
On devfs and udev
On devfs and udev
On devfs and udev
On devfs and udev
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
It's quite possible implement these without sacrificing security.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
I have used Linux since 1994. And also other Unix-based systems (not MacOS, except very occasionally). The only thing that is keeping me from jumping to FreeBSD or Dragonfly BSD, at this point, is hardware support in Linux -- NOT systemd! I'd venture to say that hardly any users care about systemd, hardly any users will benefit either, but LOTS of users care about the poisonous atmosphere that has arisen about the entire linux ecosystem in recent years.
The Grumpy Editor's guide to surviving the systemd debate
There are suggestions that though users won't care one way or another, greybeard sysadmins do care (negatively) and it is they who are behind the current backlash. Just remarking -- I'm not a sysadmin (though my stubble shows signs of grey).
Which sort of Linux user is systemd good for, exactly? The desktop/workstation user? That battle is over -- the future Linux desktop/workstation users are the ones who are comfortable with the command line, and that market will neither grow nor shrink, it will remain the niche that it is. And they don't need systemd. The average joe? There is no hope and that was never clearer than it is today. People who need a real computer use Mac, Windows, or perhaps Chromebook. People who don't use a tab. And, incidentally, Chromebooks and most tabs run Linux -- but they don't run systemd and don't need to.
Posted Nov 13, 2014 15:59 UTC (Thu)
by halla (subscriber, #14185)
[Link]
Well... OpenSUSE with systemd boots much, much faster than Ubuntu with Upstart, to the extent that after I installed Ubuntu on my workstation I actually thought it was hanging during boot. I guess users will care about that...
And I don't think many users will actually be aware of all the vitriol being spewed about systemd, most users don't read websites like this, or, worse, Phoronix. All this echo-chambery stuff doesn't have any impact in the real world, where, yes, even normal people use Linux to do their day job.
Posted Nov 13, 2014 16:03 UTC (Thu)
by Felix (subscriber, #36445)
[Link] (3 responses)
Well, Linux sales are good for about 10% of all Humble Bundle revenues (and IIRC there are some bundles which didn't have a single game which could run on Linux ). So either sysadmins play a lot more than I thought or we have quite a few "average Joes" (or plain Janes for that matter).
Posted Nov 13, 2014 16:43 UTC (Thu)
by halla (subscriber, #14185)
[Link]
Posted Nov 13, 2014 17:40 UTC (Thu)
by rsidd (subscriber, #2582)
[Link] (1 responses)
Posted Nov 13, 2014 17:45 UTC (Thu)
by jspaleta (subscriber, #50639)
[Link]
Posted Nov 13, 2014 16:10 UTC (Thu)
by jonnor (guest, #76768)
[Link] (6 responses)
It is also better than sysvinit for desktops, but that is probably less important, as this market is miniscule. However, the developments around "apps" as self-contained and sandboxed bundles could become a major improvement to desktop and mobile systems.
systemd is not end-user technology, it's "users" are developers and engineers creating and deploying systems based on GNU/Linux.
Posted Nov 13, 2014 16:44 UTC (Thu)
by pj (subscriber, #4506)
[Link] (5 responses)
Posted Nov 13, 2014 19:24 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
I've used one of the earlier versions of systemd a couple of years ago on my embedded systems.
Posted Nov 13, 2014 22:10 UTC (Thu)
by ebiederm (subscriber, #35028)
[Link]
Posted Nov 14, 2014 7:39 UTC (Fri)
by koenkooi (subscriber, #71861)
[Link]
Posted Nov 14, 2014 7:42 UTC (Fri)
by mokki (subscriber, #33200)
[Link]
Posted Nov 14, 2014 15:34 UTC (Fri)
by andza (guest, #72692)
[Link]
Posted Nov 13, 2014 18:45 UTC (Thu)
by thoeme (subscriber, #2871)
[Link]
>Linux desktop/workstation users ... And they don't need systemd.
YMMV,Thöme
Posted Nov 13, 2014 20:23 UTC (Thu)
by rodgerd (guest, #58896)
[Link]
This greybeard sysadmin cares positively (and I am hardly a unique datapoint), and is more than a little tired os self-important, self-appointed spokespeople claiming to speak for everyone. Especially when it is abundantly clear that in most cases they have never so much as booted systemd-equipped boxes, let alone run them on a production basis.
Posted Nov 13, 2014 20:46 UTC (Thu)
by misc (subscriber, #73730)
[Link]
From reading debian-users archive, I doubt that the expressed voices ( who I would count as less than 100 people ) count as a lot.
Another data point, this old petition, around 235 people who signed it.
So we have around 500, maybe 1000 people who seems to complain, and just on lwn, we have at least 90 000 accounts ( provided the id is increased by 1 for every account ).
Canonical announce numbers of users/systems around 12 to 20 millions, Fedora numbers of unique ip are around the same order of magnitude ( 1 to 2 millions ).
All of this seems to say that we can safely count gnu/linux users around the million or even more. So even if there was 10 000 of people complaining ( and I frankly do not see anything to back that estimation, but we can be generous ), this would still be only 1% of the most pessimist estimation of the total number of Linux users.
Now, of course, for a individual, 10 000 may count as a lot. But for the whole population, that's still a minority.
Posted Nov 13, 2014 17:45 UTC (Thu)
by marcH (subscriber, #57642)
[Link]
The magnifying glass effect of the Internet, where a single and tiny troll can so easily trigger a massive, de-multiplied emotional response, never stops being fascinating. Among others it demonstrates the large number of bored people with way too much free time on their hands. Get a life/job? In the case of software people, fix some bugs instead? Rewrite a better systemd even?
I think I like trolls much better than troll feeders after all. Some trolls can be really funny, feeders never are. The feeders make the noise.
(Please don't get me wrong: there are also plenty of other, valid and reasonable systemd questions and debates. It's not a minor change, far from it)
Posted Nov 13, 2014 17:57 UTC (Thu)
by marcH (subscriber, #57642)
[Link] (1 responses)
Very much indeed: there are so many nicer ways to answer the same thing. Starting with: "Sorry, that was not expected - however it's not on our priority list". Actually having a "lowest" priority value in the bug tracker for bugs that are never looked at and closed after a few months once the reporter has moved on. Costs little, does a lot of good. Having a personal or enforced rate-limiter on emails and bug trackers to avoid impulse responses. Etc.
By generating less inflammatory responses and hate mail this also saves a lot of noise, stress and time.
I think it's difficult but possible to be an engineer and a human being at the same time :-)
Posted Nov 13, 2014 18:35 UTC (Thu)
by pflugstad (subscriber, #224)
[Link]
QotW nomination here :-)
Posted Nov 13, 2014 22:29 UTC (Thu)
by ebiederm (subscriber, #35028)
[Link] (4 responses)
There has been a 100% back pedaling by the developers of udev. The only thing that has really been achieved is a less buggy implementation in the kernel.
Sadly device naming policy has for all practical purposes been removed from userspace.
Which is my long way of saying that I think it is a misrepresentation of the history of devfs and distributions to say that devfs has been removed.
Posted Nov 14, 2014 3:34 UTC (Fri)
by zuki (subscriber, #41808)
[Link] (3 responses)
It contained the following:
>The Problems:
> 2) We are (well, were) running out of major and minor numbers for
> 3) Users want a way to name devices in a persistent fashion (i.e. "This
> 4) Userspace programs want to know when devices are created or removed,
>The constraints:
> 2) Follow standards (like the LSB)
> 3) must be small so embedded devices will use it.
I really don't see the backpedalling. If you look at the *implementation*, I'll grant that it has changed a lot. But the basic design, the division of responsibilities, and capabilities are there.
Posted Nov 18, 2014 0:23 UTC (Tue)
by nix (subscriber, #2304)
[Link] (2 responses)
1) No policy in the kernel!
Check.
No coherent rationale that I can see was ever given for removing not only the requirement but even the possibility of creating /dev nodes from udev. Sure, on huge systems you want the kernel to do it, because it does it very fast -- but on normal systems, the extra flexibility seems worthwhile. It did save a few lines of code in udev, I suppose. Should that really be our priority?
Posted Nov 20, 2014 14:59 UTC (Thu)
by nye (subscriber, #51576)
[Link] (1 responses)
Well, I think that's a matter of interpretation.
Is the minor number of a device a policy question? I think most people would say no - it's a driver implementation detail and not intrinsically meaningful, nor something that you generally have to think about. So if we look at the scenario where udev creates all the device files, the naming and placement of those files is the policy, and the major/minor numbers used are not.
In contrast, we have the scenario where the kernel creates device files for everything it has, and udev creates links to them whose naming and placement conforms to (presumably) the same policy as in the first scenario.
These scenarios aren't really much different. In the first case, the major/minor numbers are some implementation detail that must be known by whatever process is deciding the policy, and are hidden from normal view. In the second case the non-normalised device files take the place of that implementation detail (well, add to it), with the only real difference being that in this case this implementation is more transparently exposed. Creating these device files is no more policy than the choice of major/minor numbers is.
I don't really see a compelling argument that either a) the details were better off left less visible, or b) the conceptual design is actually any different. It does add one extra layer of abstraction, but you seem to be saying that that extra layer actually enables the system to work *faster*, which is typically one of the big worries when adding yet another layer.
>but on normal systems, the extra flexibility seems worthwhile
What sort of things are you thinking of?
Posted Nov 20, 2014 16:11 UTC (Thu)
by zuki (subscriber, #41808)
[Link]
Or to put it more succinctly, "sda" name is not matter of policy, but "MyFavoriteDrive" is, as are the by-uuid and by-path symlinks, ownership, permissions, and acls.
> No coherent rationale that I can see was ever given for removing not only
Posted Nov 13, 2014 23:43 UTC (Thu)
by liquidweb (guest, #99771)
[Link]
Posted Nov 14, 2014 12:26 UTC (Fri)
by k8to (guest, #15413)
[Link] (8 responses)
Posted Nov 14, 2014 12:29 UTC (Fri)
by k8to (guest, #15413)
[Link] (4 responses)
Posted Nov 14, 2014 15:40 UTC (Fri)
by rsidd (subscriber, #2582)
[Link] (3 responses)
Posted Nov 14, 2014 16:13 UTC (Fri)
by johannbg (guest, #65743)
[Link]
systemd is an init system specifically written with linux in mind and thus tightly integrates and takes all of what the linux and it's kernel has to offer just like Windows has it's own (winload.exe ), BSD has it's own ( BSD-style init), Now Linux will ( in most distro's ) have it's own ( systemd ), OS-X has Launchd and Solaris has SMF.
As far as I know people aren't switching out the init system that is being shipped except on linux and on top of that last time I checked the BSD and Solaris developers were perfectly capable of updating/replacing their own init system if they deemed it necessary as well as carrying downstream patches to upstreams that dont want to support them.
Why the linux ecosystem has to have gazillion init system makes no sense and on top of that supporting more then one is arguably somewhat crazy and maintainers nightmare from my point of view.
Posted Nov 14, 2014 20:15 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link]
I would amend that to say that there is no replacement that looks more technically capable than systemd. People who are interested primarily in its technical capabilities see that as making it the most attractive choice. People who are concerned about design beyond pure technical capability don't necessarily reach the same conclusion. You are obviously skeptical of some of those other factors, too.
I agree that the big question is whether the people who don't like systemd are going to create a practical alternative. It certainly should be possible to create a better competitor for systemd than the current options while still avoiding some of the design choices that people dislike in systemd. That said, I doubt that it's possible to achieve some of the stuff that systemd does (e.g. recording things from early boot) without making the corresponding design decisions (e.g. running logging through PID 1).
Posted Nov 14, 2014 22:35 UTC (Fri)
by raven667 (subscriber, #5198)
[Link]
GNOME still runs on BSD, just without the session management that it would get on Linux, if people start using other systemd features (like the watchdog or relying on it for daemonization) then they will need to have fallbacks if they want to be portable or *BSDs will have to add the appropriate tools.
Posted Nov 17, 2014 1:02 UTC (Mon)
by ras (subscriber, #33059)
[Link] (2 responses)
We know he is thoroughly familiar with systemd - because he has effectively ported it to freebsd. That also tells us what he things of systemd as an init system: he likes it a lot. Yet he is a member of (maybe the leader of?) boycottsystemd. So for him this isn't a technical argument about systemd vs any other init system. He is boycotting systemd for some other reason. (Note how this contrasts to udev vs devfs: the divide rested on very real technical differences between the two.)
I'm guessing posts from Lennart like this one may have something to do with it:
http://lists.freedesktop.org/archives/systemd-devel/2014-...
Quoting from that link:
> Also note that at that point we intend to move udev onto kdbus as
Uselessd shines a light on that wakeup call, showing it for what it is. Its a threat by the person currently doing all the work, effectively saying "it's my way or the highway". It's only effective because he *is* doing all the work. If uselessd is a viable long term option the threat looses it's punch. Sadly uselessd's home page doesn't radiate a long term feel.
Posted Nov 17, 2014 3:29 UTC (Mon)
by raven667 (subscriber, #5198)
[Link]
Posted Nov 17, 2014 9:33 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Not really. You can use libsystemd (which contains the userspace part of kdbus) without using the rest of systemd, and if you don't want to do even that then writing your own userspace kdbus binding isn't exactly rocket science.
In effect the “threat” is that Lennart and his colleagues will eventually change one of udev's internal implementation details. The kernel developers do this all the time – with much less warning ahead of time – and nobody considers that a “threat”.
Posted Nov 14, 2014 12:29 UTC (Fri)
by karath (subscriber, #19025)
[Link]
For context, my current role is in providing and supporting the IT needs of businesses with 1 to 50 staff, largely using Windows and Office. On the other hand I've been using and playing with Unix and Linux systems since 1981 and have written a number of personal projects that I've published under the GPL.
With systemd, it is much easier for someone with a relatively low understanding to find and make change to the startup. The tens of thousands of lines of scripts that it replaces were totally impenetrable without many days or even weeks of study to understand what was scafolding/boilerplate and what was functional. In particular, I like that systemd exposes control knobs for many technologies that I've read about on LWN that were effectively inaccessible to me.
On the negative side, I've quite a bit of sympathy for the view that systemd is becoming a monolithic _project_. The core design is modularly partitioned into many separate binaries, while abstracting and reusing many utility functions such as parsing. However, the project does seem to rapidly gobble any vaguely system oriented utility.
Perhaps, as systemd matures into a project with less disruptive change/code churn, the developer team might consider separating the project into several repositories, such as utility libraries, core initialisation and monitoring, and system management utilities (maybe several of these, focusing on the different aspects of system management like networking, storage etc.). This could make the code base more accessible to 'noobs' and help throw off some of the unfortunate tags that the project attracts.
Finally, for those that that state that systemd is making Linux more like Windows, I don't think so. In the regularity and transparency of the CLI interfaces and configuration files, systemd is totally unlike what I face every day in Windows.
Posted Nov 14, 2014 15:38 UTC (Fri)
by clemensg (guest, #94377)
[Link] (6 responses)
Posted Nov 14, 2014 19:09 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
If you check the size of the init daemon itself, it's just about 50kloc with another 20kloc in libraries.
Splitting systemd-as-a-project into various components might make sense in the future once it stabilizes a bit. Inevitably there'll be questions of governance and maintenance strategy.
Posted Nov 14, 2014 20:45 UTC (Fri)
by rgmoore (✭ supporter ✭, #75)
[Link] (4 responses)
Which is the root of the claims about systemd trying to take everything over. A lot of that could be helped with some cosmetic changes of the kind Corbet is talking about. As an example, it would probably be better if the project were renamed the Linux Plumbing Layer project, with systemd just one prominent component of the project as a whole. Making it easier to get the individual components separately rather than getting the whole project and choosing what you want as configuration options would probably help, too. Those changes would fight the impression that systemd is taking over the world, and especially the wildly incorrect impression that all kinds of inappropriate stuff is winding up in PID 1.
Posted Nov 14, 2014 21:54 UTC (Fri)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
What I just heard you say was...
So systemd is currently taking over the world, in spite of itself. That's impressive. It's so useful and powerful a technology that even gross mismanagement of the project is unable to stop it from being widely adopted.
Snark aside, the downside to that cosmetic approach.. is that it claiming that level of configuration puts them on the hook for testing all the expanded configuration matrix. And requires larger API stability coverage than they are currently promising. Telling people what they want to hear, by deliberately crafting the message cosmetically...quickly puts them into a situation where they cannot deliver. I would look at cosmetic messaging like that as being far more manipulatively than what they are actually doing, designed to make people feel more comfortable than they should be.
And I think the systemd developers have been much more honest about what they are prepared to maintain and test and are telling people who want to deviate that they'll need to maintain and test that deviation. And moreover they are being very conservative about the API stability they promise. That honesty rankles, and feels like a punch in the mouth for people who want to hear the lipservice.
I still find it weird for example that systemd-shim chose to try to talk the unstable API that links logind to systemd instead of replacing logind itself and talking the stable logind API that apps depend on. That decisions still seems to me like asking for trouble and contrary to the guidance given concerning API stability. -shim is going to be a huge headache for Debian going forward as systemd evolves.
Posted Nov 14, 2014 21:57 UTC (Fri)
by mgb (guest, #3226)
[Link]
Agreed. Systemd-shim cannot succeed inside systemd's anti-innovation framework. Consolekit2 outside systemd is the future.
Posted Nov 15, 2014 5:49 UTC (Sat)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
Posted Nov 15, 2014 22:42 UTC (Sat)
by misc (subscriber, #73730)
[Link]
Posted Nov 17, 2014 3:22 UTC (Mon)
by tytso (subscriber, #9993)
[Link] (6 responses)
The bigger problem is with the other low level system components which are developed in the same git repository as systemd, and are named systemd-*. The fact that systemd can either refer to the init process or the much larger set of low-level components can very much clutter the discussion.
The other issue is that in some cases, systemd has taken over existing subsystems (i.e., consolekit) and done so with incompatible API's. Then low-level components, such as upower only work with the new systemd interfaces, and in fact, because they have broken interoperability this can end up breaking other desktops such as XFCE4. Now, one can't completely blame systemd; systemd only created the new interface. It was up to upowerd to only support systemd and to break its interfaces such that other components higher up in the stack (i.e., XFCE4) would break. And many projects in freedesktop.org (consolekit, policykit, etc.) had some very bad design decisions that have made them exceeding painful to administer, and I suspect to program to, so it's perhaps not so surprising that upower has decided to just drop support for consolekit and switch over to systemd-only support. Unfortunately, that ends up breaking everyone who depended on upower's old interfaces and old behavior.
One of the big, BIG, BIG problems in this whole space is that freedesktop.org and systemd folks don't seem to subscribe to the Kernel ethos of "thou shalt not break compatibility with your external users of your interfaces". So if you support an interface, you're obligated to support it forever, and if you change something that breaks a userspace program, you the kernel programmer are obligated to revert the change, or figure out some way to satisfy all of the users. In some cases it involves negotiating with all of the users of an existing interface before you make changes (that's what Tejun did with the cgroup interface changes; and the understanding was that if he couldn't figure out a way to make everyone happy, and then ix-nay on any backwards incompatible changes). The fact that systemd and freedesktop.org doesn't subscribe to this same ethos, and yet at the same time are trying to make changes fast, and consider it someone elses problem when they break interfaces, claiming it's up to XFCE4 (for example) to make changes to deal with the interfaces they changed/broke, is what is causing a huge amount of the heartburn.
To wit: http://m.memegen.com/u7o1tk.jpg
Posted Nov 17, 2014 7:10 UTC (Mon)
by jspaleta (subscriber, #50639)
[Link] (1 responses)
If the planned upstream maintainer transition that was suppose to happen in 2012 had actually happened as planned and CK was still actively maintained upstream, I very much doubt people would be dropping consolekit support in the last year or so.
https://mail.gnome.org/archives/distributor-list/2012-Jan...
I have no idea why the new maintainer ended not doing the expected fork/rename. The selected maintainer basically was radio silent as far as I can tell and Canonical/Ubuntu seemed to have quickly lost interest in CK completely.
Systemd did plan for compat with consolekit and handed CK over to someone else who was interested in keeping CK viable. Someone dropped the ball with CK as soon as they were given it.
So its been 2+ years since that CK codebase was dead upstream and people are only picking it back up maintainership for it now with consolekit2 opening up. Even lightdm was going to drop consolekit support until they were told about consolekit2 just this month! Do you really expect applications to hold on to support indefinitely for a codebase that is dead upstream for 2+ years? C'mon.
Honestly I don't really know what more you expected from the systemd side of things. The idea for logind was communicated early to pretty much all the CK stakeholders, and CK maintainership was gracefully handed off to someone in Ubuntu still interested in doing the work to maintain it with the expectation that CK would be renamed and continue on as an API to target. And CK upstream development basically just died from lack of maintainership interest from the new maintainer. Other developers higher up the stack ending up making the prudent choice to drop support for the bitrotting CK instead of carrying it around pointlessly.
-jef
Posted Nov 18, 2014 0:33 UTC (Tue)
by nix (subscriber, #2304)
[Link]
systemd transitioned the boot scripts from shell scripts to declarative syntax because it made things easier to write and more reliable, and hang how hard it made debugging and more complex stuff (as nbrown has mentioned). policykit has transitioned local admin security policy decisions from declarative syntax to, of all things, javascript because this increases flexiblity. Of course, it also means you're giving a JS interpreter that was not written with security in mind powers equivalent to root (!!) and, oh yes, because no backward-compatibility provisions were made, on upgrade you're silently breaking your admin's security policy. Better hope the admin knows JS well enough to hack in replacements fast.
I like using Turing-complete languages for configuration, but holy crap was this ever the wrong language in the wrong place. There's a reason most distros haven't upgraded to the JS-using version.
Posted Nov 17, 2014 7:29 UTC (Mon)
by tao (subscriber, #17563)
[Link] (3 responses)
I haven't really heard of any stable APIs provided by systemd that has changed in an incompatible way, but there obviously must be some, seeing as I've seen it mentioned multiple times.
That systemd, for instance, provides an API to do session handling dissimilar to the way console-kit did things is hardly something I consider an API break, just like I don't consider python to be an API-broken version of perl. It's a different solution to a problem, not a competing implementation. It isn't a matter of *taking over* a subsystem -- it's a matter of providing an alternative that turns out to be so superior that it out-competed the previous solution. Survival of the fittest.
As far as the kernel goes -- its API stability is good, no doubt, it certainly isn't completely set in stone though. devfs came -- and went. procfs has morphed now and then. The in-kernel webserver came and went. I seem to recall (though I may be wrong on this) that btrfs has gone through a couple of incompatible format changes. Things do get deprecated and disappear.
As for systemd being bigger than just an init system, it has good and bad sides. For instance, libc could probably be broken up into multiple different libraries. Why is libc shipped as one unit, instead of libc-str, libc-float, libc-stdio, ...? Because it's all developed as one single unit and because most of its users will be needing a lot of the components anyway. Andm being a system library, most systems will have use for all of these components.
The kernel situation is even more explicit -- you better maintain and distribute your kernel modules as part of upstream, or you don't get any xmas cookies^Wyou get to keep both pieces WHEN we break the in-kernel APIs.
The internals of the kernel is in constant flux, yet its external API tries very, very hard to remain stable. This comes at the price of, for instance, not having a stable module API. You say that your binary only module broke? Cry me a river. Much better then to maintain the modules within the kernel.
I can only imagine that the same reasoning goes for all the different helper programs that are part of systemd -- as long as said helpers are part of systemd they can have an internal API that is unstable, while trying its best to provide a stable API to the world.
Yes, gnome now relying on systemd-logind relying on systemd as pid 1 means that you have to switch init system. Guess what? I could probably go on all day listing software that has switch dependencies or bumped their dependencies suddenly forcing newer versions of software or different software to be installed. My Debian system would no longer run on a 2.0-kernel. It would no longer work with libc4. I suspect it wouldn't cope with XFree86 either, etc.
Of course there's the difference that systemd *competes* with other init systems that people want to continue using -- and they cannot be run at the same time (for obvious reasons). But systemd isn't the first piece of software that upstream depends on that will force a competing piece of software out of the way (oss vs alsa, for instance, or -- again -- the Linux kernel :P), nor will it be the last...
Posted Nov 17, 2014 21:32 UTC (Mon)
by lsl (subscriber, #86508)
[Link] (1 responses)
You're talking about Tux, right? It was never part of mainline Linux in the first place.
Posted Nov 17, 2014 21:55 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link]
Posted Nov 18, 2014 0:36 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Unless, that is, you really think people use strfry() or memfrob() a lot.
Posted Nov 17, 2014 14:24 UTC (Mon)
by palmer_eldritch (guest, #95160)
[Link] (1 responses)
After Joey Hess leaving the project, Colin Watson resigning from the TC (although willing to wait until January) and Tollef Fog Heen resigning from the pkg-systemd maintainer team, it sure looks like the debate is making things much less fun for Debian developers, let's hope things cool down once the GR is over, whatever the result is.
Posted Nov 17, 2014 15:13 UTC (Mon)
by johannbg (guest, #65743)
[Link]
I would not be surprise if others will follow in their footsteps.
Posted Nov 20, 2014 14:58 UTC (Thu)
by phred14 (guest, #60633)
[Link] (54 responses)
For a moment and for the sake of argument, please replace "systemd" with "postfix", "SysV" with "sendmail", "upstart" with "exim", etc, in the entire set of debates. Or you could replace "systemd" with "emacs" and "sysv" with "vi" if you wanted to, even "glibc" vs "uclibc" or "gcc" vs "llvm", I really don't care. I'm sure there are lots of analogies that could be made.
The problem here is that somehow systemd is supposed to become the ONLY init system. NONE of these other debates I mentioned require exclusivity, only systemd appears to. NONE of them are attempting to modify some large set of upstream to work best/exclusively with them, only systemd. It's this "must migrate" attitude that many of us are objecting to, and in any of the other examples I've cited, that attitude just doesn't exist.
Why is it so important that I move to systemd, why does anyone else care! That is not to neglect that techical issues, and I'm ready to discuss them as well, but right now issue of choice is more important.
Posted Nov 20, 2014 17:25 UTC (Thu)
by kmacleod (guest, #88058)
[Link] (53 responses)
You can't run more than one of those at the same time, you have to pick one, but you are free to pick any one of them.
Upstream software will naturally acclimate (work best, build easiest) to the most popular for now, and the more portable software will work with more of them at any given time.
Today, Linux is in the position in the OS world that you see systemd becoming in the user-space management world (of which init is just one part). Sure, it'll become the biggest player for a while, maybe it'll be a decade or two, but when you look at the pattern of containerization, bare-vm OSs, Android, Wayland/compositors, and standalone applications, the world we are in is going to go through a lot more changes in the next few years and systemd is just one of them.
Posted Nov 20, 2014 18:50 UTC (Thu)
by dlang (guest, #313)
[Link] (52 responses)
Linux succeeded because the userspace software out there was mostly written to be portable, and where it wasn't, it was acknowledged to be a weakness of the software that should be fixed, if only they had the time.
The systemd approach of replacing existing APIs with systemd specific ones (relying on dbus for the most part), means that software written to use systemd is not going to work with other init systems.
That's the problem.
Posted Nov 20, 2014 19:15 UTC (Thu)
by kmacleod (guest, #88058)
[Link]
Posted Nov 20, 2014 21:17 UTC (Thu)
by njs (subscriber, #40338)
[Link] (50 responses)
Posted Nov 20, 2014 22:19 UTC (Thu)
by dlang (guest, #313)
[Link] (49 responses)
Posted Nov 20, 2014 23:27 UTC (Thu)
by kmacleod (guest, #88058)
[Link] (45 responses)
Can you be more specific what's preventing the apps from supporting run-time or compile-time access to other APIs?
Posted Nov 21, 2014 1:46 UTC (Fri)
by raven667 (subscriber, #5198)
[Link] (44 responses)
Posted Nov 21, 2014 2:37 UTC (Fri)
by dlang (guest, #313)
[Link] (43 responses)
In practice, systemd is the new hotness and everyone who doesn't love systemd is being branded as a hater or a senile oldster.
We've seen the hate that's trotted out when a proposal is made to require people to not depend on systemd, and how some people are casting the Debian GR vote as a ringing endorsement of systemd and how it's perfectly find to be systemd only.
I have seen people here on LWN talk about using the systemd specific logging calls and not having fallback to the traditional logging capabilities.
This is the same type of thing that made people sound very opposed to Wayland a year or two ago, when it was the new hotness and 'everyone' was talking about how writing for Wayland was so much easier, people should just do that and not support that obsolete interface called X11.
It is possible for sanity to prevail here (for the most part, actually moving from the early proof of concept to a usable system has dampened the hype around Wayland significantly, it's no longer being viewed as a "must move to it within the next few months" thing)
But creating new APIs for basic plumbing functionality like name lookups and logging is not a good thing to be doing for portability.
Systemd explicitly doesn't care about portability, but users will. They may not initially as they move to systemd, but they will eventually if the software they use isn't critical enough to force everyone to switch to systemd. After all, don't the systemd advocates keep insisting that nobody is forcing anyone to use systemd?
Posted Nov 21, 2014 3:31 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (7 responses)
So an update is definitely in order. Systemd does this a bit too revolutionary, but in the end most of the proposed APIs are not very Linux-specific. They are just not implemented yet elsewhere.
But that is being fixed already. And what's more, it's definitely possible and not even _hard_ to implement API-compatible fallbacks for other systems for most of systemd functionality.
Posted Nov 21, 2014 3:45 UTC (Fri)
by dlang (guest, #313)
[Link] (6 responses)
What is the exact failure with the existing APIs that cannot be solved without involving DBUS?
Posted Nov 21, 2014 3:49 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link] (5 responses)
Posted Nov 21, 2014 8:33 UTC (Fri)
by rleigh (guest, #14622)
[Link] (4 responses)
Posted Nov 21, 2014 9:09 UTC (Fri)
by peter-b (subscriber, #66996)
[Link] (2 responses)
Trivially? Oh excellent! Since it's so straightforward, why don't you quickly knock something out over the weekend, so we can then put this whole discussion to rest? I"m sure Lennart would be really happy for other developers to get involved in tackling this problem.
Posted Nov 21, 2014 11:14 UTC (Fri)
by rleigh (guest, #14622)
[Link] (1 responses)
Posted Nov 21, 2014 11:17 UTC (Fri)
by mchapman (subscriber, #66589)
[Link]
Um. D-Bus *is* a standard library interface in practically every mainstream programming language.
Posted Nov 25, 2014 22:16 UTC (Tue)
by nix (subscriber, #2304)
[Link]
Posted Nov 22, 2014 2:50 UTC (Sat)
by thedevil (guest, #32913)
[Link] (34 responses)
I should _really_ leave this topic alone but I cannot, sigh.
You're veering into the philosophical. What is "force"?
And many of those saying nobody forces me to use systemd seem to
Maybe we should agree that the word "force", like "socialism",
Posted Nov 22, 2014 5:18 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (33 responses)
It seems pretty obvious to me with respect to any reasonable philosophy, not just among libertarians. The person was in a bad situation to start with, but the one making the offer isn't the cause. The offer can be accepted or rejected at will; if it's rejected, the person is no worse off than they would have been had the offer never been made. Accepting the offer implies that the person expects it to improve their situation. Giving someone additional options which they can choose to ignore doesn't seem at all like "force".
How would you define "force" such that making an offer like this is "force" but simply passing by and doing nothing is not "force"? Or would you consider that "force" as well? The concept that non-action could be "force" seems absurd to me, but I'm sure there's someone who thinks that way...
In any case, you hit the nail on the head: you are free to continue using the software as it exists today, and to improve on it as you see fit, by yourself or in collaboration with others who share your vision. You are not, however, entitled to improvements (including security fixes) to be developed by others to your preferred specifications. If you want to take advantage of others' work then you must be prepared to give up a measure of control—including control over details like a dependency on systemd.
Posted Nov 22, 2014 17:37 UTC (Sat)
by thedevil (guest, #32913)
[Link] (26 responses)
"you are free to continue using the software as it exists today"
This just shifts the question from "force" to "free choice". The
You are right, though, that my example was a bad one as I posed
"If you want to take advantage of others' work then you must be
I am not a totally passive recipient, I am an occassional Debian
systemd is no detail. Adoption of systemd in its full scope would make
Posted Nov 22, 2014 20:10 UTC (Sat)
by nybble41 (subscriber, #55106)
[Link] (25 responses)
Yes. As they take advantage of your work. That wasn't meant to be pejorative; we all gain an advantage from the work of others. But it does imply letting others make some of the choices.
> The crux of my position is: if one option is bad enough, it is not free choice. You could say that users of proprietary software are also "free" to just stop using it, yet that is not usually how we apply the term.
I'm not saying that anyone has to stop using Debian. Unlike proprietary software, the pre-systemd versions will remain available for them to use or improve on as they see fit. _Upgrading_ to a hypothetical new version of Debian with a hard systemd dependency would be a free choice.
> systemd is no detail. Adoption of systemd in its full scope would make a completely different OS...
Perhaps it would, but then you have two options: the software as it exists right now, pre-systemd, or the improved version with systemd. That's one of the nice things about free software, the older versions remain available for use and further development if anyone should happen to disagree with the direction taken by the project's current developers. (Just look at what happened with Gnome 3 and MATE, for example.)
There are any number of Debian derivatives available. If 30% of Debian contributors really want a Debian-style OS without systemd—or even just the 24% who listed Option 1 as their first choice—they would clearly have the resources necessary to create such a derivative without impeding the 70+% who want to use systemd. Or they could just submit patches to ensure that the packages they're interested in continue to work with other init systems in Debian proper, without imposing such support as a requirement on other maintainers.
Personally, I don't see why anyone would bother. Systemd seems strictly superior to the existing sysvinit as well as the other proposals. I'm already using it on my Debian systems and am glad for the change.
Posted Nov 22, 2014 20:39 UTC (Sat)
by thedevil (guest, #32913)
[Link] (23 responses)
Sorry, no. Running today's software, bit by bit, in 2 years (even
"they could just submit patches to ensure that the packages they're
This is what I pin my hopes on, but the tone adopted by many DDs in the
Posted Nov 22, 2014 21:02 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link] (22 responses)
Please try on said DD's shoes for size. Firstly, their principal responsibility is to say "no" to ill-conceived patches, and even just to patches that don't fit into the programming standards of the package(s). They have to triage bug reports into "requires immediate attention", "can wait" and "just not worth it". Remember they have limited resources (probably best described as "resource starved"). That means they can't responsibly take on continuing maintenance of all crazy ideas proposed. Much less when upstream won't take them over, leaving them in the bind of caring for changes forever. Pretty much the same way the systemd developers state their position; They want to build the very best possible process managing infrastructure for Linux. Diverting resources to cater for other kernels (or even not-so-new Linux versions), or compromising the use of Linux-only features for the sake of portability, just isn't in their books. Your might not like either position, but you should at least try to understand where they come from. Both Debian and systemd owe their success to following through with their visions.
Posted Nov 23, 2014 1:42 UTC (Sun)
by thedevil (guest, #32913)
[Link] (21 responses)
I actually agree with you about the vision, but the problem for me is
Bowing out of this debate for good; since the effort to switch to
Posted Nov 23, 2014 1:53 UTC (Sun)
by Zack (guest, #37335)
[Link] (19 responses)
Posted Nov 24, 2014 12:27 UTC (Mon)
by anselm (subscriber, #2796)
[Link] (18 responses)
People who hope that FreeBSD will let them stay in the 1990s forever should be really scared of this.
(Of course, once FreeBSD has systemd there will be little point in Debian/kFreeBSD staying with sysvinit.)
Posted Nov 24, 2014 14:14 UTC (Mon)
by johannbg (guest, #65743)
[Link] (17 responses)
Now let's see if that crowd will complain as much to the BSD crowd, demanding of them to make it available and work on linux too...
Posted Nov 29, 2014 9:01 UTC (Sat)
by blujay (guest, #39961)
[Link] (16 responses)
On top of that, you misrepresent the portability argument: no one is demanding that Poettering, et al make systemd work on BSDs. The problem is that he explicitly refuses to even accept patches from others to that end.
Then there's the double-speak and the "wakeup call" to Gentoo, which gives the lie to the "no one is forcing anyone" line.
And that's the biggest problem with systemd. And when people focus exclusively on the technical issues, they miss the bigger issues, the people problems. And those are harder to fix and far more damaging, because there's no "community reset --hard" command.
Posted Nov 30, 2014 15:23 UTC (Sun)
by foom (subscriber, #14868)
[Link] (15 responses)
No. That would only be a problem if:
Please note the OpenSSH/Portable OpenSSH split seems to work out just fine.
Anyone in the world can get together and work on a branch to make the bits and pieces they'd like to use portable.
Whether or not systemd upstream git tree supports other OSes is almost completely irrelevant -- unless you're asking the systemd upstream to do the portability work.
Posted Nov 30, 2014 20:34 UTC (Sun)
by dlang (guest, #313)
[Link] (14 responses)
Posted Nov 30, 2014 20:45 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link] (3 responses)
Remember the days when much stuff for Linux was developed in/through non-vanilla kernel trees, and Alan Cox' tree was the one most bleeding edge hackers followed? Could set up a git tree and merge said patches in there, that is just a few keystrokes away. Merging in upstream changes is ridiculously easy with git, no need to handle random text patches flying by on mailing lists. Not doing so is a dead giveaway to me that they aren't serious.
Posted Nov 30, 2014 21:02 UTC (Sun)
by dlang (guest, #313)
[Link] (2 responses)
For many people, systemd just isn't that compelling.
It's like the attention paid to fast boot times and suspend/resume, if you are dealing with systemd that stay up and running for months at a time, shaving a few seconds off of the boot time doesn't matter. If you are putting all your attention to servers providing 24/7 service, suspend/resume doesn't matter.
That's not to say that those features aren't interesting to other people, but the people who are interested in them (and correspondingly the people who are interested in features that systemd provides) need to accept the fact that it's not interesting to everyone.
And when there is a regression or performance hit to something that you are interested in because of some feature that you aren't interested in, that's annoying and people crowing about the feature you don't care about don't solve your problem.
Posted Nov 30, 2014 23:21 UTC (Sun)
by vonbrand (subscriber, #4458)
[Link]
I for one have never claimed systemd's advantage being fast boot, it is that it gives sane process management. That is even much more relevant on servers that should run continuously for months, having to reboot because some idiotic script got irretrievably wedged (yes, has happened to me) isn't acceptable.
Posted Dec 1, 2014 0:46 UTC (Mon)
by anselm (subscriber, #2796)
[Link]
Many people don't seem to find systemd compelling but they're still outraged that portability isn't an important goal of the project so it won't run everywhere right off the bat. This is a bit incongruous to say the least.
From what we hear, systemd does have lots of features that are interesting to many people – from embedded-system developers to server admins. Fast boot times are nice to have and systemd seems to work well in that area, but systemd is not just about fast boot times; they are a fringe benefit of the approach systemd takes for service activation. (Incidentally, even on servers, people who deal with on-demand virtual machines seem to appreciate a faster boot process, so it is incorrect to claim that boot times are irrelevant to servers.)
Of course anybody may feel free not to be interested in systemd's features, which is why systemd is not mandatory to run Linux, and is unlikely to ever be that way as long as those not interested in systemd are willing to put in the work to maintain a systemd-free Linux distribution (if nobody else does). Whether other people – such as upstream developers who would like to avail themselves of systemd's features – will bend over backwards to make it easy for them is of course up to those people. Then you get people like the Debian developers, who on the whole seem to be happy with the concept of supporting several init systems (in particular, sysvinit and systemd) at the same time as long as this is dealt with in the usual way (i.e., by means of wishlist bugs, preferably with patches attached) rather than mandated by GR. This means that if you do notice a regression or performance hit to something you are interested in, the first step towards getting that fixed is to submit a bug report. Crowing about it on an unrelated web site doesn't solve your problem, either.
Posted Nov 30, 2014 22:33 UTC (Sun)
by anselm (subscriber, #2796)
[Link] (9 responses)
The BSD OpenSSH people don't accept portability patches, either – the portable version is maintained by a different team in a separate repository. Nobody seems to mind much. There is no particular reason why a similar approach wouldn't work with systemd if somebody actually came up with patches for a portable version.
Posted Dec 2, 2014 2:58 UTC (Tue)
by blujay (guest, #39961)
[Link] (8 responses)
And you know this. "If you actually made the patches, it would be fine." This is equivalent to, "Do as I say, not as I do." "Portability patches will not be accepted....Why aren't you porting it?" You say one thing, but expect others to do the opposite, and then criticize them when they take you at your word. It's as if you expect people to think you're lying--in which case, why would they trust you?
You make no sense, but I think you know that. The question is then, why?
Posted Dec 2, 2014 5:04 UTC (Tue)
by pizza (subscriber, #46)
[Link] (4 responses)
Yeah, because one is a network-facing daemon that must conform to well-established protocol specifications in order to be of any use, and the other is operating system plumbing that tries to take advantage of the features of its targeted kernel (modern Linux). They have quite different scopes, so it's no wonder they're developed differently.
But since you brought it up, let's actually talk about some of the ways systemd and OpenSSH/OpenBSD are similarly developed:
* Principal developers have a strong vision and often abrasive personality
> You make no sense, but I think you know that. The question is then, why?
Your argument is based on factually incorrect premises, false equivalences, and downright faulty logic; this makes no sense, but I think you know that as well. The question is then, why?
Posted Dec 3, 2014 0:26 UTC (Wed)
by blujay (guest, #39961)
[Link] (3 responses)
All of which makes it more ridiculous to expect other people to maintain portability patches against the will of the developers.
> Principal developers have a strong vision and often abrasive personality
But that is supposed to be irrelevant, isn't it? After all, no one accepts that as a valid argument against systemd. And while de Raadt knows OpenSSH is vital to software around the world, Poettering explicitly disregards portability. The difference is night and day.
> All related code is developed in a single repository and built together
This favors in-tree development of portability, not out-of-tree.
> Modular, yet tightly coupled design via well-defined internal interfaces
Just like the kernel, which also maintains its many platforms in-tree.
> Extremely strong emphasis placed on "predictability and correctness"
Predictability? Like Poettering's "wake-up call" to Gentoo?
> to the point of not compromising either for the sake of expedience (or even portability)
Again, this favors in-tree portability, not out-of-tree.
> Expectation for third parties to develop and maintain portability to other systems
False! This is a lie! No one is expected to port systemd to other platforms, because it's not expected at all! You know this! That's the whole point!
> Little regard for backwards compatibilty (although systemd fares *far* better than OpenSSH here; seriously, try to compile a modern OpenSSH release on an old OpenBSD system sometime)
See previous comments about OpenSSH's knowing that their software is vital on platforms around the world. Their method of porting is just that: a method of doing it. Systemd, on the other hand, refuses to even consider it. You know this.
> Your argument is based on factually incorrect premises, false equivalences, and downright faulty logic; this makes no sense, but I think you know that as well. The question is then, why?
Nope, nice try though.
Your argument boils down to, "It's technically possible, so shut up and port it." You conveniently ignore the gross impracticalities, knowing that no such effort would be feasible with the way systemd is developed. We're talking past each other because you're moving the goalposts. And I've yet to see anyone actually respond to Poettering's "wake-up call" to Gentoo--too inconvenient for the narrative, I suppose, so better to ignore it and redirect the argument.
I think there's no point in continuing this discussion with you. Changing the subject, ignoring facts, moving the goalposts, focusing on strawmen...but what of the truth?
Posted Dec 3, 2014 2:24 UTC (Wed)
by pizza (subscriber, #46)
[Link] (1 responses)
You're one to talk, given that you've done every one of those things in your reply, including taking contradictory positions depending on the particular point you're trying to argue.
What of the truth, indeed.
Posted Dec 3, 2014 6:36 UTC (Wed)
by blujay (guest, #39961)
[Link]
Then, "No one is forcing you to use systemd.... This is your wake-up call, Gentoo! Good luck reimplementing our rapidly changing internal APIs!"
Yeah, I'm the one being self-contradictory...
Posted Dec 3, 2014 10:13 UTC (Wed)
by anselm (subscriber, #2796)
[Link]
It would be more appropriate to say that (a) the systemd developers don't see the point of portability patches to systemd because systemd relies heavily on kernel features that are currently only available on Linux in the first place, and (b) the systemd developers don't want their own code base cluttered up with portability #ifdefs. None of this prevents other people from actually trying to port systemd if they have nothing better to do with their time.
To port systemd to another Unix-like operating system kernel, somebody would have to remove all the Linux-specific bits from systemd and/or enhance the other kernel to provide compatible versions of those Linux-specific bits that one would consider worth supporting (considering that some of systemd's Linux-specific bits are really quite essential for its functionality). This would very likely involve a major effort, and – since most other Unix systems by now have their own take on an improved init – it is unclear whether such an effort would really be worthwhile. Having said that, it is fair to assume that if one is prepared to go to the trouble at all then having to maintain a separate OpenSSH-style “portable systemd” repository is probably the least of one's worries.
In this context it is worth mentioning that leading FreeBSD developers have recently gone on record to say that something like systemd would not be a bad idea at all for FreeBSD as far as they're concerned. Whether this means that FreeBSD will move towards evolving enough Linux compatibility to support a (partial?) systemd port, or whether the FreeBSD people will come up with something similar but unrelated by themselves is as yet unclear – but the fact that there is active interest does validate the principle of systemd's approach to basic plumbing (if not portability).
Posted Dec 2, 2014 8:34 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (2 responses)
Systemd is changing quickly because it is a new project (compared to OpenSSH, anyway). It will eventually settle down and evolve at a much slower rate, at which point a “portable” version may become more interesting to consider.
It is also worth pointing out that the systemd developers have not said that they will not ever consider any “portability patches” whatsoever, just that the idea doesn't make a lot of sense because systemd relies extensively on Linux-only kernel features and that as long as such patches don't exist the point is moot, anyway. Again, from the systemd developers' POV it makes good technical sense to focus on Linux first, and to deliver a clean and correct code base that runs on Linux. Once systemd does what it is supposed to do on Linux, there may come a time to think about what parts of systemd's functionality can usefully be adapted for other systems, and what extensions to those systems (e.g., additional kernel features or Linux compatibility layers) would be required for systemd support. This might eventually lead to a “portable” systemd maintained in a separate repository à la OpenSSH, and while the systemd developers may not be interested in “portability patches” per se, if there are reasonable “cleanup patches” that facilitate this without unduly complicating systemd's Linux-oriented code base then I think those might well be accepted.
Posted Dec 2, 2014 17:41 UTC (Tue)
by dlang (guest, #313)
[Link] (1 responses)
Part of what people aren't liking is the dependence on linux-only features without any fallback to operate without them.
If cgroups are required to be in the kernel, but you can operate without using any controllers (as was stated in some thread on lwn in the last few days), then refusing to boot when cgroups aren't in the kernel is the wrong thing to do. That would be one linux-only feature that would change from a hard dependency to a feature to be used when available.
Posted Dec 2, 2014 20:51 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link]
However, you don't need any cgroups-based resource management to be turned on (or even compiled in). In this case cgroups will be used only for process tracking and nothing else.
Posted Nov 24, 2014 10:31 UTC (Mon)
by jezuch (subscriber, #52988)
[Link]
I don't see how. For me it was just an apt-get away. [Besides, I don't think current packaging of systemd in Debian uses much more than the core init component.]
Posted Nov 22, 2014 20:41 UTC (Sat)
by vonbrand (subscriber, #4458)
[Link]
Please don't. You just come barging in and foul up a perfectly nice flamewar with a reasoned comment taking away their favorite arguments for fanning the flames. Sheesh...
Posted Nov 23, 2014 20:07 UTC (Sun)
by cas (guest, #52554)
[Link] (5 responses)
The fact that US Libertarians can't see this goes a long way to highlighting what's wrong with them.
Posted Nov 23, 2014 22:43 UTC (Sun)
by nybble41 (subscriber, #55106)
[Link]
I never said that it wasn't exploitation. I said that it wasn't _force_. The most obvious difference being that if someone uses force against you then a response in kind is justified (self-defense), whereas if someone merely "exploits" you, there is no justification for responding with force.
You're mixing personal/subjective morals with objective ethics. The libertarian position doesn't address the former at all; it's only concern is when the use of force is justified (in short: only when responding to the use of force by others). Your opposition to the libertarian position appears to be based on the misconception that it has something to do with "right" and "wrong", rather than the justified or unjustified use of force.
Personally, if I were in the situation you described, I believe that the right choice would be for me to offer the children whatever assistance I could provide with no strings attached. The solution to exploitation is to offer a better choice, not to remove the few they have. However, if someone else were to impose conditions, even "exploitative" ones, I would consider it wrong for me to employ force to _make_ them help without conditions, or to prevent them from making their offer, or to punish them for the "exploitation". If I did employ force in that way then, as a libertarian, I would consider a proportional defensive response against me to be justified.
Posted Nov 23, 2014 22:45 UTC (Sun)
by viro (subscriber, #7872)
[Link]
Posted Nov 29, 2014 9:22 UTC (Sat)
by blujay (guest, #39961)
[Link] (2 responses)
Well, no, that won't do, because then the poor man is still homeless and hungry and out of work.
So what should he do? Offer him a job at a certain wage (set by the government, of course)?
Well, now you're forcing him to do something against his will.
But that's okay, because it's for the greater good. The ends justify the means.
That's all well and good until you are the one being forced to do something against your will. But that's okay, because it's for the greater good. What, you're not a hater, are you? How could you object to helping people? Don't you have any compassion?
We recognize that forced love is not love at all. The same principle applies here.
The real greater good, for all of us, is best served by individual liberty, personal responsibility, and giving, not reluctantly or under compulsion, but cheerfully, from the heart.
Posted Nov 30, 2014 20:16 UTC (Sun)
by cas (guest, #52554)
[Link] (1 responses)
what's that you say? you want him to respect and the government to protect and enforce YOUR property rights? WTF should he respect your property rights when you don't respect his human right not to be exploited? why is your property more important, more worthy of government intervention than his life?
libertarian arseholes believe that property is more important than people.
the fact that you've put property up on a pedestal above everything else doesn't actually mean that it's worthy of the worship you want to force everyone else to give it.
ps: private charity is a copout. whether someone gets to eat or have shelter shouldn't be dependant on their cuteness or their ability to evoke pity. neither should it be dependant on the whims of the rich. welfare is a responsibility of society - i.e. paid for by taxes.
Posted Nov 30, 2014 20:54 UTC (Sun)
by corbet (editor, #1)
[Link]
Posted Nov 21, 2014 1:18 UTC (Fri)
by njs (subscriber, #40338)
[Link] (2 responses)
OTOH I don't see how you can claim logging as an example; systemd 100% supports the standard syslog API. They also provide some additional APIs that let you provide extra structured metadata that syslog just can't handle (so it's not really "replacing [an] existing API", it's new features entirely), but even here it would be trivial for users to include a stub implementation of this API that falls back on throwing away the metadata and calling syslog() if the journal isn't available. Heck, it'd be like a 10-line patch to teach sd_journal_sendv to just do this by default. (Also there's zero dbus involved, just good old fashioned AF_UNIX sockets like Allman intended.)
Posted Nov 21, 2014 2:40 UTC (Fri)
by dlang (guest, #313)
[Link] (1 responses)
I don't know any details about the resolvd DBUS api other than that it exists. What it replaces is the gethostbyname() and similar functions of the existing libc options.
Posted Nov 21, 2014 2:48 UTC (Fri)
by rahulsundaram (subscriber, #21946)
[Link]
Well no. It doesn't replace anything. It is an additional option.
Posted Nov 21, 2014 20:35 UTC (Fri)
by sorpigal (guest, #36106)
[Link]
I believe it was the oft-overlooked 5th commandment; let us recount them all for posterity
I. UNIX(R) is the OS and thou shall run no other OS.
And the apocryphal 11th commandment ("Release early, release often").
Lennart is a devil for trying entice us to violate the 5th commandment, but I believe most of us are sinners by now in any case.
Posted Nov 22, 2014 2:25 UTC (Sat)
by thedevil (guest, #32913)
[Link] (4 responses)
This analogy has a problem. devfs was never a required part of a
"Systemd will either be established and successful, or it will
It is the lack of a third option -- keep waiting for something
Posted Nov 22, 2014 10:16 UTC (Sat)
by anselm (subscriber, #2796)
[Link] (3 responses)
The problem with this POV is that ”waiting for something more clearly better” is no guarantee that something more clearly better will in fact come along eventually. Someone would have to do active work to make that happen.
In particular, the main problem with this POV is that, especially given that most of the rest of the Linux world seems to be reasonably happy with systemd, the pool of people who are (a) sufficiently unhappy with systemd to actually roll up their sleeves to come up with something “more clearly better”, (b) sufficently qualified to do so, and (c) sufficiently committed to the long-term viability of such a project appears to be small indeed. (It is also fairly clear that very few if any of the current crop of vocal “systemd haters” seem to belong to that pool – we hear a lot of complaints of how systemd is badly designed etc., but nobody so far has condescended to propose a better design, let alone an implementation.)
Posted Nov 22, 2014 18:16 UTC (Sat)
by thedevil (guest, #32913)
[Link] (2 responses)
"nobody so far has condescended to propose a better design"
You assume this is just due to laziness or pure troll malice, but
Posted Nov 23, 2014 2:43 UTC (Sun)
by seyman (subscriber, #1172)
[Link] (1 responses)
Given how modular systemd is, I'm not convinced splitting it up would be a huge gain. Perhaps what's needed is a document explaining how to disable all non-core features and how to re-enable them once you're comfortable with your running system.
Posted Nov 23, 2014 7:13 UTC (Sun)
by brodo (subscriber, #4049)
[Link]
... or even something like "make config".
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Works smoothly from end user point of view.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Oh really ? I have been using Linux as a desktop since 1997; currently running my *company*-provided desktop PCs with openSuSE.
Fluently on the command line ? Yes, but very fond of my KDE4 desktop, wouldn't miss it.
Well I like my notebook to boot fast...which it does thanks to systemd.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
> about the entire linux ecosystem in recent years.
https://www.change.org/p/lennart-poettering-stop-writing-...
RH announced 1 billion of $ of revenue 2 years ago, so you can divide by the price of 1 subscription ( from the website ) after removing the part of jboss/rhev/etc and remove the services/training of the revenue ( from Sec fillings ). Then you will have a idea of the installed base. And while there is maybe not 1 admin per server ( that wouldn't be efficient ), but something like 10 to 100 servers per admin ( per latest industry stats, maybe not up to date nowadays with cloudification of application ).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
devfs is not gone
devfs is not gone
> 1) A static /dev is unwieldy and big. It would be nice to only show
> the /dev entries for the devices we actually have running in the
> system.
Still there, check.
> devices.
Check.
> disk here, must _always_ be called "boot_disk" no matter where in
> the scsi tree I put it", or "This USB camera must always be called
> "camera" no matter if I have other USB scsi devices plugged in or
> not.")
Check.
> and what /dev entry is associated with them.
Check.
> 1) No policy in the kernel!
Check.
Check.
I guess this is the most arguable point. udevd binary is now much bigger than the original 6kb, but it is still used in embedded, afaik.
devfs is not gone
The constraints:
That's not true. udev no longer creates /dev nodes, only symlinks to them: you must use devtmpfs, whereupon the kernel creates them. This is policy, in the kernel.
devfs is not gone
devfs is not gone
> the requirement but even the possibility of creating /dev nodes from
> udev. Sure, on huge systems you want the kernel to do it, because it does
> it very fast -- but on normal systems, the extra flexibility seems
> worthwhile.
The reason is consistency (we want the same capabilities and mechanisms on all systems) and simplicity (we don't want to carry an alternate implementation if the kernel already provides one) and a minimal increase in safety (if udev does not create nodes, it cannot screw them up).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
(b) there is no replacement that looks more attractive than systemd
The Grumpy Editor's guide to surviving the systemd debate
Uselessd
> transport, and get rid of the userspace-to-userspace netlink-based
> tranport udev used so far. Unless the systemd-haters prepare another
> kdbus userspace until then this will effectively also mean that we will
> not support non-systemd systems with udev anymore starting at that
> point. Gentoo folks, this is your wakeup call.
Uselessd
Uselessd
Its a threat by the person currently doing all the work, effectively saying "it's my way or the highway".
systemd from a different POV
The Grumpy Editor's guide to surviving the systemd debate
I think this is one misconception about systemd. It's not just another init system. It tries to be too many things at once: init system, network-, timedate-, locale- and journal-manager, resolver, etc. It can run an HTTP server and generate QR codes, be DHCP client and server, and so on...
The size of the code base is crazy. I created a graph of the lines of code over time with GitStats and gnuplot: https://i.imgur.com/JHtArbL.png
We are at about 700k LOC at the moment. This is totally insane.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Systemd-as-a-project has stopped being just an init tool. It's now a plumbing layer replacement for Linux.
The Grumpy Editor's guide to surviving the systemd debate
systemd could be more effective taking over the world if it just made some cosmetic changes to placate the people who are afraid of it taking over the world.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Even before the handover LP expected CK to work side-by-side with logind as long as someone stepped up and became the maintainer.
http://lists.freedesktop.org/archives/consolekit/2011-May...
The Grumpy Editor's guide to surviving the systemd debate
It seems to me the only problem you have really consolekit. And consolekit is a bit of a weird duck because its been a dead upstream now for like 2 years. Do you really expect applications to continue to hold onto support for an unmaintained framework element like CK?
Well, policykit is also a screaming horror, but for reasons entirely unrelated to systemd. In fact it's almost the anti-systemd.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Why is libc shipped as one unit, instead of libc-str, libc-float, libc-stdio, ...? Because it's all developed as one single unit and because most of its users will be needing a lot of the components anyway. Andm being a system library, most systems will have use for all of these components.
Really, really no. It's shipped as one thing because it implements one set of standards (the POSIX library specification, roughly, and its ancestors and relations), because it always was one thing, and because it has insanely strict backward-compatibility constraints so cannot ever stop being one thing (at best you can replace libraries with stubs and migrate their contents into libc or replace libc implementations with forwarders and migrate their contents out, and even that can be and has been problematic).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
>
> You can't run more than one of those at the same time, you have to pick one, but you are free to pick any one of them.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
I think it's a good thing. The old API has become ossified and is not really suited for the modern needs.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
enough to force everyone to switch to systemd. After all, don't
the systemd advocates keep insisting that nobody is forcing
anyone to use systemd?"
Libertarians of the US flavor insist that they're against
any "initial use of force". But, they don't seem to have a
problem with, say, finding someone desperately hungry and
offering to hire him for half of what the work is worth. That is
not "force" to them.
mean basically than I can move to Windows / Mac, or keep using my
computer with exactly the same software os today, and forgo
security fixes etc. Not right now - but in 2-3 years, when
current stable goes out of support.
has too many meanings and it is better to always spell out what
you actually mean by it.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
doesn't seem at all like force."
crux of my position is: if one option is bad enough, it is not
free choice. You could say that users of proprietary software are also
"free" to just stop using it, yet that is not usually how we apply the term.
it.
prepared to give up a measure of control—including control over
details like a dependency on systemd."
contributor. And, apparently roughly 30% of DDs agree with me.
Are they also "taking advantage of others' work"?
a completely different OS on the level I usually interact with it
(ie. command line, editing configuration files, reading logs, setting up
cronjobs).
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
software, the pre-systemd versions will remain available for them to use
or improve on as they see fit. _Upgrading_ to a hypothetical new version
of Debian with a hard systemd dependency would be a free choice."
assuming my hardware lasts that long) would be a worse option than not
using computing at all. And you know that.
interested in continue to work with other init systems in Debian proper"
last few years when presented with patches and bugreports detracts from
those hopes. If I was conspiracy theory minded (I am not) I would describe
the tone as remarkably similar to that of systemd maintainer ;-)
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
phenomenon to me. I have been using, and trying to improve, Debian for
a long time as I wrote in my other posts here. Refusals used to be
gracious and understanding, now they're often silent or even snide.
that in the Debian case the vision seems to have changed. Very slightly
but perceptibly if you look close. Nothing I can do about that as an
individual (and not because of my lacking technical merit), and that's
really the most frustrating thing about the situation.
systemd with all its family is comparable to switching to a new distro,
I may as well start exploring the latter :-(
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
[…] and is endorsed by systemd's lead developer as positively remaining systemd free.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
a) Such patches to make systemd work on other OSes actually existed.
b) It turned out, from actual experience, that maintaining them in a separate "portable" git tree had frequent problematic merge conflicts or something like that, that made it very desirable for the tree be merged back with the Linux-only tree for developer sanity.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
* All related code is developed in a single repository and built together
* Modular, yet tightly coupled design via well-defined internal interfaces
* Extremely strong emphasis placed on "predictability and correctness" to the point of not compromising either for the sake of expedience (or even portability)
* Expectation for third parties to develop and maintain portability to other systems
* Little regard for backwards compatibilty (although systemd fares *far* better than OpenSSH here; seriously, try to compile a modern OpenSSH release on an old OpenBSD system sometime)
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
No one is expected to port systemd to other platforms, because it's not expected at all!
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
Uhm, you still NEED cgroups to use systemd. It can't really work without them.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
OK, I think it's fair to say we've gone pretty far off topic at this point; maybe it's time to close this discussion down or find a more suitable forum for it?
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
II. Thou shalt not violate AT&T copyrights
III. Thou shalt not violate UNIX(R) trademarks
IV. Time began 1970-01-01T00:00:00+0000
V. Honor Maxwell
VI. Thou shalt not kill -9 unless it doesn't respond to -15
VII. Thou shalt do one thing
VIII. Thou shalt do it well
IX. Everything is a file and a file is a stream of bytes
X. Text is the universal interface
The Grumpy Editor's guide to surviving the systemd debate
filesystem"
Linux system. I lived through the devfs years happily upgrading
Debian to each new stable, without ever turning on devfs. When
udev came around and I satisfied myself that it was the lean,
mean anti-devfs, I took the jump. But what is going on with
systemd has quite a different feel. TBH, I don't completely
understand why - technically, it is no more a hard requirement
than devfs. I _suspect_ that the difference is the tone of the
proponents. Perhaps the fact that English isn't the native
language of either primary developer plays a subtle role.
have been replaced by something better."
more clearly better -- that is the main objection. Surely this
is obvious from the Debian GR, if nothing else. Pretending that
this POV doesn't exist serves nobody.
The Grumpy Editor's guide to surviving the systemd debate
It is the lack of a third option -- keep waiting for something
more clearly better -- that is the main objection. Surely this
is obvious from the Debian GR, if nothing else. Pretending that
this POV doesn't exist serves nobody.
The Grumpy Editor's guide to surviving the systemd debate
sleeves to come up with something"
I think there is more to it. By all signs systemd's design _as
an init replacement_ is excellent, and that's why we don't see
any alternative proposals from qualified people. The problem
with systemd is its ever increasing scope, devouring (and
changing beyond recognition) more and more parts of the base
system. The solution isn't a complete redesign but splitting it
up, but that can only be done either 1. with the help of
upstream, which has not been forthcoming, or 2. by forking it.
The Grumpy Editor's guide to surviving the systemd debate
The Grumpy Editor's guide to surviving the systemd debate
