1 |
On Tue, Feb 18, 2014 at 5:35 AM, Andrew Savchenko <bircoph@×××××.com> wrote: |
2 |
> On Mon, 17 Feb 2014 19:09:40 -0600 Canek Peláez Valdés wrote: |
3 |
>> > How Integrated? The TCP/IP stack *is* integrated. But it is *protocol* |
4 |
>> > integration, *standards* integration not *software* integration. You do want |
5 |
>> > tight integration where it just can't work otherwise, but the design of Unix |
6 |
>> > provides (well, again repeating this), and almost any robust design should |
7 |
>> > provide, the ignorance of one abstraction level about another. Why HAL? Why |
8 |
>> > udev? Why drivers as modules? Why not just go and integrate all stuff into |
9 |
>> > the kernel, well (again!) like MS do, and don't please say I compare wrong |
10 |
>> > things just because MS is not OSS. |
11 |
>> |
12 |
>> You make a wrong comparison, because MS is not free (libre) software. |
13 |
>> With Linux, and systemd, and OpenRC, and HAL, and devfs, and sysv, we |
14 |
>> have been able to try new technologies (and see that some of them |
15 |
>> fail, like HAL [yuck!]), because we have the source. |
16 |
> |
17 |
> But the comparison is quite right. When one have to deal with software |
18 |
> lock-in, this means that one have to fork a huge stack of software |
19 |
> which is theoretically doable (because software is free), but is |
20 |
> impractical unless one owns a corporation with large number of full |
21 |
> time paid developers. The same way one in theory can change everything |
22 |
> in MS by changing assembler code of their software. Well, this will |
23 |
> require some time, but asm is nothing more than low-level programming |
24 |
> language, thus formally one have "the sources". |
25 |
|
26 |
You cannot distribute changes that you do to proprietary disassembled |
27 |
code. So again, the comparison makes no sense. |
28 |
|
29 |
> The key feature here is deliberate and malicious lock-in: as long as |
30 |
> software enforces one, it is non-free in practical terms. |
31 |
|
32 |
We are running around in circles; I told you why is not a reasonable |
33 |
comparison, and I failed to convince you. You told me that it's a |
34 |
right comparison to make, and you failed to convince me. We could keep |
35 |
beating a dead horse, but it's better if we agree to disagree on this |
36 |
point. |
37 |
|
38 |
(Which kinda makes the rest of the discussion moot, but whatever). |
39 |
|
40 |
>> As you said, you can replace the whole of Linux if you so desire (and |
41 |
>> have the technical ability). |
42 |
>> |
43 |
>> You will never be able to do that with any MS software, and so the |
44 |
>> comparison makes no sense. |
45 |
> |
46 |
> Hey, but people are already doing this! Google for ReactOS or Wine. |
47 |
|
48 |
I mentioned ReactOS in this thread; from [1]: |
49 |
|
50 |
"If enough people, willing and able, want to do it, they will. Look at |
51 |
ReactOS. Or Syllable. Or Hurd. Or Debian/kFreeBSD." |
52 |
|
53 |
However, the ReactOS people aren't disassembling code; they are coding |
54 |
a different (but compatible) implementation. Same goes with Wine. |
55 |
|
56 |
And even if you say that disassembled code is the same as carefully |
57 |
written code (which is not), we have comments inside the code [2], and |
58 |
DCSV logs [3], and tons of documentation. With proprietary code we |
59 |
don't; sometimes a little documentation for how to *use* the code, but |
60 |
not how to *change* it or *understand* it. |
61 |
|
62 |
>> The thing (and that's also my point), apparently *most* of the people |
63 |
>> willing and able to create cool software have decided that systemd is |
64 |
>> the way to go. And, even if you want to attribute that to a simple |
65 |
>> monetary issue, most of them do it *happily* because many things are |
66 |
>> just easier to do with systemd. |
67 |
> |
68 |
> Most people should never care what init system is in charge while |
69 |
> writing end-user software. If software (e.g. some daemon) depends on |
70 |
> specific init system, it is broken by design. |
71 |
|
72 |
They don't care about the "init" system. They care about the |
73 |
*features* systemd provides; logind, the journal, timedated, |
74 |
hostnamed, etc. |
75 |
|
76 |
Obviously systemd is much more than just an init system. |
77 |
|
78 |
>> > They'll be able to |
79 |
>> > stuff everything into it, making effectively a thing in itself which will |
80 |
>> > dictate you where to go and what to do, just because you're not technically |
81 |
>> > competent enough to deal with it -- hence more support calls and more $ etc |
82 |
>> > etc. |
83 |
>> |
84 |
>> Oh, but nobody will be able to do that to me. I know how to write |
85 |
>> code. I'm willing (and I believe able) to write and/or modify software |
86 |
>> if I don't like how it does things. I've done it before; I could do it |
87 |
>> again. |
88 |
> |
89 |
> Even if you have superior and outstanding programming skills I doubt |
90 |
> you have time and resources to rewrite the whole software stack (e.g. |
91 |
> systemd and everything depending on it) yourself. |
92 |
|
93 |
As I said, that is moot since Linux+systemd+GNOME are taking Linux to |
94 |
the place I always wanted it to be. |
95 |
|
96 |
>> >> If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE |
97 |
>> >> it would happen. |
98 |
>> >> |
99 |
>> >> But don't complain if no one does, and it doesn't. |
100 |
>> > |
101 |
>> > |
102 |
>> > That's your point -- and mine. We aren't complaining -- we want to prevent |
103 |
>> > this. |
104 |
>> |
105 |
>> Prevent what? People writing new software that offers cool features, |
106 |
>> and therefore distros are using them? |
107 |
> |
108 |
> Prevent loosing our freedom in practical sense: while the software |
109 |
> will be still free in FSF license terms, it will be so locked onto |
110 |
> itself that it will be eventually impossible for anyone besides large |
111 |
> corporations to replace it. Thus in the end we'll be dictated what to |
112 |
> do and how to do. |
113 |
|
114 |
You will never loose your freedom in the most practical of senses: the |
115 |
code is free. |
116 |
|
117 |
>> > The forward-looking people must unite, it may sound ridiculous, |
118 |
>> > against systemd |
119 |
>> |
120 |
>> You cannot stop people for writing new cool stuff, nor distros for |
121 |
>> wanting to using them. You CAN write your own cool stuff, and |
122 |
>> convincing people that is better than the alternative. |
123 |
> |
124 |
> And you can't force people to use your cool stuff because you're |
125 |
> assuming it is cool. |
126 |
|
127 |
Who is forcing you? If at some point in the future the Gentoo council |
128 |
sets systemd as the default recommended init system for the |
129 |
distribution, OpenRC will still be available. |
130 |
|
131 |
Nobody is forcing no one to anything. |
132 |
|
133 |
> That's called freedom, freedom of choice. That |
134 |
> is what I love Gentoo for. That's why I support systemd |
135 |
> profile propose. |
136 |
|
137 |
Well, "support" is code, not words. This is not a democracy; the users |
138 |
don't "vote" what they want. |
139 |
|
140 |
If that's the option you prefer, help the devs achieve it. |
141 |
|
142 |
> That's why I will do my best to protect this freedom |
143 |
> in our community. |
144 |
|
145 |
Do it with code, not arguing in a mailing list. |
146 |
|
147 |
And I'm not talking about C; ebuilds, overlays, the profiles settings, |
148 |
even documentation; anything that helps the distro go in the direction |
149 |
you want it to go. |
150 |
|
151 |
Again, arguing in the ML has no real impact in the distro. |
152 |
|
153 |
>> > You know what it is: everything's free but nothing to choose from. We had it |
154 |
>> > before, it's called communism. Maybe it is not that bad but we don't want it |
155 |
>> > anymore. |
156 |
>> |
157 |
>> (Really? A cold war reference?) |
158 |
> |
159 |
> Yes, we have a software^Wcorporation war right upon us. |
160 |
|
161 |
There is no war; we are all on the same side, the FLOSS side. |
162 |
|
163 |
Regards. |
164 |
|
165 |
[1] http://article.gmane.org/gmane.linux.gentoo.user/272617 |
166 |
[2] http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/sd-journal.c#n63 |
167 |
[3] http://cgit.freedesktop.org/systemd/systemd/log/ |
168 |
[4] http://www.freedesktop.org/wiki/Software/systemd/#manualsanddocumentationforusersandadministrators |
169 |
-- |
170 |
Canek Peláez Valdés |
171 |
Posgrado en Ciencia e Ingeniería de la Computación |
172 |
Universidad Nacional Autónoma de México |