LWN: Comments on "The Grumpy Editor's guide to surviving the systemd debate"

The Grumpy Editor's guide to surviving the systemd debate

neilbrown — Fri, 13 Mar 2015 00:37:26 +0000

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

Nobody expects the spanish plonk squad!

nix — Thu, 11 Dec 2014 17:04:48 +0000

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

The Grumpy Editor's guide to surviving the systemd debate

mathstuf — Thu, 11 Dec 2014 03:03:22 +0000

Is this[1] it?

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

Nobody expects the spanish plonk squad!

mathstuf — Wed, 10 Dec 2014 20:53:47 +0000

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!

nix — Wed, 10 Dec 2014 16:32:38 +0000

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!

The Grumpy Editor's guide to surviving the systemd debate

anselm — Wed, 03 Dec 2014 10:13:57 +0000

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

blujay — Wed, 03 Dec 2014 06:36:59 +0000

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

pizza — Wed, 03 Dec 2014 02:24:16 +0000

> 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

blujay — Wed, 03 Dec 2014 00:26:20 +0000

> 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

Cyberax — Tue, 02 Dec 2014 20:51:29 +0000

> 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

dlang — Tue, 02 Dec 2014 17:41:16 +0000

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

anselm — Tue, 02 Dec 2014 08:34:10 +0000

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

pizza — Tue, 02 Dec 2014 05:04:25 +0000

> 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

blujay — Tue, 02 Dec 2014 02:58:13 +0000

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

anselm — Mon, 01 Dec 2014 00:46:01 +0000

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

vonbrand — Sun, 30 Nov 2014 23:21:54 +0000

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

anselm — Sun, 30 Nov 2014 22:33:44 +0000

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

dlang — Sun, 30 Nov 2014 21:02:13 +0000

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

corbet — Sun, 30 Nov 2014 20:54:12 +0000

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

vonbrand — Sun, 30 Nov 2014 20:45:03 +0000

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

dlang — Sun, 30 Nov 2014 20:34:25 +0000

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

cas — Sun, 30 Nov 2014 20:16:23 +0000

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

foom — Sun, 30 Nov 2014 15:23:14 +0000

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

Nobody expects the spanish plonk squad!

dlang — Sun, 30 Nov 2014 01:43:27 +0000

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

Nobody expects the spanish plonk squad!

mgb — Sat, 29 Nov 2014 16:49:09 +0000

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!

ksandstr — Sat, 29 Nov 2014 16:29:10 +0000

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

The Grumpy Editor's guide to surviving the systemd debate

blujay — Sat, 29 Nov 2014 09:22:42 +0000

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

blujay — Sat, 29 Nov 2014 09:01:48 +0000

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.

Nobody expects the spanish plonk squad!

Cyberax — Sat, 29 Nov 2014 03:15:55 +0000

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!

mgb — Sat, 29 Nov 2014 00:39:27 +0000

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

viro — Sat, 29 Nov 2014 00:10:35 +0000

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!

anselm — Fri, 28 Nov 2014 23:05:27 +0000

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!

dlang — Fri, 28 Nov 2014 22:47:47 +0000

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!

anselm — Fri, 28 Nov 2014 22:40:43 +0000

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!

mgb — Fri, 28 Nov 2014 22:24:56 +0000

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

dlang — Fri, 28 Nov 2014 22:06:48 +0000

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

The Grumpy Editor's guide to surviving the systemd debate

viro — Fri, 28 Nov 2014 19:11:35 +0000

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

Nobody expects the spanish plonk squad!

foom — Fri, 28 Nov 2014 15:58:59 +0000

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

ksandstr — Fri, 28 Nov 2014 15:15:37 +0000

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

mathstuf — Fri, 28 Nov 2014 13:52:20 +0000

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