1 |
On Mon, Feb 24, 2014 at 2:54 PM, Mick <michaelkintzios@×××××.com> wrote: |
2 |
> On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote: |
3 |
>> On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@×××××.com> wrote: |
4 |
>> |
5 |
>> [ snip ] |
6 |
>> |
7 |
>> > Well, I'm no authority on this since I can't code, |
8 |
>> |
9 |
>> My point exactly. |
10 |
> |
11 |
> I think your point is not valid, unless you view Linux as an operating system |
12 |
> intended for and inviting comments only from an inspired l33t who can code and |
13 |
> it is *only* their user requirements that count. |
14 |
|
15 |
Of course comments can come from anyone. But it stands to reason that, |
16 |
in the first place, the people *writing* the code would primarily |
17 |
listen to people that actually know what they are talking about. In |
18 |
the second place, even if they *listen*, that doesn't mean they will |
19 |
*implement* whatever a random set of users ask for. |
20 |
|
21 |
> I understand though that it is their/their employer's choice as to how they |
22 |
> spend their coding time and what they spend it on. I am not ungrateful for |
23 |
> their generosity whether I agree with their approach or not. |
24 |
|
25 |
Glad to hear that. |
26 |
|
27 |
>> And that's the point; the people doing this changes *obviously |
28 |
>> understand Unix*. They understand it so well that they are able to |
29 |
>> look at it honestly, beyond dogma or articles of faith, and see its |
30 |
>> downsides, so they can try to fix them. |
31 |
> |
32 |
> You seem to have a lot of faith in their approach and choice-limiting |
33 |
> decisions. |
34 |
|
35 |
I have nothing even remotely close to "faith". I can read code, I can |
36 |
read design documents, and I follow the discussions in the different |
37 |
forums where systemd is the topic. It's my educated and reasonable |
38 |
conclusion that their approach is correct (in general terms; of course |
39 |
I don't agree with everything). |
40 |
|
41 |
> They have made arbitrary decisions in developing their software in |
42 |
> ways contrary to their predecessors. |
43 |
|
44 |
Excuse me, but where do you get the idea to call their decisions |
45 |
"arbitrary". Again, read the code (if you are able to), read the |
46 |
design documents, read the discussions. You can disagree with their |
47 |
decisions (I do with some of them); but I don't think there is a |
48 |
single one that can be called "arbitrary". |
49 |
|
50 |
> I don't know if this is because they are |
51 |
> cleverer than their predecessors, or more ignorant/arrogant/wrong. |
52 |
|
53 |
Not necessarily "cleverer"; they just have more software history |
54 |
available to determine what it works and what it doesn't. |
55 |
|
56 |
>> > http://en.wikipedia.org/wiki/Unix_philosophy |
57 |
>> |
58 |
>> This reminds me of the people that quote from religious books to argue |
59 |
>> about anything non theological. The "rules" and "sound bites" in the |
60 |
>> links you provide are there to summarize rules of thumb; they are NOT |
61 |
>> scripture, and they are certainly NOT the only way to get a |
62 |
>> technically good program that is easily maintainable. In other words, |
63 |
>> you can ignore most of them, or just following them to a point, and |
64 |
>> anyway end up with a sound design and a technically great program that |
65 |
>> is easy to maintain and extend. |
66 |
> |
67 |
> I agree. |
68 |
|
69 |
Glad to hear that. |
70 |
|
71 |
> This is not a religion, but a statement of design principles based |
72 |
> on some observations of what seemed to work (at the time) that were made after |
73 |
> the event. |
74 |
|
75 |
You said it: "at the time". Hardware is highly dynamic now; hard |
76 |
drives, sound cards, network cards, memory and even CPUs can come and |
77 |
go while the systems is running. SysV (and therefore, OpenRC) was |
78 |
*never* intended to work like that, so what it does it does badly, if |
79 |
at all. |
80 |
|
81 |
>> The people with coding experience (or most of them anyway) understand |
82 |
>> this; we are not a religion, we don't have prophets that speak the |
83 |
>> undeniably truth. We have highly skilled developers who can have |
84 |
>> opposing views on how to design and implement many different ideas, |
85 |
>> and that doesn't (necessarily) means that any of them are wrong. |
86 |
> |
87 |
> We agree again, except that some of these opposing ideas are limiting future |
88 |
> development choices and current user options. |
89 |
|
90 |
No they are not; THE CODE IS OUT THERE. Anyone can take the code at |
91 |
any point in time before systemd, and start a new path if this one |
92 |
turns out to be failing. There is no "limiting" no one and nothing; |
93 |
while there are people willing and able to, any design path can be |
94 |
explored. |
95 |
|
96 |
>> There are many ways to solve a problem of sets of problems. Having |
97 |
>> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is |
98 |
>> "wrong", nor the other way around. |
99 |
> |
100 |
> KDE took a wrong turn the moment it started emulating Gnome by hardcoding |
101 |
> redland a whole host of components in its pursuit of a semantic desktop, |
102 |
> removing choice from users who would be otherwise very happy with the KDE3 |
103 |
> functionality. Many users have voted with their feet - not because they can |
104 |
> code better or code at all, but because they still have a choice as plain |
105 |
> users. |
106 |
|
107 |
That's your analysis; I really don't like KDE, but I love my GNOME 3 |
108 |
desktop. That's subjective and has nothing to do with the topic at |
109 |
hand; I was talking about how different (and sometimes opposite) ways |
110 |
to solve a problem doesn't mean (necessarily) that one of them is |
111 |
wrong. |
112 |
|
113 |
> At least KDE has not hardcoded a requirement for systemd as Gnome now has. |
114 |
|
115 |
GNOME has no hardcoded requirement for systemd; do your homework. |
116 |
|
117 |
>> >> I've now concluded it's a myth, much like invisible pink unicorns. |
118 |
>> >> |
119 |
>> >> Is it like the kernel? A huge monolithic chunk of code with support for |
120 |
>> >> modules? |
121 |
>> > |
122 |
>> > I would think that although the kernel has grown over the years, it has |
123 |
>> > not done so like systemd. You can still *not* build modules you don't |
124 |
>> > need in your kernel. |
125 |
>> |
126 |
>> This has nothing to do with "Unix principles"; it's just that someone |
127 |
>> willing and able implemented the different options. |
128 |
> |
129 |
> Well, "someone willing and able implemented the different options", but did so |
130 |
> by following the paradigm of modular development. |
131 |
|
132 |
Not true; not always anyway. And that's my point; if the "rule" is |
133 |
only applied sometimes THERE IS NO RULE. |
134 |
|
135 |
>> > The Unix design philosophy may not be globally applicable, but has served |
136 |
>> > Linux well over the years. |
137 |
>> |
138 |
>> No; what has served Linux is to have developers willing and able to |
139 |
>> write the necessary code, following whatever design they decide is the |
140 |
>> correct one. |
141 |
> |
142 |
> I think we have a fundamental disagreement here. The Unix design principles |
143 |
> inc. modularisation and extensibility make good sense when seen from the |
144 |
> perspective of many contributors adding to and improving code in a piece meal |
145 |
> fashion. |
146 |
|
147 |
In some cases, yes, they did. In others (like systemd), they didn't; |
148 |
do your homework and study that cases. Just like systemd |
149 |
|
150 |
Why? Because this is not a religion, and there is no hard rule. There |
151 |
are rules of thumb that you can ignore if you think your design works |
152 |
better without them. |
153 |
|
154 |
Like systemd (in general). |
155 |
|
156 |
> X11 did not follow this approach and ended up with convoluted |
157 |
> unmaintainable code that had to be broken up. |
158 |
|
159 |
And the declared crap by the same X11 developers, and now they are |
160 |
focusing in Wayland. |
161 |
|
162 |
> Having developers able and willing to write code is of course a precondition, |
163 |
> but not just any code. It has to be code which others can pick up, improve |
164 |
> and extend. |
165 |
|
166 |
I agree; that's why systemd has recruited dozens of developers from |
167 |
basically all distributions under the sun, and they are able to pick |
168 |
up, improve and extend the code. Like networkd; that's new. Or like |
169 |
watchdog support. Or like SMACK labels. You name it. |
170 |
|
171 |
> In other words, they have to write code which is versatile, being |
172 |
> respectful of and keeping in mind future development effort. |
173 |
|
174 |
And that's the case of systemd's code, which if you took the effort to |
175 |
learn how to program, you will be able to see by yourself. Even if it |
176 |
doesn't follow all the "unix principles" to the rule, it is versatile |
177 |
and keeping in mind future development effort. That's why GNOME, KDE |
178 |
and Xfce would depend (optionally) on it; that's why the author of NFS |
179 |
was happy to finally create a set of unit files that would work on any |
180 |
distro; that's why embedded guys like Tizen or Jolla are using it. |
181 |
|
182 |
>> > Lennart has de facto introduced a different way of |
183 |
>> > developing his Linux code, which to others and me seems more restrictive. |
184 |
>> |
185 |
>> First of all, it's not only Lennart; the systemd repo has (literally) |
186 |
>> dozens of contributors with write access. |
187 |
>> |
188 |
>> Second of all, calling "restrictive" the tightly integrated approach, |
189 |
>> is exactly as constructive as calling "anarchic" the loosely |
190 |
>> integrated one. Like "Unix principles", it means nothing and it says |
191 |
>> nothing. |
192 |
> |
193 |
> On the contrary, I think it says something quite specific: Lennart and other |
194 |
> contributors have decided to not follow a modular approach and have hard |
195 |
> wired components into a growing monolith. |
196 |
|
197 |
It's modular enough, where it has reasons to be. |
198 |
|
199 |
> In doing so they have remove choice from users. |
200 |
|
201 |
Why? You can keep using the same stuff as before. |
202 |
|
203 |
> You want Gnome? You *must* user systemd. |
204 |
|
205 |
This is simply not true; GNOME 3.10 *runs in OpenBSD* [1]. Do. Your. Homework. |
206 |
|
207 |
In Gentoo you need systemd, but that's a decision from the Gentoo |
208 |
maintainers. They do the job, they make the choices. |
209 |
|
210 |
> At least for this |
211 |
> reason alone his and other contributors design approach is deficient and |
212 |
> criticised by many as inappropriate for Linux. |
213 |
|
214 |
Do your homework before saying things that are not true. |
215 |
|
216 |
> I expect that ultimately, this hard wiring will meet its timely end because it |
217 |
> is by its nature self-limiting and a new development effort will start again. |
218 |
|
219 |
Wanna bet a beer that doesn't happen in the next 20 years? I'll bet a beer. |
220 |
|
221 |
(I don't drink beer). |
222 |
|
223 |
Regards. |
224 |
|
225 |
[1] http://undeadly.org/cgi?action=article&sid=20140219085851 |
226 |
-- |
227 |
Canek Peláez Valdés |
228 |
Posgrado en Ciencia e Ingeniería de la Computación |
229 |
Universidad Nacional Autónoma de México |