Re: systemd effectively mandatory now due to GNOME
On Wed, Oct 23, 2013 at 02:39:15PM -0700, Steve Langasek wrote:
> The problem is the scope creep. It's perfectly fine for
> gnome-settings-daemon to depend on the dbus services provided by systemd;
No, not even that, as long as xfce4[1] and other non-GNOME environments
require gnome-settings-daemon. A bunch of us ran away from GNOME for a
reason (ok, plenty of reasons).
A daemon to hold *settings* for an user interface must not force a whole
init system. This lies squarely in the "breaks unrelated software" land
(as long as systemd does break a single thing, and with its scope it does
break far more than one).
> You should not get an init system installed when you install the dbus
> services. This is deliberate embrace-and-extend on the part of systemd
> upstream, and Debian should not tolerate it.
Also, GNOME does _not_ absolutely need systemd. Proof: Ubuntu. This part
of its packaging in Debian strikes me as being intentionally malicious to
push an agenda. And this is not the first time, we had this with Network
Manager already.
> > Well, Debian is aiming for full systemd integration with Jessie, so
> > there is that.
>
> No, please reread that mail from the release team. It is a *proposal* from
> the systemd maintainers to implement full systemd support. The release team
> have not said that they have endorsed this as a release goal (and frankly, I
> don't expect them to do so; it's not the release team's place to decide what
> Debian should use as its default init system, and to endorse such a release
> goal would presuppose such a decision).
There are quite a few reasons to avoid systemd like the plague it is. It's
not the place to repeat those (just recall the most epic flamewar in
Debian's history), so here are just two additional reasons I learned in the
past ~2 months:
* it is buggy. I did install a straightforward install of experimental
GNOME to test if it improved even a bit, running systemd as init, and, with
2G RAM assigned to the machine, I got an OOM from one of systemd's
components. Excuse me for not looking more closely but purging the machine
and running away screaming: even in early stages of integration, an init
system which even *can* possibly OOM is not fit for any non-toy use.
* it breaks other users of cgroups. I have not tested this personally
(mostly because of the above point), but if I understand it right, it takes
over the whole cgroups system, requiring anything that runs on the same
kernel instance to beg it via dbus to perform required actions. This might
be possible to organize on a single system, but not really between multiple
systems on the same kernel. Even if you run massive Rube Goldberg tricks
(akin to those once needed for dbus inside a chroot), this is still doable
only if you run the same version both in host and guests. And I for one
heavily use vservers, which are supposed to be replaced with lxc. Not being
able to run an arbitrary, possibly old[2], distribution in a guest -- or even
being able to move a live system into a container, without replacing its
init system, means it's a no-no for me.
[1]. Fortunately not for its core functionality.
[2]. It took me a lot of nudging to get the last person to finally upgrade a
lenny system long after it lost security support.
--
ᛊᚨᚾᛁᛏᚣ᛫ᛁᛊ᛫ᚠᛟᚱ᛫ᚦᛖ᛫ᚹᛖᚨᚲ
Reply to: