1 |
On Monday, 5 August 2019 17:17:53 BST Grant Taylor wrote: |
2 |
> On 8/5/19 4:49 AM, Mick wrote: |
3 |
|
4 |
> Just because it's the same developers promoting both does not mean that |
5 |
> any logic / evidence they might provide in support of /usr merge is |
6 |
> inherently wrong. We should judge the merits of their logic / evidence |
7 |
> on it's own, independent of what we think of their other work. (Read: |
8 |
> Don't turn this technical conversation into a character discussion.) |
9 |
|
10 |
I am not entertaining ad hominem attacks on whoever may have been involved in |
11 |
such decisions. Only the impacts of such decisions on gentoo in particular. |
12 |
|
13 |
|
14 |
> > Sure, but for how much longer? |
15 |
> |
16 |
> /me looks around for something that he must have missed. |
17 |
|
18 |
I probably used an incorrect figure of speech and caused confusion. We're |
19 |
only discussing the merge of /bin and /sbin to /usr/bin and /usr/sbin (it |
20 |
seems to be more nuanced than this though - see gentoo forums thread further |
21 |
down). However, the takeover of Linux in general by systemd architectural |
22 |
changes is a fact. It is also a fact gentoo has been changed a lot to |
23 |
accommodate systemd. I have set USE="-systemd" but still end up with service |
24 |
unit files on my system, unless I take additional steps to remove/mask them. |
25 |
At some point udev/dbus/what-ever will be irrevocably linked to systemd, just |
26 |
because its devs do not care for alternative architectures. Some packages |
27 |
require systemd components, like (e)logind, and so on. Some years ago eudev |
28 |
was forked from systemd with a stated aim at the time to also restore the |
29 |
borked separate /usr without an initrd - did this ever happen? There is a |
30 |
direction of travel and it has been influenced heavily by systemd design |
31 |
decisions. |
32 |
|
33 |
|
34 |
> I didn't see anything about combining bin and sbin. |
35 |
|
36 |
There isn't any - I haven't seen it either. Sorry if I confused the point. |
37 |
|
38 |
|
39 |
> Let's focus on the /usr merger discussion /first/. Then we can address |
40 |
> bin vs sbin. |
41 |
> |
42 |
> > You need to check the direction of travel here and how long before a |
43 |
> > particular dev priesthood which imposes initrd, systemd and a single |
44 |
> > partition image, or whatever suits their mass market use cases agenda, |
45 |
> > foists their choice upon *all* users. |
46 |
> |
47 |
> Again, focus on technical, this is not a character discussion. |
48 |
> |
49 |
> I also don't think they will be successful in foisting their ideas on |
50 |
> *all* users. I'm quite confident that there will always be some random |
51 |
> distro that does not subscribe to them. Maybe the usable percentage |
52 |
> will be quite small. But any distro that doesn't tow the line means |
53 |
> that not /all/ distros follow the agenda. (Yes, I'm saying distro |
54 |
> instead of user, but I think you understand either way.) |
55 |
> |
56 |
> I personally don't like the idea of /{,s}bin being a sym-link to |
57 |
> /usr/\1. I like the idea that / (root) and /usr are (or can be) |
58 |
> separate file systems. That being said, I've not actually /needed/ them |
59 |
> to be separate file systems in quite a while. I may have /wanted/ them |
60 |
> to be separate so that I could utilize different file system types for / |
61 |
> (root) and /usr. |
62 |
|
63 |
Yes, same here, but this is primarily because since gentoo's change in this |
64 |
area I moved away from using a separate /usr fs to avoid having to use an |
65 |
initrd. |
66 |
|
67 |
|
68 |
> Looking back at all the systems that I've administered for the last ~20 |
69 |
> years, almost all of them did use a single file system for / (root) and |
70 |
> /usr. Sure, they likely had other file systems as well; /var, /tmp, and |
71 |
> /home most likely. |
72 |
> |
73 |
> Given how Unix / Linux is changing—evolving—where and how it's being |
74 |
> used, I can see how there is no longer any need for the separate file |
75 |
> systems. I think this lack of need combined with the additional |
76 |
> complexity is evolving into a desire for a single file system for / |
77 |
> (root) and /usr. Since I can't point to any specific use case—in about |
78 |
> 90 seconds—that a single file system would break, I'm pausing and thinking. |
79 |
> |
80 |
> So, since we're discussing it, I invite you, and anyone else, to list |
81 |
> pros and / or cons for either methodology. I'm quite interested in |
82 |
> learning what others think. |
83 |
|
84 |
I have given one benefit of keeping a separate fs for /usr, mounting it read |
85 |
only for daily use. Or you could have a shared NFS partition across various |
86 |
client PCs, facilitating system duplication. You could also have /usr on a |
87 |
faster disk for performance reasons. |
88 |
|
89 |
A benefit of /var being separate (or wherever www/, logs/, mail/ and databases |
90 |
are stored) is so that if it runs out of space the remaining system is not |
91 |
brought to its knees. |
92 |
|
93 |
Ditto for /home, with the addition of encrypting user's data/partition and |
94 |
mounting it with nosetuid (to prevent the users from running their own secret |
95 |
root shell). |
96 |
|
97 |
So at least two reasons, helping to manage (simply) access rights and space |
98 |
are valid enough reasons IMHO to not remove a separate /usr option from |
99 |
gentoo, but I'm interested to hear what others think. One might argue you |
100 |
still retain the option of using a separate /usr, but with the new added |
101 |
restriction of being obliged to engage in boot time gymnastics with an initrd, |
102 |
LVM, your mount-bind solution and whatever else. However, workarounds which |
103 |
add complication (remove simplicity and flexibility) to fix something after |
104 |
breaking it, is what all this argument is about. Such changes remove choice. |
105 |
|
106 |
|
107 |
> I will warn you that I'll likely respond with counter points and / or |
108 |
> workarounds. I will also expect that you will respond in kind to my |
109 |
> response. |
110 |
> |
111 |
> 10 point |
112 |
> 20 counterpoint |
113 |
> 30 counter counterpoint |
114 |
> 40 goto 10 |
115 |
|
116 |
I'll try not to mess up the thread. :-) |
117 |
|
118 |
|
119 |
> > I think following the lib directories merge, the discussion is now about |
120 |
> > |
121 |
> > merging: |
122 |
> > /bin -> /usr/bin |
123 |
> > /sbin -> /usr/bin |
124 |
> > /usr/sbin -> /usr/bin |
125 |
> |
126 |
> Let's fully qualify those directories. ;-) |
127 |
> |
128 |
> I've not seen /any/ discussion about merging bin and sbin. Perhaps I've |
129 |
> just missed it. I'm going to ignore the merging of bin and sbin for the |
130 |
> time being. |
131 |
|
132 |
Please do, the systemd merge refers merging /bin to /usr/bin and /sbin to / |
133 |
usr/sbin. |
134 |
|
135 |
https://fedoraproject.org/wiki/Features/UsrMove |
136 |
|
137 |
|
138 |
However, this gentoo thread mentions further merging, which made my head spin: |
139 |
|
140 |
https://forums.gentoo.org/viewtopic-p-7902764.html |
141 |
|
142 |
|
143 |
> So the /bin vs /sbin split that you're referring to doesn't jive with |
144 |
> the history that I've seen / read / heard time and time again. |
145 |
|
146 |
You're probably correct. In any case, the initial move of subdirectories of |
147 |
the / fs to different physical disks and hence different fs' was for storage |
148 |
space reasons. |
149 |
|
150 |
|
151 |
> My understanding is that /sbin was originally intended for binaries |
152 |
> needed to bring the system up. (I view the "s" in "sbin" as meaning |
153 |
> "system (binaries)".) |
154 |
|
155 |
Yes. |
156 |
|
157 |
|
158 |
> Similarly, my understanding is that /bin was originally intended for |
159 |
> general use binaries that were used by more people. |
160 |
|
161 |
Yes, for plain users. |
162 |
|
163 |
|
164 |
> Note: The same understanding applies to the directories wherever they |
165 |
> are located, / (root), /usr, and /usr/local. |
166 |
|
167 |
Yes. |
168 |
|
169 |
|
170 |
> > This historical fact of UNIX evolution to use multiple and subsequently |
171 |
> > larger storage devices is being conflated with the purpose of these |
172 |
> > directories, what they were created for back then and what their use |
173 |
> > should be today. |
174 |
> That sounds good. But please put some details behind it. What do you |
175 |
> think the purpose of the directories was? (Please provide your |
176 |
> counterpart to what I outlined above.) |
177 |
> |
178 |
> > The passage of time has introduced shared libs, which necessitate |
179 |
> > certain directories being on the same fs. |
180 |
> |
181 |
> Nope. I can't agree to that. |
182 |
> |
183 |
> Nothing about shared libraries necessitates that they and the binaries |
184 |
> that use them /need/ to be on the same file system. |
185 |
|
186 |
OK, I'll rephrase this. Certain binaries require corresponding libs to be |
187 |
accessible at the same time and /libs under /usr mushroomed to allow a |
188 |
separate /usr partition to function. |
189 |
|
190 |
|
191 |
> Yes, they need to be administered in concert with each other. But they |
192 |
> can be in any directory (assuming proper configuration) on any |
193 |
> accessible file system. |
194 |
> |
195 |
> We've had binaries in /usr or /usr/local or /opt or NFS mounts that rely |
196 |
> on libraries in /lib. They have been working across file system |
197 |
> boundaries for decades. |
198 |
> |
199 |
> > Back then everything was statically linked so fs could be more |
200 |
> > independent. |
201 |
> |
202 |
> Yes, shared libraries and their associated dynamic, non-static, binaries |
203 |
> have complicated things. But they don't necessitate that the binaries |
204 |
> and associated libraries be on the same file system. ;-) |
205 |
|
206 |
You are right, they just require to be accessible at the same time, which |
207 |
during boot time when some fs are not yet mounted (e.g. /usr) could cause |
208 |
breakage. |
209 |
|
210 |
|
211 |
> > Whether the *initial* directory split across different fs was introduced |
212 |
> > because UNIX had put on weight and disks became larger is of secondary |
213 |
> > importance IMHO. |
214 |
> |
215 |
> How do you justify what was the /primary/ reason for the split as |
216 |
> secondarily important? |
217 |
|
218 |
It is secondarily important today, although at the time disk space was the |
219 |
primary reason for migrating fs away from / partition. |
220 |
|
221 |
|
222 |
> Or are you diverging from history and now going into what you would like |
223 |
> to see in the future? |
224 |
|
225 |
What I was trying to say is, today storage space is usually a smaller and |
226 |
cheaper problem than it was at the early stages of UNIX and therefore *today* |
227 |
it is likely different purposes could be listed as having a higher priority |
228 |
for requiring different fs' to be deployed. Discovering my flexible gentoo |
229 |
system won't boot without an initrd, just because binary distros use initrd by |
230 |
default, should not be the logic for limiting architectural choices, on |
231 |
gentoo. We should pause, discuss and (hopefully) agree. |
232 |
|
233 |
|
234 |
> > That said devs are of course free to develop what they like, want |
235 |
> > and prefer, but if they cannot/will not serve the wider needs of |
236 |
> > the project and its community, then it may suit them to look for a |
237 |
> > new project. |
238 |
> |
239 |
> Be careful with that statement. |
240 |
> |
241 |
> Here's how that played out in my head: |
242 |
> |
243 |
> "If you (Developer) can't / won't follow the Gentoo way, then you need |
244 |
> to go elsewhere." |
245 |
|
246 |
The Gentoo Trustees should do just that, i.e. ensure the project follows the |
247 |
Gentoo way. No.1 Gentoo Principle: |
248 |
|
249 |
"Gentoo provides choices." |
250 |
|
251 |
https://wiki.gentoo.org/wiki/Foundation:Main_Page |
252 |
|
253 |
If some dev, i.e. a gentoo community member who is contributing code, limits |
254 |
choices for users, then it follows his/her code does not fit into Gentoo and |
255 |
therefore Gentoo *should* not adopt it. If s/he is a project lead and pushes |
256 |
changes against the Principles, then technical decisions on such matters can |
257 |
be taken by the Gentoo Council, but it is ultimately down to the Trustees to |
258 |
straighten out deviations from the Gentoo Principles. I've written this as if |
259 |
it is black and white, but of course there are various shades of grey in- |
260 |
between. Either way, making one wrong decision at at time could end up with |
261 |
Gentoo gradually mutating into a systemd solution, which has already |
262 |
restricted choice (udev -> usr -> initrd). |
263 |
|
264 |
|
265 |
> To me, that's antithetical to Unix's open methodology of "I made this, |
266 |
> if you can use it, great!". It also feels rather Debian ish to me. |
267 |
> "No, we don't accept your licensing for Mozilla Firefox, so we will fork |
268 |
> it and make our own program based on your code." |
269 |
|
270 |
I did not mean it this way. Code is gratefully received, but let's not change |
271 |
Gentoo because any code was received. The shoe has to fit the foot. |
272 |
|
273 |
|
274 |
> > As the world moved on and Linux was created, the split fs concept |
275 |
> > grew legs and different distros made their own choices how different |
276 |
> > directories/fs were created and their permanence between reboots, |
277 |
> > e.g. /tmp, /var/tmp, /usr/tmp etc.> This created the known Linux |
278 |
> > fs architecture variability which could well suited the particular |
279 |
> > distro communities who introduced it, |
280 |
> |
281 |
> This is /far/ from a Linux thing. It may (now) be more prevolent and / |
282 |
> or visible in Linux. But this very thing has existed in Unix for the |
283 |
> last 40+ years. |
284 |
> |
285 |
> > but I understand why it would not suit cookie-cutter thin provisioned |
286 |
> > VM images. |
287 |
> |
288 |
> Please enlighten me why this might not suite cookie-cutter thin |
289 |
> provisioned (virtual) machines. |
290 |
|
291 |
Because RHL devs have particular use cases in mind. For them /usr on a |
292 |
separate fs without an initrd is a "custom setup". |
293 |
|
294 |
|
295 |
> Note: Virtual or not makes effectively no difference. |
296 |
|
297 |
Agreed. |
298 |
|
299 |
|
300 |
> Unix and Linux distros have been automating the deployment of multiple |
301 |
> partitions ~> file systems for 30+ years. This is nothing new. We do |
302 |
> and have had the tools to do this for a long time. |
303 |
> |
304 |
> The only thing that I see changing is people are asking /why/ there are |
305 |
> separate partitions ~> file systems. More specifically, they are asking |
306 |
> why they can't be one partition ~> file system. I think asking those |
307 |
> questions is a very good thing. |
308 |
|
309 |
Sure. Investigating opportunities to improve Linux is laudable. |
310 |
|
311 |
|
312 |
> Note: Asking the question indicates that someone is paying attention |
313 |
> and thinking. The act of asking the question and listening ~> thinking |
314 |
> does /not/ mean that things are going to change. |
315 |
|
316 |
Right, until udev won't work without /usr being mounted and then an initrd is |
317 |
a must. |
318 |
|
319 |
|
320 |
> Remember, thin provisioning is possible on physical systems connected to |
321 |
> SAN too. |
322 |
> |
323 |
> > This brings my understanding to today's purpose of having different |
324 |
> > /bin, / sbin, /usr/bin and /usr/sbin directories as per FHS: |
325 |
> > |
326 |
> > /bin should contain binaries that need to be available in single user |
327 |
> > mode for all users, like ls, cp, cat. |
328 |
> > |
329 |
> > /sbin is for system binaries, like fsck, route, init, halt. |
330 |
> > |
331 |
> > /usr/bin is for non-essential binaries for all users, your everyday |
332 |
> > desktop applications. |
333 |
> > |
334 |
> > /usr/sbin is for non-essential system binaries like daemons, network |
335 |
> > utilities, some fs utilities. |
336 |
> > |
337 |
> > The above FHS logic questions why you would need /usr to be mounted |
338 |
> > in order to boot the OS, |
339 |
> |
340 |
> I don't think it questions anything. On the contrary, I think it calls |
341 |
> out that /usr should /not/ be needed to boot the system. |
342 |
|
343 |
Yes, until we started deviating from it, because someone offered us code. |
344 |
|
345 |
|
346 |
> I'm afraid that some people think of a community as their walled garden |
347 |
> and that everybody inside of it must do the same thing. |
348 |
|
349 |
Gentoo is by principle more accommodative than binary distributions and I'd |
350 |
rather it remained so. |
351 |
|
352 |
|
353 |
> I think of a community as people that have some overlapping ideas and |
354 |
> differing ideas that benefit from each other, including the different |
355 |
> perspective. I certainly hope that these types of communities don't |
356 |
> shun / exclude outsiders simply because they think or do something |
357 |
> differently. |
358 |
|
359 |
Agreed. I'm not advocating stifling discussion or innovation. |
360 |
|
361 |
|
362 |
> Aside: I'm watching Old Usenet (currently from '89) where people are |
363 |
> publishing what they have done that has worked for them. The spirit is |
364 |
> akin to "Here's something. If you can take it, adapt it, and use it, |
365 |
> then please do so." |
366 |
|
367 |
Right, which is rather different from: |
368 |
|
369 |
We've outsourced code development to RHL devs and we'll use whatever they feed |
370 |
us, even if this changes our OS to a disagreeable degree. |
371 |
|
372 |
At the same time I know devs are a scarce resource and good devs even scarcer, |
373 |
so there will always be a need to avoid reinventing the wheel and use what |
374 |
upstream provide. I just hope the Gentoo principles hold a while longer. |
375 |
-- |
376 |
Regards, |
377 |
|
378 |
Mick |