GNOME and logind+systemd thoughts | Hacker News Reader

GNOME and logind+systemd thoughts

blogs.gnome.org

45 pointsbkor35 comments

I'd note that, based on the comments in that commit, by default OpenRC still doesn't kill off all processes launched by a service when it's restarted because generally that's not desirable. For example, if you restart SSH you don't want the child processes to be killed immediately because that'd disconnect you.

Testing that scenario with systemd - the child processes are spawned in a separate cgroup to the main sshd

(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...)

A GUI being dependent on an init system!? I still don't understand why modularity had to be abandoned in order to implement event-based init.

GNOME is a lot more than a GUI. When I installed Arch Linux it was a pain configuring X startup, graphical login, wifi management, etc. As soon as I installed GNOME, all of that was working for me. Plus I like the latest GNOME desktop better than Unity, especially with the direction Canonical's taken with affiliate links in desktop search results.

So uninstall the shopping lens or do not use desktop search to find things to buy... this is not a serious usability or even ethical criticism

I'm not really criticizing Unity here, just saying I prefer GNOME.

tldr: gnome now actually requires systemd

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" :)

I wonder what the Ubuntu GNOME guys will do with regards to wayland / mir? Anyone know?

As an aside I really love GNOME 3.

I'm sure that there would be less controversy about this if systemd and its associated parts were under a permissive license rather than a copyleft, which leaves it incompatible with several operating system environments, notably OpenSolaris which is released under the CDDL and incompatible with the LGPL that systemd is licensed under.

That's not correct. At its level systemd is just a component, it's not linked against anything that would cause it to be incompatible and all communication with systemd and its parts are through process-level interfaces (like D-Bus and signals). OpenSolaris, and certainly its derivatives, ship with many GPL and LGPL'd components as far as I'm aware. At this level it falls under GPL's "mere aggregation" clause.

It would still form part of a greater work and have to be shipped under the GPL, which is incompatible with the CDDL, so in the end you really can't do it.

The OpenIndiana package repository[1] appears to contain several dozen (counting all Gnome packages as just one) GPL'd packages as part of the OpenIndiana-distributed greater work. Can you be more specific as to why this one package would be different?

[1] http://pkg.openindiana.org/dev/en/catalog.shtml

Requirement to statically link against CDDL elements, which is still not permitted by the LGPL.

LGPL allows for static linking. The distributor need only be able provide the binary library elements necessary to re-link the LGPL library against. OpenIndiana already provides those. In other contexts, it wouldn't even matter if they were wholly closed-source binary libraries as long as they can be re-linked against. (Aside as an example, in our case of an embedded system, our lawyer has cleared us to do exactly this: link a LGPL'd source file against our proprietary application as long as we provide the ability to re-compile and re-link the LGPL'd source file against our code, delivered as a library.)

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.

GNOME also requires kerberos :S

[Edit: I originally wrote openldap, my bad...]

why is that a problem?

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?)

Well, mostly because it is basically an "enterprise" requirement. More info here: https://bugzilla.gnome.org/show_bug.cgi?id=686840 :)

Gnome's Bugzilla 403's for me... is it just me?

Please send an email to bugmaster@gnome.org with your IP address, browser, etc. Could be that you're in a netblock that was used by spammers/bots.

Luckily it is a Linux only world, where we don't have to build cross platform solutions, none of that considering those nasty BSDs or Minix or anything else really. Just Linux. Oh wait....

The question is if it’s worth the extra work. I think for minix it’s obvious that it’s not worth it — nobody is using it seriously as a desktop system with gnome (a quick googling for it even brought up that gnome 3 isn’t running on minix anyway). Relying on some things can make it easier to go forward (for instance the mentioned sandboxes).

This point of view is perilously shortsighted; even I, a die-hard Linux fan, realize that nothing is forever. Someday (some would argue that day is today ;), nobody will be using Linux seriously as a desktop system with GNOME. Linux may not be around forever, and even if it is, one thing history has taught us is that it won't be the same.

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.

Having to write an own abstraction layer as a perl script that often stops working certainly is more likely to introduce bugs than having a reliable dbus api. Spending the time needed instead for working on bugs that are actually reported by users is more useful. The developers only have a finite amount of time, either they use it to move forward or they use it to try to support every obscure system.

Reply on news.ycombinator.com