Re: systemd as external dependency

On Wed, 18.05.11 15:40, Michael Biebl (mbiebl gmail com) wrote:

> > We're already using the hostnamed interface in the info panel, allowing
> > changing the machine's "pretty hostname".
> Isn't that the kind of functionality that was supposed to be provided
> in gnome-system-tools and system-tools-backend? What will happen with
> g-s-t and s-t-b?
> Why is it better to have that functionality in systemd itself instead
> of g-s-t?

Because it is tiny and simple and allows us to standardize configuration
files as side-effect. Having 10 different projects for 10 tiny things is
just borked. I want to ensure that everybody uses the same platform and
offers the same set of basic services. I think Linux as a platform can
only benefit if app developers don't have to keep 50 different platforms
in mind when developing code; a platform consisting of a 100 different
basic packages used in 200 different combinations. It is my intention to
do my bit to clean this all up, so that we have the same combination of
basic tools on Linux distros, with the same configuration files and only
a small set of necessary base packages.

If you keep all these things separate then you multiply the maintenance
work, and Linux continues to be the mix&match balkanized platform that
is so difficult to develop for as a 3rd party developer.

Because we can reuse a lot of code the end result will be much smaller,
more robust and normalized than if we duplicate the setup code over a
number of different base packages.

> I second that.
> Speaking as a member of the Debian GNOME team, having the independent
> parts be compilable on their own would definitely help us:
> - While Debian has a systemd package and we hope to have systemd as a
> supported alternative for wheezy, sysvinit is still the default.
> Having GNOME depend on systemd would definitely complicate things for
> us.
> -  Debian's has non-Linux ports. Having the non-arch specific parts in
> a separate package would mean we can more easily make the GNOME
> packages depend on them.

No, that's not going to happen. systemd is strictly Linux-only. I have
no plans porting it to other kernels, and I will not merge any such
patches. One of the reasons systemd is small and easy to read is that we
don't waste time and resources on abstractions and use the power the
Linux platform supports. For example our main loops are pure epoll(),
and I have no plans at all supporting anything else with a metric ton of

If the other kernels matter, then the folks working on them should share
our interfaces (such as the hostnamed bus iface), not our code.

What I am willing to support is builds of systemd that consist only of
the tiny mechanism daemons, and leave the core of it outside. That way
folks can install these mechanisms and stick with their old init systems
for a while.


Lennart Poettering - Red Hat, Inc.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]