[linux-elitists] How about a fork of Jessie without systemd?
rick at linuxmafia.com
Mon Aug 3 11:29:15 PDT 2015
Quoting Ruben Safir (ruben at mrbrklyn.com):
> I've already had trouble getting logging to function on Suse and Manjaro
> from its nicely integrated package until 6 months ago, but if you wish
> to change from $100 to the typical betting vehical of choice on the
> internet which is Junior Cheese Cakes, then I'm willing to make a go of
Junior's Cheesecakes of Brooklyn looks to do fabulous work;
unfortunately, lactose and I long ago has a parting of ways.
Fortunately, just across the East River sits Second Avenue Deli,
purveyor of fine pastrami sandwiches with potato salad and mixed
pickles, one dish of which I'm glad to have as my wager payoff.
But, sorry, I have no ability to predict how often OpenSUSE or Manjaro
breaks logging, or how important functional rsyslog and syslog-ng
logging is to their developers -- but I do know Debian cares quite a bit
about that, which is why, for example, Debian's systemd package disables
systemd's systemd-journald feature and redirects system logging output
Wager offer as amended to a Junior's cheesecake and the best pastrami in
Midtown East is still outstanding -- but still limited to Debian rsyslog
/ syslog-ng, because Debian's serious about functional system logging.
> How many current debian packages have dependency on systemd ?
Asked and answered. To recap:
10 debian-installer* packages that depend directly on systemd because
the Debian 8.0 default installer provides it.
2 GNOME packages that depend on systemd or its PAM auth library
1 WindowMaker dock applet for shutting down a machine by clicking a
5 packages that depend on systemd because they're systemd-related:
(live-config-systemd, libpam-systemd, systemd-dbg, systemd-sysv,
1 GNOME display manager (gdm3).
1 GNOME-affiliated display manager that requires either libpam-system or
6 assorted other packages that require that systemd _or_ something else be
present (mate-power-manager, solaar, libguestfs0, sogo, ligthttpd,
2 packages from the core Freedesktop.org stack -- the guys responsible
for most of the furious code churn in GNOME -- that depend on
libpam-systemd (policykit-1, udisks2).
1 network manager from GNOME that depends on libpam-systemd
For completeness, one would also want ot chase down what depends on
policykit-1 ('framework for managing administrative policies and
privileges') or udisks2 ('D-Bus service to access and manipulate storage
devices'). I'm sure they're becoming a bit of a problem among the sorts
of desktop software that has been wooed over by the Freedesktop.org
infrastructure. At a glance, looks like the most annoying of those is
hplip, which depends on policykit-1. (Why on Earth? So, that one
useful package might need local rebuilding.) Mostly, otherwise, it's a
dozen or so libs, gnome-core, gnome-disk-utility, and things like the
pcmanfm lightweight graphical file manger, and daisy-player ('player for
DAISY Digital Talking Books'), both of which I think I can live without.
> The Gnome interface, btw, is not a small matter...
Bloated, in fact. ;->
Yeah, sorry, GNOME is deeply in bed with the Freedesktop.org framework,
which means 'seat' support is required in the display manager, thus
requiring either libpam-systemd or ConsoleKit, and the latter is
unmaintained and suffering bitrot like a typical Freedesktop.org 'We
redesign everything every six months' project. Also, you get
dependencies via policykit-1 and udisks.
So, write it off, or learn to love the whole Freedesktop.org code
hairball, including systemd (which actually should be the least of your
worries, but maybe you've been oblivious about what's gone on with
> ....and the wifi networking tools are not simple to drop in and
Are you saying you were yet another person caught napping by
NetworkManager wanting to pull in the whole code hairball? Well, there
at least you have good company, as Marc got caught by the same thing.
However, you both basically _should_ have been forewarned, because
NetworkManager says GNOME right on the tin.
Time for you to look at wicd, connman, etc. Inconvenient? Shed a
bitter tear into your egg cream, and deal.
> How do you install, now, X11 without systemd?
On Debian, using apt-get or tasksel. You seem to be assuming problems
not present. If you're saying OpenSUSE presented you with some tale of
woe, sorry to hear that.
> Those would be two different install approaches altogehter, and would
> require a split in the packages if one is using the rootless systemd
You might need to unpack that. I'm guessing you encountered some trauma
on distros that try to abstract session management via systemd-logind or
ConsoleKit and suspend/hibernate via upower (all of that
Freesdesktop.org stack's stuff), and where, thus, the X server cannot
open /dev/ttyN at startup because it lacks root rights unless the whole
Freedesktop.org thundering herd of systemd-logind | ConsoleKit, upower,
PolicyKit, udisk2 (etc.) being present, because otherwise lacks
root-window rights and isn't being helped by the Freedesktop.org stuff
to run 'rootless'. Generally, this is a GNOME problem.
(I should stress that I don't really know this stuff, having gone to
some pains to avoid needing to know it.)
The obstinate take measures to restore the X server's root-window rights
xorg-xwrapper (if you omitted it from the commands above) or by creating
/etc/X11/Xwrapper.config (containing 'echo "needs_root_rights = yes"')
and, basically write off GNOME as hopeless.
The lazy (like me) take the more prudent path of sticking to distros
that haven't fallen for the whole Freedesktop.org tangleware trap --
like Debian, for example. And also write off GNOME as hopeless.
My view, yours for a small fee and waiver of reverse-engineering rights.
More information about the linux-elitists