1 |
On Sat, Feb 22, 2014 at 6:40 AM, Canek Peláez Valdés <caneko@×××××.com> wrote: |
2 |
> On Fri, Feb 21, 2014 at 2:14 PM, J. Roeleveld <joost@××××××××.org> wrote: |
3 |
>> On Thu, February 20, 2014 06:34, Canek Peláez Valdés wrote: |
4 |
>>> On Wed, Feb 19, 2014 at 3:00 AM, J. Roeleveld <joost@××××××××.org> wrote: |
5 |
>>>> On Tue, February 18, 2014 18:12, Canek Peláez Valdés wrote: |
6 |
>>> |
7 |
>>> [ snip ] |
8 |
>>> |
9 |
>>>>> Of course the larger a project is the *potential* number of bugs |
10 |
>>>>> increases, but so what? With enough developers, users and testers, all |
11 |
>>>>> bugs are *potentially* squashed. |
12 |
>>>> |
13 |
>>>> Agreed, but I know of enough large projects with large development teams |
14 |
>>>> and even more users that don't get the most basic bugs fixed. |
15 |
>>>> Quantity is not equivalent to Quality. |
16 |
>>> |
17 |
>>> I also agree with that. My point is that the systemd project has |
18 |
>>> enough numbers of *talented* developers to do it. |
19 |
>>> |
20 |
>>> You can disagree, of course. |
21 |
>> |
22 |
>> Talented developer, maybe. |
23 |
>> But not talented designers. |
24 |
> |
25 |
> That's subjective. For me (and many others), the design of systemd is sound. |
26 |
> |
27 |
>>>>> And systemd has a *much* wider community than any other init system. |
28 |
>>>>> So it can handle a larger code base. |
29 |
>>>> |
30 |
>>>> Incorrect. How many people use systemd as opposed to SysV Init? |
31 |
>>> |
32 |
>>> Users? Like five thousand godzillions more. |
33 |
>> |
34 |
>> I tend to disagree. |
35 |
> |
36 |
> I meant that SysV has like five thousand godzillions more that |
37 |
> systemd. Sorry for the confussion. |
38 |
> |
39 |
>> Systemd is ONLY on Linux. |
40 |
>> SysV init can be found on alot of other platforms used in the world. Think |
41 |
>> Solaris, AIX, HPuX and Linux machines that have not had their init-systems |
42 |
>> changed. |
43 |
>> |
44 |
>>> Developers? It would not surprise me that systemd has several times |
45 |
>>> more developers that SysV ever had. |
46 |
>> |
47 |
>> Maybe, but the developers back then still followed the unix-way: Have a |
48 |
>> tool do one job and do it well. |
49 |
> |
50 |
> Again, for many of us that doesn't matter, and we don't take it like |
51 |
> an article of faith. |
52 |
> |
53 |
>> From what I see from systemd, it tries to do too much and the single jobs |
54 |
>> suffer from feature-bloat. |
55 |
> |
56 |
> Many of us believe they solve real problems, and they make our life easier. |
57 |
> |
58 |
>>> What's more, I think those developers are talented enough, to say the |
59 |
>>> least. |
60 |
>> |
61 |
>> I miss talented designers. |
62 |
> |
63 |
> Wonder why? |
64 |
> |
65 |
>>>>>>> > SysVinit code size is about 10 000 lines of code, OpenRC contains |
66 |
>>>>>>> > about 13 000 lines, systemd  about 200 000 lines. |
67 |
>>>>>>> |
68 |
>>>>>>> If you take into account the thousands of shell code that SysV and |
69 |
>>>>>>> OpenRC need to fill the functionality of systemd, they use even more. |
70 |
>>>> |
71 |
>>>> The shell-code is proven to work though and provided with most of the |
72 |
>>>> software. Where it isn't provided, it can be easily created. |
73 |
>>>> I have seen (and used) complex start-up scripts for large software |
74 |
>>>> implementations which complex dependencies. |
75 |
>>>> Fortunately, later versions of those software packages have fixed that |
76 |
>>>> mess to a large extend, but I wonder how well systemd unit-files can |
77 |
>>>> work |
78 |
>>>> in such an environment. |
79 |
>>> |
80 |
>>> You can read [1]. I think it provides a fair and impartial account of |
81 |
>>> how to use systemd to start a complex service (NFS, by its author). |
82 |
>> |
83 |
>> I would not class NFS as a complex service. |
84 |
>> I am talking about a dozen different services that need to be started in a |
85 |
>> specific order where the next one is not allowed to start before the |
86 |
>> previous one actually responds to TCP/IP connections. |
87 |
> |
88 |
> If you had read the link, you would have learned that NFS has 14 unit |
89 |
> files, form a lot of daemons that have to run in concurrent form (and |
90 |
> some of them only when others are not, etc.) It *IS* a complex |
91 |
> service. |
92 |
> |
93 |
>> How would I configure that in systemd unit-files? |
94 |
> |
95 |
> Read the link |
96 |
|
97 |
Canek, you're too polite. |
98 |
|
99 |
This deserves a /usr/src/linux/Documentation/ManagementStyle, chapter 5 |
100 |
reply. At my risk entirely, here is one: |
101 |
|
102 |
You ignorant nitwit. |
103 |
|
104 |
Read the fine link. Read the fine docs. Read the fine manual. Read the |
105 |
fine publicly |
106 |
posted rationales. Read the fine publicly held distro and package manager |
107 |
discussions. And know what a fine socket is before you start spouting |
108 |
your diarrhea crap about spawning sockets in advance. |
109 |
|
110 |
And if you don't, here's the thing, maybe you're not really familiar |
111 |
with the "Unix |
112 |
way" that you're so proud about. Because you don't get to skip all that and make |
113 |
ridiculous sweeping generalizations and assertions that the docs DO answer. |
114 |
|
115 |
The so-called Unix way that many of you peeps are waxing priest-like about |
116 |
is in reality just one aspect, one part of the Unix way, meant to |
117 |
apply to a particular |
118 |
class of applications. It doesn't apply to everything. |
119 |
|
120 |
Especially, text filter design does not apply to applications that are |
121 |
meant for solving genuinely complex problems - the kernel itself is a glaring |
122 |
violation of the one small thing doing one thing well rule. And why? One, |
123 |
because it uses that complexity to solve things that would be harder to do |
124 |
in the minikernel approach, and two, even as the complex beast it has become |
125 |
it's still simpler (read: Unixier) than the alternative solution of |
126 |
interacting servers. |
127 |
|
128 |
Even as the complex beast it has become systemd is still simpler than the |
129 |
alternative of having abominations of unreliable shell scripts checking to see |
130 |
which version of grep and sed is used to split the command line, or whether |
131 |
the system uses tempfile or mktemp, or depending on perl. |
132 |
|
133 |
ergo libreoffice. desktop environments. firefox. databases. Heck much of |
134 |
what's being said about systemd applies to postfix - there's no general case |
135 |
reason for me to grab some random postfix component and use it for everyday |
136 |
work, therefore postfix is just some closed-source monolithic virus, right? |
137 |
-- |
138 |
This email is: [ ] actionable [ ] fyi [x] social |
139 |
Response needed: [ ] yes [x] up to you [ ] no |
140 |
Time-sensitive: [ ] immediate [ ] soon [x] none |