
GNOME and logind+systemd thoughts - bkor
http://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
======
makomk
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
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...)

------
dreamdu5t
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
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
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
I'm not really criticizing Unity here, just saying I prefer GNOME.

------
zobzu
tldr: gnome now _actually_ requires systemd

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

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

As an aside I really love GNOME 3.

------
synchronise
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
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
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
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
Requirement to statically link against CDDL elements, which is still not
permitted by the LGPL.

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

------
plaes
GNOME also requires kerberos :S

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

~~~
hellerbarde
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
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
Gnome's Bugzilla 403's for me... is it just me?

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

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

