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

The Grumpy Editor's guide to surviving the systemd debate

Posted Nov 13, 2014 22:21 UTC (Thu) by dlang (guest, #313)
In reply to: The Grumpy Editor's guide to surviving the systemd debate by valhalla
Parent article: The Grumpy Editor's guide to surviving the systemd debate

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.

to post comments

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.