1 |
On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote: |
2 |
> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@××××××××.org> wrote: |
3 |
>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote: |
4 |
> |
5 |
> [ snip ] |
6 |
> |
7 |
>>> Of course the larger a project is the *potential* number of bugs |
8 |
>>> increases, but so what? With enough developers, users and testers, all |
9 |
>>> bugs are *potentially* squashed. |
10 |
>> |
11 |
>> Agreed, but I know of enough large projects with large development teams |
12 |
>> and even more users that don't get the most basic bugs fixed. |
13 |
>> Quantity is not equivalent to Quality. |
14 |
> |
15 |
> I also agree with that. My point is that the systemd project has |
16 |
> enough numbers of *talented* developers to do it. |
17 |
> |
18 |
> You can disagree, of course. |
19 |
|
20 |
Talented developer, maybe. |
21 |
But not talented designers. |
22 |
|
23 |
>>> And systemd has a *much* wider community than any other init system. |
24 |
>>> So it can handle a larger code base. |
25 |
>> |
26 |
>> Incorrect. How many people use systemd as opposed to SysV Init? |
27 |
> |
28 |
> Users? Like five thousand godzillions more. |
29 |
|
30 |
I tend to disagree. |
31 |
Systemd is ONLY on Linux. |
32 |
SysV init can be found on alot of other platforms used in the world. Think |
33 |
Solaris, AIX, HPuX and Linux machines that have not had their init-systems |
34 |
changed. |
35 |
|
36 |
> Developers? It would not surprise me that systemd has several times |
37 |
> more developers that SysV ever had. |
38 |
|
39 |
Maybe, but the developers back then still followed the unix-way: Have a |
40 |
tool do one job and do it well. |
41 |
From what I see from systemd, it tries to do too much and the single jobs |
42 |
suffer from feature-bloat. |
43 |
|
44 |
> What's more, I think those developers are talented enough, to say the |
45 |
> least. |
46 |
|
47 |
I miss talented designers. |
48 |
|
49 |
>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains |
50 |
>>>>> > about 13 000 lines, systemd — about 200 000 lines. |
51 |
>>>>> |
52 |
>>>>> If you take into account the thousands of shell code that SysV and |
53 |
>>>>> OpenRC need to fill the functionality of systemd, they use even more. |
54 |
>> |
55 |
>> The shell-code is proven to work though and provided with most of the |
56 |
>> software. Where it isn't provided, it can be easily created. |
57 |
>> I have seen (and used) complex start-up scripts for large software |
58 |
>> implementations which complex dependencies. |
59 |
>> Fortunately, later versions of those software packages have fixed that |
60 |
>> mess to a large extend, but I wonder how well systemd unit-files can |
61 |
>> work |
62 |
>> in such an environment. |
63 |
> |
64 |
> You can read [1]. I think it provides a fair and impartial account of |
65 |
> how to use systemd to start a complex service (NFS, by its author). |
66 |
|
67 |
I would not class NFS as a complex service. |
68 |
I am talking about a dozen different services that need to be started in a |
69 |
specific order where the next one is not allowed to start before the |
70 |
previous one actually responds to TCP/IP connections. |
71 |
|
72 |
How would I configure that in systemd unit-files? |
73 |
|
74 |
If I were to have sockets created in advance (does it work with TCP/IP |
75 |
sockets?) I would get timeouts on the responses which would lead to some |
76 |
services not starting correctly and ending up in limbo... |
77 |
|
78 |
>> Having sockets created prior to service start will not work as |
79 |
>> components |
80 |
>> will fail due to time-outs, leaving even a bigger mess. |
81 |
> |
82 |
> I could be wrong, but I believe the use of cgroups takes care of all |
83 |
> that. If the service fails, systemd PID 1 can reliable detect it, and |
84 |
> force the socket to close, and even reopen it for new connections if |
85 |
> so configured by the administrator. |
86 |
|
87 |
Force the socket to close? That's nice, goodbye connection to one of the |
88 |
databases. Hello auto-shutdown of services because something is clearly |
89 |
wrong. |
90 |
With auto-restart, that will create an interesting sequence of events |
91 |
designed to really break the installation. |
92 |
|
93 |
>>>> If that code will fail, this wouldn't be critical at system level. |
94 |
>>>> Thus scope of fatal error is limited. |
95 |
>>> |
96 |
>>> Also in systemd, since most of its code is not critical (again; |
97 |
>>> logind, datetimed, localed, etc., failing, has no impact whatsoever on |
98 |
>>> the rest of the system). |
99 |
>> |
100 |
>> I understand the usecase for "logind", but what is the point of a daemon |
101 |
>> to supply the time (datetimed)? Is this a full replacement for "ntpd"? |
102 |
>> And what does "localed" do? That's configured once in the environment |
103 |
>> and |
104 |
>> should be handled using environment variables. |
105 |
> |
106 |
> I'm sorry, but *everything* you are asking for is in the link I gave |
107 |
> you that you qualified it of "not necessary for this discussion" (I |
108 |
> also pointed someone else to [2]). If you are really interested in the |
109 |
> answers, go on and read it there. |
110 |
> |
111 |
> It's certainly better than hearing it from me. |
112 |
|
113 |
Maybe, but based on the name, and I am assuming the names have some sort |
114 |
of relevance, localed makes no sense. |
115 |
|
116 |
-- |
117 |
Joost |