(I'm trying out systemd for monitoring and automatically restarting my custom daemons, and finding it much nicer to use and more reliable than the alternatives - while at work we're using sysvinit, and I spent a whole day banging my head against couchdb's init script which tries to do auto-restart-on-crash at the shell level, with all sorts of terrible side-effects...)
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.
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 :)
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
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.
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.
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.
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.
As an aside I really love GNOME 3.
Also, the GPL'd portions linking against the CDDL system libraries (as all the other GPL'd packages do) fall under the system library exception.
[Edit: I originally wrote openldap, my bad...]
EDIT: Ah, I see. Is that a big overhead? How does it affect me as a non-enterprise user? unnecessarily large installation footprint? (if so, by how much?)
On top of all that, it's never wise to turn down an opportunity to test code against multiple targets (hardware, operating systems, compilers, etc). You'd be amazed at the bugs such testing flushes out.