1 |
On Monday, 5 August 2019 02:26:11 BST Grant Taylor wrote: |
2 |
> On 8/4/19 12:03 PM, Mick wrote: |
3 |
> > I don't know more about this, but it seems we are being dragged towards |
4 |
> > a systemd inspired future, whether the majority of the gentoo community |
5 |
> > of users want it or not. |
6 |
> |
7 |
> How is the /usr merger /directly/ related to systemd? |
8 |
|
9 |
It is being /assertively/ promoted persistently by the same devs. |
10 |
|
11 |
|
12 |
> > In my view system binaries should not be thrown in the same pot as user |
13 |
> > binaries and keeping the two separate makes good sense for those of us |
14 |
> > who do not spin up 200 cloned VMs a second on a RHL corporate farm. |
15 |
> |
16 |
> What are you using to differentiate system binaries and user binaries? |
17 |
> Are you using the /usr directory? Or the bin vs sbin directories? |
18 |
> |
19 |
> Please elaborate on your working understanding. I ask because I want |
20 |
> correctly understand you and speak to what you're talking about. |
21 |
> Especially considering that there will still be the bin vs sbin directories. |
22 |
|
23 |
Sure, but for how much longer? You need to check the direction of travel here |
24 |
and how long before a particular dev priesthood which imposes initrd, systemd |
25 |
and a single partition image, or whatever suits their mass market use cases |
26 |
agenda, foists their choice upon *all* users. |
27 |
|
28 |
I think following the lib directories merge, the discussion is now about |
29 |
merging: |
30 |
|
31 |
/bin -> usr/bin |
32 |
/sbin -> usr/bin |
33 |
/usr/sbin -> bin |
34 |
|
35 |
|
36 |
Since you asked this is my understanding, which may need correction by more |
37 |
learned contributors, because some of this has happened well before I sat in |
38 |
front of a keyboard. Back in late 60s, early 70s, disks became larger as UNIX |
39 |
was getting bigger. This initially led to /bin and /sbin split across |
40 |
different physical devices and soon the same happened for /home, et al. |
41 |
|
42 |
This historical fact of UNIX evolution to use multiple and subsequently larger |
43 |
storage devices is being conflated with the purpose of these directories, what |
44 |
they were created for back then and what their use should be today. The |
45 |
passage of time has introduced shared libs, which necessitate certain |
46 |
directories being on the same fs. Back then everything was statically linked |
47 |
so fs could be more independent. |
48 |
|
49 |
Whether the *initial* directory split across different fs was introduced |
50 |
because UNIX had put on weight and disks became larger is of secondary |
51 |
importance IMHO. As a user I tend to focus on the current usefulness of |
52 |
different *choices* and understand it is preferable to retain them |
53 |
architecturally as choices to also suit other users' preferences and use |
54 |
cases. I'm talking about an acceptance of Linux and Gentoo in particular as a |
55 |
meta-distribution being created for the benefit of a community of users which |
56 |
is wider than my single interests and needs, but also wider than individual |
57 |
developers agendas and preferences. That said devs are of course free to |
58 |
develop what they like, want and prefer, but if they cannot/will not serve the |
59 |
wider needs of the project and its community, then it may suit them to look |
60 |
for a new project. |
61 |
|
62 |
As the world moved on and Linux was created, the split fs concept grew legs |
63 |
and different distros made their own choices how different directories/fs were |
64 |
created and their permanence between reboots, e.g. /tmp, /var/tmp, /usr/tmp |
65 |
etc. This created the known Linux fs architecture variability which could |
66 |
well suited the particular distro communities who introduced it, but I |
67 |
understand why it would not suit cookie-cutter thin provisioned VM images. |
68 |
|
69 |
This brings my understanding to today's purpose of having different /bin, / |
70 |
sbin, /usr/bin and /usr/sbin directories as per FHS: |
71 |
|
72 |
/bin should contain binaries that need to be available in single user mode for |
73 |
all users, like ls, cp, cat. |
74 |
|
75 |
/sbin is for system binaries, like fsck, route, init, halt. |
76 |
|
77 |
/usr/bin is for non-essential binaries for all users, your everyday desktop |
78 |
applications. |
79 |
|
80 |
/usr/sbin is for non-essential system binaries like daemons, network |
81 |
utilities, some fs utilities. |
82 |
|
83 |
The above FHS logic questions why you would need /usr to be mounted in order |
84 |
to boot the OS, or why using an initrd to achieve it is what we should be |
85 |
doing in gentoo a meta-distribution, just because all binary distros do so. |
86 |
|
87 |
|
88 |
> > I'm not arguing against systemd, or merging all directories under an |
89 |
> > equivalent of a $WINDOWS/ path, but it seems to me a gentoo system |
90 |
> > architecture should retain the freedom of choice and flexibility it |
91 |
> > has been famous for. |
92 |
> |
93 |
> I agree that the user choice is *EXTREMELY* *IMPORTANT*! |
94 |
|
95 |
Yes, this is what *community* projects are constitutionally put together for. |
96 |
Otherwise we all have our own pet projects, but (I hope) we don't try to foist |
97 |
them on our friends and neighbors. |
98 |
|
99 |
|
100 |
> > Retrograde steps like being forced to use an initramfs just for |
101 |
> > retaining a separate /usr partition, should not be the way gentoo |
102 |
> > evolves. |
103 |
> |
104 |
> Agreed. |
105 |
> |
106 |
> I am curious why /you/ want (the ability to have) a separate /usr file |
107 |
> system. I know that I want to retain the ability. That being said, |
108 |
> I've not needed it in quite a while. |
109 |
|
110 |
For the good reasons presented above as per FHS I want to retain the ability |
111 |
of a separate /usr and I would much prefer it as it was before on its own |
112 |
partition and without an initrd. The /usr fs can be mounted as read only for |
113 |
an additional layer of security. I used to have /usr on a separate partition, |
114 |
but since initrd became a necessity to keep /usr separate I moved it under /. |
115 |
I have used initrds over the years and some of my binary systems have it by |
116 |
design, but it is not a design choice I want to adopt. I would still prefer / |
117 |
usr being on its own partition and without an initrd whether I use it today or |
118 |
not. I mean, if I want to use initrd, systemd, binary log files and whatever |
119 |
else, there are a tonne of binary distros out there to choose from. The |
120 |
*main* reason I use Gentoo is because of the user choice and flexibility it |
121 |
offers, something binary distros cannot provide. |
122 |
|
123 |
|
124 |
> I am also using a bit of a hack that I think could be (re)used to allow |
125 |
> /usr being a separate file system without /requiring/ an initramfs / |
126 |
> initrd. (I'll reply in another email with details to avoid polluting |
127 |
> this thread.) |
128 |
> |
129 |
> > Setting up a USE flag to accommodate such changes would be more |
130 |
> > agreeable for many gentoo users, rather than changing the default |
131 |
> > set up. |
132 |
> |
133 |
> Please forgive my ignorance. What was the default before 'split-user' |
134 |
> was made global? I assume that 'split-user' wasn't a default. So, by |
135 |
> my limited understanding, 1) it was / still is a USE flag and 2) has |
136 |
> chosen the more historically compatible as the new default. |
137 |
|
138 |
I don't know when it kicked in, because I don't follow the dev mailing list, |
139 |
but I assume it became necessary when the drive to align with RHL design |
140 |
principles started being implemented? |
141 |
|
142 |
https://packages.gentoo.org/useflags/split-usr |
143 |
|
144 |
|
145 |
> > NOTE: Please do not start a flamewar, I'm just expressing my opinion |
146 |
> > as a long term gentoo user who prefers to use gentoo for personal |
147 |
> > computing, instead of other binary systemd based distros. |
148 |
> |
149 |
> I'm not taking this as a flame. I'm taking it as an honest and open |
150 |
> discussion to learn what others are doing / thinking. |
151 |
> |
152 |
> For the record, I'm largely okay with /bin being a sym-link to /usr/bin. |
153 |
> However I do want /sbin to remain local to the root file system. I've |
154 |
> supported multiple installs where /usr was a separate file system and |
155 |
> needed the minimal system (not an initramfs nor an initrd) to fix things |
156 |
> at times. I'm also quite happy without an initramfs / initrd. |
157 |
|
158 |
I'd rather keep things as they have been/were until and unless the usefulness |
159 |
of a change weighs heavier than keeping them the same and the community at |
160 |
large agrees with it after being presented with the factual arguments for and |
161 |
against. By all means let's merge /bin into /usr/bin, but not if the caveat |
162 |
is we now *must* have an initrd to be able to boot and the only reason to |
163 |
change is so that gentoo becomes aligned with the systemd project. Let's |
164 |
review any changes on their merits *before* they are implemented. |
165 |
|
166 |
-- |
167 |
Regards, |
168 |
|
169 |
Mick |