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

[Gevisz]

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

> On Mon, Feb 17, 2014 at 8:05 PM, Gevisz <gevisz@×××××.com> wrote:
> [ snip ]
> > How can you be sure if something is "large enough" if, as you say
> > below, you do not care about probabilities?
>
> By writing correct code?

No, by arguing that fixing bugs in a 200K line program is as easy as
fixing a bug in 20 10K line programs. It is just not true, just the
opposite. 

> >> > 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.
>
> My PhD thesis (which I will defend in a few weeks) is in computer
> science, specifically computational geometry and combinatorics.

It is even more shameful for you to not understand such a simple facts
from elementary probability theory (which is mostly based on
combinatorics).

And, believe me, here, in this mailing list, there are a lot people
that have there PhD defended a long time ago. However, they do not
thing it is appropriate to use such facts in their arguments about
merits or "dismerits" of one or the other approach to computer
programming.   

> But hey, thanks for the lesson.

Not at all.

> >> 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."
>
> I never said that. I trust the quality of the code, measured by my own
> judgment and bug reports, etc. Not past performance.
>
> And even if a bug goes by, then what? The world will end?
>
> No, the bug will be reported, and fixed. And life will go on.
>
> > 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.
>
> Thanks for the tip, but I have never understood the people that
> believes economics is closer to mathematics than sociology.
>
> >> 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!"
>
> If you don't think Greg's words have any weight in a Linux-related
> technical discussion, then I'm afraid we will need to agree to
> disagree on any technical subject.
>
> > 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."
>
> Getting personal, are we?

I am really sorry for getting personal here, but it was only because
your level of argumentation went far below any acceptable level and
it became absolutely clear that you continue to argue only because
you do not want to accept that you are wrong and, moreover, it already
looks like you are trying to sell to others the thing that they do not
want to buy. 

> >> > 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! :-)
>
> They, contrary to you, actually give technical arguments instead of
> splutter some nonsense about combinatorics that has nothing to do with
> the subject at hand.
>
> >> 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!
>
> OK, that's it; I actually thought for a moment that you wanted to have
> a civil, intelligent and technical oriented conversation. I now see
> you don't.

Once more, I am really sorry for getting personal here, but it was only
because your level of argumentation went far below any acceptable level
and it became absolutely clear that you continue to argue only because
you do not want to accept that you are wrong and, moreover, it already
looks like you are trying to sell to others the thing that they do not
want to buy.

> >> 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!
>
> And that confirms it. Goodbye; I'm done with you in this thread.
>
> Regards.