On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote: > On Tue, Feb 18, 2014 at 10:36 AM, Andrew Savchenko <birc...@gmail.com> > wrote: > [...] >> 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.
Agreed, but I know of enough large projects with large development teams and even more users that don't get the most basic bugs fixed. Quantity is not equivalent to Quality. >> 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. Incorrect. How many people use systemd as opposed to SysV Init? >>> > 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. The shell-code is proven to work though and provided with most of the software. Where it isn't provided, it can be easily created. I have seen (and used) complex start-up scripts for large software implementations which complex dependencies. Fortunately, later versions of those software packages have fixed that mess to a large extend, but I wonder how well systemd unit-files can work in such an environment. Having sockets created prior to service start will not work as components will fail due to time-outs, leaving even a bigger mess. >> 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). I understand the usecase for "logind", but what is the point of a daemon to supply the time (datetimed)? Is this a full replacement for "ntpd"? And what does "localed" do? That's configured once in the environment and should be handled using environment variables. -- Joost
