1 |
On Mon, Feb 17, 2014 at 6:17 AM, Tanstaafl <tanstaafl@×××××××××××.org> wrote: |
2 |
[snip] |
3 |
> Maybe it is 'full of errors', but is the primary point true? |
4 |
|
5 |
False implies whatever you want it to imply. You can't prove anything |
6 |
if your assumptions are incorrect. |
7 |
|
8 |
>> There is actually little code inside PID 1; |
9 |
> |
10 |
> |
11 |
> The quoted text said nothing about this, so please stay on point. |
12 |
|
13 |
I was answering to someone else. |
14 |
|
15 |
> As to the point raised: |
16 |
> |
17 |
> |
18 |
>>> Can you surgically remove systemd in the future without reverse |
19 |
>>> engineering |
20 |
>>> half of what the LSB would look at the time, or will its developers |
21 |
>>> ensure |
22 |
>>> that this is a one time choice only? |
23 |
> |
24 |
> |
25 |
>> You guys talk about software like if it was a big bad black magical |
26 |
>> box with inexplicable powers. |
27 |
>> |
28 |
>> If someone is willing and able, *everything* can be "surgically |
29 |
>> remove[d]". We got rid of devfs, remember? We got rid of OSS (thank |
30 |
>> the FSM for ALSA). We got rid of HAL (yuck!). GNOME got rid of bonobo, |
31 |
>> and ESD. KDE got rid of aRts (and who knows what more). |
32 |
> |
33 |
> |
34 |
> I think you are being a little disingenuous here. |
35 |
|
36 |
I am not. |
37 |
|
38 |
> The obvious unspoken meaning behind the 'can you surgically remove' was: |
39 |
> |
40 |
> Can you do it *easily*? I'm sure you would not suggest that getting rid of |
41 |
> the above were 'easy'? |
42 |
|
43 |
I've never said it was easy. I said it could be done by someone |
44 |
willing and able. I repeated that like five times I think. I said it |
45 |
was done before; I never said it was easy. |
46 |
|
47 |
But it can be done, and that's a indisputable fact. |
48 |
|
49 |
> It simply doesn't matter if systemd boils down to one monolithic binary, or |
50 |
> 600, if they are tied together in such a way that they can not |
51 |
> *individually* be replaced *easily and simply* (ie, without having to |
52 |
> rewrite the whole of systemd). |
53 |
|
54 |
You are setting a group of conditions that preemptively wants to stop |
55 |
adoption of anything that is tightly integrated. That is a losing |
56 |
strategy (different projects actually *want* tight integration), and |
57 |
besides the burden of work should not fall on the people wanting to |
58 |
use a tightly integrated stack. |
59 |
|
60 |
You want individual modules that are "easily and simply" replaced? |
61 |
Then WROTE THEM. Don't expect the systemd authors (or any other) to do |
62 |
it for you. |
63 |
|
64 |
> That said, it seems to me that, for now at least, it isn't that big a deal |
65 |
> to switch back and forth between systemd and, for example, OpenRC. |
66 |
|
67 |
It depends; right now you can't switch back and forth between OpenRC |
68 |
and systemd without reemerging some stuff. Some of those packages |
69 |
*could* be made to switch functionality at run time instead of compile |
70 |
time, but SOMEONE has to write that support, and it's probably that |
71 |
the upstream for the package will not accept those changes, since for |
72 |
binary distributions it makes no sense to have the complexity on the |
73 |
code of switching behavior at runtime when doing at compile time is |
74 |
easier and the distribution generates one binary per architecture for |
75 |
all its users. |
76 |
|
77 |
> So my main concern is - will it still be possible - *and* easy - in a year? |
78 |
> Three years? Five? If the answer to *any* of those is no, then I think the |
79 |
> best solution - for gentoo at least - is to make whether or not systemd is |
80 |
> to be used more like a *profile* choice - a decision that you can make at |
81 |
> install time, similar to choosing between hardened or not (not easy/simple |
82 |
> to switch to/from after a system is up and running). |
83 |
|
84 |
That's how it works right now, because Gentoo developers *did* the |
85 |
work. And the whole point of my "willing and able" mantra is to see if |
86 |
someone here steps up into the plate. |
87 |
|
88 |
It's *really* easy to say "oh, systemd should be provided by a profile |
89 |
so the user is free to CHOICE if she wants to use it or not", but |
90 |
*someone* has to write the necessary support so that the profile |
91 |
actually exists. You want to be sure your choice is not "taken away" |
92 |
from you? Join Gentoo and help to make that choice possible. |
93 |
|
94 |
Don't expect that someone will do it for you. |
95 |
|
96 |
There is a lengthy discussion in gentoo-dev about the problem with |
97 |
understaffed arch teams. It's worth a reading, but the general |
98 |
consensus is that the minor archs cannot be kept in stable if there |
99 |
are not enough developers for said arch to do the testing. |
100 |
|
101 |
It sucks? Of course it sucks; but there is no magical fairy that |
102 |
automatically will keep working all the ebuilds for all the archs in |
103 |
Gentoo. SOMEONE has to do the testing, someone has to triage bugs, |
104 |
someone has to *fix* them. |
105 |
|
106 |
If there is no one, then the arch cannot be kept in stable. And that's |
107 |
a hard cold fact. |
108 |
|
109 |
If *all* the Gentoo developers switched to systemd (highly unlikely), |
110 |
then how could they support a separated profile for systemd? They |
111 |
won't, and your "choice" will then be "taken away". |
112 |
|
113 |
If the Gentoo developers decide that having systemd in a separated |
114 |
profile is too much work (likely, even now), then what? More whining |
115 |
from users because they "took away" their "choice"? |
116 |
|
117 |
They could whine all they want, but if nobody steps up to the plate to |
118 |
do the actual work, nobody (necessarily) will do it for them. |
119 |
|
120 |
> In fact, it seems to me that, since (from what I've read) the primary reason |
121 |
> that systemd was written in the first place was to provide extremely fast |
122 |
> boots *in virtualized environments*, |
123 |
|
124 |
You are wrong; systemd was created because Upstart had the silly CLA |
125 |
from Canonical[1], and because its authors wanted a novel init system |
126 |
for Linux (and Linux only) that used all the cool technologies the |
127 |
kernel provides, and that it could solve problems like: how to easily |
128 |
and consistently start daemons with well defined semantics for its |
129 |
dependencies; how to easily and consistently apply resource quotas to |
130 |
them; how to deal with modern computers where hardware comes and goes |
131 |
(including CPUs) all the time, etc. [2]. |
132 |
|
133 |
> having it be a choice made by selecting |
134 |
> a corresponding *profile* is the *ideal* solution - at least for gentoo. At |
135 |
> least this way everything could be documented, and switching between a |
136 |
> systemd and non-systemd profile can be supported for as long as possible, |
137 |
> understanding that at some point in time it may have to become an install |
138 |
> time choice - kind of like choosing between hardened or not is mostly an |
139 |
> install time choice now. |
140 |
|
141 |
That profile idea sounds even reasonable. But I don't think the devs |
142 |
will implement it, since simple dependencies seems to work up until |
143 |
now, and *someone* would need to write the profile, and *someone* |
144 |
would need to test it, and *someone* would need to triage bugs for it, |
145 |
and *someone* would need to fix them. |
146 |
|
147 |
If *someone*, *willing* AND *able* steps up to do ALL that work, MAYBE |
148 |
it would happen. |
149 |
|
150 |
But don't complain if no one does, and it doesn't. |
151 |
|
152 |
Regards. |
153 |
|
154 |
[1] https://plus.google.com/u/0/+KaySievers/posts/C3chC26khpq |
155 |
[2] http://0pointer.de/blog/projects/systemd.html |
156 |
-- |
157 |
Canek Peláez Valdés |
158 |
Posgrado en Ciencia e Ingeniería de la Computación |
159 |
Universidad Nacional Autónoma de México |