On Thu, Jul 28, 2016 at 03:47:45PM -0700, Rick Moen wrote: > Quoting Adam Borowski (kilob...@angband.pl): > > > 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. _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
