1 |
On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@××××××××.org> wrote: |
2 |
> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote: |
3 |
|
4 |
[ snip ] |
5 |
|
6 |
>> Of course the larger a project is the *potential* number of bugs |
7 |
>> increases, but so what? With enough developers, users and testers, all |
8 |
>> bugs are *potentially* squashed. |
9 |
> |
10 |
> Agreed, but I know of enough large projects with large development teams |
11 |
> and even more users that don't get the most basic bugs fixed. |
12 |
> Quantity is not equivalent to Quality. |
13 |
|
14 |
I also agree with that. My point is that the systemd project has |
15 |
enough numbers of *talented* developers to do it. |
16 |
|
17 |
You can disagree, of course. |
18 |
|
19 |
>> And systemd has a *much* wider community than any other init system. |
20 |
>> So it can handle a larger code base. |
21 |
> |
22 |
> Incorrect. How many people use systemd as opposed to SysV Init? |
23 |
|
24 |
Users? Like five thousand godzillions more. |
25 |
|
26 |
Developers? It would not surprise me that systemd has several times |
27 |
more developers that SysV ever had. |
28 |
|
29 |
What's more, I think those developers are talented enough, to say the least. |
30 |
|
31 |
>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains |
32 |
>>>> > about 13 000 lines, systemd — about 200 000 lines. |
33 |
>>>> |
34 |
>>>> If you take into account the thousands of shell code that SysV and |
35 |
>>>> OpenRC need to fill the functionality of systemd, they use even more. |
36 |
> |
37 |
> The shell-code is proven to work though and provided with most of the |
38 |
> software. Where it isn't provided, it can be easily created. |
39 |
> I have seen (and used) complex start-up scripts for large software |
40 |
> implementations which complex dependencies. |
41 |
> Fortunately, later versions of those software packages have fixed that |
42 |
> mess to a large extend, but I wonder how well systemd unit-files can work |
43 |
> in such an environment. |
44 |
|
45 |
You can read [1]. I think it provides a fair and impartial account of |
46 |
how to use systemd to start a complex service (NFS, by its author). |
47 |
|
48 |
> Having sockets created prior to service start will not work as components |
49 |
> will fail due to time-outs, leaving even a bigger mess. |
50 |
|
51 |
I could be wrong, but I believe the use of cgroups takes care of all |
52 |
that. If the service fails, systemd PID 1 can reliable detect it, and |
53 |
force the socket to close, and even reopen it for new connections if |
54 |
so configured by the administrator. |
55 |
|
56 |
>>> If that code will fail, this wouldn't be critical at system level. |
57 |
>>> Thus scope of fatal error is limited. |
58 |
>> |
59 |
>> Also in systemd, since most of its code is not critical (again; |
60 |
>> logind, datetimed, localed, etc., failing, has no impact whatsoever on |
61 |
>> the rest of the system). |
62 |
> |
63 |
> I understand the usecase for "logind", but what is the point of a daemon |
64 |
> to supply the time (datetimed)? Is this a full replacement for "ntpd"? |
65 |
> And what does "localed" do? That's configured once in the environment and |
66 |
> should be handled using environment variables. |
67 |
|
68 |
I'm sorry, but *everything* you are asking for is in the link I gave |
69 |
you that you qualified it of "not necessary for this discussion" (I |
70 |
also pointed someone else to [2]). If you are really interested in the |
71 |
answers, go on and read it there. |
72 |
|
73 |
It's certainly better than hearing it from me. |
74 |
|
75 |
Regards. |
76 |
|
77 |
[1] http://lwn.net/Articles/584175/ |
78 |
[2] http://www.freedesktop.org/wiki/Software/systemd/#manualsanddocumentationforusersandadministrators |
79 |
-- |
80 |
Canek Peláez Valdés |
81 |
Posgrado en Ciencia e Ingeniería de la Computación |
82 |
Universidad Nacional Autónoma de México |