Re: [gentoo-user] Re: USE flag 'split-usr' is now global

[Grant Taylor <gtaylor@gentoo.tnetconsulting.net>]

On 8/5/19 4:49 AM, Mick wrote:
> It is being /assertively/ promoted persistently by the same devs.

Okay.

Just because it's the same developers promoting both does not mean that 
any logic / evidence they might provide in support of /usr merge is 
inherently wrong.  We should judge the merits of their logic / evidence 
on it's own, independent of what we think of their other work.  (Read: 
Don't turn this technical conversation into a character discussion.)

> Sure, but for how much longer?

/me looks around for something that he must have missed.

I didn't see anything about combining bin and sbin.

Let's focus on the /usr merger discussion /first/.  Then we can address 
bin vs sbin.

> You need to check the direction of travel here and how long before a 
> particular dev priesthood which imposes initrd, systemd and a single 
> partition image, or whatever suits their mass market use cases agenda, 
> foists their choice upon *all* users.

Again, focus on technical, this is not a character discussion.

I also don't think they will be successful in foisting their ideas on 
*all* users.  I'm quite confident that there will always be some random 
distro that does not subscribe to them.  Maybe the usable percentage 
will be quite small.  But any distro that doesn't tow the line means 
that not /all/ distros follow the agenda.  (Yes, I'm saying distro 
instead of user, but I think you understand either way.)

I personally don't like the idea of /{,s}bin being a sym-link to 
/usr/\1.  I like the idea that / (root) and /usr are (or can be) 
separate file systems.  That being said, I've not actually /needed/ them 
to be separate file systems in quite a while.  I may have /wanted/ them 
to be separate so that I could utilize different file system types for / 
(root) and /usr.

Looking back at all the systems that I've administered for the last ~20 
years, almost all of them did use a single file system for / (root) and 
/usr.  Sure, they likely had other file systems as well; /var, /tmp, and 
/home most likely.

Given how Unix / Linux is changing—evolving—where and how it's being 
used, I can see how there is no longer any need for the separate file 
systems.  I think this lack of need combined with the additional 
complexity is evolving into a desire for a single file system for / 
(root) and /usr.  Since I can't point to any specific use case—in about 
90 seconds—that a single file system would break, I'm pausing and thinking.

So, since we're discussing it, I invite you, and anyone else, to list 
pros and / or cons for either methodology.  I'm quite interested in 
learning what others think.

I will warn you that I'll likely respond with counter points and / or 
workarounds.  I will also expect that you will respond in kind to my 
response.

10 point
20 counterpoint
30 counter counterpoint
40 goto 10

> I think following the lib directories merge, the discussion is now about
> merging:
> 
>   /bin -> /usr/bin
>   /sbin -> /usr/bin
>   /usr/sbin -> /usr/bin

Let's fully qualify those directories.  ;-)

I've not seen /any/ discussion about merging bin and sbin.  Perhaps I've 
just missed it.  I'm going to ignore the merging of bin and sbin for the 
time being.

> Since you asked this is my understanding, which may need correction by more
> learned contributors, because some of this has happened well before I sat in
> front of a keyboard.  Back in late 60s, early 70s, disks became larger as UNIX
> was getting bigger.

ACK

> This initially led to /bin and /sbin split across different physical 
> devices and soon the same happened for /home, et al.

That's different than the history that I've heard.

Originally, everything was on one single disk.

Then a second disk was added and /usr was created.  User home 
directories were moved to /usr (hence it's name), and many of the same 
directory structures were replicated from / (root) to /usr.  (Likewise 
with /usr/local on other Unixes / Linuxes later.)

Then a third disk was added and /home was created.  User home 
directories were moved to /home.

So the /bin vs /sbin split that you're referring to doesn't jive with 
the history that I've seen / read / heard time and time again.

My understanding is that /sbin was originally intended for binaries 
needed to bring the system up.  (I view the "s" in "sbin" as meaning 
"system (binaries)".)

Similarly, my understanding is that /bin was originally intended for 
general use binaries that were used by more people.

Note:  The same understanding applies to the directories wherever they 
are located, / (root), /usr, and /usr/local.

But, I am ~> we are, ignoring bin vs sbin for much of this message and 
focusing on /usr merge.  ;-)

> This historical fact of UNIX evolution to use multiple and subsequently larger
> storage devices is being conflated with the purpose of these directories, what
> they were created for back then and what their use should be today.

That sounds good.  But please put some details behind it.  What do you 
think the purpose of the directories was?  (Please provide your 
counterpart to what I outlined above.)

> The passage of time has introduced shared libs, which necessitate 
> certain directories being on the same fs.

Nope.  I can't agree to that.

Nothing about shared libraries necessitates that they and the binaries 
that use them /need/ to be on the same file system.

Yes, they need to be administered in concert with each other.  But they 
can be in any directory (assuming proper configuration) on any 
accessible file system.

We've had binaries in /usr or /usr/local or /opt or NFS mounts that rely 
on libraries in /lib.  They have been working across file system 
boundaries for decades.

> Back then everything was statically linked so fs could be more 
> independent.

Yes, shared libraries and their associated dynamic, non-static, binaries 
have complicated things.  But they don't necessitate that the binaries 
and associated libraries be on the same file system.  ;-)

> Whether the *initial* directory split across different fs was introduced
> because UNIX had put on weight and disks became larger is of secondary
> importance IMHO.

How do you justify what was the /primary/ reason for the split as 
secondarily important?

Or are you diverging from history and now going into what you would like 
to see in the future?

> As a user I tend to focus on the current usefulness of different 
> *choices* and understand it is preferable to retain them 
> architecturally as choices to also suit other users' preferences and 
> use cases.

Sure.

> I'm talking about an acceptance of Linux and Gentoo in particular 
> as a meta-distribution being created for the benefit of a community 
> of users which is wider than my single interests and needs, but also 
> wider than individual developers agendas and preferences.

Okay.

> That said devs are of course free to develop what they like, want 
> and prefer, but if they cannot/will not serve the wider needs of 
> the project and its community, then it may suit them to look for a 
> new project.

Be careful with that statement.

Here's how that played out in my head:

"If you (Developer) can't / won't follow the Gentoo way, then you need 
to go elsewhere."

To me, that's antithetical to Unix's open methodology of "I made this, 
if you can use it, great!".  It also feels rather Debian ish to me. 
"No, we don't accept your licensing for Mozilla Firefox, so we will fork 
it and make our own program based on your code."

Please be careful.  If that's what you /mean/ to imply, well....  If 
it's not, be mindful of how someone that you're telling to change might 
receive it.

> As the world moved on and Linux was created, the split fs concept 
> grew legs and different distros made their own choices how different 
> directories/fs were created and their permanence between reboots, 
> e.g. /tmp, /var/tmp, /usr/tmp etc.> This created the known Linux 
> fs architecture variability which could well suited the particular 
> distro communities who introduced it,

This is /far/ from a Linux thing.  It may (now) be more prevolent and / 
or visible in Linux.  But this very thing has existed in Unix for the 
last 40+ years.

> but I understand why it would not suit cookie-cutter thin provisioned 
> VM images.

Please enlighten me why this might not suite cookie-cutter thin 
provisioned (virtual) machines.

Note:  Virtual or not makes effectively no difference.

Unix and Linux distros have been automating the deployment of multiple 
partitions ~> file systems for 30+ years.  This is nothing new.  We do 
and have had the tools to do this for a long time.

The only thing that I see changing is people are asking /why/ there are 
separate partitions ~> file systems.  More specifically, they are asking 
why they can't be one partition ~> file system.  I think asking those 
questions is a very good thing.

Note:  Asking the question indicates that someone is paying attention 
and thinking.  The act of asking the question and listening ~> thinking 
does /not/ mean that things are going to change.

Remember, thin provisioning is possible on physical systems connected to 
SAN too.

> This brings my understanding to today's purpose of having different 
> /bin, / sbin, /usr/bin and /usr/sbin directories as per FHS:
> 
> /bin should contain binaries that need to be available in single user 
> mode for all users, like ls, cp, cat.
> 
> /sbin is for system binaries, like fsck, route, init, halt.
> 
> /usr/bin is for non-essential binaries for all users, your everyday 
> desktop applications.
> 
> /usr/sbin is for non-essential system binaries like daemons, network 
> utilities, some fs utilities.
> 
> The above FHS logic questions why you would need /usr to be mounted 
> in order to boot the OS,

I don't think it questions anything.  On the contrary, I think it calls 
out that /usr should /not/ be needed to boot the system.

> or why using an initrd to achieve it is what we should be doing in 
> gentoo a meta-distribution, just because all binary distros do so.

I think that initramfs / initrd is a bit of a hack to make it simpler 
for distributions to boot without any knowledge of the hardware that 
they are booting on.

I personally have never used an initramfs / initrd on any of my Gentoo 
systems.  I have a kernel with the necessary drivers built in and I pass 
the root device as a command line option.

Admittedly, almost all of my systems are not using anything like iSCSI 
or multi-path for the / (root) file system.  Though I think it's 
particularly likely fair to say that the vast majority of systems 
qualify there too.  VMs and containers are even more likely to qualify too.

> Yes, this is what *community* projects are constitutionally put 
> together for.  Otherwise we all have our own pet projects, but (I hope) 
> we don't try to foist them on our friends and neighbors.

I'm afraid that some people think of a community as their walled garden 
and that everybody inside of it must do the same thing.

I think of a community as people that have some overlapping ideas and 
differing ideas that benefit from each other, including the different 
perspective.  I certainly hope that these types of communities don't 
shun / exclude outsiders simply because they think or do something 
differently.

Aside:  I'm watching Old Usenet (currently from '89) where people are 
publishing what they have done that has worked for them.  The spirit is 
akin to "Here's something.  If you can take it, adapt it, and use it, 
then please do so."

> For the good reasons presented above as per FHS I want to retain the 
> ability of a separate /usr and I would much prefer it as it was before 
> on its own partition and without an initrd.

I'm not convinced that /bin & /sbin /need/ to be separate from /usr/bin 
& /usr/sbin.  Yes, they certainly can be.  FHS speaks to why /it/ (as 
opposed to a different file system hierarchy standard) does what it does.

Your /preference/ is exactly that, a /preference/.  You are obviously 
free to have your own preferences.  But a /preference/ does not directly 
translate to a /need/.  ;-)

> The /usr fs can be mounted as read only for an additional layer of 
> security.  I used to have /usr on a separate partition, but since 
> initrd became a necessity to keep /usr separate I moved it under /.

I've not installed a Gentoo system onto a separate /usr file system in 
quite a while.  So I can't speak with any current authority as to if 
it's possible or not with /Gentoo/.

I do know for a fact that it is quite possible to install other 
/distributions/ onto separate file systems /without/ an initramfs / initrd.

> I have used initrds over the years and some of my binary systems 
> have it by design, but it is not a design choice I want to adopt.

My opinion is that an initramfs / initrd is a hack used by distributions 
to make their lives easier.

I remember the days when Slackware had a HUGE kernel that included an 
extremely large number of drivers /in/ /the/ /kernel/ so that it could 
boot and see the vast majority of hardware.  Then you installed what you 
needed where you wanted it, all without an initramfs / initrd.  One of 
the first things that was frequently done was rebuilding a kernel that 
only had the drivers that you needed.

About the only thing that I'm aware of that /necessitates/ an initramfs 
/ initrd is complicated storage like iSCSI and / or multi-path SAN 
attachments for the / (root) file system.  Maybe for 3rd party binary 
only drivers for local storage.  Beyond that, I'm not aware of anything 
that can't be done from the / (root) file system.

I guess disk encryption would also be another thing.  Though I've not 
/seen/ the / (root) file system encrypted on servers.  I have read about 
some people doing it on VPSs.  (My VPS has an unencrypted root with a 
LUKS encrypted data partition.)

> I would still prefer / usr being on its own partition and without 
> an initrd whether I use it today or not.  I mean, if I want to use 
> initrd, systemd, binary log files and whatever else, there are a 
> tonne of binary distros out there to choose from.  The *main* reason 
> I use Gentoo is because of the user choice and flexibility it offers, 
> something binary distros cannot provide.

You are free to have any preference you want.  As are we all.

Sometimes we have to decide if we want to allow our preference to make 
decisions for us by excluding options that don't honor our preference.

> I don't know when it kicked in, because I don't follow the dev mailing 
> list, but I assume it became necessary when the drive to align with 
> RHL design principles started being implemented?
> 
> https://packages.gentoo.org/useflags/split-usr

Sadly, that doesn't give any context, much less history.  I assume 
that's contained in a mailing list archive somewhere.

> I'd rather keep things as they have been/were until and unless the 
> usefulness of a change weighs heavier than keeping them the same

Fair enough.

That mirrors my logic process on many things too.

Aside:  I questioned the need to remove Token Ring support from 
3.<something> kernels.  I question the need to remove floppy drive 
support now.

> the community at large agrees with it after being presented with the 
> factual arguments for and against.

Sure.

> By all means let's merge /bin into /usr/bin, but not if the caveat is 
> we now *must* have an initrd to be able to boot

Agreed.

> and the only reason to change is so that gentoo becomes aligned with 
> the systemd project.

I don't think alignment with another project is a valid reason.  I am 
willing to entertain discussions about the ideas why other projects have 
done something and assess if we want to make a similar change 
independent of the project that we are observing make the same change.

Read:

  · I /don't/ want to start cooking my food because my neighbor is doing it.
  · I /do/ want to start cooking my food because I think that cooked 
food is tastier than uncooked food.

> Let's review any changes on their merits *before* they are implemented.

Sure.



-- 
Grant. . . .
unix || die