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

[Mick <michaelkintzios@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 8163 bytes --]

On Monday, 5 August 2019 02:26:11 BST Grant Taylor wrote:
> On 8/4/19 12:03 PM, Mick wrote:
> > I don't know more about this, but it seems we are being dragged towards
> > a systemd inspired future, whether the majority of the gentoo community
> > of users want it or not.
> 
> How is the /usr merger /directly/ related to systemd?

It is being /assertively/ promoted persistently by the same devs.


> > In my view system binaries should not be thrown in the same pot as user
> > binaries and keeping the two separate makes good sense for those of us
> > who do not spin up 200 cloned VMs a second on a RHL corporate farm.
> 
> What are you using to differentiate system binaries and user binaries?
> Are you using the /usr directory?  Or the bin vs sbin directories?
> 
> Please elaborate on your working understanding.  I ask because I want
> correctly understand you and speak to what you're talking about.
> Especially considering that there will still be the bin vs sbin directories.

Sure, but for how much longer?  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.

I think following the lib directories merge, the discussion is now about 
merging:

 /bin -> usr/bin
 /sbin -> usr/bin
 /usr/sbin -> bin 


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.  This initially led to /bin and /sbin split across 
different physical devices and soon the same happened for /home, et al.

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.  The 
passage of time has introduced shared libs, which necessitate certain 
directories being on the same fs.  Back then everything was statically linked 
so fs could be more independent.

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.  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.  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.  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.

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, but I 
understand why it would not suit cookie-cutter thin provisioned VM images.

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, 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'm not arguing against systemd, or merging all directories under an
> > equivalent of a $WINDOWS/ path, but it seems to me a gentoo system
> > architecture should retain the freedom of choice and flexibility it
> > has been famous for.
> 
> I agree that the user choice is *EXTREMELY* *IMPORTANT*!

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.


> > Retrograde steps like being forced to use an initramfs just for
> > retaining a separate /usr partition, should not be the way gentoo
> > evolves.
> 
> Agreed.
> 
> I am curious why /you/ want (the ability to have) a separate /usr file
> system.  I know that I want to retain the ability.  That being said,
> I've not needed it in quite a while.

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.  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 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.  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.


> I am also using a bit of a hack that I think could be (re)used to allow
> /usr being a separate file system without /requiring/ an initramfs /
> initrd.  (I'll reply in another email with details to avoid polluting
> this thread.)
> 
> > Setting up a USE flag to accommodate such changes would be more
> > agreeable for many gentoo users, rather than changing the default
> > set up.
> 
> Please forgive my ignorance.  What was the default before 'split-user'
> was made global?  I assume that 'split-user' wasn't a default.  So, by
> my limited understanding, 1) it was / still is a USE flag and 2) has
> chosen the more historically compatible as the new default.

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


> > NOTE: Please do not start a flamewar, I'm just expressing my opinion
> > as a long term gentoo user who prefers to use gentoo for personal
> > computing, instead of other binary systemd based distros.
> 
> I'm not taking this as a flame.  I'm taking it as an honest and open
> discussion to learn what others are doing / thinking.
> 
> For the record, I'm largely okay with /bin being a sym-link to /usr/bin.
>   However I do want /sbin to remain local to the root file system.  I've
> supported multiple installs where /usr was a separate file system and
> needed the minimal system (not an initramfs nor an initrd) to fix things
> at times.  I'm also quite happy without an initramfs / initrd.

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 and the community at 
large agrees with it after being presented with the factual arguments for and 
against.  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 and the only reason to 
change is so that gentoo becomes aligned with the systemd project.  Let's 
review any changes on their merits *before* they are implemented.

-- 
Regards,

Mick

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]