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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 14, 2014 4:03 UTC (Fri) by mathstuf (subscriber, #69389)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by mgb
Parent article: The Grumpy Editor's guide to surviving the systemd debate

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*

to post comments

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.