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

[Gevisz]

On Mon, 17 Feb 2014 18:35:34 -0600
Canek Peláez Valdés <caneko@×××××.com> wrote:

> On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko
> <bircoph@×××××.com> wrote:
> > On Sun, 16 Feb 2014 15:16:36 -0600 Canek Peláez Valdés wrote:
> >> On Sun, Feb 16, 2014 at 2:58 PM, Volker Armin Hemmann
> >> <volkerarmin@××××××××××.com> wrote:
> >> > Am 16.02.2014 21:08, schrieb Canek Peláez Valdés:
> >> >> On Sun, Feb 16, 2014 at 12:59 PM, Volker Armin Hemmann
> >> >> <volkerarmin@××××××××××.com> wrote:
> >> >> [ snip ]
> >> >>> or it is an idiotic decision. Because features means
> >> >>> complexity.
> >> >> Yeah, like the kernel.
> >> >>
> >> >>> 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 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.
>
> > 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.
>
> > That's why critical components should
> > be as simple and clean as possible.
>
> Like the kernel? You call that "simple"?
>
> 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.

How can you be sure if something is "large enough" if, as you say below,
you do not care about probabilities?

> > 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.
>
> Also, again, systemd have a lot of little binaries, many of them
> optional. The LOC of PID 1 is actually closer to SysV (although still
> bigger).
>
> > 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;

If you do not care (= do not now anything) about probabilities
(and mathematics, in general), you just unable to understand
that debugging a program with 200K lines of code take

200000!/(10000!)^20

more time than debugging of 20 different programs with 10K lines of
code. You can try to calculate that number yourself but I quite sure
that if the latter can take, say, 20 days, the former can take
millions of years.

It is all the probability! Or, to be more precise, combinatorics.  

> I care about facts: FACT, I've been using systemd since 2010,
> in several machines, and I haven't had a single segfault.

Have you ever tried forex? If yes, you should have been warned
that "no past performance guarantee the future one."

And if you do not believe that (and do not care about probability
and all the stuff like that), you should visit any of the forex forums
where you will be suggested a magical money winning strategy that, in
the past, behaved very well and earned 200 or even 500% a month.

> FACT: almost no bug report in systemd involves a
> segfault in PID 1.
>
> >> >> All of them are different tools providing one capability to
> >> >> systemd as a whole. So systemd is a collection of tools, where
> >> >> each one does one thing, and it does it well.
> >> >>
> >> >> By your definition, systemd perfectly follows "the unix way".
> >> >>
> >> >
> >> > no, it isn't.
> >> >
> >> > How are those binaries talk to each other?
> >>
> >> dbus, which is about to be integrated into the kernel with kdbus.
> >
> > And this is a very, very bad idea. Looks like you don't know matter
> > at all: to begin with kdbus protocol is NOT compatible dbus and
> > special converter daemon will be needed to enable dbus to talk to
> > kdbus.
>
> kdbus uses a different wire protocol than dbus; but for clients that
> doesn't matter; libsystemd-dbus will offer a compatibility layer (talk
> about "standard" and "replaceable"), so if your application uses dbus
> today, it will work with kdbus.
>
> Of course, new applications will take advantage of the new features
> of kdbus.
>
> > The
> > whole kdbus technology is very questionable itself (and was
> > forcefully pushed by RH devs),
>
> Sorry, but it's you who doesn't know the matter at hand: kdbus was
> (and is) written by Greg Kroah-Hartman, Linus' right hand, and who
> works for the Linux Foundation.

Lol, he seems to start to use the arguments like "You even do not know
my elder brother/acquaintance from the street nearby who can easily
hit you down!"

So, here, I would like to thank everybody in this discussion who
helped me to understand the danger of systemd and note that it is
now became pointless to continue this discussion with this "unpayed
systemd promoter."

> > anyway it is possible to disable this
> > stuff in kernel and guess what will be done on my systems.
>
> Good for you. Guess what will be done in mine?
>
> >> > 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.

Aha! How could you even doubt my understanding the words of these prophets! :-)
 
> I mean, I myself know a thing or two about computing and Linux, and I
> promote systemd (and nobody pays me, BTW), but obviously you don't
> need to believe in my credentials.

I have said you, he is just an unpayed fanatic systemd promoter!  
 
> And, no offense, but I will always give more weight to the words of
> Greg Kroah-Hartman or Keith Packard (to name only two), instead of a
> random user in gentoo-user.
>
> There are knowledgeable people who are against systemd. But usually
> they don't give *technical* sound reasons.
>
> > 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

And A Holy Words of our Mighty God!

> before saying something like that. I did.
>
> Regards