1 |
On 8/5/19 4:49 AM, Mick wrote: |
2 |
> It is being /assertively/ promoted persistently by the same devs. |
3 |
|
4 |
Okay. |
5 |
|
6 |
Just because it's the same developers promoting both does not mean that |
7 |
any logic / evidence they might provide in support of /usr merge is |
8 |
inherently wrong. We should judge the merits of their logic / evidence |
9 |
on it's own, independent of what we think of their other work. (Read: |
10 |
Don't turn this technical conversation into a character discussion.) |
11 |
|
12 |
> Sure, but for how much longer? |
13 |
|
14 |
/me looks around for something that he must have missed. |
15 |
|
16 |
I didn't see anything about combining bin and sbin. |
17 |
|
18 |
Let's focus on the /usr merger discussion /first/. Then we can address |
19 |
bin vs sbin. |
20 |
|
21 |
> You need to check the direction of travel here and how long before a |
22 |
> particular dev priesthood which imposes initrd, systemd and a single |
23 |
> partition image, or whatever suits their mass market use cases agenda, |
24 |
> foists their choice upon *all* users. |
25 |
|
26 |
Again, focus on technical, this is not a character discussion. |
27 |
|
28 |
I also don't think they will be successful in foisting their ideas on |
29 |
*all* users. I'm quite confident that there will always be some random |
30 |
distro that does not subscribe to them. Maybe the usable percentage |
31 |
will be quite small. But any distro that doesn't tow the line means |
32 |
that not /all/ distros follow the agenda. (Yes, I'm saying distro |
33 |
instead of user, but I think you understand either way.) |
34 |
|
35 |
I personally don't like the idea of /{,s}bin being a sym-link to |
36 |
/usr/\1. I like the idea that / (root) and /usr are (or can be) |
37 |
separate file systems. That being said, I've not actually /needed/ them |
38 |
to be separate file systems in quite a while. I may have /wanted/ them |
39 |
to be separate so that I could utilize different file system types for / |
40 |
(root) and /usr. |
41 |
|
42 |
Looking back at all the systems that I've administered for the last ~20 |
43 |
years, almost all of them did use a single file system for / (root) and |
44 |
/usr. Sure, they likely had other file systems as well; /var, /tmp, and |
45 |
/home most likely. |
46 |
|
47 |
Given how Unix / Linux is changing—evolving—where and how it's being |
48 |
used, I can see how there is no longer any need for the separate file |
49 |
systems. I think this lack of need combined with the additional |
50 |
complexity is evolving into a desire for a single file system for / |
51 |
(root) and /usr. Since I can't point to any specific use case—in about |
52 |
90 seconds—that a single file system would break, I'm pausing and thinking. |
53 |
|
54 |
So, since we're discussing it, I invite you, and anyone else, to list |
55 |
pros and / or cons for either methodology. I'm quite interested in |
56 |
learning what others think. |
57 |
|
58 |
I will warn you that I'll likely respond with counter points and / or |
59 |
workarounds. I will also expect that you will respond in kind to my |
60 |
response. |
61 |
|
62 |
10 point |
63 |
20 counterpoint |
64 |
30 counter counterpoint |
65 |
40 goto 10 |
66 |
|
67 |
> I think following the lib directories merge, the discussion is now about |
68 |
> merging: |
69 |
> |
70 |
> /bin -> /usr/bin |
71 |
> /sbin -> /usr/bin |
72 |
> /usr/sbin -> /usr/bin |
73 |
|
74 |
Let's fully qualify those directories. ;-) |
75 |
|
76 |
I've not seen /any/ discussion about merging bin and sbin. Perhaps I've |
77 |
just missed it. I'm going to ignore the merging of bin and sbin for the |
78 |
time being. |
79 |
|
80 |
> Since you asked this is my understanding, which may need correction by more |
81 |
> learned contributors, because some of this has happened well before I sat in |
82 |
> front of a keyboard. Back in late 60s, early 70s, disks became larger as UNIX |
83 |
> was getting bigger. |
84 |
|
85 |
ACK |
86 |
|
87 |
> This initially led to /bin and /sbin split across different physical |
88 |
> devices and soon the same happened for /home, et al. |
89 |
|
90 |
That's different than the history that I've heard. |
91 |
|
92 |
Originally, everything was on one single disk. |
93 |
|
94 |
Then a second disk was added and /usr was created. User home |
95 |
directories were moved to /usr (hence it's name), and many of the same |
96 |
directory structures were replicated from / (root) to /usr. (Likewise |
97 |
with /usr/local on other Unixes / Linuxes later.) |
98 |
|
99 |
Then a third disk was added and /home was created. User home |
100 |
directories were moved to /home. |
101 |
|
102 |
So the /bin vs /sbin split that you're referring to doesn't jive with |
103 |
the history that I've seen / read / heard time and time again. |
104 |
|
105 |
My understanding is that /sbin was originally intended for binaries |
106 |
needed to bring the system up. (I view the "s" in "sbin" as meaning |
107 |
"system (binaries)".) |
108 |
|
109 |
Similarly, my understanding is that /bin was originally intended for |
110 |
general use binaries that were used by more people. |
111 |
|
112 |
Note: The same understanding applies to the directories wherever they |
113 |
are located, / (root), /usr, and /usr/local. |
114 |
|
115 |
But, I am ~> we are, ignoring bin vs sbin for much of this message and |
116 |
focusing on /usr merge. ;-) |
117 |
|
118 |
> This historical fact of UNIX evolution to use multiple and subsequently larger |
119 |
> storage devices is being conflated with the purpose of these directories, what |
120 |
> they were created for back then and what their use should be today. |
121 |
|
122 |
That sounds good. But please put some details behind it. What do you |
123 |
think the purpose of the directories was? (Please provide your |
124 |
counterpart to what I outlined above.) |
125 |
|
126 |
> The passage of time has introduced shared libs, which necessitate |
127 |
> certain directories being on the same fs. |
128 |
|
129 |
Nope. I can't agree to that. |
130 |
|
131 |
Nothing about shared libraries necessitates that they and the binaries |
132 |
that use them /need/ to be on the same file system. |
133 |
|
134 |
Yes, they need to be administered in concert with each other. But they |
135 |
can be in any directory (assuming proper configuration) on any |
136 |
accessible file system. |
137 |
|
138 |
We've had binaries in /usr or /usr/local or /opt or NFS mounts that rely |
139 |
on libraries in /lib. They have been working across file system |
140 |
boundaries for decades. |
141 |
|
142 |
> Back then everything was statically linked so fs could be more |
143 |
> independent. |
144 |
|
145 |
Yes, shared libraries and their associated dynamic, non-static, binaries |
146 |
have complicated things. But they don't necessitate that the binaries |
147 |
and associated libraries be on the same file system. ;-) |
148 |
|
149 |
> Whether the *initial* directory split across different fs was introduced |
150 |
> because UNIX had put on weight and disks became larger is of secondary |
151 |
> importance IMHO. |
152 |
|
153 |
How do you justify what was the /primary/ reason for the split as |
154 |
secondarily important? |
155 |
|
156 |
Or are you diverging from history and now going into what you would like |
157 |
to see in the future? |
158 |
|
159 |
> As a user I tend to focus on the current usefulness of different |
160 |
> *choices* and understand it is preferable to retain them |
161 |
> architecturally as choices to also suit other users' preferences and |
162 |
> use cases. |
163 |
|
164 |
Sure. |
165 |
|
166 |
> I'm talking about an acceptance of Linux and Gentoo in particular |
167 |
> as a meta-distribution being created for the benefit of a community |
168 |
> of users which is wider than my single interests and needs, but also |
169 |
> wider than individual developers agendas and preferences. |
170 |
|
171 |
Okay. |
172 |
|
173 |
> That said devs are of course free to develop what they like, want |
174 |
> and prefer, but if they cannot/will not serve the wider needs of |
175 |
> the project and its community, then it may suit them to look for a |
176 |
> new project. |
177 |
|
178 |
Be careful with that statement. |
179 |
|
180 |
Here's how that played out in my head: |
181 |
|
182 |
"If you (Developer) can't / won't follow the Gentoo way, then you need |
183 |
to go elsewhere." |
184 |
|
185 |
To me, that's antithetical to Unix's open methodology of "I made this, |
186 |
if you can use it, great!". It also feels rather Debian ish to me. |
187 |
"No, we don't accept your licensing for Mozilla Firefox, so we will fork |
188 |
it and make our own program based on your code." |
189 |
|
190 |
Please be careful. If that's what you /mean/ to imply, well.... If |
191 |
it's not, be mindful of how someone that you're telling to change might |
192 |
receive it. |
193 |
|
194 |
> As the world moved on and Linux was created, the split fs concept |
195 |
> grew legs and different distros made their own choices how different |
196 |
> directories/fs were created and their permanence between reboots, |
197 |
> e.g. /tmp, /var/tmp, /usr/tmp etc.> This created the known Linux |
198 |
> fs architecture variability which could well suited the particular |
199 |
> distro communities who introduced it, |
200 |
|
201 |
This is /far/ from a Linux thing. It may (now) be more prevolent and / |
202 |
or visible in Linux. But this very thing has existed in Unix for the |
203 |
last 40+ years. |
204 |
|
205 |
> but I understand why it would not suit cookie-cutter thin provisioned |
206 |
> VM images. |
207 |
|
208 |
Please enlighten me why this might not suite cookie-cutter thin |
209 |
provisioned (virtual) machines. |
210 |
|
211 |
Note: Virtual or not makes effectively no difference. |
212 |
|
213 |
Unix and Linux distros have been automating the deployment of multiple |
214 |
partitions ~> file systems for 30+ years. This is nothing new. We do |
215 |
and have had the tools to do this for a long time. |
216 |
|
217 |
The only thing that I see changing is people are asking /why/ there are |
218 |
separate partitions ~> file systems. More specifically, they are asking |
219 |
why they can't be one partition ~> file system. I think asking those |
220 |
questions is a very good thing. |
221 |
|
222 |
Note: Asking the question indicates that someone is paying attention |
223 |
and thinking. The act of asking the question and listening ~> thinking |
224 |
does /not/ mean that things are going to change. |
225 |
|
226 |
Remember, thin provisioning is possible on physical systems connected to |
227 |
SAN too. |
228 |
|
229 |
> This brings my understanding to today's purpose of having different |
230 |
> /bin, / sbin, /usr/bin and /usr/sbin directories as per FHS: |
231 |
> |
232 |
> /bin should contain binaries that need to be available in single user |
233 |
> mode for all users, like ls, cp, cat. |
234 |
> |
235 |
> /sbin is for system binaries, like fsck, route, init, halt. |
236 |
> |
237 |
> /usr/bin is for non-essential binaries for all users, your everyday |
238 |
> desktop applications. |
239 |
> |
240 |
> /usr/sbin is for non-essential system binaries like daemons, network |
241 |
> utilities, some fs utilities. |
242 |
> |
243 |
> The above FHS logic questions why you would need /usr to be mounted |
244 |
> in order to boot the OS, |
245 |
|
246 |
I don't think it questions anything. On the contrary, I think it calls |
247 |
out that /usr should /not/ be needed to boot the system. |
248 |
|
249 |
> or why using an initrd to achieve it is what we should be doing in |
250 |
> gentoo a meta-distribution, just because all binary distros do so. |
251 |
|
252 |
I think that initramfs / initrd is a bit of a hack to make it simpler |
253 |
for distributions to boot without any knowledge of the hardware that |
254 |
they are booting on. |
255 |
|
256 |
I personally have never used an initramfs / initrd on any of my Gentoo |
257 |
systems. I have a kernel with the necessary drivers built in and I pass |
258 |
the root device as a command line option. |
259 |
|
260 |
Admittedly, almost all of my systems are not using anything like iSCSI |
261 |
or multi-path for the / (root) file system. Though I think it's |
262 |
particularly likely fair to say that the vast majority of systems |
263 |
qualify there too. VMs and containers are even more likely to qualify too. |
264 |
|
265 |
> Yes, this is what *community* projects are constitutionally put |
266 |
> together for. Otherwise we all have our own pet projects, but (I hope) |
267 |
> we don't try to foist them on our friends and neighbors. |
268 |
|
269 |
I'm afraid that some people think of a community as their walled garden |
270 |
and that everybody inside of it must do the same thing. |
271 |
|
272 |
I think of a community as people that have some overlapping ideas and |
273 |
differing ideas that benefit from each other, including the different |
274 |
perspective. I certainly hope that these types of communities don't |
275 |
shun / exclude outsiders simply because they think or do something |
276 |
differently. |
277 |
|
278 |
Aside: I'm watching Old Usenet (currently from '89) where people are |
279 |
publishing what they have done that has worked for them. The spirit is |
280 |
akin to "Here's something. If you can take it, adapt it, and use it, |
281 |
then please do so." |
282 |
|
283 |
> For the good reasons presented above as per FHS I want to retain the |
284 |
> ability of a separate /usr and I would much prefer it as it was before |
285 |
> on its own partition and without an initrd. |
286 |
|
287 |
I'm not convinced that /bin & /sbin /need/ to be separate from /usr/bin |
288 |
& /usr/sbin. Yes, they certainly can be. FHS speaks to why /it/ (as |
289 |
opposed to a different file system hierarchy standard) does what it does. |
290 |
|
291 |
Your /preference/ is exactly that, a /preference/. You are obviously |
292 |
free to have your own preferences. But a /preference/ does not directly |
293 |
translate to a /need/. ;-) |
294 |
|
295 |
> The /usr fs can be mounted as read only for an additional layer of |
296 |
> security. I used to have /usr on a separate partition, but since |
297 |
> initrd became a necessity to keep /usr separate I moved it under /. |
298 |
|
299 |
I've not installed a Gentoo system onto a separate /usr file system in |
300 |
quite a while. So I can't speak with any current authority as to if |
301 |
it's possible or not with /Gentoo/. |
302 |
|
303 |
I do know for a fact that it is quite possible to install other |
304 |
/distributions/ onto separate file systems /without/ an initramfs / initrd. |
305 |
|
306 |
> I have used initrds over the years and some of my binary systems |
307 |
> have it by design, but it is not a design choice I want to adopt. |
308 |
|
309 |
My opinion is that an initramfs / initrd is a hack used by distributions |
310 |
to make their lives easier. |
311 |
|
312 |
I remember the days when Slackware had a HUGE kernel that included an |
313 |
extremely large number of drivers /in/ /the/ /kernel/ so that it could |
314 |
boot and see the vast majority of hardware. Then you installed what you |
315 |
needed where you wanted it, all without an initramfs / initrd. One of |
316 |
the first things that was frequently done was rebuilding a kernel that |
317 |
only had the drivers that you needed. |
318 |
|
319 |
About the only thing that I'm aware of that /necessitates/ an initramfs |
320 |
/ initrd is complicated storage like iSCSI and / or multi-path SAN |
321 |
attachments for the / (root) file system. Maybe for 3rd party binary |
322 |
only drivers for local storage. Beyond that, I'm not aware of anything |
323 |
that can't be done from the / (root) file system. |
324 |
|
325 |
I guess disk encryption would also be another thing. Though I've not |
326 |
/seen/ the / (root) file system encrypted on servers. I have read about |
327 |
some people doing it on VPSs. (My VPS has an unencrypted root with a |
328 |
LUKS encrypted data partition.) |
329 |
|
330 |
> I would still prefer / usr being on its own partition and without |
331 |
> an initrd whether I use it today or not. I mean, if I want to use |
332 |
> initrd, systemd, binary log files and whatever else, there are a |
333 |
> tonne of binary distros out there to choose from. The *main* reason |
334 |
> I use Gentoo is because of the user choice and flexibility it offers, |
335 |
> something binary distros cannot provide. |
336 |
|
337 |
You are free to have any preference you want. As are we all. |
338 |
|
339 |
Sometimes we have to decide if we want to allow our preference to make |
340 |
decisions for us by excluding options that don't honor our preference. |
341 |
|
342 |
> I don't know when it kicked in, because I don't follow the dev mailing |
343 |
> list, but I assume it became necessary when the drive to align with |
344 |
> RHL design principles started being implemented? |
345 |
> |
346 |
> https://packages.gentoo.org/useflags/split-usr |
347 |
|
348 |
Sadly, that doesn't give any context, much less history. I assume |
349 |
that's contained in a mailing list archive somewhere. |
350 |
|
351 |
> I'd rather keep things as they have been/were until and unless the |
352 |
> usefulness of a change weighs heavier than keeping them the same |
353 |
|
354 |
Fair enough. |
355 |
|
356 |
That mirrors my logic process on many things too. |
357 |
|
358 |
Aside: I questioned the need to remove Token Ring support from |
359 |
3.<something> kernels. I question the need to remove floppy drive |
360 |
support now. |
361 |
|
362 |
> the community at large agrees with it after being presented with the |
363 |
> factual arguments for and against. |
364 |
|
365 |
Sure. |
366 |
|
367 |
> By all means let's merge /bin into /usr/bin, but not if the caveat is |
368 |
> we now *must* have an initrd to be able to boot |
369 |
|
370 |
Agreed. |
371 |
|
372 |
> and the only reason to change is so that gentoo becomes aligned with |
373 |
> the systemd project. |
374 |
|
375 |
I don't think alignment with another project is a valid reason. I am |
376 |
willing to entertain discussions about the ideas why other projects have |
377 |
done something and assess if we want to make a similar change |
378 |
independent of the project that we are observing make the same change. |
379 |
|
380 |
Read: |
381 |
|
382 |
· I /don't/ want to start cooking my food because my neighbor is doing it. |
383 |
· I /do/ want to start cooking my food because I think that cooked |
384 |
food is tastier than uncooked food. |
385 |
|
386 |
> Let's review any changes on their merits *before* they are implemented. |
387 |
|
388 |
Sure. |
389 |
|
390 |
|
391 |
|
392 |
-- |
393 |
Grant. . . . |
394 |
unix || die |