Re: systemd as external dependency

[Lennart Poettering <mztabzr 0pointer de>]

On Thu, 19.05.11 23:51, Luca Ferretti (lferrett gnome org) wrote:

> > In the future I expect more interfacing with GNOME however, and I'd thus
> > like to see the discussion regarding acceptance as blessed
> > dependency started early.
>
> Are you planning to "delegate" single module maintainers to implement
> those interfaces? Do they agree on it? Do you have a list of involved
> "core" modules (apart the ones listed below: gdm, gnome-session and
> gnome-control-center)?

Well, we'll see who will do the work in the end but I am pretty sure
that somebody will do it. I am pretty sure that will be in big parts
me.

Bastien worked on the hostname panel. I will work on gdm, and work with
the maintainers to make this happen. gnome-session is not a pressing
issue right now, but I will probably too be the one who does the
work.

> > In the long run I expect the following additional interfaces used by
> > GNOME or one of its components:
> >
> > - I am working on two more mechanisms generalizing control of the system
> >   locale and system clock/timezone for use in the control center and by
> >   other UIs.
>
> Reducing this to a yes-or-no-feature view: distro/kernels without
> systemd will have to apply a (big?) patch gnome-control-center in order
> to provide the ability to change locale and time settings. Is this
> correct?

No.

As I tried to make clear a gazillions of times: the mode of cooperation
with other kernels is sharing interfaces, not code. i.e. other OSes can
reimplement the bus interface. Bastien's g-c-c stuff uses the D-Bus
interface, and if they reimplement that they can benefit from the same
features.

It's all documented:

http://www.freedesktop.org/wiki/Software/systemd/hostnamed

There's nothing systemd specific in that iface.

And as mentioned, other Linux distros can compile systemd and strip
everything but hostnamed and friends. I wrote that explcitly in my
original mail.

> Also, if I haven't misunderstood, 'cause you will not maintain a systemd
> version for non-linux kernels, if FreeBSD (just and example) will switch
> to systemd, FreeBSD developers will have to maintain their own forked or
> patched version of systemd, haven't they?

No. It makes no sense running systemd on the BSDs. I don't think anybody
who knows systemd and the BSDs would seriously suggest anything like
this. See this mail of mine for an explanation:

https://mail.gnome.org/archives/desktop-devel-list/2011-May/msg00447.html

Focus is on sharing interfaces, not code.

> > - gdm will interface with the new CK-replacing code I am working on.
> >
> >   http://lwn.net/Articles/441328/
>
> Same previous yes-or-no question (to simplify: no systemd, no login),
> plus I suppose this bond between systemd and gdm will add another -1 to
> lightdm.

Well, the interfaces we provide in systemd are not bound exclusively to
be consumed by gdm. The KDE folks for example are very welcome to
support the same functionality for KDM, and use our interfaces. And
that's true for any other kind of DM too.

> > - Later on I hope that we can use per-application cgroups to create
> >   reliable mapping between desktop files and processes. (i.e. place each
> >   app in a cgroup and name it after the .desktop file), integrated into
> >   the systemd cgroup hierarchy, so that this can be used for g-s and
> >   other UIs to relate desktop files to processes.
>
> Is this the only way to create a relationship between processes
> and .desktop files? For example, another solution to this feature seems
> to be BAMF (https://launchpad.net/bamf/  ), and I remember it was
> suggested as a viable solution (maybe by vuntz?). Advantages?
> Drawbacks?

I have not looked in detail into BAMF. I want the definition of an app
in the OS, not as glue code bolted on top that works with heuristics.

> Do you think systemd approach will be used by or can be shared to
> non-GNOME stuff too (for instance firefox or libreoffice or qt apps and
> so on)?

Yes, it pushes the definition of an app into the kernel, via
cgroups. That is compatible with all kinds of apps.

> > systemd is Linux-only. That means if we still care for those non-Linux
> > platforms replacements have to be written.
>
> So, IIRC, the release team will have to choose between "have
> features" (or enhancements to currently available features) and "create
> a lockin" (or something that, at least currently, resembles a lockin).

Using "lock-in" as word is inappropriate here. It's free software. That
per definition doesn't cause lock-in.

It's like it always is: some features are available on some systems
only, but the others can catch up if they want.

> Do you think we (release team) should follow a technical approach or a
> "political" approach to this question? Why?

I dont understand the question.

I tried to outline the mode of cooperation I am suggesting on these
interfaces.

> We are still at 3.2 release and systemd is a young project and not
> widely adopted solution. Any special reason to introduce this "lockin"
> in GNOME now?

There is no lock-in.

I think it is amazingly widely adopted. fedora, meego, suse,
mandriva/mageia will do their coming releases with it by
default. Debian, Gentoo, Arch have it, too.

> Isn't better to wait next releases and systemd maturity (read: a more
> clear vision about systemd adoption in linux world and in non-linux
> environments)? Do you have any plan to "sponsor" systemd outside linux
> world (apart "here is the code, but I will not introduce your non-linux
> stuff")?

I think if the distributions put enough trust in systemd to make it the
default then this should be more than enough for GNOME.

I have a very clear vision of systemd on non-Linux systems: it makes no
sense. I have made that clear repeatedly. See above.

> > systemd itself has very minimal external dependencies. You need Linux,
> > udev, D-Bus, and that's it. (there are a couple of additional optional
> > deps however).
>
> Could you please list those optional deps and explain how they are
> useful?

They integrate systemd with other stuff. If you have gtk you get a gtk
frontend. If you have PAM you get a PAM module. If you have
libcryptsetup you get automatic handling of cryptodisks, if you have
libaudit then systemd will write audit records for you. If you have
libselinux systemd will put proper SELinux labels on everything. If you
have tcpwrap then systemd will check tcpwrap for sockets. Nothing of
that is really relevant for GNOME.

> > The first version i'd like to see blessed is systemd 26.
>
> Do you have any plan about API/ABI/interface/other/whatever stability or
> similar? How will a break effect GNOME modules?

http://www.freedesktop.org/wiki/Software/systemd/InterfaceStabilityPromise

Lennart

--
Lennart Poettering - Red Hat, Inc.