On Thu, Jul 28, 2016 at 03:47:45PM -0700, Rick Moen wrote:
> Quoting Adam Borowski (kilobyte@???):
>
> > I'd propose giving them some gasoline to burn systemd-shim with. It's a
> > tool to run *drumroll* systemd on a system not yet running it as pid 1.
>
> *headdesk*
>
> Um, no.

Well, have you bothered taking a look?

> systemd-shim is/was a third-party Canonical, Ltd. (now apparently orphaned) codebase,
> that until recently also had a surviving fork maintained by a Debian
> Project package maintainer, that permitted certain GNOME and XFCE
> applications such as gnome-shell, that otherwise would require systemd
> (because those applications invoke GNOME login and power-management
> services), to function without systemd. That secondary fork is now also orphaned.
>
> In the model that systemd-shim supported, GNOME/XFCE talks to
> systemd-logind, which talks to systemd-shim (instead of systemd). (Some
> KDE4 stuff is also affected.)

And of what, pray tell, systemd-logind is an inseparable[1] component of?
In which package is it located?

There's precisely one real[2] package with a dependency on systemd-shim:
libpam-systemd which, as its name says, is a PAM module for systemd
integration, its description is:
This package contains the PAM module which registers user sessions in
the systemd control group hierarchy for logind.


> My personal solution is: _Don't use_ those particular GNOME/XFCE (and KDE4) codebases.
> They have proven to be dependency hairballs, and that is never IMO going
> to get fixed.

You mean that GNOME which is Debian's default on amd64 and i386 (ie,
architectures used by 98.968% of popcon submissions) and XFCE which is
default on the rest of Debian and all archs of Devuan? Some die-hard
folks will stick with fvwm they used in 1994 or WindowMaker from 1998
(neither appears to have improved since), but most of us, especially
new users, prefer convenience over saving a handful of megabytes of RAM.

As a x32 porter, an arch whose main schtick is memory saving over amd64
(and speed over i386), I can tell you this: while you can use hundreds of
servers at once, you still use only a single GUI at a time, and switch among
no more than a few GUI systems. Thus, while optimizing servers (that run in
kvm/vserver/lxc/...) is a worthwhile effort, trimming GUIs beyond a "good
enough" level is a pure waste of time. These days, cheapest ARM SoCs ship
with 2GB RAM, so do most phones -- any "real" workstation will start at 4GB
in Africa and more in the civilized world. There's a long tail of legacy
hardware, but there's a limit on how deep you can dive in that dumpster.

Only GNOME has some troublesome requirements (it needs powerful graphics
hardware, with slow emulation on amd64+i386 and doesn't work at all on other
archs), but no other desktop environment has even a slight chance of slowing
down a machine that can reasonably run a modern browser (this is the main
source of bloat these days). If you run fvwm, you do this by choice, not
by need.

Thus, we _need_ to make mainstream desktop environments work, now and in the
long term when stuff like consolekit bitrots into unusability. Otherwise,
welcome to the 0.001% userbase land.


Meow!

[1]. According to the systemd package maintainers.

[2]. Not counting Recommends: from xfce4-session (redundant because of
libpam-systemd) and Depends: from init-select broken, uninstallable).
--
An imaginary friend squared is a real enemy.