1 |
On Sunday 23 Feb 2014 23:54:32 Canek Peláez Valdés wrote: |
2 |
> On Sun, Feb 23, 2014 at 5:12 PM, Mick <michaelkintzios@×××××.com> wrote: |
3 |
> |
4 |
> [ snip ] |
5 |
> |
6 |
> > Well, I'm no authority on this since I can't code, |
7 |
> |
8 |
> My point exactly. |
9 |
|
10 |
I think your point is not valid, unless you view Linux as an operating system |
11 |
intended for and inviting comments only from an inspired l33t who can code and |
12 |
it is *only* their user requirements that count. |
13 |
|
14 |
I understand though that it is their/their employer's choice as to how they |
15 |
spend their coding time and what they spend it on. I am not ungrateful for |
16 |
their generosity whether I agree with their approach or not. |
17 |
|
18 |
|
19 |
> And that's the point; the people doing this changes *obviously |
20 |
> understand Unix*. They understand it so well that they are able to |
21 |
> look at it honestly, beyond dogma or articles of faith, and see its |
22 |
> downsides, so they can try to fix them. |
23 |
|
24 |
You seem to have a lot of faith in their approach and choice-limiting |
25 |
decisions. They have made arbitrary decisions in developing their software in |
26 |
ways contrary to their predecessors. I don't know if this is because they are |
27 |
cleverer than their predecessors, or more ignorant/arrogant/wrong. |
28 |
|
29 |
|
30 |
> > http://en.wikipedia.org/wiki/Unix_philosophy |
31 |
> |
32 |
> This reminds me of the people that quote from religious books to argue |
33 |
> about anything non theological. The "rules" and "sound bites" in the |
34 |
> links you provide are there to summarize rules of thumb; they are NOT |
35 |
> scripture, and they are certainly NOT the only way to get a |
36 |
> technically good program that is easily maintainable. In other words, |
37 |
> you can ignore most of them, or just following them to a point, and |
38 |
> anyway end up with a sound design and a technically great program that |
39 |
> is easy to maintain and extend. |
40 |
|
41 |
I agree. This is not a religion, but a statement of design principles based |
42 |
on some observations of what seemed to work (at the time) that were made after |
43 |
the event. |
44 |
|
45 |
|
46 |
> The people with coding experience (or most of them anyway) understand |
47 |
> this; we are not a religion, we don't have prophets that speak the |
48 |
> undeniably truth. We have highly skilled developers who can have |
49 |
> opposing views on how to design and implement many different ideas, |
50 |
> and that doesn't (necessarily) means that any of them are wrong. |
51 |
|
52 |
We agree again, except that some of these opposing ideas are limiting future |
53 |
development choices and current user options. |
54 |
|
55 |
|
56 |
> There are many ways to solve a problem of sets of problems. Having |
57 |
> Emacs doesn't mean vi is "wrong", nor having GNOME means KDE is |
58 |
> "wrong", nor the other way around. |
59 |
|
60 |
KDE took a wrong turn the moment it started emulating Gnome by hardcoding |
61 |
redland a whole host of components in its pursuit of a semantic desktop, |
62 |
removing choice from users who would be otherwise very happy with the KDE3 |
63 |
functionality. Many users have voted with their feet - not because they can |
64 |
code better or code at all, but because they still have a choice as plain |
65 |
users. |
66 |
|
67 |
At least KDE has not hardcoded a requirement for systemd as Gnome now has. |
68 |
|
69 |
|
70 |
> >> I've now concluded it's a myth, much like invisible pink unicorns. |
71 |
> >> |
72 |
> >> Is it like the kernel? A huge monolithic chunk of code with support for |
73 |
> >> modules? |
74 |
> > |
75 |
> > I would think that although the kernel has grown over the years, it has |
76 |
> > not done so like systemd. You can still *not* build modules you don't |
77 |
> > need in your kernel. |
78 |
> |
79 |
> This has nothing to do with "Unix principles"; it's just that someone |
80 |
> willing and able implemented the different options. |
81 |
|
82 |
Well, "someone willing and able implemented the different options", but did so |
83 |
by following the paradigm of modular development. |
84 |
|
85 |
|
86 |
> > The Unix design philosophy may not be globally applicable, but has served |
87 |
> > Linux well over the years. |
88 |
> |
89 |
> No; what has served Linux is to have developers willing and able to |
90 |
> write the necessary code, following whatever design they decide is the |
91 |
> correct one. |
92 |
|
93 |
I think we have a fundamental disagreement here. The Unix design principles |
94 |
inc. modularisation and extensibility make good sense when seen from the |
95 |
perspective of many contributors adding to and improving code in a piece meal |
96 |
fashion. X11 did not follow this approach and ended up with convoluted |
97 |
unmaintainable code that had to be broken up. |
98 |
|
99 |
Having developers able and willing to write code is of course a precondition, |
100 |
but not just any code. It has to be code which others can pick up, improve |
101 |
and extend. In other words, they have to write code which is versatile, being |
102 |
respectful of and keeping in mind future development effort. |
103 |
|
104 |
|
105 |
> > Lennart has de facto introduced a different way of |
106 |
> > developing his Linux code, which to others and me seems more restrictive. |
107 |
> |
108 |
> First of all, it's not only Lennart; the systemd repo has (literally) |
109 |
> dozens of contributors with write access. |
110 |
> |
111 |
> Second of all, calling "restrictive" the tightly integrated approach, |
112 |
> is exactly as constructive as calling "anarchic" the loosely |
113 |
> integrated one. Like "Unix principles", it means nothing and it says |
114 |
> nothing. |
115 |
|
116 |
On the contrary, I think it says something quite specific: Lennart and other |
117 |
contributors have decided to not follow a modular approach and have hard |
118 |
wired components into a growing monolith. In doing so they have remove choice |
119 |
from users. You want Gnome? You *must* user systemd. At least for this |
120 |
reason alone his and other contributors design approach is deficient and |
121 |
criticised by many as inappropriate for Linux. |
122 |
|
123 |
I expect that ultimately, this hard wiring will meet its timely end because it |
124 |
is by its nature self-limiting and a new development effort will start again. |
125 |
-- |
126 |
Regards, |
127 |
Mick |