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. 🙁
GNOME does not depend on systemd,true.
There is coordination btw what systemd is doing and what GNOME want and expect from the base system.
GNOME starts to expect features that are added to and exist on in systemd,true.
This means,a GNOME user and a non systemd user will have to follow closely what systemd is doing and pick up its features that GNOME starts to expect.The statement that GNOME does not depend on systemd may be accurate but its misleading and distributions are starting to pick up systemd not because they want it,but because GNOME will continue to makes it prohibitively expensive to run it without systemd.
Yes, I think you’re dead on, there. It’s not that Gnome depends on systemd – but it’s increasingly dependent on features that are only provided by systemd. The example of OpenRC not behaving according to GDM’s assumptions is a perfect illustration of that. It’s dependent not on systemd, but on something that for practical purposes is indistinguishable from systemd.
I tried to reflect something similar with one addition: I don’t see anything changing. E.g. there is no assistance towards GNOME from developers/users not wanting systemd. At the same time, GNOME is expecting systemd-like features.
I saw in a Hackers News thread that OpenRC wants GNOME to support them resource wise. To me that’s absurd, why would a desktop environment be required or expected to help out an init system? It takes time and effort and we will miss out on people because they work on OpenRC, but it will also cause extra resources within GNOME. While Gentoo already is going to make GNOME depend on systemd.
In brief: GNOME will rely more and more on systemd, non-systemd developers/users will keep complaining.
“In brief: GNOME will rely more and more on systemd, non-systemd developers/users will keep complaining.”
The way they go around the dependency on systemd amounts to lying.Sooner or later,GNOME will want a functionality and one part of it will be implemented in GNOME and the remaining part will be implemented in systemd.But they wont say systemd is a required dependency to give the other half of the feature.GNOME will just say “we just expect the base system to have this functionality” and any person who will look at the functionality will see that only systemd offers it and GNOME expects the functionality exactly in the way systemd offers it and everybody else will just be expected to add the functionality in their base system in a way that systemd does it.
Then GNOME should just come clean and say “we depend on systemd and here is a hard dependency on it” and be done with it.
Hi mtz,
Don’t you realize that I am a GNOME foundation member and I am on the GNOME release team?
As such, your suggestions are really inaccurate. If you want to have a proper discussion, cool. However, suggesting that we will lie is not terribly constructive.
Aside from your lying suggestion: I mentioned in the blog post regarding systemd dependency. I also mentioned more regarding Wayland.
You get more results by being constructive.
Agreed, though I think this is where the misunderstandings are coming from. Gnome is saying they don’t depend on systemd, but functionality keeps breaking on non-systemd systems – and while I understand why that is, it’s conveying something of a mixed message.
Perhaps you need to either formally decide that only systemd is supported, *or* provide a clear statement of what functionality a systemd alternative must provide.
Usually things are done in cooperation. E.g. a distribution notifies that something broke, we fix it. E.g. Fedora compiled some optional stuff, mutter-wayland didn’t check for it but assumed it existed. Then the compilation gives weird error messages on another distro (Mageia, which I help out in).
People in the release team use various distributions. We select people based on how different they are from the existing release team people. So different distributions, different interests, abilities, etc.
But you cannot expect things to be perfect. Development has to be followed because stuff will be missed. E.g. that GDM, nobody had any idea. For real dependencies, we can easily make a matrix. What I fear is the hidden stuff nobody notices until someone notifies us.
And aside from just nobody knowing. It could be that a bug is filed, the maintainer knows, but nobody else in GNOME knows. There is a big assumption that everyone is aware about everything.
Within GNOME people work on continuous integration to determine bugs asap. Also to figure out what regressed, etc. There seems to be a notion that you can just take upstream without any involvement. Ideally 6 months delayed because that makes it somehow more stable. I think that is a short sighted way of doing packaging.
There would be greater interest in supporting non-systemd OS’s if ConsoleKit was still supported and under a non-GPL license.
However I have contacted the developer about this and I haven’t received a response yet.
I would like to start making some edits to it, but as long as it’s under a copyleft license it can’t really be used by OS’s that have an aversion to it such as FreeBSD.
ConsoleKit was always under the same license. AFAIK, it was used on BSD. ConsoleKit is still supported by GNOME, just that it might be buggy because none of the developers use it.
Anyway, it seems eventually GNOME will head to be systemd and Linux-only.
Really? Last I’d seen, Debian still carried a pile of patches to make logind work without systemd, and a pile of patches to GNOME as well, largely because of Debian’s painful support for non-Linux kernels. I’d really love to hear about this changing, but I’ve seen no signs of that.
I think the problem here was that we have a different opinion of basic functionality, as echoed in that releng meeting summary. We regard power management (such as being able to suspend your laptop) as basic functionality in the year 2013. As such GNOME-3.8 and onwards hard-depends on logind, which in turn is too hard to keep working outside systemd as PID 1.
If power management if considered basic functionality, then there should be just one way to handle this. Not all kinds of different ways. If you want to offer choice, cool, but then work via Plummers or freedesktop.org to ensure that choice means choice, not choice due to extra burden.
There is a give and take with expected functionality from a distro and the desktop environment, and so it cannot be classified as one party’s fault or another’s, still I think it would make sense for GNOME to define what it expects as areas that should be standardized. The fact is that people disagree on how much should be standardized, some people find the fact that desktop environments are not standardized across Linux as bizarre (not me really, but I have heard other people say so). In the end the areas of the platform which are standardized are going to be the areas where standards exist and are promoted. Thus if GNOME wants some aspect of the platform standardized which does not currently have a standard, then it should lead the change, instead of expecting others to.