On Mon, Feb 17, 2014 at 11:52 AM, Andrew Savchenko <birc...@gmail.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 >> <volkerar...@googlemail.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 >> >> <volkerar...@googlemail.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. > 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; 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. >> >> 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. > 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. 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. 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 before saying something like that. I did. Regards -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
