The Grumpy Editor's guide to surviving the systemd debate [LWN.net]

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 30, 2014 22:33 UTC (Sun) by anselm (subscriber, #2796)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by dlang
Parent article: The Grumpy Editor's guide to surviving the systemd debate

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.

to post comments

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.