On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <jo...@antarean.org> wrote: > On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote:
[ snip ] >> 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. I also agree with that. My point is that the systemd project has enough numbers of *talented* developers to do it. You can disagree, of course. >> 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? Users? Like five thousand godzillions more. Developers? It would not surprise me that systemd has several times more developers that SysV ever had. What's more, I think those developers are talented enough, to say the least. >>>> > 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. You can read [1]. I think it provides a fair and impartial account of how to use systemd to start a complex service (NFS, by its author). > Having sockets created prior to service start will not work as components > will fail due to time-outs, leaving even a bigger mess. I could be wrong, but I believe the use of cgroups takes care of all that. If the service fails, systemd PID 1 can reliable detect it, and force the socket to close, and even reopen it for new connections if so configured by the administrator. >>> 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. I'm sorry, but *everything* you are asking for is in the link I gave you that you qualified it of "not necessary for this discussion" (I also pointed someone else to [2]). If you are really interested in the answers, go on and read it there. It's certainly better than hearing it from me. Regards. [1] http://lwn.net/Articles/584175/ [2] http://www.freedesktop.org/wiki/Software/systemd/#manualsanddocumentationforusersandadministrators -- Canek Peláez Valdés Posgrado en Ciencia e Ingeniería de la Computación Universidad Nacional Autónoma de México
