Re: let's split the systemd binary package
On 25/10/13 11:52, Dmitrijs Ledkovs wrote:
> - using XDG_* environment variables, instead of LOGIND_* or SYSTEMD_* variables
I assume you mainly mean XDG_RUNTIME_DIR here, since the rest are
basically user-level rather than system-level.
The point of the XDG_* family of variables is that they're intended to
be a cross-desktop, multi-implementation standard. I think pam_systemd
and its communication with systemd-logind might be the only
implementation of XDG_RUNTIME_DIR we have right now, but there'd be
nothing to stop someone writing a pam_xdgruntime that did it in-process,
analogous to pam_mkhomedir.
The advantage of XDG_RUNTIME_DIR is that it makes any specification that
refers to it simpler. For instance, if it had existed all along and been
a prerequisite for D-Bus, we could say "use the Unix socket
$XDG_RUNTIME_DIR/dbus/session" rather than "There's a socket somewhere,
probably in /tmp or something, or it might be abstract, who knows? Use
$DBUS_SESSION_BUS_ADDRESS to find it, and make sure that variable gets
set correctly, otherwise you lose".
The disadvantage of XDG_RUNTIME_DIR, which sets it apart from the other
XDG_* variables, is that there's no good default if it isn't set: it
requires that something on the system creates a suitable directory,
potentially requiring privileges to do so. In contrast,
XDG_{CACHE,DATA,CONFIG}_* can all have sensible defaults (a
dot-directory in $HOME, which applications can create when needed).
The reason that XDG_RUNTIME_DIR potentially requires privileges is that
unprivileged users can't guarantee to be able to create a directory on a
fully-featured local Unix filesystem with Unix sockets, fifos, atomic
rename, etc. (as opposed to NFS or VFAT or something similarly limited).
systemd-logind guarantees that by using a tmpfs, which has those features.
> I think from above points you can see, that it's not unreasonable to
> easily mistake that systemd brings logind, instead of "logind is part
> of the systemd software collection" & that all of "the systemd daemon
> collection" somehow is required / endorsed by FreeDesktop project.
To clarify, freedesktop.org is (at least) two things:
* specifications: a set of desktop-agnostic would-be-standards for
"APIs" that desktop environments benefit from sharing (window manager X
property conventions, .desktop files to describe applications, XDG_*
search paths for data/configuration, etc.). I suppose the ideal for
these could be expressed as "not having a competing standard because
nobody needs one".
* software: a hosting site for projects that aspire to be used in a
cross-desktop way, analogous to a more focused
Sourceforge/Github/Alioth. Some of these remain current (systemd,
Telepathy, D-Bus, LibreOffice, Xorg, lightdm), some get deprecated as
their authors realize they had design issues (ConsoleKit, HAL), some
never really got wide adoption in the first place (Ytstenut, APOC,
arguably Geoclue). Many of these projects have long-term competitors
(systemd/Upstart/OpenRC/etc., NM/wicd/ConnMan/etc.,
lightdm/gdm/kdm/etc., Xorg/Wayland) and that's fine.
With hindsight, it would have probably been better off with two separate
names for those things, but it's rather too late.
Things named with "XDG" are mostly the specification side. Things that
have their own "brand name" are mostly the software side (e.g. they're
called Telepathy and lightdm, not "Freedesktop Communications" and "XDG
Display Manager" or something).
Some of the software projects (e.g. systemd, Telepathy) also promote
their own API specifications which are intended to be implemented by
third parties (e.g. systemd's /etc/machine-id and /etc/os-release,
Telepathy's clients and connection managers).
> I don't know if it works on older kernels and/or without cgroups
> and/or how portable /just/ logind is, or other individual daemons in
> "the systemd daemon collection".
I don't think systemd-as-init requires any of the other daemons (pid 1
requiring other processes has chicken-and-egg problems!), but (the
systemd implementations of) some of the other daemons require
systemd-as-init. You might have been assuming it to be the other way round?
In practice, I think the situation is something like:
* hostnamed and timedated probably work fine without systemd-as-init, or
if not, they'd be relatively straightforward to fork or reimplement (I
believe the OpenRC people already reimplemented them?)
* logind (<= 204) works without systemd-as-init
* logind (>= 205) requires systemd-as-init, which it uses to manage cgroups
S
Reply to: