On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote: > On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <[email protected]> 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.
Talented developer, maybe. But not talented designers. >>> 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. I tend to disagree. Systemd is ONLY on Linux. SysV init can be found on alot of other platforms used in the world. Think Solaris, AIX, HPuX and Linux machines that have not had their init-systems changed. > Developers? It would not surprise me that systemd has several times > more developers that SysV ever had. Maybe, but the developers back then still followed the unix-way: Have a tool do one job and do it well. >From what I see from systemd, it tries to do too much and the single jobs suffer from feature-bloat. > What's more, I think those developers are talented enough, to say the > least. I miss talented designers. >>>>> > 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). I would not class NFS as a complex service. I am talking about a dozen different services that need to be started in a specific order where the next one is not allowed to start before the previous one actually responds to TCP/IP connections. How would I configure that in systemd unit-files? If I were to have sockets created in advance (does it work with TCP/IP sockets?) I would get timeouts on the responses which would lead to some services not starting correctly and ending up in limbo... >> 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. Force the socket to close? That's nice, goodbye connection to one of the databases. Hello auto-shutdown of services because something is clearly wrong. With auto-restart, that will create an interesting sequence of events designed to really break the installation. >>>> 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. Maybe, but based on the name, and I am assuming the names have some sort of relevance, localed makes no sense. -- Joost
