[lfs-dev] dbus, systemd, polkit, and consolekit

akhiezer lfs65 at cruziero.com
Sat May 10 03:55:20 PDT 2014

> Date: Fri, 09 May 2014 21:37:37 -0500
> From: Bruce Dubbs <bruce.dubbs at gmail.com>
> To: LFS Developers Mailinglist <lfs-dev at linuxfromscratch.org>
> Subject: [lfs-dev] dbus, systemd, polkit, and consolekit
> I tried to step back and see just what is all this dbus, systemd, 
> polkit, and consolekit stuff all about.  My conclusion is that it is to 
> manage multiple simultaneous desktops on a single system.
> My question then is "In today's environment, where does all this fit 
> in".  Are there many places where multiple desktop environments are 
> needed on a single system?  I am certainly not aware of that.

iirc/ottomh, s'thing re cloud workspaces.

> I've said it before: it appears that systemd is a solution in search of 
> a problem.  For 99% of users, especially LFS users, systemd provides no 
> discernible benefits and a lot of problems.  You are either all in or 
> not.  There does not seem to be a halfway.
> Unless I get some feedback in the next couple of days with solid reasons 
> that systemd, polkit, and consolekit are important, I am going to 
> replace systemd with eudev in LFS and minimize recommendations for 
> polkit and consolekit in BLFS.
> I'm a little undecided whether dbus should remain in LFS or not.  It 
> doesn't hurt much, but it also isn't much use in an non-xorg environment 
> unless you are using systemd.  To use it in an xorg environment, it (at 
> least dbus-launch) needs to be built after xorg-libs.

(d-bus is not even really needed in x per se; e.g. we use twm-based
environments - as rich or as minimal as we want - perfectly happily without
it. (We also have perfectly happily rejected *kit/udisk*/hal/udev/&c&c&c
over the years - while at the same time adopting & staying with several
other new technologies.))

> Many users come to LFS because they don't want the "bloat" of the 
> commercial distros.  I am now willing to return to those roots.
> Feedback is welcome.

One branch for lfs-nix, one for lfs-sysd, and perhaps one for any possible
mergings/combined-book.  Similarly for blfs: one branch for 'normal'
computing, one for sysd/gnome/etal, and perhaps one for any possible

Why the 'support' from here for (separate/'pure') sysd-based books at
all? Fwiw, we are actually interested in observing how the sysd 'ecosystem'
goes about things - from various angles (not just the technical), and
from +ve thru -ve aspects; and as part of that find the separate/'pure'
b/lfs-sysd 'books' interesting. (That though is as part of a wider picture
of similar in windows, mac, bsd, android, and more-experimental stuff.)

Folks that are interested in at least trying-out sysd are, well,
interested in at least trying it out. They're going to try it out
anyway: cf e.g. folks trying out cyanogen-mod or gnu/hurd or freebsd or
windows-8.1-on-touchscreens; but at the same time they wouldn't normally try
to mix it in with their lfs-nix system (or indeed would have the modicum of
foresight to not expect to find, or make, the instructions mixed-in with
each other ... ). Arguably, for sysd, such folks could just use another
distro. But having detailed walkthroughs in separate/'pure' b/lfs-sysd
books can be useful to let people understand better if it's routes that they
want to go down. It also helps hold sysd 'up to the light', pick it apart,
and examine and test it, and eventually help hold it (more) to account.

As noted before, having the two separate strands helps 'keep the peace',
with folks much more readily working on and contributing to the areas that
they're interested in, with at least reasonable expectation that it's not
wasted resource-spend. Also as noted, the quality/level of help that can
be offered via mailing-lists/irc/&c, is likely to be far higher - much
more effective - with separated-out books than with mixed-in books. (I'd
suggest *not* separating-out the mailing-lists).

That said, it's perhaps worth restating a few wider-picture home truths
about the thing. sysd &c is (currently) largely a (semi-)'closed system',
more akin to osx than *nix or even gnu/linux, and intending and trying
to head further down those routes that it's currently on. Folks who are
trying to do their computing via sysd/gnome/&c, would actually be far better
off just using osx; similar ideas, executed much better overall, and with
similar levels of opacity & user/admin (micro-)'manageability'. Such folks
can still have their 'closed system', 'operate' it, try to control and admin
and configure and manage and understand it with one hand tied behind their
back, be dictated-to haughtily from the 'vendors', and generally be led.

Meanwhile, there will always be a demand for powerful, transparent,
loosely-coupled components, brought together fairly readily into a powerful,
'clean', interoperating-well, & transparent, os & working computing
environment. If b/lfs isn't one of the sources for that, then its place(s)
will be taken; and b/lfs can find or lose itself over in the herd queue.



>    -- Bruce
> -- 


More information about the lfs-dev mailing list