|
|
Log in / Subscribe / Register

The Grumpy Editor's guide to surviving the systemd debate

By Jonathan Corbet
November 12, 2014
The systemd debate appears to be one of those gifts that keeps on giving; whenever it seems that the issues are approaching resolution and things might calm down, a new flame war starts up. Most recently, this dispute is threatening to tear apart the Debian community. Your editor would like to suggest that such an outcome would be far too high a cost to pay for a disagreement over a system initialization and service management system.

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.

to post comments

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 2:52 UTC (Thu) by bferrell (subscriber, #624) [Link] (145 responses)

Dear grumpy editor,

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:32 UTC (Thu) by jonnor (guest, #76768) [Link] (21 responses)

init does not have "one simple configuration file". inittab is basically only used for runlevels and ttys, the rest of config and logic is spread around in /etc/rc.d, /etc/init.d/, /etc/default, /etc/sysconfig - depending on which distro you are on.

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.
Or you can complain that you don't like any of these choices, and put the responsibility onto someone else for the situation.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 6:01 UTC (Thu) by bferrell (subscriber, #624) [Link] (11 responses)

Sir, you have just demonstrated your complete ignorance of exactly HOW init works.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:42 UTC (Thu) by rvfh (guest, #31018) [Link] (1 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.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 9:01 UTC (Thu) by peter-b (guest, #66996) [Link]

> Or are you just trolling?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 15:39 UTC (Thu) by jonnor (guest, #76768) [Link]

I know that to be even remotely useful, sysvinit needs much more than just the init binary. Typically it needs some thousand lines of shell code, all executed as root.

Thank you for ignoring the point that you do have a number of constructive options available.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:11 UTC (Thu) by smurf (subscriber, #17840) [Link]

>> What init DOES do is to call a very flexible process management system

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:12 UTC (Thu) by mmeehan (subscriber, #72524) [Link]

> 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.

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
[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

Posted Nov 13, 2014 18:53 UTC (Thu) by Seegras (guest, #20463) [Link] (5 responses)

> 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.

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 19:36 UTC (Thu) by bferrell (subscriber, #624) [Link]

I remember before ANY init scripts... when init ran everything

And yes, if you run emacs as init, flamed is probably not needed... But you MIGHT get a darwin award

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 23:41 UTC (Mon) by nix (subscriber, #2304) [Link] (3 responses)

I ran Emacs as init for a while, but its service supervision really isn't very good.

One shouldn't write init systems in Lisp anyway. They have not enough pros and far too many cons.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 19, 2014 22:04 UTC (Wed) by cesarb (subscriber, #6266) [Link] (2 responses)

> One shouldn't write init systems in Lisp anyway. They have not enough pros and far too many cons.

In case anyone didn't get the joke: https://en.wikipedia.org/wiki/cons

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 19, 2014 22:29 UTC (Wed) by neilbrown (subscriber, #359) [Link] (1 responses)

> In case anyone didn't get the joke ...

thanks for pointing that out!! I would have missed it otherwise and that would have been a shame.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 25, 2014 22:11 UTC (Tue) by nix (subscriber, #2304) [Link]

I dunno. Your software saves my data repeatedly, I make you chuckle once.

It doesn't really seem like sufficient recompense...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 17:41 UTC (Thu) by toyotabedzrock (guest, #88005) [Link] (8 responses)

You are claiming that he can choose when he clearly cannot.
And this is a community. Not a business, you cannot dismiss users or people who contribute to other parts of the Linux ecosystem.

Without them you might as well contribute to dev/null

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 22:13 UTC (Thu) by wagner17 (guest, #5580) [Link] (7 responses)

Why are you saying there is no choice? The article pointed out several choices.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 17:51 UTC (Sat) by thedevil (guest, #32913) [Link] (6 responses)

"The article pointed out several choices."

Quote?

Ok, this isn't fair, because I know you can't - you probably
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

Posted Nov 22, 2014 19:45 UTC (Sat) by dlang (guest, #313) [Link] (5 responses)

also note the "this is a warning to you Gentoo" notice about how systemd is going to change udev so it no longer works on the current Gentoo

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 19:59 UTC (Sat) by filipjoelsson (guest, #2622) [Link]

You do know that udev already has been forked by Gentoo, right?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 20:04 UTC (Sat) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

You are presenting a classic false dichotomy. Both can be true at the same time. They can accomplish the goal of being a standard plumbing layer without the use of force by making it better than the alternatives so that major distributions voluntarily use it by default. One could say, they have already done just that.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 21:20 UTC (Sat) by mgb (guest, #3226) [Link] (2 responses)

> They can accomplish the goal of being a standard plumbing layer without the use of force by making it better than the alternatives so that major distributions voluntarily use it by default.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 22:41 UTC (Sat) by gracinet (guest, #89400) [Link]

"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."

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 18:53 UTC (Sun) by njs (subscriber, #40338) [Link]

> 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.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:37 UTC (Thu) by mgb (guest, #3226) [Link] (26 responses)

Init. Logging. Process Monitoring. Udev. Networking. Login. Audio. Printing. Desktop. Security. NTP. DNS. KDbus. Distribution. Packaging.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:52 UTC (Thu) by jonnor (guest, #76768) [Link] (2 responses)

No, this debate is about fear, unwillingness to work constructively and take responsibility.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 18:34 UTC (Sat) by thedevil (guest, #32913) [Link]

"No, this debate is about fear"

Sometimes fear is justified.

I fear the next US national election, because I have lived long enough
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

Posted Nov 28, 2014 5:43 UTC (Fri) by blujay (guest, #39961) [Link]

> unwillingness to work constructively

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 12:15 UTC (Thu) by motk (subscriber, #51120) [Link]

The debate is about ethics in gaming^Wlinux journalism.

Not really. Sheesh, overreach.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 12:55 UTC (Thu) by cortana (subscriber, #24596) [Link] (21 responses)

I think you just went full Godwin. *plonk*

Nobody expects the spanish plonk squad!

Posted Nov 20, 2014 1:35 UTC (Thu) by ksandstr (guest, #60862) [Link] (20 responses)

That's funny: I didn't think there were killfiles on LWN. What is the reason you go out of your way to state that you won't be listening in the future?

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.

Nobody expects the spanish plonk squad!

Posted Nov 20, 2014 1:59 UTC (Thu) by mpr22 (subscriber, #60784) [Link]

I didn't think there were killfiles on LWN.

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.

Nobody expects the spanish plonk squad!

Posted Nov 21, 2014 0:53 UTC (Fri) by flussence (guest, #85566) [Link] (18 responses)

> What is the reason you go out of your way to state that you won't be listening in the future?

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.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 6:14 UTC (Fri) by blujay (guest, #39961) [Link] (12 responses)

Your comment presumes that the person in question "screwed up" and needs to "do better" in the first place. I see no such thing. What I see is an argument based on principle, one which many people not only do not seem to comprehend, but become actively angry about. The response is then equivalent to a drive-by, "la la la, I can't hear you!" In contrast, to "face someone down and tell them why they've screwed up badly" would mean engaging in a rational discussion.

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.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 13:52 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (10 responses)

> In contrast, to "face someone down and tell them why they've screwed up badly" would mean engaging in a rational discussion.

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.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 22:06 UTC (Fri) by dlang (guest, #313) [Link] (9 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.

> 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.

Nobody expects the spanish plonk squad!

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?

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 22:47 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

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.

But that would make the claims that systemd isn't forcing you to use everything a lie.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 23:05 UTC (Fri) by anselm (subscriber, #2796) [Link] (4 responses)

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

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.

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.

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).

Nobody expects the spanish plonk squad!

Posted Nov 29, 2014 0:39 UTC (Sat) by mgb (guest, #3226) [Link]

> Hence my question whether anything outside of udev uses it (and Gentoo's udev fork doesn't really count).

Will your proposed kernel changes break eudev?

Nobody expects the spanish plonk squad!

Posted Dec 10, 2014 16:32 UTC (Wed) by nix (subscriber, #2304) [Link] (2 responses)

Sorry, last I encountered it, udev was userspace, right? And there are other things that do what udev does (Gentoo's fork, eudev, perhaps mdev?). That makes this a userspace/kernel ABI in my eyes, with multiple users, making breaking it verboten. What's worse they are multiple boot-critical users!

Nobody expects the spanish plonk squad!

Posted Dec 10, 2014 20:53 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

It's backwards. My understanding: the kernel and udev currently communicate over netlink. Newer udev will only talk over kdbus (netlink isn't going away in the kernel) and kdbus requires some userspace process to set up the bus (which systemd currently does). Gentoo can fix this by writing their own kdbus setup tool (which is what the warning was about).

Nobody expects the spanish plonk squad!

Posted Dec 11, 2014 17:04 UTC (Thu) by nix (subscriber, #2304) [Link]

Ah, so this is 'newer udev will require a bleeding-edge kernel yet again', not 'we're going to break everyone using older udev and force them to upgrade'. So I'm not as annoyed as I might be, and Al is probably more annoyed...

Nobody expects the spanish plonk squad!

Posted Nov 29, 2014 0:10 UTC (Sat) by viro (subscriber, #7872) [Link] (1 responses)

You still don't get it. Incompatible changes in udev did happen. _Exactly_ because somebody thought that there is such a thing as application-private kernel API. And it was a fucking disaster.

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.

Nobody expects the spanish plonk squad!

Posted Nov 29, 2014 3:15 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

As I understand, nobody is going to rip off the netlink API from the kernel. They simply plan to rip it from udev. Your old boot system will still work.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 15:58 UTC (Fri) by foom (subscriber, #14868) [Link]

> Another possibility is a simple lack of patience.

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?

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 15:15 UTC (Fri) by ksandstr (guest, #60862) [Link] (4 responses)

>(...) it gives the plonk-ee at least the courtesy of knowing they've gone off-course far enough to provoke such a reaction, (...)

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.

Nobody expects the spanish plonk squad!

Posted Nov 28, 2014 22:24 UTC (Fri) by mgb (guest, #3226) [Link] (3 responses)

> However, the original plonker up there only came, plonked, and then vanished.

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/

Nobody expects the spanish plonk squad!

Posted Nov 29, 2014 16:29 UTC (Sat) by ksandstr (guest, #60862) [Link] (2 responses)

>It has been fascinating watching you echo each other but why should any of us experienced software professionals waste LWN bandwidth responding to you?

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.

Nobody expects the spanish plonk squad!

Posted Nov 29, 2014 16:49 UTC (Sat) by mgb (guest, #3226) [Link] (1 responses)

Thank you for putting the time and effort into an exemplary post. I agree we must move forward but respectfully disagree on the details.

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.

Nobody expects the spanish plonk squad!

Posted Nov 30, 2014 1:43 UTC (Sun) by dlang (guest, #313) [Link]

> And exploring the various technical alternatives is *much* more interesting than trying to convert systemd believers.

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)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:45 UTC (Thu) by rahvin (guest, #16953) [Link]

Thank you for ignoring Jon's request.

Nobody is forcing you to do anything unless you have a completely different definition of force.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:12 UTC (Thu) by cdmiller (guest, #2813) [Link] (32 responses)

"It is just a system initialization utility". Really? A simple system initialization utility in one large software suite that includes 69 individual binaries. From all indications that number is set to continue growing. There are some indications that tight coupling of those binaries and forced exclusion of their alternatives is increasingly preferred.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:36 UTC (Thu) by jspaleta (subscriber, #50639) [Link] (21 responses)

There are bug reports? Can you point me to your favorite ones?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 4:20 UTC (Fri) by cdmiller (guest, #2813) [Link] (20 responses)

Since I mentioned the journal I'll take your bait and point you at one. Probably the most rehashed, bug 64116.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 9:10 UTC (Fri) by niner (guest, #26151) [Link] (19 responses)

Can you please explain to me why the following comment from the bug report you mentioned, does not explain the rationale behind this design decision sufficiently?

Lennart Poettering 2014-10-08 20:27:49 UTC
Since this bugyilla report is apparently sometimes linked these days as an example how we wouldn't fix a major bug in systemd:

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 23:45 UTC (Mon) by nix (subscriber, #2304) [Link] (5 responses)

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.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 23:59 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

As far as I remember, X.org's repositories were corrupted beyond recovery after power failed multiple times during fsck.

I've also had a similar experiences (albeit with NTFS on Windows).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 2:58 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

> 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 3:47 UTC (Thu) by dlang (guest, #313) [Link] (2 responses)

with a binary file format, finding the start of the next message is not that easy.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 4:28 UTC (Thu) by raven667 (subscriber, #5198) [Link]

sorry, I maybe should have been more clear, journalctl reads both the currently writing log and all previous ones that have been rotated and are still around, it should only restart journald if the corruption is in the log that journald is currently writing. The reason to implement this in the reader is that the I don't expect the log writer be reading often enough to notice if something has gone wrong.

I don't know if that's how it actually works, that's just my first idea of how I think it should work.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 9:15 UTC (Fri) by zlynx (guest, #2285) [Link]

Finding stuff in "binary" files is no more difficult than text files. It depends on the particular format.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 23:47 UTC (Mon) by nix (subscriber, #2304) [Link] (9 responses)

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

Posted Nov 18, 2014 0:07 UTC (Tue) by rahulsundaram (subscriber, #21946) [Link]

That is not what the bug report claims:

"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."

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:15 UTC (Tue) by mchapman (subscriber, #66589) [Link] (7 responses)

> 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:59 UTC (Tue) by dlang (guest, #313) [Link] (6 responses)

the instance of journald corruption that I saw ended up with the binary pointers going backwards and so walking the journal ended up with an endless loop

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 2:34 UTC (Tue) by mchapman (subscriber, #66589) [Link] (5 responses)

Right. I haven't seen that myself, but I could imagine it could happen.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 4:03 UTC (Tue) by dlang (guest, #313) [Link] (4 responses)

It does make it so that all log entries after the corruption are lost though.

This is one of the problems with binary logs

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 5:04 UTC (Tue) by mchapman (subscriber, #66589) [Link] (3 responses)

Only up until the next rotation... which would presumably happen when you update systemd to fix the bug, if not earlier.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 11:59 UTC (Tue) by notninjaz (guest, #99725) [Link] (2 responses)

As I read it, the original "empty" statement was referring to the new journal which would be empty as in a clean slate, comparing it to offering the user a new clean slate filesystem rather than trying to repair a corrupted one.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 13:14 UTC (Tue) by mchapman (subscriber, #66589) [Link] (1 responses)

> As I read it, the original "empty" statement was referring to the new journal which would be empty as in a clean slate, comparing it to offering the user a new clean slate filesystem rather than trying to repair a corrupted one.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 14:51 UTC (Tue) by notninjaz (guest, #99725) [Link]

Right, I was referencing the statement: "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."

I meant to express a design preference rather to critique any particular software with regard to text vs. binary logs.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 22:52 UTC (Tue) by cdmiller (guest, #2813) [Link] (2 responses)

The technical side is still debatable as evidenced below. There is apparent confusion over common failure modes of the binary log and what log data is available or potentially lost after a failure. Folks appear to not fully understand or agree with the explanation. The timing of the more detailed response is troubling. What you posted above appeared over a year after the initial bug report. Suffice it to say I'm not convinced systemd-journald log corruption handling is sufficient for servers, or that anything more robust is being pursued.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 19, 2014 0:35 UTC (Wed) by rodgerd (guest, #58896) [Link] (1 responses)

TO be honest, journald *features* are nice, but the implementation detail still seems like the main weakness in systemd-the-suite-of-programs. I don't quite understand why the binary blob DB isn't based on an already extant DB, for example (Gnu DB, Berkely, whatever), and the corruption and lack of a remote logging mechanism undermine the work Lennart did to try and make it more useful as an audit tool.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 19, 2014 11:07 UTC (Wed) by mchapman (subscriber, #66589) [Link]

> I don't quite understand why the binary blob DB isn't based on an already extant DB

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-...
[2] http://cgit.freedesktop.org/systemd/systemd/plain/src/jou...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:01 UTC (Thu) by notninjaz (guest, #99725) [Link] (9 responses)

I would be interested to read about the misfeatures your team has identified. It was welcome news here that log lines are being shown complete instead of abbreviated with ..., which leads me to believe that the developers are addressing this kind of thing based on sysadmin feedback.

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 5:14 UTC (Fri) by cdmiller (guest, #2813) [Link] (8 responses)

As far as SLES goes we are locked to RHEL on some systems due to vendor support, though it sounds well worth a look at for our Oracle servers.

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.
Custom binary log format.
Lack of log shipping.
Log corruption.
The requirement to run multiple log daemons.
Web access to log files.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 11:24 UTC (Fri) by pbonzini (subscriber, #60935) [Link]

> The binary format of the journal is an unnecessary non feature.

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".

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 14:15 UTC (Fri) by notninjaz (guest, #99725) [Link]

Thanks for the reply!

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 16:28 UTC (Fri) by Wol (subscriber, #4433) [Link] (5 responses)

> At the very least the journal could use an existing vetted database back end.

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,
Wol

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 25, 2014 22:24 UTC (Tue) by nix (subscriber, #2304) [Link] (4 responses)

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!

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).

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 25, 2014 22:37 UTC (Tue) by dlang (guest, #313) [Link]

> 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.

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)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 26, 2014 20:36 UTC (Wed) by Wol (subscriber, #4433) [Link] (2 responses)

> 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).

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,
Wol

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 26, 2014 20:41 UTC (Wed) by Wol (subscriber, #4433) [Link] (1 responses)

Oops - I think I've missed a trick - if the initial log entry gets saved successfully, then the transaction can be rolled forward, but you've still got an unnecessary window for data loss.

Cheers,
Wol

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 26, 2014 23:36 UTC (Wed) by dlang (guest, #313) [Link]

the key is that the database doesn't consider the transaction complete until it gets confirmation that the log entry has been written successfully.

so there is no data loss once the database acks the transaction.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 22:13 UTC (Thu) by valhalla (guest, #56634) [Link] (61 responses)

> 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 22:21 UTC (Thu) by dlang (guest, #313) [Link] (60 responses)

the concern isn't about running jessie, it's what's going to happen after that. People want to be sure that they will continue to have the option of not installing it going forward.

The Grumpy Editor's guide to surviving the systemd debate

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 0:52 UTC (Fri) by mgb (guest, #3226) [Link] (46 responses)

> These people are free to submit patches to ensure that packages support the non-systemd init system of their choice

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 4:03 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (45 responses)

Do you not have a long-term memory? There's a thread asking for what, exactly, broke and here you are yet again spreading unsubstantiated claims. Do you not realize you're basically just a broken record at this point?

*plonk*

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 6:06 UTC (Fri) by mgb (guest, #3226) [Link] (37 responses)

> Do you not have a long-term memory? There's a thread asking for what, exactly, broke and here you are yet again spreading unsubstantiated claims. Do you not realize you're basically just a broken record at this point?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 7:19 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (36 responses)

A very simple question:

Are these packages not working properly without systemd?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 7:53 UTC (Fri) by mgb (guest, #3226) [Link] (34 responses)

> Are these packages not working properly without systemd?

They won't even install without chunks of systemd.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 7:55 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (33 responses)

I'm sorry, I think I asked quite clearly: "Do these packages refuse to work without systemd?"

Does booting Debian with SysV init or upstart somehow stops these packages from functioning?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 17:39 UTC (Fri) by mgb (guest, #3226) [Link] (32 responses)

http://lwn.net/Articles/620159/

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 17:41 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (31 responses)

Basically, you're admitting that these packages work fine. Ok.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:03 UTC (Fri) by mgb (guest, #3226) [Link] (30 responses)

> Basically, you're admitting that these packages work fine. Ok.

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.

The Grumpy Editor's guide to surviving the systemd debate

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”.

  • The vast majority of Linux programs doesn't actually know or care what init system is being used. Therefore there is no plausible way for systemd to influence the degree of innovation there.
  • Much of the innovation in Linux takes place inside the kernel, where it does not matter in any way whether the system is running systemd or not. Systemd cannot hurt kernel-side innovation.
  • With systemd, writing background service processes is much easier because they require a lot less boilerplate code for daemonising themselves, logging, service management, etc. This should actually lead to increased innovation in that space because the bar to entry is lower.
  • With systemd, much of the “basic plumbing” that distributions used to have to provide, in a non-standardised fashion, has been unified. This means that the distribution developers no longer have to spend their time reinventing that particular set of wheels, and can instead work on improvements elsewhere (including in the shared set of tools that systemd provides for the benefit of all systemd-based distributions). Again, this should lead to increased, not reduced, innovation.
  • Even in the embedded space, many developers actually seem to be quite happy with systemd and the things it provides. Many other embedded-system developers are used to doing their own thing and will be able to continue doing so in the future. Again, innovation is not impaired.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:53 UTC (Fri) by mgb (guest, #3226) [Link] (25 responses)

> Please explain how “post-systemd Linux” is less conducive to innovation than “pre-systemd Linux”.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:37 UTC (Fri) by johannbg (guest, #65743) [Link] (6 responses)

"Systemd is so tied to RedHat's business goals"

By all means elaborate what you mean by this.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:45 UTC (Fri) by mgb (guest, #3226) [Link] (3 responses)

> By all means elaborate what you mean by this.

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]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:32 UTC (Sat) by johannbg (guest, #65743) [Link] (2 responses)

By calculation the share arrogance of some of Red Hat's employees will have the corporate eat the Mahatma Gandhi quote it decided to commercialize in the long run but I dont give shit about some fancy notion shitty corporation like Red Hat force adoption ( which by the way it forces that adoption through Fedora, think products here or "recommendation" if you want to go further into the past ) What I asked you was to elaborate was why do you think "Systemd is so tied to RedHat's business goals".

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 15:54 UTC (Sat) by flussence (guest, #85566) [Link] (1 responses)

I knew you were a crank before, but this tactless rage-spew confirms it beyond a shadow of a doubt. *plonk*

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 17:10 UTC (Sat) by johannbg (guest, #65743) [Link]

And?

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 23:51 UTC (Mon) by nix (subscriber, #2304) [Link] (1 responses)

Clearly that it serves RH's business goals to ship a working init system that's better than any other out there.

I'm not really sure why this is objectionable, mind.

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:29 UTC (Fri) by anselm (subscriber, #2796) [Link] (12 responses)

Systemd is not portable to other OSs so it loses synergy.

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.

Making it harder for you and me to innovate is very bad.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:54 UTC (Fri) by mgb (guest, #3226) [Link] (7 responses)

If RedHat and FreeDesktop had wanted to support innovation they would have employed a modern component architecture rather than a throwback to the 1970's.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 23:12 UTC (Fri) by pizza (subscriber, #46) [Link] (6 responses)

> If RedHat and FreeDesktop had wanted to support innovation they would have employed a modern component architecture rather than a throwback to the 1970's.

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*.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 23:26 UTC (Fri) by dlang (guest, #313) [Link] (5 responses)

At the risk of feeding a troll

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 5:46 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (4 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.
And that perfectly describes DBUS.

> 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
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

Posted Nov 15, 2014 5:52 UTC (Sat) by mathstuf (subscriber, #69389) [Link] (3 responses)

> I have my own small version in pure Rust, for example.

Ooh, nice. Linky please? :)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 5:54 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

I'll send a link to http://discuss.rust-lang.org in a week or so, once it clears our IP lawyers.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 6:06 UTC (Sat) by mathstuf (subscriber, #69389) [Link]

Woo, thanks. I'd love to use Rust as the language for my "no-DE" DBus service endpoints (logind, polkit, udisk, etc.). Both to get them done and to use Rust without it being a "eh, I'll reimplement this" project. *waits impatiently*

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 11, 2014 3:03 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Is this[1] it?

[1]https://github.com/diwic/dbus-rs

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 28, 2014 6:39 UTC (Fri) by blujay (guest, #39961) [Link] (3 responses)

I have yet to see such a hateful comment as this from systemd dissenters.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 28, 2014 13:29 UTC (Fri) by mathstuf (subscriber, #69389) [Link] (2 responses)

Have you missed the screeds by Gregory Smith (or whatever his pseudonym is today) on the Debian lists?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 28, 2014 13:48 UTC (Fri) by mpr22 (subscriber, #60784) [Link] (1 responses)

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

Posted Nov 28, 2014 19:11 UTC (Fri) by viro (subscriber, #7872) [Link]

I wouldn't bet even on that. Or on any specific gender, for that matter. About the only thing obvious about that wankstain is that it's really, really desperate for attention. Of any kind. Proof positive that the well-meaning drivel along the lines of "nobody is worthless" is just that...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 20:04 UTC (Thu) by horsethief (guest, #99889) [Link] (4 responses)

Thank you for this, you've really hit the nail on the head. I don't understand why the pro-systemd people are willing to regress to this design pattern/mentality/architecture.

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 21:13 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link]

It's feasible to replace individual portions by reimplementing the same interfaces. Take a look at what systembsd for an example.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 9:25 UTC (Fri) by zlynx (guest, #2285) [Link] (2 responses)

Your diagram is wrong though. You have a solid block for systemd, which isn't how it works. Please go study it and look at its interfaces between components. Then you can update your drawing.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 17:26 UTC (Fri) by mgb (guest, #3226) [Link] (1 responses)

Every systemd component that interfaces with any other systemd component via any interface that is not public and guaranteed stable is part of the systemd entangled monolith.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 20:29 UTC (Fri) by peter-b (guest, #66996) [Link]

Okay, cool. That's measurable. So by your definition, the "systemd entangled monolith" is:

* systemd
* systemd-journald
* systemd-logind

Seems reasonable.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:29 UTC (Fri) by rahvin (guest, #16953) [Link]

You don't see how silly it is being opposed to having the files on your system even if you aren't using the software? Because that's what you are arguing, you dislike the software so much that you don't even want it's files on the system even if it's not being used for it's primary purpose for which you claim to be opposed. That is an irrational position.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 16, 2014 15:02 UTC (Sun) by robclark (subscriber, #74945) [Link] (1 responses)

> Most GUIs in the world run Android because pre-systemd Linux was a great platform for innovation.

lol.. you have not actually looked at an android userspace have you?

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 8:48 UTC (Fri) by dlang (guest, #313) [Link]

they are now, but there was a time when they didn't, and instead of altering the packages to work without systemd, the decision was to switch to systemd

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 8:47 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

you have a faulty memory

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 9:45 UTC (Fri) by anselm (subscriber, #2796) [Link] (5 responses)

but the whole fuss was exactly because DD decided to make a package only work with systemd.

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?)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 10:28 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> I was under the impression that upstream GNOME was changed to use systemd-logind rather than the obsolete and unmaintained ConsoleKit.

"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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 10:33 UTC (Fri) by ovitters (guest, #27950) [Link] (3 responses)

> I was under the impression that upstream GNOME was changed to
> use systemd-logind rather than the obsolete and unmaintained ConsoleKit.

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.

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:54 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

go back up several posts, the claim was made that systemd was always purely optional.

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)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 11:00 UTC (Sat) by micka (subscriber, #38720) [Link]

Well, being the default desktop environment doesn't really give them that much power, as since that time the default desktop environment in debian must have (only from memory) changed three times.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 8:45 UTC (Fri) by dlang (guest, #313) [Link] (9 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 9:32 UTC (Fri) by anselm (subscriber, #2796) [Link]

Too many people related to systemd have publicly stated that they consider supporting anything else to be a waste of time

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:57 UTC (Fri) by rahvin (guest, #16953) [Link] (6 responses)

No what they are asking for is that Debian maintainers be forced to support other init's or the software they maintain will be removed after someone files a bug report about the lack of support. It's completely against the Debian constitution and contrary to the principles of the entire project.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:06 UTC (Fri) by mgb (guest, #3226) [Link] (5 responses)

Deliberately breaking previously working software in order to force systemd to be installed is contrary to Debian's Social Contract.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:10 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

the problem is in evaluating intent

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 28, 2014 6:47 UTC (Fri) by blujay (guest, #39961) [Link]

Isn't the end result more important than someone's intentions?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:49 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (2 responses)

s/breaking/changing/

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:26 UTC (Fri) by mgb (guest, #3226) [Link] (1 responses)

> Would you like to borrow my time machine and go back to 2012 and fork consolekit when it was a timely option?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:23 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

No my timemachine doesn't run fedora.. it runs android...being from the future and all.

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...

http://lists.freedesktop.org/archives/lightdm/2014-Novemb...

Once consolekit2 shows up in deb packaging, that will be an interesting discussion.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 12:32 UTC (Sat) by ms_43 (subscriber, #99293) [Link]

The systemd approach to OS portability is similar to the OpenSSH project... see my earlier comment on this:

https://lwn.net/Articles/620747/

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 18:46 UTC (Sat) by thedevil (guest, #32913) [Link] (1 responses)

"package maintainers should be encouraged to take these on"

Encouraged by whom?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 23:03 UTC (Sun) by anselm (subscriber, #2796) [Link]

Debian distribution policy. Works for most other things in Debian.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:09 UTC (Thu) by timtas (guest, #2815) [Link] (19 responses)

Amen. What a truly touching sermon. There will come a time, when bla bla bla. Another one bites the dust, I'd say. I guess I'll get my longstanding membership of lwn.net revoked after this post, which makes me sad. I have been following everything Linux related fo the last 20 years and there has never been anything remotely as divisive to the community as systemd, and I bet all the systemd fanboys are wetting their pants from all the attention they receive. It is the sheer universal intrusiveness of the systemd project that leads to this broad resistance, and sadly this intrusiveness is the main goal of systemd, making everything depend on it. And no cheap Lennart Poettering rhetorics can talk away the fact that this is so fundanentally the opposite of how Linux came to be what is today. Linux was able to take all of platform-independent Gnu, all of X11, all of BSD and on and on an so was able to quickly rise to being a usable system for us. And now those systemd hipsters come along and throw all the core principles out of the window. And then people wonder why everybody gets angry.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 3:49 UTC (Thu) by jonnor (guest, #76768) [Link] (1 responses)

The goal is to make things that works better than today/yesterday. Because Linux core system has been developed as a hodgepodge of independent solutions to often partially overlapping problems, by multiple disparate groups of people with little collaboration (especially between distros), many things are* not working as well as it could.
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.

* well, were; systemd project has fixed a lot already

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 11:39 UTC (Fri) by johannbg (guest, #65743) [Link]

" The goal is to make things that works better than today/yesterday."

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
115

Full of distribution spesific bits like...

if [ -f /etc/redhat-release ]
then
. /etc/init.d/functions <-- needless deviation between distro's
...
elif [ -f /etc/SuSE-release ]
then
. /etc/rc.status <--- needless deviation between distro's
...

And supports only RHEL and SLES...

else
echo "This distribution is not supported"
exit 2
fi
....

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
13

An unit file that is self explanatory and usable by --> all <-- systemd based distribution

### dsmcad.service ###

[Unit]
Description=IBM Tivoli Storage Manager Client
Documentation=http://www-01.ibm.com/support/knowledgecenter/SSGSG7_7.1....
After=network.target

[Service]
Type=forking
GuessMainPID=no
ExecStart=/usr/bin/dsmcad
Restart=on-failure

[Install]
WantedBy=multi-user.target

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...
2. http://www-01.ibm.com/support/docview.wss?uid=swg21417165...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 4:03 UTC (Thu) by jonnor (guest, #76768) [Link] (12 responses)

If you are arguing against how the systemd project is set up, why are not not arguing as fervently against the Linux kernel project? It is constructed in a possibly more monolithic way. You cannot run Linux together with another kernel at the same time. They refuse to write code that works also on BSD kernels, GCC is the only supported compiler. All drivers and functionality are supposed to be in _their_ source tree, there is no stable ABI/API for modules. It does networking, disk, audio, video, security policies, IPC, process and memory management, performance monitoring. All in one project, over 10 million lines of code!

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 4:10 UTC (Thu) by jonnor (guest, #76768) [Link]

Heck, every single change has to go through Linus Torvalds to be accepted into mainline.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:28 UTC (Thu) by timtas (guest, #2815) [Link] (9 responses)

So, where did I use the word monolithic? Sometimes, it seems that you systemd fanboys all have a copy of Lennart's "30 myths about systemd" in front of you and then randomly throw one point of it at anybody having any issue with systemd.
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

Posted Nov 13, 2014 8:48 UTC (Thu) by rvfh (guest, #31018) [Link] (5 responses)

> (...) systemd fanboys (...)

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:06 UTC (Thu) by bronson (subscriber, #4806) [Link] (4 responses)

This sounds fascinating! Any chance you wrote it up? I've been meaning to do it too but haven't found the round tuits yet.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 16, 2014 11:22 UTC (Sun) by jonnor (guest, #76768) [Link] (2 responses)

systemd on Raspberry PI you mean? I use Arch Linux on my RPis, which comes with systemd by default. I'd expect installing systemd on RPi on the default Debian-based image to be like in https://wiki.debian.org/systemd
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

Posted Nov 17, 2014 12:37 UTC (Mon) by peter-b (guest, #66996) [Link]

I use systemd on my Pidora print server. It works beautifully. *shrug*

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 13:41 UTC (Mon) by rvfh (guest, #31018) [Link]

Well, I have a spare one that I use for all kinds of tests before I apply them to the 'production' ones (those that manage my lights, gates, radiators...)

I also run the upgrades on that one to make sure things don't break before upgrading the rest :-)

Example of SysVinit and SystemD configs

Posted Nov 17, 2014 13:46 UTC (Mon) by rvfh (guest, #31018) [Link]

If you look in http://sourceforge.net/p/hnet/code/ci/master/tree/etc/dae..., there are two files of interest:
* hnet is the sysvinit script
* hnet.service is the systemd service file

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:00 UTC (Thu) by jonnor (guest, #76768) [Link]

Monolithic was perhaps the wrong word, swap it out for "intrusive" and parse again. My point is that, in many ways, the systemd project (of providing a core base system) is set up like the Linux kernel project. Which seems to have worked out pretty ok. Despite arguments by for instance A. Tannenbaum for a more minimal core and looser coupling of components, which seems like quite analogue.

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.

* Since free operating systems became prevalent at least.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:45 UTC (Thu) by pgoetz (guest, #4931) [Link] (1 responses)

> I was actually talking about the intrusiveness of systemd and in that respect Linux generally alwas played along nicely with the unix ecosystem

Reading your comments gives the strong impression that you don't know very much about systemd. Lots of words, very little relevant content.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:13 UTC (Thu) by bronson (subscriber, #4806) [Link]

Also, the flame wars with the Solaris and BSD guys 1992-1997 demonstrates that Linux has definitely NOT always played along nicely with the unix ecosystem. You can pick almost any subsystem and find traditional Unixers howling that Linux is doing it wrong.

And often it was. :)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:40 UTC (Thu) by Felix (subscriber, #36445) [Link]

You could also mention that all of this code runs with an even higher privilege level than root (for being in the kernel).

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 9:47 UTC (Thu) by imitev (guest, #60045) [Link] (3 responses)

>> I guess I'll get my longstanding membership of lwn.net revoked after this post

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 10:03 UTC (Thu) by timtas (guest, #2815) [Link] (2 responses)

That was a misunderstanding, due to my far from perfect English. I was not intending to revoke my membership, but expect(-ed) it to have it revoked due to the sarcastic opening of my response.
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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 10:27 UTC (Thu) by luya (subscriber, #50741) [Link]

Interchangeability and portability never truly worked on init like sysvinit for Linux kernel as evident of numerous features exposed by systemd, different i.e. non standard implementations of scripts on main distribution. Slackware retained the old BSD init and never used sysvint.

UNIX system virtually abandoned sysvint knowing a core part like init or specifically a system management have to be designed for their own kernels.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 19:53 UTC (Thu) by rahvin (guest, #16953) [Link]

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

Posted Nov 13, 2014 3:37 UTC (Thu) by notninjaz (guest, #99725) [Link] (2 responses)

Nice writeup! Having used SMF on Solaris 10 for the past six years and systemd on a RHEL 7 server for a few months, I can attest that on Solaris, this kind of init system is a mild annoyance but not a total disaster.

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. :-)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 11:16 UTC (Thu) by mezcalero (subscriber, #45103) [Link] (1 responses)

> It sure would be nice to have the default for viewing logs changed to show the entire line instead of abbreviating with "...", too.

It already has been changed in more recent versions of systemd.

Lennart

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:20 UTC (Thu) by notninjaz (guest, #99725) [Link]

This is very welcome news.

Btw, thanks to whomever came up with the name rsyslog.service. I really like it much better than svc:/system/system-log

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 4:08 UTC (Thu) by vkoul (subscriber, #75277) [Link]

Thanks Jon for sane point of view. Really too much has been made out of this debate. Both sides need to calm down after all its just an init system. If you don't like it, replace it with your choice and keep hacking :)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 4:09 UTC (Thu) by neilbrown (subscriber, #359) [Link] (25 responses)

> There is plenty of experience by now to show that Linux systems still work when systemd is installed

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.
So some important issues are complexity, transparency, familiarity, learning curves, etc.

> 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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 8:56 UTC (Thu) by rvfh (guest, #31018) [Link] (2 responses)

> It isn't about whether it works, it is about what it is like to work with.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 22:39 UTC (Fri) by neilbrown (subscriber, #359) [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?

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:
> Simple things should be simple, complex things should be possible.

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.
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

Posted Nov 21, 2014 17:56 UTC (Fri) by Wol (subscriber, #4433) [Link]

> > It isn't about whether it works, it is about what it is like to work with.

> 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,
Wol

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 9:35 UTC (Thu) by anselm (subscriber, #2796) [Link] (21 responses)

So some important issues are complexity, transparency, familiarity, learning curves, etc.

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.

All the heat makes is very hard to address the other issues coherently.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:10 UTC (Thu) by skorgu (subscriber, #39558) [Link] (3 responses)

Systemd in and of itself, sure. It is a bit of a lightning rod/poster child for a definite change in how systems are built though and teasing those two roles apart isn't always easy. I was trying to debug an early-boot process in CentOS 7 this week which supports both a complex set of shell scripts in the form of /etc/init.d/network (now started through systemd) and NetworkManager.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 19:33 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

A better solution would have been to add a em1 dependency to the NetworkManager target. It can be done by creating a socket unit depending on the em1 device and adding it to the dependency list.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 18:59 UTC (Fri) by skorgu (subscriber, #39558) [Link] (1 responses)

I didn't think of that, thanks for the suggestion!

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 19:03 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I don't think that socket targets actually depend on the network-online target, they are activated directly by udev events. So it should have helped.

Also, can you file a bug for this? It's clearly an issue that should be fixed.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 6:07 UTC (Fri) by ploxiln (subscriber, #58395) [Link]

If only systemd was just for running services. If only!

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 23:36 UTC (Fri) by neilbrown (subscriber, #359) [Link] (15 responses)

> How much more complex can you get?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:24 UTC (Sat) by anselm (subscriber, #2796) [Link] (7 responses)

My preferences is generally towards having a simple engine

“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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 1:44 UTC (Sat) by dlang (guest, #313) [Link] (6 responses)

actually, what you dismiss as a whole pile of shell scripts doing almost the same thing is actually frequently a small amount of boilerplate that is calling the helper functions (as scripts or binaries) that provide exactly the type of extensions that you are saying need to be added

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 5:42 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

Except that helper functions are not really helpful at all. They don't do namespacing, SELinux or even bad old chrooting. They barely provide PID file tracking, and even that without daemon readiness protocol or anything like this.

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...

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 1:46 UTC (Mon) by neilbrown (subscriber, #359) [Link] (2 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.

Is it?
What if your policy is algorithmic in nature, or is more complex than the designers of the config file imagined?

TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.
Are they all gross violations? (I almost added PHP to the list, but that might hurt my argument....)

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:07 UTC (Tue) by nix (subscriber, #2304) [Link] (1 responses)

TCL, lua, javascript are all languages that effectively allow very sophisticated tools to be configured in very sophisticated ways.

Are they all gross violations?

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

Posted Nov 18, 2014 2:40 UTC (Tue) by zlynx (guest, #2285) [Link]

Sort of. But serious users of JSON never stick it into a string and eval(). That way lies nightmares and security holes.

In best practice JSON is non-executable.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 9:07 UTC (Sat) by fandingo (guest, #67019) [Link] (6 responses)

Why do you speak in metaphors and veiled examples in your several replies? What's the metaphor: game engines, search engines, steam engines, locomotives?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 12:02 UTC (Sat) by viro (subscriber, #7872) [Link] (1 responses)

"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."

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 12:56 UTC (Sat) by pizza (subscriber, #46) [Link]

> Off-topic, but... Jet engines getting "practically no maintenance" are the stuff of which the nightmares are made...

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 0:57 UTC (Mon) by neilbrown (subscriber, #359) [Link] (1 responses)

> Why do you speak in metaphors

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.
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.

"Requisite" is a requirement with no signal
"Wants" is a signal with no requirement
"Requires" is a combination of the two.

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.
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.

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 18:58 UTC (Mon) by cebewee (guest, #94775) [Link]

A nice property of a restricted language is that it is usually much more accessible to static analysis (and turing-complete languages aren't). This might be one of the reasons why the systemd developers lean on this side of exposing functionality.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 1:33 UTC (Mon) by neilbrown (subscriber, #359) [Link] (1 responses)

> Why do you speak in ... veiled examples in your several replies?

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.
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.

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.
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".

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:
1/ wait the timeout
2/ assemble the md array
3/ activate the LVM volume

all of which it does correctly. During this time, systemd is waiting for the root device to appear.
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.

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Mar 13, 2015 0:37 UTC (Fri) by neilbrown (subscriber, #359) [Link]

For the record, the problem with dracut was that it has a systemd 'generator' which only creates the important files the first time it is run: rootfs-generator.sh

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 9:47 UTC (Thu) by tialaramex (subscriber, #21167) [Link] (5 responses)

It's good to see a subscriber-only thread for this.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 10:12 UTC (Thu) by cesarb (subscriber, #6266) [Link] (1 responses)

> It's good to see a subscriber-only thread for this.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 22:06 UTC (Mon) by eean (subscriber, #50420) [Link]

Judging by this train-wreck of a thread:
http://lwn.net/Articles/621003/

It didn't come soon enough. :/

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 2:59 UTC (Thu) by ksandstr (guest, #60862) [Link] (2 responses)

Sir, your generation wouldn't recognize a troll if one told you to slaughter Irish orphans for lunchmeat and then bit you in the arse to drive the point home further.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 14:04 UTC (Thu) by mathstuf (subscriber, #69389) [Link] (1 responses)

Have you considered writing for HBO?

https://youtube.com/watch?v=g4PuFAb-XIQ

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 14:05 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

Oops, wrong comment to reply to.

On devfs and udev

Posted Nov 13, 2014 10:38 UTC (Thu) by cesarb (subscriber, #6266) [Link] (8 responses)

Setting aside the amount of debate, I'd argue that the devfs equivalent was upstart, and that systemd is more like 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.

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).

On devfs and udev

Posted Nov 13, 2014 11:46 UTC (Thu) by luya (subscriber, #50741) [Link]

That is already possible as explained by this documentation:
http://freedesktop.org/wiki/Software/systemd/MinimalBuilds/

GENEVI, Angstrom and other embedded companies already applied similar method above. Also take a look at:
http://lccoelce14.sched.org/event/2b63b9b5ab23a133c8c2a62...

On devfs and udev

Posted Nov 13, 2014 12:10 UTC (Thu) by csamuel (✭ supporter ✭, #2624) [Link] (1 responses)

I am completely agnostic to systemd at present but for the sake of info there is uselessd that might (eventually) provide what you're after as a "systemd lite":

http://uselessd.darknedgy.net/

"a project to reduce systemd to a base initd, process supervisor and transactional dependency system, while minimizing intrusiveness and isolationism".

On devfs and udev

Posted Nov 13, 2014 22:30 UTC (Thu) by mathstuf (subscriber, #69389) [Link]

There is also systembsd[1].

[1]http://undeadly.org/cgi?action=article&sid=2014091506...

On devfs and udev

Posted Nov 13, 2014 16:41 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (2 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.

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.

On devfs and udev

Posted Nov 13, 2014 17:34 UTC (Thu) by johannbg (guest, #65743) [Link] (1 responses)

It started out as Launchd + SMF + Linux integration and improvements sprinkled on top of that. I'm unsure how much upstart was taken into the original picture thou.

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?

On devfs and udev

Posted Nov 13, 2014 22:26 UTC (Thu) by eean (subscriber, #50420) [Link]

Ha, I didn't know this history, makes all the "but but the Unix way" arguments a bit ironic.

On devfs and udev

Posted Nov 21, 2014 10:16 UTC (Fri) by horsethief (guest, #99889) [Link] (1 responses)

I agree, it's not its final form, and we will have a further init system.

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.

On devfs and udev

Posted Nov 21, 2014 12:34 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

It is split into components. Sure, it all ships in one tarball/blob (as does coreutils, binutils, FreeBSD core, OS X, and others), but that doesn't mean you can't replace just certain bits (as I can with any of those projects listed). Though, yes, journald, systemd (the PID 1 binary), and logind might require more code replacement than just the single binary due to the architecture, that's 3 binaries out of 69 which might be not-as-straightforward and are at the *core* of the project, so that seems reasonable to me.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 12:01 UTC (Thu) by dps (guest, #5725) [Link] (5 responses)

I have some *very* negative experience of systemd. A box which has systemd and local media was rendered unbootable by a networking problem unless I used init=/bin/bash and did things manually. However desirable the remainder of systemd might be this sort of behaviour is a huge step in the wrong direction.

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.

The Grumpy Editor's guide to surviving the systemd debate

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 14:49 UTC (Thu) by JGR (subscriber, #93631) [Link]

Changing the firewall rules at run time, logging/reporting, various forms of error handling and recovery (network goes down then up after init, etc.) and so on generally need some form of user-space.
It's quite possible implement these without sacrificing security.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:15 UTC (Thu) by dlang (guest, #313) [Link]

real firewalls are more than just packet filtering, no matter what Cisco and Checkpoint try to tell you.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 15:35 UTC (Thu) by jonnor (guest, #76768) [Link] (1 responses)

Are shell scripts ran as root more suitable for this paranoid system? That is what sysvinit mostly is afterall.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:17 UTC (Thu) by dlang (guest, #313) [Link]

Yes, because you can easily delete them if you don't want them to run.

It's not as if the shell scripts are being provided by the attacker or handling any data provided by the attacker.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 15:20 UTC (Thu) by p2290 (subscriber, #39950) [Link]

Well stated!

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 15:39 UTC (Thu) by rsidd (guest, #2582) [Link] (15 responses)

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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 15:59 UTC (Thu) by halla (subscriber, #14185) [Link]

"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."

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:03 UTC (Thu) by Felix (subscriber, #36445) [Link] (3 responses)

> 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.

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:43 UTC (Thu) by halla (subscriber, #14185) [Link]

Yes, we have. There are millions of plain, ordinary non-developer, non-geek users of Linux. In my circle of acquaintances, there are artists, musicians, writers, students, scientists, grandparents, parents, children, civil servants and, yes, geeks, who use Linux.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:40 UTC (Thu) by rsidd (guest, #2582) [Link] (1 responses)

If you had said "10% of all gaming revenues", that would have been a good talking point.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:45 UTC (Thu) by jspaleta (subscriber, #50639) [Link]

how big is the android gaming market nowadays?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:10 UTC (Thu) by jonnor (guest, #76768) [Link] (6 responses)

systemd is superior to sysvinit (and upstart) for embedded systems, servers and light container/VM OSes for "the cloud".

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 16:44 UTC (Thu) by pj (subscriber, #4506) [Link] (5 responses)

So, speaking of other systems, what has the general reaction from distros like OpenWRT and OpenEmbedded been to systemd? positive? negative? indifferent? Has anyone from the systemd project tried to put systemd on a system of that size? I've seen little press, if so, and I think it would likely be several points in favor of systemd if the superiority you cite (sadly without references) was quantified and publicized.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 19:24 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

There are uclibc-based builds of systemd for OpenWRT. So it's definitely interesting for embedded people.

I've used one of the earlier versions of systemd a couple of years ago on my embedded systems.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 22:10 UTC (Thu) by ebiederm (subscriber, #35028) [Link]

Openwrt uses something much slimmer the systemd.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 7:39 UTC (Fri) by koenkooi (subscriber, #71861) [Link]

<pet peeve>OE is not a distro, it can build one</pet peeve> I've been using systemd happily on all my embedded systems and even gave a few presentations about it: http://elinux.org/images/b/b3/Elce11_koen.pdf

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 7:42 UTC (Fri) by mokki (subscriber, #33200) [Link]

I am writing this comment on Jolla ohone. Jolla/SailfishOS uses systemd +wayland+btrfs. All this released in a 2013.
Works smoothly from end user point of view.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 15:34 UTC (Fri) by andza (guest, #72692) [Link]

Well, we have systemd support integrated in OpenEmbedded as well as in Buildroot... So, yes, it's definitely of interest for quite a few embedded systems.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:45 UTC (Thu) by thoeme (subscriber, #2871) [Link]

>People who need a real computer use Mac, Windows,
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.

>Linux desktop/workstation users ... And they don't need systemd.
Well I like my notebook to boot fast...which it does thanks to systemd.

YMMV,Thöme

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:23 UTC (Thu) by rodgerd (guest, #58896) [Link]

> greybeard sysadmins do care (negatively) and it is they who are behind the current backlash.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 20:46 UTC (Thu) by misc (subscriber, #73730) [Link]

> but LOTS of users care about the poisonous atmosphere that has arisen
> about the entire linux ecosystem in recent years.

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.
https://www.change.org/p/lennart-poettering-stop-writing-...

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 ).
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 ).

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:45 UTC (Thu) by marcH (subscriber, #57642) [Link]

> 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.

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)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 17:57 UTC (Thu) by marcH (subscriber, #57642) [Link] (1 responses)

> Avoiding "not our problem" responses when things break would be helpful.

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 :-)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 18:35 UTC (Thu) by pflugstad (subscriber, #224) [Link]

> I think it's difficult but possible to be an engineer and a human being at the same time :-)

QotW nomination here :-)

devfs is not gone

Posted Nov 13, 2014 22:29 UTC (Thu) by ebiederm (subscriber, #35028) [Link] (4 responses)

For some interesting reading go look in an old version of udev for it's why not devfs document, then compare that to what is delivered today with udev.

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.

devfs is not gone

Posted Nov 14, 2014 3:34 UTC (Fri) by zuki (subscriber, #41808) [Link] (3 responses)

Do you mean docs/udev_vs_devfs?

It contained the following:

>The Problems:
> 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.

> 2) We are (well, were) running out of major and minor numbers for
> devices.
Check.

> 3) Users want a way to name devices in a persistent fashion (i.e. "This
> 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.

> 4) Userspace programs want to know when devices are created or removed,
> and what /dev entry is associated with them.
Check.

>The constraints:
> 1) No policy in the kernel!
Check.

> 2) Follow standards (like the LSB)
Check.

> 3) must be small so embedded devices will use it.
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.

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.

devfs is not gone

Posted Nov 18, 2014 0:23 UTC (Tue) by nix (subscriber, #2304) [Link] (2 responses)

The constraints:

1) No policy in the kernel!

Check.

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.

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?

devfs is not gone

Posted Nov 20, 2014 14:59 UTC (Thu) by nye (guest, #51576) [Link] (1 responses)

>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.

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?

devfs is not gone

Posted Nov 20, 2014 16:11 UTC (Thu) by zuki (subscriber, #41808) [Link]

Yes.

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
> 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

Posted Nov 13, 2014 23:43 UTC (Thu) by liquidweb (guest, #99771) [Link]

i really dont have any comments for the systemd update at this time.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 12:26 UTC (Fri) by k8to (guest, #15413) [Link] (8 responses)

I think almost all the commentary is kind of missing the boat, including this article. I'm pretty much in full agreement with this article, and think people who care at all about the topic,or the metatopic, should read http://uselessd.darknedgy.net/ProSystemdAntiSystemd/

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 12:29 UTC (Fri) by k8to (guest, #15413) [Link] (4 responses)

Err, I meant the above article misses the boat a bit, and the linked article is on the money.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 15:40 UTC (Fri) by rsidd (guest, #2582) [Link] (3 responses)

The question is, will the anti-systemd folks actually do something about it? There seems to be consensus that (a) sysvinit has outlived its usefulness (b) there is no replacement that looks more attractive than systemd (even the original upstart author, Scott James Remnant, seems to think systemd is better today). I have not used a systemd-based system and have no technical objections to it. My objection is to the authors' philosophy that only Linux matters (I have used FreeBSD and Dragonfly BSD in the past), and to the tendency to make systemd a hard dependency of userland software (especially in Gnome) as opposed to merely a better way to handle dependencies when booting a system.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 16:13 UTC (Fri) by johannbg (guest, #65743) [Link]

That's rather interesting perspective since there is nothing that says that open or closed software has to be share-able between OS and there is nothing wrong with writing software specifically with spesific OS in mind be it Windows, BSD, Linux, OS-X or Solaris to take directly benefits of what relevant OS has to offer.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:15 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link]

(b) there is no replacement that looks more attractive than systemd

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).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 22:35 UTC (Fri) by raven667 (subscriber, #5198) [Link]

If people who want systemd features on BSD want to go down this path the option is always available to port systemd to a new OS with its own repo. Different OSs make different decisions though, BSD already had a totally different init system than most Linux systems, and has a different kernel with different features. If you are a userspace software developer, the kernel and low level plumbing outside of POSIX (packet filtering, or *notify or kqueue or cgroups, jails or namespaces) on different systems is going to always be different, if you use a platform-specific feature then you have to think about portability, either re-implementing chunks of code for different kernels or accepting that you can only run on a particular platform.

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.

Uselessd

Posted Nov 17, 2014 1:02 UTC (Mon) by ras (subscriber, #33059) [Link] (2 responses)

The person behind uselessd writes more insight into systemd than most, and he puts that on display in the uselessd home page. It's an excellent read if you have the time.

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
> 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 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.

Uselessd

Posted Nov 17, 2014 3:29 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't think there is a "threat" here, implicit or otherwise, and Lennart doesn't do all the work, there are plenty of other developers and if his leadership is a problem for other developers and downstream users then they can fork it, like Xorg/Xfree86, and move on.

Uselessd

Posted Nov 17, 2014 9:33 UTC (Mon) by anselm (subscriber, #2796) [Link]

Its a threat by the person currently doing all the work, effectively saying "it's my way or the highway".

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”.

systemd from a different POV

Posted Nov 14, 2014 12:29 UTC (Fri) by karath (subscriber, #19025) [Link]

My thoughts on the systemd project are mixed but largely positive.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 15:38 UTC (Fri) by clemensg (guest, #94377) [Link] (6 responses)

"It is just a system initialization utility"
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

Posted Nov 14, 2014 19:09 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

Systemd-as-a-project has stopped being just an init tool. It's now a plumbing layer replacement for Linux.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 20:45 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (4 responses)

Systemd-as-a-project has stopped being just an init tool. It's now a plumbing layer replacement for Linux.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:54 UTC (Fri) by jspaleta (subscriber, #50639) [Link] (1 responses)

What I just heard you say was...
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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 21:57 UTC (Fri) by mgb (guest, #3226) [Link]

> 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.

Agreed. Systemd-shim cannot succeed inside systemd's anti-innovation framework. Consolekit2 outside systemd is the future.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 5:49 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

Well, yes. Renaming the project might help with the politics. I'm not so sure about splitting into multiple subprojects. Systemd is just not yet big enough for that (though it does approach the threshold where it might start making sense).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 15, 2014 22:42 UTC (Sat) by misc (subscriber, #73730) [Link]

So we would explicitly acknowledge that we care than more than the purely technical merits ( not that this would be a bad thing, since we do not really care about technical merits only, but given the not so recent discussions around "meritocracy", it would be a interesting twist ).

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 3:22 UTC (Mon) by tytso (✭ supporter ✭, #9993) [Link] (6 responses)

I really don't think it's about systemd the init process. If it were only about systemd unit files and socket activation, I'd be all for systemd. It's certainly better than sysvinit scripts, although there are still things which are easier for me to configure with init scripts than with systemd unit files --- and in the worst case, if I really have to, I can hard code dependencies and have unit files that fire off shell scripts if it's the only way I can work around some broken daemon startup. Or heck, I'll just start up the daemon by hand. It wasn't all that long ago that the way I got onto the network was to su to root and run "dhclient"...

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 7:10 UTC (Mon) by jspaleta (subscriber, #50639) [Link] (1 responses)

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?

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.
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...

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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:33 UTC (Tue) by nix (subscriber, #2304) [Link]

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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 7:29 UTC (Mon) by tao (subscriber, #17563) [Link] (3 responses)

Out of curiosity it'd be interesting to hear examples of what interfaces systemd has broken of the ones that are flagged as non-experimental/non-internal? In my opinion I think it's rather fair that programmers shouldn't be expecting interfaces flagged as "API not stable" to have a stable API, while they should be able to rely on the APIs covered by an API guarantee to remain stable.

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 21:32 UTC (Mon) by lsl (subscriber, #86508) [Link] (1 responses)

> The in-kernel webserver came and went.

You're talking about Tux, right? It was never part of mainline Linux in the first place.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 21:55 UTC (Mon) by mjg59 (subscriber, #23239) [Link]

khttpd was around for a while in the 2.2 era.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 18, 2014 0:36 UTC (Tue) by nix (subscriber, #2304) [Link]

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).

Unless, that is, you really think people use strfry() or memfrob() a lot.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 14:24 UTC (Mon) by palmer_eldritch (guest, #95160) [Link] (1 responses)

And now Russ Allbery resigns from the tech committee: https://lists.debian.org/debian-project/2014/11/msg00054....

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 17, 2014 15:13 UTC (Mon) by johannbg (guest, #65743) [Link]

It's huge loss for the Debian community loosing Russ which from my point ov view is the voice of reason in the community from serving on TC as well as loosing Tollef from the systemd maintainership and Joey in general.

I would not be surprise if others will follow in their footsteps.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 14:58 UTC (Thu) by phred14 (guest, #60633) [Link] (54 responses)

I guess I must chime in here.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 17:25 UTC (Thu) by kmacleod (guest, #88058) [Link] (53 responses)

I think the better comparison would be to replace systemd with "Linux", sysv with "Solaris", and upstart with "BSD".

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 18:50 UTC (Thu) by dlang (guest, #313) [Link] (52 responses)

> I think the better comparison would be to replace systemd with "Linux", sysv with "Solaris", and upstart with "BSD".
>
> 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 19:15 UTC (Thu) by kmacleod (guest, #88058) [Link]

Oddly enough I think that's exactly what I said, I think we just disagree on the severity or long term effect of the problem.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 21:17 UTC (Thu) by njs (subscriber, #40338) [Link] (50 responses)

Which existing APIs are you thinking of? Solaris and OS X and the BSDs all have different init systems with different APIs to start with of course. Systemd's socket activation API was intentionally designed to stick close to the Solaris and OS X socket activation APIs to facilitate software portability. And there's the ConsoleKit mess I guess, but (a) everyone seems to agree that the old API there was terrible anyway, and (b) the systemd developers seem to have tried hard to keep ConsoleKit and its API alive (finding a new maintainer for it etc.), and then other people flaked out, so it's hard to blame them for that. And anyway that's a case of replacing one d-bus API with a different d-bus API, and also the one case where there's famously a non-systemd implementation, so it doesn't sound like what you're thinking of. What am I missing?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 22:19 UTC (Thu) by dlang (guest, #313) [Link] (49 responses)

DNS and logging are both cases where they are introducing new APIs and working to get people to switch to them in a way that would make the apps not work without systemd.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 20, 2014 23:27 UTC (Thu) by kmacleod (guest, #88058) [Link] (45 responses)

> in a way that would make the apps not work without systemd

Can you be more specific what's preventing the apps from supporting run-time or compile-time access to other APIs?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 1:46 UTC (Fri) by raven667 (subscriber, #5198) [Link] (44 responses)

I don't see how this is different than any other portability, like an app that supports kqueue or epoll, if the developer wants the app to be portable then they have to write the code to deal with other systems which have different symantics. If you don't want the new features you can continue to use the old APIs for as long as you want, (like syslog() or gethostbyname(), they will be supported effectively forever.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 2:37 UTC (Fri) by dlang (guest, #313) [Link] (43 responses)

In theory this isn't different from any other portability issue.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 3:31 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

> But creating new APIs for basic plumbing functionality like name lookups and logging is not a good thing to be doing for portability.
I think it's a good thing. The old API has become ossified and is not really suited for the modern needs.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 3:45 UTC (Fri) by dlang (guest, #313) [Link] (6 responses)

> I think it's a good thing. The old API has become ossified and is not really suited for the modern needs.

What is the exact failure with the existing APIs that cannot be solved without involving DBUS?

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 3:49 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (5 responses)

They are not asynchronous, they don't cope well with international domain names, no support for DNSSEC, poor support for multiple networks and interfaces (no way to do gethostbyname limited to a single interface) - that's what I personally encountered.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 8:33 UTC (Fri) by rleigh (guest, #14622) [Link] (4 responses)

Assuming that all these are true and are important problems which need fixing, a dbus API and service is still an awful solution to the problem. It could be trivially implemented in a simple library. It could also be discussed on the Austin list and fixed in POSIX if people really care about having these things fixed properly for the long term.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 9:09 UTC (Fri) by peter-b (guest, #66996) [Link] (2 responses)

> Assuming that all these are true and are important problems which need fixing, a dbus API and service is still an awful solution to the problem. It could be trivially implemented in a simple library.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 11:14 UTC (Fri) by rleigh (guest, #14622) [Link] (1 responses)

Trivial in the sense that it would be simpler and more portable to do via a standard library interface than via dbus. And the work has apparently already been done given that there's an implementation out there using dbus in systemd.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 11:17 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> Trivial in the sense that it would be simpler and more portable to do via a standard library interface than via dbus.

Um. D-Bus *is* a standard library interface in practically every mainstream programming language.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 25, 2014 22:16 UTC (Tue) by nix (subscriber, #2304) [Link]

Quite. It's not like the Austin Group is a bunch of terrible monsters who beat off people making suggestions with flaming shovels.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 2:50 UTC (Sat) by thedevil (guest, #32913) [Link] (34 responses)

"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?"

I should _really_ leave this topic alone but I cannot, sigh.

You're veering into the philosophical. What is "force"?
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.

And many of those saying nobody forces me to use systemd seem to
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.

Maybe we should agree that the word "force", like "socialism",
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

Posted Nov 22, 2014 5:18 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (33 responses)

> What is "force"? 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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 17:37 UTC (Sat) by thedevil (guest, #32913) [Link] (26 responses)

"Giving someone additional options which they can choose to ignore
doesn't seem at all like force."

"you are free to continue using the software as it exists today"

This just shifts the question from "force" to "free choice". 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.

You are right, though, that my example was a bad one as I posed
it.

"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."

I am not a totally passive recipient, I am an occassional Debian
contributor. And, apparently roughly 30% of DDs agree with me.
Are they also "taking advantage of others' work"?

systemd is no detail. Adoption of systemd in its full scope would make
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

Posted Nov 22, 2014 20:10 UTC (Sat) by nybble41 (subscriber, #55106) [Link] (25 responses)

> I am not a totally passive recipient, I am an occassional Debian contributor. And, apparently roughly 30% of DDs agree with me. Are they also "taking advantage of others' work"?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 20:39 UTC (Sat) by thedevil (guest, #32913) [Link] (23 responses)

"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."

Sorry, no. Running today's software, bit by bit, in 2 years (even
assuming my hardware lasts that long) would be a worse option than not
using computing at all. And you know that.

"they could just submit patches to ensure that the packages they're
interested in continue to work with other init systems in Debian proper"

This is what I pin my hopes on, but the tone adopted by many DDs in the
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

Posted Nov 22, 2014 21:02 UTC (Sat) by vonbrand (guest, #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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 1:42 UTC (Sun) by thedevil (guest, #32913) [Link] (21 responses)

My point (a minor and apropos one, anyway) was that this is a new
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.

I actually agree with you about the vision, but the problem for me is
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.

Bowing out of this debate for good; since the effort to switch to
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

Posted Nov 23, 2014 1:53 UTC (Sun) by Zack (guest, #37335) [Link] (19 responses)

Please consider GNU/kFreeBSD in your list of alternatives to explore. It has 90% of the archive build, so you likely won't miss out on any apt goodness, it works like GNU (because it is GNU), and is endorsed by systemd's lead developer as positively remaining systemd free.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 24, 2014 12:27 UTC (Mon) by anselm (subscriber, #2796) [Link] (18 responses)

[…] and is endorsed by systemd's lead developer as positively remaining systemd free.

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.)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 24, 2014 14:14 UTC (Mon) by johannbg (guest, #65743) [Link] (17 responses)

Dam you spoiled the surprise for the anti-systemd crowd that would go running over to FreeBSD in the masses due to systemd being installed on their favourite linux distro only to find a launchd alternative, bsd kernel spesific and on feature par with systemd in the future ;)

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 29, 2014 9:01 UTC (Sat) by blujay (guest, #39961) [Link] (16 responses)

What a petty comment. You sound as if you want systemd dissenters to be miserable, as if they did something to harm you and you want to see them suffer in return. This kind of sore-winner attitude is part of the problem the dissenters have with the systemd movement. It's the opposite of the attitudes of cooperation and congenial coexistence that have made Debian and the rest of the FOSS movement possible.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 15:23 UTC (Sun) by foom (subscriber, #14868) [Link] (15 responses)

> The problem is that he explicitly refuses to even accept patches from others to that end.

No. That would only be a problem if:
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.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 20:34 UTC (Sun) by dlang (guest, #313) [Link] (14 responses)

why would someone waste time creating such patches when the project has already stated that they won't accept them?"

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 20:45 UTC (Sun) by vonbrand (guest, #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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 21:02 UTC (Sun) by dlang (guest, #313) [Link] (2 responses)

I remember those days, but you only go to that sort of effort if you _really_ want the functionality provided and it's worth maintaining a fork.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 23:21 UTC (Sun) by vonbrand (guest, #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.

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 2:58 UTC (Tue) by blujay (guest, #39961) [Link] (8 responses)

There certainly is such a reason: the ways in which systemd and OpenSSH are developed are a world apart. OpenSSH changes slowly, valuing stability and predictability and correctness, actively expecting people to maintain its portability patches, knowing that a wide variety of platforms and projects depend on it around the world. Systemd changes rapidly and incompatibly, explicitly disregarding backwards compatibility and the needs of other projects. The effort required to maintain portability patches for each is incomparable.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 5:04 UTC (Tue) by pizza (subscriber, #46) [Link] (4 responses)

> There certainly is such a reason: the ways in which systemd and OpenSSH are developed are a world apart.

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
* 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)

> 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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 3, 2014 0:26 UTC (Wed) by blujay (guest, #39961) [Link] (3 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.

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?

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 3, 2014 2:24 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> 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?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 3, 2014 6:36 UTC (Wed) by blujay (guest, #39961) [Link]

You did not refute a single point I made. I rest my case. Systemd proponents (at least, some of these vocal ones) say one thing, expect another, and then criticize when people decline to waste their own time playing catch-up to a project expressly disinterested in portability. "We won't accept portability patches.... Why aren't you porting it? This proves that no one cares."

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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 3, 2014 10:13 UTC (Wed) by anselm (subscriber, #2796) [Link]

No one is expected to port systemd to other platforms, because it's not expected at all!

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).

The Grumpy Editor's guide to surviving the systemd debate

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 17:41 UTC (Tue) by dlang (guest, #313) [Link] (1 responses)

given that the scope of systemd is not defined, how long for it to settle down? it could be a couple of decades.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Dec 2, 2014 20:51 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

> 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.
Uhm, you still NEED cgroups to use systemd. It can't really work without them.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 24, 2014 10:31 UTC (Mon) by jezuch (subscriber, #52988) [Link]

> since the effort to switch to systemd with all its family is comparable to switching to a new distro

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.]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 20:41 UTC (Sat) by vonbrand (guest, #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...

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 20:07 UTC (Sun) by cas (guest, #52554) [Link] (5 responses)

the trouble with your "obvious" "reasonable philosophy" is that it is exploitation, taking advantage of other people's misfortune. your example is ethically no different than finding lost children in a forest and "offering" them a choice between coming home with you and being your sex toy or just being ignored and left where they are. they are, after all, free to reject your offer and starve or be eaten by bears or die from hypothermia.

The fact that US Libertarians can't see this goes a long way to highlighting what's wrong with them.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 22:43 UTC (Sun) by nybble41 (subscriber, #55106) [Link]

> the trouble with your "obvious" "reasonable philosophy" is that it is exploitation, taking advantage of other people's misfortune.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 22:45 UTC (Sun) by viro (subscriber, #7872) [Link]

As much as I dislike the randians, that one's over the top. s/child/grown-up/ and it might become a bit more adequate - still somewhat of a stretch, though. Your variant is beyond "a stretch", though - there are informed consent issues that make your comparison invalid.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 29, 2014 9:22 UTC (Sat) by blujay (guest, #39961) [Link] (2 responses)

So what should the hypothetical libertarian capitalist do then? Not offer the man a job at all?

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 20:16 UTC (Sun) by cas (guest, #52554) [Link] (1 responses)

or he could just steal what he needs from rich and/or exploitative jerks.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 20:54 UTC (Sun) by corbet (editor, #1) [Link]

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

Posted Nov 21, 2014 1:18 UTC (Fri) by njs (subscriber, #40338) [Link] (2 responses)

So what's the existing portable non-dbus DNS management API that they're replacing? For that matter, what's the dbus-based DNS management API that they've added? (I can't find any docs describing such a thing on the systemd website, but am not an expert on DNS stuffs.)

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.)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 2:40 UTC (Fri) by dlang (guest, #313) [Link] (1 responses)

syslog can handle the additional metadata, systemd has just opted to do something incompatible.

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 2:48 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

> What it replaces is the gethostbyname() and similar functions of the existing libc options.

Well no. It doesn't replace anything. It is an additional option.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 21, 2014 20:35 UTC (Fri) by sorpigal (subscriber, #36106) [Link]

I think we all know what the real issue is with systemd: The use of the .service extension. Obviously this should have been .daemon; Lennart's Windows-centric worldview clearly motivated the choice of service over daemon, in direct contravention of the uniX Commandments as brought down on magnetic tablets from Mt. Bell.

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.
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

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 2:25 UTC (Sat) by thedevil (guest, #32913) [Link] (4 responses)

"Some of us will remember the multi-year dispute over the devfs
filesystem"

This analogy has a problem. devfs was never a required part of a
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.

"Systemd will either be established and successful, or it will
have been replaced by something better."

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

Posted Nov 22, 2014 10:16 UTC (Sat) by anselm (subscriber, #2796) [Link] (3 responses)

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 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.)

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 22, 2014 18:16 UTC (Sat) by thedevil (guest, #32913) [Link] (2 responses)

"sufficiently unhappy with systemd to actually roll up their
sleeves to come up with something"

"nobody so far has condescended to propose a better design"

You assume this is just due to laziness or pure troll malice, but
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

Posted Nov 23, 2014 2:43 UTC (Sun) by seyman (subscriber, #1172) [Link] (1 responses)

> The solution isn't a complete redesign but splitting it up

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.

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 23, 2014 7:13 UTC (Sun) by brodo (subscriber, #4049) [Link]

> 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.

... or even something like "make config".


Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds