1 |
On 8/5/19 5:34 PM, Mick wrote: |
2 |
> I am not entertaining ad hominem attacks on whoever may have been |
3 |
> involved in such decisions. Only the impacts of such decisions on |
4 |
> gentoo in particular. |
5 |
|
6 |
:-) |
7 |
|
8 |
> I probably used an incorrect figure of speech and caused confusion. |
9 |
> We're only discussing the merge of /bin and /sbin to /usr/bin and |
10 |
> /usr/sbin (it seems to be more nuanced than this though - see gentoo |
11 |
> forums thread further down). |
12 |
|
13 |
I started to read to be able to be informed when drafting my reply. |
14 |
Emphasis on "started". The first comment to the quote makes me think |
15 |
that it's going to be a lively discussion. I'll read it later as time |
16 |
permits and respond accordingly. |
17 |
|
18 |
> However, the takeover of Linux in general by systemd architectural |
19 |
> changes is a fact. It is also a fact gentoo has been changed a lot |
20 |
> to accommodate systemd. I have set USE="-systemd" but still end |
21 |
> up with service unit files on my system, unless I take additional |
22 |
> steps to remove/mask them. At some point udev/dbus/what-ever will be |
23 |
> irrevocably linked to systemd, just because its devs do not care for |
24 |
> alternative architectures. Some packages require systemd components, |
25 |
> like (e)logind, and so on. Some years ago eudev was forked from |
26 |
> systemd with a stated aim at the time to also restore the borked |
27 |
> separate /usr without an initrd - did this ever happen? There is |
28 |
> a direction of travel and it has been influenced heavily by systemd |
29 |
> design decisions. |
30 |
|
31 |
ACK |
32 |
|
33 |
I think I could draw analogies with XFree86 vs Xorg vs Wayland. In the |
34 |
beginning, nobody wants to actively stop development of the old method. |
35 |
But in the end, nobody wants to devote any effort to keep bring the old |
36 |
method forward. Thus the old method gets left behind. |
37 |
|
38 |
I'm not saying it's correct, or not, just that it is the nature of things. |
39 |
|
40 |
> There isn't any - I haven't seen it either. Sorry if I confused |
41 |
> the point. |
42 |
|
43 |
Actually, the quote in the first forum post you linked to has the following: |
44 |
|
45 |
/sbin->usr/bin |
46 |
/usr/sbin->bin |
47 |
|
48 |
That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and |
49 |
combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it |
50 |
also crosses bin & sbin as well as going opposite directions with the |
51 |
links. — Yuck!!! |
52 |
|
53 |
> Yes, same here, but this is primarily because since gentoo's change in |
54 |
> this area I moved away from using a separate /usr fs to avoid having |
55 |
> to use an initrd. |
56 |
|
57 |
ACK |
58 |
|
59 |
> I have given one benefit of keeping a separate fs for /usr, mounting |
60 |
> it read only for daily use. Or you could have a shared NFS partition |
61 |
> across various client PCs, facilitating system duplication. You could |
62 |
> also have /usr on a faster disk for performance reasons. |
63 |
|
64 |
ACK |
65 |
|
66 |
> A benefit of /var being separate (or wherever www/, logs/, mail/ |
67 |
> and databases are stored) is so that if it runs out of space the |
68 |
> remaining system is not brought to its knees. |
69 |
|
70 |
ACK |
71 |
|
72 |
|
73 |
> Ditto for /home, with the addition of encrypting user's data/partition |
74 |
> and mounting it with nosetuid (to prevent the users from running |
75 |
> their own secret root shell). |
76 |
|
77 |
ACK |
78 |
|
79 |
> So at least two reasons, helping to manage (simply) access rights and |
80 |
> space are valid enough reasons IMHO to not remove a separate /usr |
81 |
> option from gentoo, but I'm interested to hear what others think. |
82 |
|
83 |
Agreed.. |
84 |
|
85 |
> One might argue you still retain the option of using a separate /usr, |
86 |
> but with the new added restriction of being obliged to engage in |
87 |
> boot time gymnastics with an initrd, LVM, your mount-bind solution |
88 |
> and whatever else. |
89 |
|
90 |
I don't have any current first hand experience with /usr being a |
91 |
separate file system without using an initramfs / initrd. So I'm going |
92 |
to have to take what you, and others, say on faith that it can't |
93 |
/currently/ be done. But I've got to say, that I find that idea |
94 |
disturbing and highly suspicious. |
95 |
|
96 |
I'd be curious for pointers to bugs about this if you have them handy. |
97 |
Please don't look, I'll dig later if I'm sufficiently motivated. |
98 |
|
99 |
> However, workarounds which add complication (remove simplicity and |
100 |
> flexibility) to fix something after breaking it, is what all this |
101 |
> argument is about. Such changes remove choice. |
102 |
|
103 |
Ya. It's sort of like painting yourself into a corner because one (or |
104 |
more) too many bad decisions were made in the past. I'd much rather |
105 |
admit that a bad decision was made, undo it, and move forward again with |
106 |
new knowledge. Sadly, IMHO not enough people do that. |
107 |
|
108 |
> I'll try not to mess up the thread. :-) |
109 |
|
110 |
:-D |
111 |
|
112 |
I'll try as well. But I'm betting that we're both human. |
113 |
|
114 |
> Please do, the systemd merge refers merging /bin to /usr/bin and |
115 |
> /sbin to / usr/sbin. |
116 |
> |
117 |
> https://fedoraproject.org/wiki/Features/UsrMove |
118 |
> |
119 |
> However, this gentoo thread mentions further merging, which made my |
120 |
> head spin: |
121 |
> |
122 |
> https://forums.gentoo.org/viewtopic-p-7902764.html |
123 |
|
124 |
Ya. I need to read that thread in detail. |
125 |
|
126 |
The following bit concerns me. I do hope that it's a typo. |
127 |
|
128 |
/sbin->usr/bin |
129 |
/usr/sbin->bin |
130 |
|
131 |
> You're probably correct. In any case, the initial move of |
132 |
> subdirectories of the / fs to different physical disks and hence |
133 |
> different fs' was for storage space reasons. |
134 |
|
135 |
Agreed. |
136 |
|
137 |
> Yes, for plain users. |
138 |
|
139 |
I think it's for /all/ users, not just plain (non-root) users, because |
140 |
root will also want commands in /bin & /usr/bin for various things. |
141 |
|
142 |
I think of it more as non-root users don't /need/ the contents of /sbin |
143 |
& /usr/sbin for the vast majority of what they do. |
144 |
|
145 |
> OK, I'll rephrase this. Certain binaries require corresponding libs |
146 |
> to be accessible at the same time and /libs under /usr mushroomed to |
147 |
> allow a separate /usr partition to function. |
148 |
|
149 |
Agreed. |
150 |
|
151 |
> You are right, they just require to be accessible at the same time, |
152 |
> which during boot time when some fs are not yet mounted (e.g. /usr) |
153 |
> could cause breakage. |
154 |
|
155 |
Yep. |
156 |
|
157 |
I have historically considered what's on the / (root) file system to be |
158 |
what's required to boot-strap the system. Once the system has been |
159 |
booted, then all typical file systems are accessible. |
160 |
|
161 |
> It is secondarily important today, although at the time disk space |
162 |
> was the primary reason for migrating fs away from / partition. |
163 |
|
164 |
Okay. That makes more sense. Thank you for clarifying. |
165 |
|
166 |
> What I was trying to say is, today storage space is usually a smaller |
167 |
> and cheaper problem than it was at the early stages of UNIX and |
168 |
> therefore *today* it is likely different purposes could be listed as |
169 |
> having a higher priority for requiring different fs' to be deployed. |
170 |
|
171 |
Fair enough. |
172 |
|
173 |
> Discovering my flexible gentoo system won't boot without an initrd, |
174 |
> just because binary distros use initrd by default, should not be the |
175 |
> logic for limiting architectural choices, on gentoo. We should pause, |
176 |
> discuss and (hopefully) agree. |
177 |
|
178 |
Agreed. |
179 |
|
180 |
> The Gentoo Trustees should do just that, i.e. ensure the project |
181 |
> follows the Gentoo way. No.1 Gentoo Principle: |
182 |
> |
183 |
> "Gentoo provides choices." |
184 |
> |
185 |
> https://wiki.gentoo.org/wiki/Foundation:Main_Page |
186 |
> |
187 |
> If some dev, i.e. a gentoo community member who is contributing code, |
188 |
> limits choices for users, then it follows his/her code does not fit |
189 |
> into Gentoo and therefore Gentoo *should* not adopt it. |
190 |
|
191 |
I feel like there is an important distinction between what you have now |
192 |
said and what I meant with what you quoted. |
193 |
|
194 |
IMHO there is a big difference in the Gentoo community deciding (through |
195 |
due process) that the community does not want to include the developers |
196 |
code into the base portage. |
197 |
|
198 |
Conversely, I was originally meaning something along the lines of "you |
199 |
don't follow the Gentoo methodology, therefore you are forbidden from |
200 |
even applying to the community for inclusion." |
201 |
|
202 |
> If s/he is a project lead and pushes changes against the Principles, |
203 |
> then technical decisions on such matters can be taken by the Gentoo |
204 |
> Council, but it is ultimately down to the Trustees to straighten |
205 |
> out deviations from the Gentoo Principles. |
206 |
|
207 |
Oy vey! |
208 |
|
209 |
> I've written this as if it is black and white, but of course there |
210 |
> are various shades of grey in- between. |
211 |
|
212 |
*nod*nod* |
213 |
|
214 |
> Either way, making one wrong decision at at time could end up with |
215 |
> Gentoo gradually mutating into a systemd solution, which has already |
216 |
> restricted choice (udev -> usr -> initrd). |
217 |
|
218 |
I don't want to agree, but your logic is correct. |
219 |
|
220 |
> I did not mean it this way. Code is gratefully received, but let's |
221 |
> not change Gentoo because any code was received. The shoe has to |
222 |
> fit the foot. |
223 |
|
224 |
Agreed. |
225 |
|
226 |
Sometimes that means taking 95% of the code and modifying 5% of it to |
227 |
fit the Gentoo methodology. ;-) |
228 |
|
229 |
> Because RHL devs have particular use cases in mind. For them /usr |
230 |
> on a separate fs without an initrd is a "custom setup". |
231 |
|
232 |
Yet RHEL has Kickstart and many different ways to automate such "custom |
233 |
setups". |
234 |
|
235 |
Has RHEL gotten /that/ short sighted that they think there are no longer |
236 |
people that do anything but click next a bunch of times and accepting |
237 |
the default? |
238 |
|
239 |
*HEAVYsigh* |
240 |
|
241 |
Nevermind. Don't answer that. |
242 |
|
243 |
> Sure. Investigating opportunities to improve Linux is laudable. |
244 |
|
245 |
Very well said. |
246 |
|
247 |
> Right, until udev won't work without /usr being mounted and then an |
248 |
> initrd is a must. |
249 |
|
250 |
I need to do some research. |
251 |
|
252 |
> Yes, until we started deviating from it, because someone offered |
253 |
> us code. |
254 |
|
255 |
Is any distro following FHS even remotely faithfully any more? I |
256 |
thought most mainstream distros had moved on about ten years ago. |
257 |
|
258 |
> Gentoo is by principle more accommodative than binary distributions |
259 |
> and I'd rather it remained so. |
260 |
|
261 |
ACK |
262 |
|
263 |
> Agreed. I'm not advocating stifling discussion or innovation. |
264 |
|
265 |
:-) |
266 |
|
267 |
> Right, which is rather different from: |
268 |
> |
269 |
> We've outsourced code development to RHL devs and we'll use whatever |
270 |
> they feed us, even if this changes our OS to a disagreeable degree. |
271 |
|
272 |
:-/ |
273 |
|
274 |
> At the same time I know devs are a scarce resource and good devs |
275 |
> even scarcer, so there will always be a need to avoid reinventing |
276 |
> the wheel and use what upstream provide. I just hope the Gentoo |
277 |
> principles hold a while longer. |
278 |
|
279 |
Maybe it's my Slackware roots showing. But I want to believe that it's |
280 |
possible to judiciously configure and compile software to work on just |
281 |
about any platform. (Assuming that the requisite version of libraries |
282 |
are somewhere on the system.) |
283 |
|
284 |
|
285 |
|
286 |
-- |
287 |
Grant. . . . |
288 |
unix || die |