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