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

[Andrew Savchenko <bircoph@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4215 bytes --]

On Mon, 17 Feb 2014 18:35:34 -0600 Canek Peláez Valdés wrote:
[...]
> >> >>> Complexity means bugs.
> >> >> Bugs get reported, bugs get fixes. Life goes on.
> >>
> >> You didn't answered this, did you?
> >
> > Bugs are different.
> 
> Bugs are bugs, period. And they get reported and fixed.

Bugs are not equal. They differ in at least two dimensions:
significance depending on the component affected and severity of the
bug itself.

> > Bugs in the critical system components are
> > critical to the whole system.
> 
> Yeah, that's why we have unit testing and QA teams and stable and
> unstable releases, etc.

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.

> > If Libreoffice or browser
> > segfaults, some data may be lost and inconvenience created, but the
> > system will continue to run. If PID 1 segfaults — everything is
> > lost, you have a kernel panic.
> 
> And the world will end? The same happens if the kernel has an error.

Kernel has mature error correction infrastructure (Oops handling) and
much wider community.
 
> > That's why critical components should
> > be as simple and clean as possible.
> 
> Like the kernel? You call that "simple"?

Don't mix user space and kernel space, please. There are
more secure by design micro kernels out there (like Hurd), but
they're out of the scope of this discussion.

> I'm sorry, but you are (IMO) wrong: critical components should be
> thoroughly tested and debugged, and have integrated unit testing, and
> a large enough group of volunteers to test new releases before they go
> into the general public.

You're pointing to valid issues, but not to the whole picture.
Critical components should _start_ from good design, sound modular
architecture and _then_ with QA and testing. You're omitting the most
important stuff, though.

> > 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.

If that code will fail, this wouldn't be critical at system level.
Thus scope of fatal error is limited.

> > Even assuming
> > systemd code is as mature as sysvinit or openrc (though I doubt this)
> > you can calculate probabilities of segfaults yourself easily.
> 
> I don't care about probabilities; I care about facts: FACT, I've been
> using systemd since 2010, in several machines, and I haven't had a
> single segfault. FACT: almost no bug report in systemd involves a
> segfault in PID 1.

You need facts? Here is one for you (systemd-208):
http://fly.osdn.org.ua/~mike/img/misc/systemd-segfault.jpg
 
> >> > Looks broken. Broken by design. The worst form of broken.
> >>
> >> By your opinion, not others.
> >
> > That is not just an opinion. There is a science and experience behind
> > system's design.
> 
> Yeah, what do you think about  Greg Kroah-Hartman, Linus' right hand,
> or Keith Packard of X.org fame? None of them works for Red Hat; both
> of them know more about Unix and Linux than you and me together, and
> both of them promote systemd.

I respect Greg for most of his work, but this doesn't mean he is an
oracle we need to adhere to. But in FOSS reputation is not that
important, though clean technical reasons are.
 
> > And all that science was ignored during systemd
> > architecture process if there was any at all.
> 
> You should read systemd-devel and Lennart's blog posts before saying
> something like that. I did.

I read that blog. No valid reason were found (if we're comparing
systemd to what is outside of systemd's world, not only to bare
sysvinit). But what I found it that blog is a lack of thorough
project design (it looks like many components were added by the fly
without preliminary planning) and a lot of religious statements.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]