I am more and more convinced that moving from GNOME 2 to XFCE was the right move, not just for me, but for many other people.

Choosing a desktop environment ought to be completely decoupled from what init system you have. Building dependencies like this -- both the upstream dependency that was removed, and the various downstream dependencies that are unlikely to be removed because it is a support nightmare to do otherwise -- reduces the user's available choices.

Now, lots of people like to say that choice is bad. And they're wrong about that.

Choice is harder.

I think the real problem is that if you want fancy features like a sandboxing solution that leverages the proper way to do it (kernel cgroups, if I understood that correctly), you need to have some dependencies that reach deeper than before.

That being said, no-one is stopping enthusiasts from providing their own solution for the problems that systemd and logind solve for the GNOME project.

I always hated how all these little utilities of GNOME solved problems that were solved a long time ago and properly at that. leveraging existing solutions is definitely a good thing.

disclaimer: i really like systemd :)

> if you want fancy features like a sandboxing solution that leverages the proper way to do it (kernel cgroups, if I understood that correctly)

I'm really liking systemd too, in particular because it integrates so well with cgroups -- IMO we should really be adding equivalent sandboxing APIs to other kernels rather than crippling the init system to remain compatible with the lowest common denominator

Various APIs are being added at the kernel layer (kdbus). Only for cgroups there is a change coming up where they just want 1 process to manage the cgroups. At the moment that is only implemented by systemd. This resulted in logind relying on systemd. A lot of bits (kdbus) are on the kernel layer. This is on purpose, we the kernel should track and take care of the sandboxing as much as possible.

So for sandboxing you could do without systemd, but using systemd would automatically give you cgroups. So by (probably) duplicating the systemd code (or maybe using Upstart Session bit), you could do without systemd. But that is not what GNOME is doing.

The problem I have with this approach - keep everything compatible and portable - is that it holds back development and puts the effort in other parts of the stack to waste.

What is the point of awesome ‘new’ kernel features like cgroups if nothing in userspace really uses them? With systemd, I feel like my computer is actually taking advantage of being a modern Linux system, not just a warmed-over historical UNIX.

With Gnome using systemd, it can take advantage of those capabilities as as well.

If they do not depend on systemd, they have three options:

1. Don't have features that require its capabilities.

2. Have those features conditionally depending on whether systemd is present. This has at least 2 problems: inconsistent experience / feature set and maintenance of less-tested alternate code paths.

3. Implement fallbacks for systemd capabilities. This has more maintenance problems than (2), in addition to the redundant effort re-implementing (subsets of) features systemd provides.

I prefer to see the Gnome leverage systemd and build an excellent platform. With scarce resources, (2) and (3) are a significant drag on the project. 'Choice' is not only hard, it requires time/money, and that time/money comes at the expense of other things that would benefit from it.

>keep everything compatible and portable - is that it holds back development and puts the effort in other parts of the stack to waste...

This is utter crap, making things portable creates better code as you aren't tied to an implementation with bugs and incompatible features but to the interface you or someone else has written.

@bkor (cannot reply directly), What happens when another init takes it's place? The code in question would be riddled throughout with bugs and assumptions.

As mentioned in the blog, almost all GNOME developers use a systemd distribution. How would adding another layer in between make things less buggy? Especially as almost nobody would test that code?

GNOME will release 3.10.0. Gentoo seems to be integrating 3.8. That's a difference of 6 months! Way too late to do anything about bugs.

GNOME 3.8 has been available on Gentoo in various forms since April - first in the gnome overlay, then hardmasked in the portage tree, then unmasked into unstable/testing ie. ~arch. The (one month old) gentoo-dev thread that the blog author referred to is talking about the stabilization of GNOME 3.8, which is the tier used by the most conservative users who have chosen to only use well-tested software that is known to build/run well on their architecture and has received ample testing. This is not very different from binary distributions, Ubuntu 13.04 shipped on April 2013 with GNOME 3.6 from Sep 2012.

Their dependencies are based on their feature set and their wish to get rid of some code. It's only reasonable.

Only if you use the latest logind.

well that's "now" :)