Gentoo Archives: gentoo-user

From: "Canek Peláez Valdés" <caneko@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie
Date: Tue, 18 Feb 2014 15:02:50
Message-Id: CADPrc82-wPxcw=gsUcZcqjSrAKyB3P3FkptYo=v9XdRMCr4xTw@mail.gmail.com
In Reply to: Re: [gentoo-user] Debian just voted in systemd for default init system in jessie by Andrew Savchenko
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