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

[Denys Vlasenko]

Hi Lennart,

On Mon, 2011-06-13 at 10:15 +0200, Lennart Poettering wrote:
> On Fri, 10.06.11 15:07, Denys Vlasenko (dvlasenk at redhat.com) wrote:
> > I understand your desire to replace everything by systemd.
> 
> I have no such desire.

What is this then?

int main(int argc, char *argv[]) {
...
        if (arg_running_as == MANAGER_SYSTEM && !serialization) {
                locale_setup();

                if (arg_show_status || plymouth_running()) <== ??
                        status_welcome();

                kmod_setup();  <=== ???
                hostname_setup(); <=== ???
                machine_id_setup(); <=== ???
                loopback_setup();

                test_mtab();
                test_usr();
                test_cgroups();
        }

"plymouth_running()"? Plymouth? Systemd knows about plymouth? Why?
This is an antithesis to modular, Unix way of doing things.
It starts to have shadows of monolithic Windows-like
"we know better than you what you need" approach.

hostname_setup()?
machine_id_setup()? Why systemd has *source-code-level knowledge*
about it? I would say that if admin wants to have /etc/machine-id,
he can set up startup code to generate it.

For one, I had no /etc/machine-id on machines I was administering
for decades, with no ill effects. I don't want init to know better
than me what I want to have.

kmod_setup() loads autofs4, ipv6 and unix modules.
Why? What if I don't want to run automounter?
systemd will force me to do so?
Why it (a *program*) took upon itself to decide what modules should
be running? There decisions are traditionally up to *humans*
in Unix world.


> > I really do. syslogd, klogd, mount, fsck, and a dozen other things
> 
> We don't replace syslogd, klogd, mount, fsck and dozen of other things.

What is /lib/systemd/systemd-fsck then?
/lib/systemd/systemd-logger?
(Also, most of them don't emit useful info on --help...)


> > Now I hear about plans to incorporate ConsoleKit into it
> > (hearsay, so maybe it's not true).
> 
> Yes, systemd as a platform will include a tiny daemon which takes over
> the role of CK.

That's what I was referring to by "taking over the world".

Today I can remove CK from my Fedora install if I want to.
If it goes into systemd, I will be unable to do so.
Yet another bit of freedom taken away.


> > I propose to stop for a second and optimize systemd down
> > instead of trying to add even more bells and whistles to it.
> > Or else you'll soon end up linking against every /lib/lib*.so*
> 
> I think systemd is much more optimized that what existed
> previously. (what else is parallelization but optimization?) I bet with
> you that a systemd system (modulo SELinux) can be built in a way that
> uses much less resources and boot time than one built on Upstart.

I never used upstart. I used daemontools. I bet you can't beat *that*
on resource front. Boot time is comparable.


> (How?
> We simply spawn shell (or even zero) shells and other interpretors, and
> start a number of seldom-things only when needed and the rest in
> parallel).

Optimizing towards not spawning shell at all is a strange optimization
target. Reducing the need to spawn shells - yes, eliminating - no.


> > It is an *init replacement*, not the replacement for everything.
> 
> I like to see it as a modular platform to build an OS from.

That's what I was referring to by "taking over the world".


> It includes an
> init system and a few auxiliary tools (readahead for example, and C
> implementations of the basic boot scripts).

Readahead is a band aid for stuff which is bloated enough
to affect boot by sheer amount of necessary reading.
I don't say others must not use it, but I would like to be able
to switch it off. (For one, it makes bloat more noticeable,
so I can see what needs fixing.)
As I said, freedom to do things as admin wants
is important trait of Unix way.

C implementation of shell scripts tends to be too rigid.
I don't see why you are trying to do that.
If it because bash startup time is too long, I have
a few faster shells for you...


> > Every new feature you add and library you link against
> > works against that goal.
> 
> Nah, don't think so. We have fewer deps, and less dependencies than the
> equivalent Upstart- and shell based boot.

Competing with Upstart is easy :)


> It is my intention to minimize
> the minimum set of packages you need to bootstrap a Linux system. While
> the systemd package might get a bit bigger than sysvinit through that --
> *overall* you get a much smaller and simpler system, build from a much
> smaller number of source packages. That saves resources, makes things
> simpler and faster.

Everyone who likes coding thinks that his favorite package is great.
I have no doubt that you are proud of systemd. It actually isn't
a bad software.

However, allow me to have a not completely rosy view of it either.
"Saves resources" is not exactly true, as I see it,
on memory consumption front.


> > To be honest, I doubt the wisdom of implementing service manager
> > as an init process. There is no inherent reason why it has to be init -
> > you can run it as *a child of init*, and keep init very simple.
> 
> No, that would complicate things for little reason.

How running under PID != 1 makes any difference? I was running
various service monitoring tools as ordinary
(non-init) processes and it works equally good. No, better,
because crashes in non-init are not as detrimental.


> I find a system
> whose PID after boot is in the 500 range much simpler and leaner than
> one that is in the 5000 range.

That's what I was referring to by "taking over the world".
You want to be "special". You want to have PID 1.


-- 
vda