Distributions usage

At most 3 weeks ago I noticed by then already month old thread on gentoo-dev discussing that GNOME 3.8 has a dependency on systemd. At most this should be about logind, even though logind is optional. The assertion of Gentoo is different than what we communicated. 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.

Figuring out why Gentoo really believes systemd is a requirement took a while to figure out. For one, gentoo-dev is unfortunately like a lot of mailing lists. Loads and loads of noise. Out of the 190+ messages, only one or two has a pointer to some more information. One was Bugzilla, another was that logind now requires systemd. Apparently our (=GNOME) assumption that logind was independent from systemd changed since systemd v205 due to the cgroups kernel change. This is really unfortunate, but GNOME 3.8 does not require logind. I discussed the non-dependency of logind+systemd on #gentoo-desktop and why they thought different. 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. 😛

Due to 1) logind now requiring systemd, 2) that they don’t have time to develop missing functionality in OpenRC 3) supporting non-systemd + systemd at the same time likely resulting in bugs and a lot of support time, they decided it is much easier to just require systemd/logind. This also get the features that systemd and logind offer and avoid any weird bugs (as most GNOME developers seem to use systemd).

Debian GNOME packagers are planning the same AFAIK; they rather just rely on systemd (as init system, not just some dependencies). In the end, the number of distributions not having systemd decreases. This despite clarifying that GNOME really does not need systemd, nor logind and trying to help out with issues (though GNOME is not going to maintain distribution specific choices).

Wayland

GNOME 3.10 has Wayland as technological preview. The Wayland support in Mutter is being tracked in a special branch and tarballs are released as mutter-wayland. The Wayland support in GNOME will rely on logind to function (to be clear: Wayland in GNOME, not Wayland in general). If you have read my entire blog, you’ll notice that though we knew about logind runing on Ubuntu, as of version 205, logind is now tied together to systemd.

GNOME session

For GNOME 3.12, a feature has been proposed called systemd for the user session. This feature is explained as follows:

When booted on systemd systems, we can use systemd to also manage parts of the user session. There are a number of benefits to this, but the primary one is to place each application in its own kernel cgroup. This allows gnome-shell to do application matching more reliably, and one can use resource controls to (for example) say Epiphany only gets 20% of system RAM.

Furthermore, this lays some fundamental groundwork for application sandboxing.

It’s important to note that with these patches, we still support non-systemd systems (as well as older systemd). How far into the future we do so is an open question, but it should not be too difficult to leave non-systemd systems with the previous model over the next few cycles.

Upstart has something similar, called Session Init. I am not sure if what Upstart does is the same as systemd, just that they seem the same. In Ubuntu/Unity this is already used (though not sure to what extend), reasoning is described here (recommend to read it).

Making use of systemd in short term just provides some benefits and allows us to eventually support application sandboxing. However, long term hopefully gnome-session can die and such code in systemd. There it could possibly be reused by other desktop environments (only aware of Enlightenment).

ConsoleKit

We’ve been relying on ConsoleKit for a long time. If you see the git history, you’ll note that it was first written by a GNOME developer and my impression is that he wrote the majority of the code. Since preferring logind, ConsoleKit development has as good as completely stopped. No development in 1.5 years.

Upstream vs downstream

I remember the days where we had a program which tried to change some “OS” settings. E.g. maybe the timezone. IIRC this was handled using a Perl backend which would try and determine the OS/distribution and then would do whatever it needed to do. A complication was that things might change between the version of the OS/distribution, so the version also needed to be tracked. As a result, this program would sometimes ask you if your distribution was the same or similar to one of the distributions it knew about.

Only since very recently, we rely on fancy new things like dbus and the dbus specification described at http://www.freedesktop.org/wiki/Software/systemd/timedated/. Since the GNOME 1.x days, we’ve gone from trying to support all the differences out there, to promoting standardization (across desktop environments as well as OS/distributions). And in some cases like this timedated dbus specification, we either provide a function or it won’t work. It will be up to a distribution/OS to ensure that the function is available.

Future

Personally speaking, it seems that there is little going on to change the direction in which GNOME is heading. GNOME is getting rid of more and more code which overlaps with other code. Fallback mode, ConsoleKit, power management vs systemd handling this, etc. Then for new functionality, GNOME is also relying on new things. Think of Wayland, timedated, localed, application sandboxing, etc.

At the same time, I don’t see people working on ConsoleKit. Or ensuring that either there is a replacement for logind or ability to run logind without systemd. Development of any init system other than Upstart (user session is cool) seems low and in need of extra help.

Having GNOME run on non-Linux based operating systems (*BSD) and distributions not willing to switch for whatever reason to systemd is great. But it seems distributions rather depend GNOME on systemd than maintain things themselves. Leaving out *BSD, GNU/Hurd and Ubuntu. 🙁