I've always found this part particularly hilarious/misleading in retrospect:

"For one, in the last stages of GNOME 3.8.0 as release team we specifically approved some patches to allow Canonical to run logind without systemd. Secondly, the last official statement still stands, No hard compile time dep on systemd for “basic functionality”. This is a bit vague but think of session tracking as basic functionality."

It's now the position of the systemd developers that running logind without systemd was never supported, and that distros like Ubuntu should never have tried to do it. I believe they've now broken the ability to do so. It's one of the major reasons Ubuntu had to switch to systemd.

(Oh, and for some context, http://www.freedesktop.org/wiki/Software/systemd/logind/ is the logind DBUS API. Good luck reimplementing that!)

That's the fundamental problem with DBus-exposed interfaces: they're APIs that get marketed as abstractions. APIs don't leave much room for different interpretations, meaning you'll end up rewriting the component you're trying to avoid using in the first place.

I'm not sure what you're saying here. If you want to avoid using a particular piece of software, but need to adhere to its API, you're going to either reimplement parts of it, or use someone else's reimplementation. There's really no way around that. It's a fundamental problem shared by all software.

Exactly. I'm (obliquely) affirming your argument that the commonly thrown-around excuse of "you don't need systemd, you just need something that implements its DBus interfaces" is a distinction without a difference.

Is a system running Linux + Wine no different than Windows, just because it implements the same Win32 API? Is FreeBSD the same as Linux, since they both implement POSIX?

There are many ways to implement the same APIs.

Wine is not reliable enough for mission-critical software. Nor is running a nominally POSIX-compliant program that hasn't been tested on FreeBSD. If a project claims not to hard-depend on systemd, I would not trust that unless it's actually, y'know, tested on something that isn't systemd.

Ah. I largely agree that it is a distinction without a difference.

However, I would argue that it's far easier for an end-user to drop in a replacement for a DBUS API implementation than it is to drop in a replacement for a C/C++ API implementation. So... there's that, I guess. :/

from same article:

"Apparently GDM 3.8 assumes that an init system will also clean up any processes it started. This is what systemd does, but OpenRC didn’t support that. Which means that GDM under OpenRC would leave lingering processes around, making it impossible to restart/shutdown GDM properly. The Gentoo GNOME packagers had to add this ability to OpenRC themselves. Then there were various other small little bugs, details which I already forgot and cannot be bothered to read the IRC logs. "

So apparently there are bugs when using OpenRC with Gnome. That is not to say, Gnome requires systemd (I did not make that claim).

Unless you're ovitters, I never claimed that you claimed that Gnome requires systemd. You did -however- say that "...when Gentoo developers tried integrating OpenRC they ran into too many bugs."

Your statement is not true. Stable Gentoo had its default init system switched to OpenRC in mid 2011. OpenRC has been great for Gentoo.

"Apparently GDM 3.8 assumes that an init system will also clean up any processes it started."

AFAIK, the only Linux init system that behaves in this way is systemd. Expecting this behavior means that one expects one's init system to behave like systemd. It is disingenuous to claim that one's software doesn't require the use of systemd when it relies on process management -and other- behavior that can only be found in systemd.

To make an analogy: I write software that makes extensive use of cgroups. If I said:

"My software doesn't require Linux. We could run on *BSD if they'd just implement cgroups, and Windows if they'd just implement POSIX and cgroups. It's a pity that they don't make this effort, and I don't have the bandwidth to help them out, but my software doesn't require you to use Linux to run it."

you would likely accuse me of sophistry; and with good reason!

I find myself reminded of a poster at a school toilet: "your mother does not work here, clean up after yourself".

I'm afraid that I have no idea what you're trying to say. Would you elaborate?

Gnome apparently assumes someone else is supposed to clean up after them, and so leave processes behind.

In essence, systemd has becomes Gnome's mother...

As anyone who's used a language at least as modern as C will tell you, it's awfully nice when a runtime system will help you clean up when your task terminates.

My beef with the article that the GGP links to is not that GDM now requires such a system (strategic laziness is a virtue!), but that the author refuses to admit that

1) There currently exists only one such runtime system that provides the behavior that GDM relies on.

2) There is absolutely no guarantee that the GDM folks won't come to rely on more systemd implementation detail in the future. Indeed, given the way Gnome development seems to happen, it's almost a certainty that GDM will depend on more and more systemd implementation detail in an entirely ad-hoc manner as time goes on.

When unable to provide a cogent response, a parable will be a sufficient substitute.