7 ms·

GNOME and logind+systemd thoughts

45 points by bkor 13y ago

zobzu 13y ago
tldr: gnome now actually requires systemd
- the_mitsuhiko 13y ago
  Only if you use the latest logind.
  - zobzu 13y ago
    well that's "now" :)
- dsr_ 13y ago
  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.
  - hellerbarde 13y ago
    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 :)
    - Shish2k 13y ago
      > 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
      - bkor 13y ago
        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.
  - xentronium 13y ago
    Their dependencies are based on their feature set and their wish to get rid of some code. It's only reasonable.
  - elehack 13y ago
    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.
    - nwmcsween 13y ago
      >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 13y ago
        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.
        mrpdaemon 13y ago
        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.
plaes 13y ago
GNOME also requires kerberos :S [Edit: I originally wrote openldap, my bad...]
- hellerbarde 13y ago
  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?)
  - plaes 13y ago
    Well, mostly because it is basically an "enterprise" requirement. More info here: https://bugzilla.gnome.org/show_bug.cgi?id=686840 https://bugzilla.gnome.org/show_bug.cgi?id=686840 :)
    - hellerbarde 13y ago
      Gnome's Bugzilla 403's for me... is it just me?
      - bkor 13y ago
        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.
elktea 13y ago
I wonder what the Ubuntu GNOME guys will do with regards to wayland / mir? Anyone know? As an aside I really love GNOME 3.
makomk 13y ago
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.
- Shish2k 13y ago
  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...)
static_typed 13y ago
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....
- legulere 13y ago
  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).
  - npsimons 13y ago
    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.
    - legulere 13y ago
      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.
dreamdu5t 13y ago
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.
- reedlaw 13y ago
  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.
  - pekk 13y ago
    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
    - reedlaw 13y ago
      I'm not really criticizing Unity here, just saying I prefer GNOME.
synchronise 13y ago
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.
- kmacleod 13y ago
  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.
  - synchronise 13y ago
    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.
    - kmacleod 13y ago
      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 http://pkg.openindiana.org/dev/en/catalog.shtml
      - synchronise 13y ago
        Requirement to statically link against CDDL elements, which is still not permitted by the LGPL.
        13y ago

45 points by bkor 13y ago

zobzu 13y ago

tldr: gnome now actually requires systemd

the_mitsuhiko 13y ago
Only if you use the latest logind.
- zobzu 13y ago
  well that's "now" :)
dsr_ 13y ago
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.
- hellerbarde 13y ago
  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 :)
  - Shish2k 13y ago
    > 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
    - bkor 13y ago
      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.
- xentronium 13y ago
  Their dependencies are based on their feature set and their wish to get rid of some code. It's only reasonable.
- elehack 13y ago
  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.
  - nwmcsween 13y ago
    >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 13y ago
      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.
      - mrpdaemon 13y ago
        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.

plaes 13y ago

GNOME also requires kerberos :S [Edit: I originally wrote openldap, my bad...]

hellerbarde 13y ago
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?)
- plaes 13y ago
  Well, mostly because it is basically an "enterprise" requirement. More info here: https://bugzilla.gnome.org/show_bug.cgi?id=686840 https://bugzilla.gnome.org/show_bug.cgi?id=686840 :)
  - hellerbarde 13y ago
    Gnome's Bugzilla 403's for me... is it just me?
    - bkor 13y ago
      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.

elktea 13y ago

I wonder what the Ubuntu GNOME guys will do with regards to wayland / mir? Anyone know? As an aside I really love GNOME 3.

makomk 13y ago

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.

Shish2k 13y ago
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...)

static_typed 13y ago

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

legulere 13y ago
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).
- npsimons 13y ago
  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.
  - legulere 13y ago
    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.

dreamdu5t 13y ago

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.

reedlaw 13y ago
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.
- pekk 13y ago
  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
  - reedlaw 13y ago
    I'm not really criticizing Unity here, just saying I prefer GNOME.

synchronise 13y ago

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.

kmacleod 13y ago
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.
- synchronise 13y ago
  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.
  - kmacleod 13y ago
    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 http://pkg.openindiana.org/dev/en/catalog.shtml
    - synchronise 13y ago
      Requirement to statically link against CDDL elements, which is still not permitted by the LGPL.
      - 13y ago