systemd: please stop trying to take over the world :)

[Lennart Poettering]

On Mon, 13.06.11 18:01, Miloslav Trmač (mitr at volny.cz) wrote:

> 
> On Mon, Jun 13, 2011 at 5:29 PM, Lennart Poettering
> <mzerqung at 0pointer.de> wrote:
> >> "plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?
> >
> > Because we need to constantly send updates to it. It's a trivial socket
> > operation. It's a trivial thing and spawning a separate process to send
> > those updates each and every single time is a major waste of resources
> > and basically doubles the processes we have to spawn at boot.
>
> The long-term question here is "what happens when Plymouth is replaced
> by something different, first in one specialist distribution, later by
> one major distribution (perhaps Fedora), and only much later by most
> distributions?".  Will systemd only support the new thing, forcing the
> "slower" distributions to backport patches?  Will systemd support both
> systems, and over time become burdened with compatibility code?
> Something else?

As usual, we'll decide case-by-case and as I know myself and the
triviality of this code we'd probably support both for a while and then
drop the old code a bit later.

> Historically, each distribution had its own system integration scripts
> that supported only the tools the distribution cared about, so there
> never was a single project fighting with the matrix of N distributions
> x M implementations of major features.

With systemd we have a very strict policy: we want to gently push the
distros to standardize on the same components for the base system. That
means that if you use ply and systemd together you get the best features
but you can still use them independently too. It's loosely coupled, but
we do want to get people to use this combination and no other by
offering them the best support for this combination.

> >> (Also, most of them don't emit useful info on --help...)
> >
> > They aren't user binaries. They are in /lib/systemd, not /usr/bin...
> 
> But they do implement user-visible functionality, and have
> user-visible /proc/cmdline options.  Yes, old initscripts didn't
> document the behavior either, but the sysadmin (who, for better or
> worse, pretty much has to be able to read shell code) could find them
> and could understand and debug the boot process by reading /etc/rc.*.
> I think that asking the sysadmin to read the C code of systemd to
> understand the boot process and how it can be configured is rather
> excessive.

I think systemd documentation is much better than the documentation of
most other open source projects. If we missed something in the
documentation please file a bug and we'll fix it.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.