Re: [gentoo-user] Debian just voted in systemd for default init system in jessie

[J. Roeleveld]

On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
> On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <bircoph@×××××.com>
> wrote:
> [...]
>> Every decent project has QA and unit tests one way or another. But
>> the larger project is, the more bugs it has. And I do not want bugs
>> in PID 1, that's why it should be small and sound, not bloated (even
>> with some components split as separate binaries) and broken by design.
>
> Of course the larger a project is the *potential* number of bugs
> increases, but so what? With enough developers, users and testers, all
> bugs are *potentially* squashed.

Agreed, but I know of enough large projects with large development teams
and even more users that don't get the most basic bugs fixed.
Quantity is not equivalent to Quality.

>> Kernel has mature error correction infrastructure (Oops handling) and
>> much wider community.
>
> And systemd has a *much* wider community than any other init system.
> So it can handle a larger code base.

Incorrect. How many people use systemd as opposed to SysV Init?

>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains
>>> > about 13 000 lines, systemd — about 200 000 lines.
>>>
>>> If you take into account the thousands of shell code that SysV and
>>> OpenRC need to fill the functionality of systemd, they use even more.

The shell-code is proven to work though and provided with most of the
software. Where it isn't provided, it can be easily created.
I have seen (and used) complex start-up scripts for large software
implementations which complex dependencies.
Fortunately, later versions of those software packages have fixed that
mess to a large extend, but I wonder how well systemd unit-files can work
in such an environment.
Having sockets created prior to service start will not work as components
will fail due to time-outs, leaving even a bigger mess.

>> If that code will fail, this wouldn't be critical at system level.
>> Thus scope of fatal error is limited.
>
> Also in systemd, since most of its code is not critical (again;
> logind, datetimed, localed, etc., failing, has no impact whatsoever on
> the rest of the system).

I understand the usecase for "logind", but what is the point of a daemon
to supply the time (datetimed)? Is this a full replacement for "ntpd"?
And what does "localed" do? That's configured once in the environment and
should be handled using environment variables.

--
Joost