On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <birc...@gmail.com> wrote: [...] > Bugs are not equal. They differ in at least two dimensions: > significance depending on the component affected and severity of the > bug itself.
I've never said that they don't have different significance, severity or scope. I said that all bugs are bugs (which is a tautology), and that you only need to fix them once to go on. >> > 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. 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. That's the important thing; you should not emasculate a project just to keep it "simple" under *your* definition of simple; have you looked at most of systemd code? It's actually pretty small and simple, and with well defined interfaces and boundaries. >> > 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. And systemd has a *much* wider community than any other init system. So it can handle a larger code base. >> > 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 not mixing kernel/user space; I'm saying that critical components don't need to be "simple"; they need to be *reliable*. >> 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. I just have a different point of view for the bigger 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. But systemd has a *good* design, a modular architecture (that's why it's splited in dozens of, you know, modules), and *besides* it has QA and testing. I'm not omitting nothing; I just don't share the same opinion as you as to what constitutes a good design. And this is debatable; with design, nothing is absolute. >> > 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. 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). >> > 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 I've never said there was no segfaults; I said I had not a single one. Also, there are also segfaults for SysV, and for OpenRC, and for almost any other software out there. The important thing is the ratio of segfaults. Again, search for yourself in the case of PID 1 in systemd. And yeah, it will be larger than SysV, but SysV has, what, 40 years of existence? systemd has 4. >> >> > 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. You are twisting my motives to mention Greg; you said "There is a science and experience behind system's design"; but apparently you only care about the experience that supports your point of view. As a counter argument I mentioned Greg and Keith because both of them have a *LOT* of experience on Unix/Linux, and they support systemd. >> > 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. Again look [1]. To me, that's a "thorough project design", and flexible enough that it has allowed to integrate more and more features in the four years since it was written. You don't agree with that? That's fine, but the design is there. We can agree to disagree if it's sound or it isn't. Regards. [1] http://0pointer.de/blog/projects/systemd.html -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
