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

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

[Kai Peter]

Hi,

now, upstream made the USE flag 'split-usr' global. This puts me a bit 
in a state of uncertainty :(.

What is the reason or goal behind this change? I did read something 
about the flag itself but it wasn't really clear to me. What does this 
mean:

"Enable behavior to support maintaining /bin and /lib separately from 
/usr/bin and /usr/lib"

Maybe I have overseen some documentation?

regards
Kai

-- 
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

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

[Mick]

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

On Sunday, 4 August 2019 11:23:20 BST Kai Peter wrote:
> Hi,
> 
> now, upstream made the USE flag 'split-usr' global. This puts me a bit
> in a state of uncertainty :(.
> 
> What is the reason or goal behind this change? I did read something
> about the flag itself but it wasn't really clear to me. What does this
> mean:
> 
> "Enable behavior to support maintaining /bin and /lib separately from
> /usr/bin and /usr/lib"
> 
> Maybe I have overseen some documentation?
> 
> regards
> Kai

Have a look at this link, but there may be better explanations in the 
interwebs:

https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/

Essentially the historical reasons for having a lot of separate directories/
fs/partitions/disks are becoming obsolete and many of them are due to merge, 
changing the baselayout.  I assume the move to profile 17.1 to deal with the 
various /lib directories was the start.

-- 
Regards,

Mick

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

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

[Ian Zimmerman]

On 2019-08-04 12:29, Mick wrote:

> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> 
> Essentially the historical reasons for having a lot of separate
> directories/ fs/partitions/disks are becoming obsolete and many of
> them are due to merge, changing the baselayout.  I assume the move to
> profile 17.1 to deal with the various /lib directories was the start.

I know about the history as it relates to Unix and Linux in general.  In
fact I think I've read that article long ago.  But the question is
what's up in gentoo.  I suspect another potentially painful migration is
on the horizon; it would be good to know the speed we're moving toward
the horizon :-)

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Dale]

Ian Zimmerman wrote:
> On 2019-08-04 12:29, Mick wrote:
>
>> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
>>
>> Essentially the historical reasons for having a lot of separate
>> directories/ fs/partitions/disks are becoming obsolete and many of
>> them are due to merge, changing the baselayout.  I assume the move to
>> profile 17.1 to deal with the various /lib directories was the start.
> I know about the history as it relates to Unix and Linux in general.  In
> fact I think I've read that article long ago.  But the question is
> what's up in gentoo.  I suspect another potentially painful migration is
> on the horizon; it would be good to know the speed we're moving toward
> the horizon :-)
>


It was discussed on -dev in at least a couple threads I think.  I sort
of followed it and my take is, when set to on, which I think it is by
default, everything stays as it is now.  Could that change later on,
possibly.  I suspect given the change being pretty large, if it does
there will be a news item about it . Of course, that would be discussed
in advance on -dev as well. 

One way to get a heads up on this sort of thing, subscribe to -dev and
follow the threads that interest you, about upcoming changes at least. 
That's why I subscribe to -dev myself and have done so for years.  I
ignore a lot of it but the things that I think might affect me, I tend
to read those so as to figure out how it might affect me and can even
know the path going forward or how to work around it.  Just a thought.

Dale

:-)  :-) 

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

[Mick]

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

On Sunday, 4 August 2019 18:07:41 BST Ian Zimmerman wrote:
> On 2019-08-04 12:29, Mick wrote:
> > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> > 
> > Essentially the historical reasons for having a lot of separate
> > directories/ fs/partitions/disks are becoming obsolete and many of
> > them are due to merge, changing the baselayout.  I assume the move to
> > profile 17.1 to deal with the various /lib directories was the start.
> 
> I know about the history as it relates to Unix and Linux in general.  In
> fact I think I've read that article long ago.  But the question is
> what's up in gentoo.  I suspect another potentially painful migration is
> on the horizon; it would be good to know the speed we're moving toward
> the horizon :-)

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.  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.  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.  
Retrograde steps like being forced to use an initramfs just for retaining a 
separate /usr partition, should not be the way gentoo evolves.  Setting up a 
USE flag to accommodate such changes would be more agreeable for many gentoo 
users, rather than changing the default set up.

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

Mick

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

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

[Grant Taylor]

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?

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

> 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*!

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

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.

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



-- 
Grant. . . .
unix || die

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

[Kai Peter]

On 2019-08-04 20:01, Dale wrote:
> 
> It was discussed on -dev in at least a couple threads I think.  I sort

Thanks for that good hint. I did browse through the archives.

-- 
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail

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

[Mick]

[-- 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 --]

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

[Grant Taylor]

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

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

[Mick]

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

On Monday, 5 August 2019 17:17:53 BST Grant Taylor wrote:
> On 8/5/19 4:49 AM, Mick wrote:

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

I am not entertaining ad hominem attacks on whoever may have been involved in 
such decisions.  Only the impacts of such decisions on gentoo in particular.


> > Sure, but for how much longer?
> 
> /me looks around for something that he must have missed.

I probably used an incorrect figure of speech and caused confusion.  We're 
only discussing the merge of /bin and /sbin to /usr/bin and /usr/sbin (it 
seems to be more nuanced than this though - see gentoo forums thread further 
down).  However, the takeover of Linux in general by systemd architectural 
changes is a fact.  It is also a fact gentoo has been changed a lot to 
accommodate systemd.  I have set USE="-systemd" but still end up with service 
unit files on my system, unless I take additional steps to remove/mask them.  
At some point udev/dbus/what-ever will be irrevocably linked to systemd, just 
because its devs do not care for alternative architectures.  Some packages 
require systemd components, like (e)logind, and so on.  Some years ago eudev 
was forked from systemd with a stated aim at the time to also restore the 
borked separate /usr without an initrd - did this ever happen?  There is a 
direction of travel and it has been influenced heavily by systemd design 
decisions.


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

There isn't any - I haven't seen it either.  Sorry if I confused the point.


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

Yes, same here, but this is primarily because since gentoo's change in this 
area I moved away from using a separate /usr fs to avoid having to use an 
initrd.


> 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 have given one benefit of keeping a separate fs for /usr, mounting it read 
only for daily use.  Or you could have a shared NFS partition across various 
client PCs, facilitating system duplication.  You could also have /usr on a 
faster disk for performance reasons.

A benefit of /var being separate (or wherever www/, logs/, mail/ and databases 
are stored) is so that if it runs out of space the remaining system is not 
brought to its knees.

Ditto for /home, with the addition of encrypting user's data/partition and 
mounting it with nosetuid (to prevent the users from running their own secret 
root shell).

So at least two reasons, helping to manage (simply) access rights and space 
are valid enough reasons IMHO to not remove a separate /usr option from 
gentoo, but I'm interested to hear what others think.  One might argue you 
still retain the option of using a separate /usr, but with the new added 
restriction of being obliged to engage in boot time gymnastics with an initrd, 
LVM, your mount-bind solution and whatever else.  However, workarounds which 
add complication (remove simplicity and flexibility) to fix something after 
breaking it, is what all this argument is about.  Such changes remove choice.


> 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'll try not to mess up the thread.  :-)


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

Please do, the systemd merge refers merging /bin to /usr/bin and /sbin to /
usr/sbin.

https://fedoraproject.org/wiki/Features/UsrMove


However, this gentoo thread mentions further merging, which made my head spin:

https://forums.gentoo.org/viewtopic-p-7902764.html


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

You're probably correct.  In any case, the initial move of subdirectories of 
the / fs to different physical disks and hence different fs' was for storage 
space reasons.


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

Yes.


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

Yes, for plain users.


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

Yes.


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

OK, I'll rephrase this.  Certain binaries require corresponding libs to be 
accessible at the same time and /libs under /usr mushroomed to allow a 
separate /usr partition to function.


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

You are right, they just require to be accessible at the same time, which 
during boot time when some fs are not yet mounted (e.g. /usr) could cause 
breakage.


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

It is secondarily important today, although at the time disk space was the 
primary reason for migrating fs away from / partition.


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

What I was trying to say is, today storage space is usually a smaller and 
cheaper problem than it was at the early stages of UNIX and therefore *today* 
it is likely different purposes could be listed as having a higher priority 
for requiring different fs' to be deployed.  Discovering my flexible gentoo 
system won't boot without an initrd, just because binary distros use initrd by 
default, should not be the logic for limiting architectural choices, on 
gentoo.  We should pause, discuss and (hopefully) agree.


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

The Gentoo Trustees should do just that, i.e. ensure the project follows the 
Gentoo way.  No.1 Gentoo Principle:

"Gentoo provides choices."

https://wiki.gentoo.org/wiki/Foundation:Main_Page

If some dev, i.e. a gentoo community member who is contributing code, limits 
choices for users, then it follows his/her code does not fit into Gentoo and 
therefore Gentoo *should* not adopt it.  If s/he is a project lead and pushes 
changes against the Principles, then technical decisions on such matters can 
be taken by the Gentoo Council, but it is ultimately down to the Trustees to 
straighten out deviations from the Gentoo Principles.  I've written this as if 
it is black and white, but of course there are various shades of grey in-
between.  Either way, making one wrong decision at at time could end up with 
Gentoo gradually mutating into a systemd solution, which has already 
restricted choice (udev -> usr -> initrd).


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

I did not mean it this way.  Code is gratefully received, but let's not change 
Gentoo because any code was received.  The shoe has to fit the foot.


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

Because RHL devs have particular use cases in mind.  For them /usr on a 
separate fs without an initrd is a "custom setup".


> Note:  Virtual or not makes effectively no difference.

Agreed.


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

Sure.  Investigating opportunities to improve Linux is laudable.


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

Right, until udev won't work without /usr being mounted and then an initrd is 
a must.


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

Yes, until we started deviating from it, because someone offered us code.


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

Gentoo is by principle more accommodative than binary distributions and I'd 
rather it remained so.


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

Agreed.  I'm not advocating stifling discussion or innovation.


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

Right, which is rather different from:

We've outsourced code development to RHL devs and we'll use whatever they feed 
us, even if this changes our OS to a disagreeable degree.

At the same time I know devs are a scarce resource and good devs even scarcer, 
so there will always be a need to avoid reinventing the wheel and use what 
upstream provide.  I just hope the Gentoo principles hold a while longer.
-- 
Regards,

Mick

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

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

[Ian Zimmerman]

If I correctly remember the post by Lennart that spawned this entire
debate, there were and are genuine technical reasons why a separate /usr
filesystem doesn't really work anymore.  Perhaps fixable _if_ all package
developers (other than init) paid attention but that's not going to
happen.

Now of course there is some leap from the above to making /bin and
/usr/bin the same _directory_.  AFAIK there is no good reason for that
other than making it easier to write initscripts (or units).  I'm not
going to opine how good a reason is that :P

Myself, I just have /usr on the rootfs.  I don't have an initramfs; when
I need a "rescue" environment I boot from a USB stick, not necessarily
gentoo.  Devuan seems to be the best for this kind of thing nowadays.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Grant Taylor]

On 8/5/19 5:34 PM, Mick wrote:
> I am not entertaining ad hominem attacks on whoever may have been 
> involved in such decisions.  Only the impacts of such decisions on 
> gentoo in particular.

:-)

> I probably used an incorrect figure of speech and caused confusion. 
> We're only discussing the merge of /bin and /sbin to /usr/bin and 
> /usr/sbin (it seems to be more nuanced than this though - see gentoo 
> forums thread further down).

I started to read to be able to be informed when drafting my reply. 
Emphasis on "started".  The first comment to the quote makes me think 
that it's going to be a lively discussion.  I'll read it later as time 
permits and respond accordingly.

> However, the takeover of Linux in general by systemd architectural 
> changes is a fact.  It is also a fact gentoo has been changed a lot 
> to accommodate systemd.  I have set USE="-systemd" but still end 
> up with service unit files on my system, unless I take additional 
> steps to remove/mask them.  At some point udev/dbus/what-ever will be 
> irrevocably linked to systemd, just because its devs do not care for 
> alternative architectures.  Some packages require systemd components, 
> like (e)logind, and so on.  Some years ago eudev was forked from 
> systemd with a stated aim at the time to also restore the borked 
> separate /usr without an initrd - did this ever happen?  There is 
> a direction of travel and it has been influenced heavily by systemd 
> design decisions.

ACK

I think I could draw analogies with XFree86 vs Xorg vs Wayland.  In the 
beginning, nobody wants to actively stop development of the old method. 
But in the end, nobody wants to devote any effort to keep bring the old 
method forward.  Thus the old method gets left behind.

I'm not saying it's correct, or not, just that it is the nature of things.

> There isn't any - I haven't seen it either.  Sorry if I confused 
> the point.

Actually, the quote in the first forum post you linked to has the following:

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

That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and 
combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it 
also crosses bin & sbin as well as going opposite directions with the 
links.  —  Yuck!!!

> Yes, same here, but this is primarily because since gentoo's change in 
> this area I moved away from using a separate /usr fs to avoid having 
> to use an initrd.

ACK

> I have given one benefit of keeping a separate fs for /usr, mounting 
> it read only for daily use.  Or you could have a shared NFS partition 
> across various client PCs, facilitating system duplication.  You could 
> also have /usr on a faster disk for performance reasons.

ACK

> A benefit of /var being separate (or wherever www/, logs/, mail/ 
> and databases are stored) is so that if it runs out of space the 
> remaining system is not brought to its knees.

ACK


> Ditto for /home, with the addition of encrypting user's data/partition 
> and mounting it with nosetuid (to prevent the users from running 
> their own secret root shell).

ACK

> So at least two reasons, helping to manage (simply) access rights and 
> space are valid enough reasons IMHO to not remove a separate /usr 
> option from gentoo, but I'm interested to hear what others think.

Agreed..

> One might argue you still retain the option of using a separate /usr, 
> but with the new added restriction of being obliged to engage in 
> boot time gymnastics with an initrd, LVM, your mount-bind solution 
> and whatever else.

I don't have any current first hand experience with /usr being a 
separate file system without using an initramfs / initrd.  So I'm going 
to have to take what you, and others, say on faith that it can't 
/currently/ be done.  But I've got to say, that I find that idea 
disturbing and highly suspicious.

I'd be curious for pointers to bugs about this if you have them handy. 
Please don't look, I'll dig later if I'm sufficiently motivated.

> However, workarounds which add complication (remove simplicity and 
> flexibility) to fix something after breaking it, is what all this 
> argument is about.  Such changes remove choice.

Ya.  It's sort of like painting yourself into a corner because one (or 
more) too many bad decisions were made in the past.  I'd much rather 
admit that a bad decision was made, undo it, and move forward again with 
new knowledge.  Sadly, IMHO not enough people do that.

> I'll try not to mess up the thread.  :-)

:-D

I'll try as well.  But I'm betting that we're both human.

> Please do, the systemd merge refers merging /bin to /usr/bin and 
> /sbin to / usr/sbin.
> 
> https://fedoraproject.org/wiki/Features/UsrMove
> 
> However, this gentoo thread mentions further merging, which made my 
> head spin:
> 
> https://forums.gentoo.org/viewtopic-p-7902764.html

Ya.  I need to read that thread in detail.

The following bit concerns me.  I do hope that it's a typo.

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

> You're probably correct.  In any case, the initial move of 
> subdirectories of the / fs to different physical disks and hence 
> different fs' was for storage space reasons.

Agreed.

> Yes, for plain users.

I think it's for /all/ users, not just plain (non-root) users, because 
root will also want commands in /bin & /usr/bin for various things.

I think of it more as non-root users don't /need/ the contents of /sbin 
& /usr/sbin for the vast majority of what they do.

> OK, I'll rephrase this.  Certain binaries require corresponding libs 
> to be accessible at the same time and /libs under /usr mushroomed to 
> allow a separate /usr partition to function.

Agreed.

> You are right, they just require to be accessible at the same time, 
> which during boot time when some fs are not yet mounted (e.g. /usr) 
> could cause breakage.

Yep.

I have historically considered what's on the / (root) file system to be 
what's required to boot-strap the system.  Once the system has been 
booted, then all typical file systems are accessible.

> It is secondarily important today, although at the time disk space 
> was the primary reason for migrating fs away from / partition.

Okay.  That makes more sense.  Thank you for clarifying.

> What I was trying to say is, today storage space is usually a smaller 
> and cheaper problem than it was at the early stages of UNIX and 
> therefore *today* it is likely different purposes could be listed as 
> having a higher priority for requiring different fs' to be deployed.

Fair enough.

> Discovering my flexible gentoo system won't boot without an initrd, 
> just because binary distros use initrd by default, should not be the 
> logic for limiting architectural choices, on gentoo.  We should pause, 
> discuss and (hopefully) agree.

Agreed.

> The Gentoo Trustees should do just that, i.e. ensure the project 
> follows the Gentoo way.  No.1 Gentoo Principle:
> 
> "Gentoo provides choices."
> 
> https://wiki.gentoo.org/wiki/Foundation:Main_Page
> 
> If some dev, i.e. a gentoo community member who is contributing code, 
> limits choices for users, then it follows his/her code does not fit 
> into Gentoo and therefore Gentoo *should* not adopt it.

I feel like there is an important distinction between what you have now 
said and what I meant with what you quoted.

IMHO there is a big difference in the Gentoo community deciding (through 
due process) that the community does not want to include the developers 
code into the base portage.

Conversely, I was originally meaning something along the lines of "you 
don't follow the Gentoo methodology, therefore you are forbidden from 
even applying to the community for inclusion."

> If s/he is a project lead and pushes changes against the Principles, 
> then technical decisions on such matters can be taken by the Gentoo 
> Council, but it is ultimately down to the Trustees to straighten 
> out deviations from the Gentoo Principles.

Oy vey!

> I've written this as if it is black and white, but of course there 
> are various shades of grey in- between.

*nod*nod*

> Either way, making one wrong decision at at time could end up with 
> Gentoo gradually mutating into a systemd solution, which has already 
> restricted choice (udev -> usr -> initrd).

I don't want to agree, but your logic is correct.

> I did not mean it this way.  Code is gratefully received, but let's 
> not change Gentoo because any code was received.  The shoe has to 
> fit the foot.

Agreed.

Sometimes that means taking 95% of the code and modifying 5% of it to 
fit the Gentoo methodology.  ;-)

> Because RHL devs have particular use cases in mind.  For them /usr 
> on a separate fs without an initrd is a "custom setup".

Yet RHEL has Kickstart and many different ways to automate such "custom 
setups".

Has RHEL gotten /that/ short sighted that they think there are no longer 
people that do anything but click next a bunch of times and accepting 
the default?

*HEAVYsigh*

Nevermind.  Don't answer that.

> Sure.  Investigating opportunities to improve Linux is laudable.

Very well said.

> Right, until udev won't work without /usr being mounted and then an 
> initrd is a must.

I need to do some research.

> Yes, until we started deviating from it, because someone offered 
> us code.

Is any distro following FHS even remotely faithfully any more?  I 
thought most mainstream distros had moved on about ten years ago.

> Gentoo is by principle more accommodative than binary distributions 
> and I'd rather it remained so.

ACK

> Agreed.  I'm not advocating stifling discussion or innovation.

:-)

> Right, which is rather different from:
> 
> We've outsourced code development to RHL devs and we'll use whatever 
> they feed us, even if this changes our OS to a disagreeable degree.

:-/

> At the same time I know devs are a scarce resource and good devs 
> even scarcer, so there will always be a need to avoid reinventing 
> the wheel and use what upstream provide.  I just hope the Gentoo 
> principles hold a while longer.

Maybe it's my Slackware roots showing.  But I want to believe that it's 
possible to judiciously configure and compile software to work on just 
about any platform.  (Assuming that the requisite version of libraries 
are somewhere on the system.)



-- 
Grant. . . .
unix || die

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

[Canek Peláez Valdés]

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

On Mon, Aug 5, 2019 at 9:38 PM Grant Taylor <
gtaylor@gentoo.tnetconsulting.net> wrote:
[...]
> I don't have any current first hand experience with /usr being a
> separate file system without using an initramfs / initrd.  So I'm going
> to have to take what you, and others, say on faith that it can't
> /currently/ be done.  But I've got to say, that I find that idea
> disturbing and highly suspicious.

If it's computable it can be done, of course. Therefore it can be done,
currently. I don't think nobody has said it absolutely cannot be done.

The thing is:

1. How much work implies to get it done.
2. Who is gonna do said work.

The answer to 1 is "a lot", since (as someone mentioned in the thread) it
involves changing not only the init (nevermind systemd; *ALL* init
systems), but all applications that may require to use binaries in /usr
before it's mounted.

The answer to 2 is, effectively, "nobody", since it requires a big
coordinated effort, stepping into the toes of several projects,
significantly augmenting their code complexity for a corner case[1] that
can be trivially be solved with an initramfs, which it just works.

Arguing against this trivial (and IMHO, elegant) solution is tilting at
windmills. Specially if it is for ideological reasons instead of technical
ones.

Regards.

[1] I firmly believe that's the situation nowadays.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 1917 bytes --]

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

[Rich Freeman]

On Tue, Aug 6, 2019 at 11:54 AM Canek Peláez Valdés <caneko@gmail.com> wrote:
>
> Arguing against this trivial (and IMHO, elegant) solution is tilting at windmills. Specially if it is for ideological reasons instead of technical ones.
>

++

Some of the solutions I've seen tossed out in this thread are more
complex than just building your own initramfs from scratch.

An initramfs is just a userspace bootloader that runs on top of linux.
Nobody has any problem with conventional bootloaders, and if you want
to do anything with one of those you have to muck around in low-level
C or assembly.

There has been talk of gathering up all the stuff you need from /usr
to bootstap everything, and then adding some scripting to mount
everything.  The proposals have been to shove all that in / somewhere
(perhaps even in /bin or /sbin).  If instead you just stick it all in
a cpio archive you basically have an initramfs, and you don't need to
have cruft all over your filesystem to do it.  There are already
configurable and modular solutions like dracut which do a really nice
job of building one, and they make your bootstrapping process
infinitely flexible.

If you want root to be a zip file hosted on a webserver somewhere that
isn't a problem.  If you want root to be a rar file on a gpg-encrypted
attachment to a message stored on some IMAP server, you could do that
too.  To make all that work you can just script it in bash using
regular userspace tools like curl or fetchmail, without any need to go
mucking around with lower-level code.  Then once your root filesystem
is mounted all that bootstrapping code just deletes itself and the
system operates as if it was never there (strictly speaking this isn't
required but this is usually how it is done).

I doubt we'll see a /usr merge anytime soon, or any huge rush to break
a separate /usr completely without an initramfs.  However, there are
already use cases known where a separate /usr can cause problems
without either an initramfs or some kind of early-boot shell script
(there have already been solutions tossed out for that which are much
simpler than the ones in this thread).  The biggest example I've heard
is bluetooth keyboards - that was what made most of the zealots give
up on supporting anything that could possibly be needed for
bootstrapping being in /, as bluetooth has a bunch of deps and at that
point you might as well shove gnome in /bin.

So, for the forseeable future your system probably won't break if you
are using a separate /usr, but if it does the policy has been
established for a long time that nobody is obligated to fix it (nor
are they prohibited from doing so).

Really, though, you should take the time to appreciate an initramfs
whether you decide to use one or not.  They're a really elegant
solution to the problem.  Sometimes I think that half the objection is
due to the fact that they use cpio which is a bit obscure - if they
were tarballs people would be tearing them apart and playing with them
more.

-- 
Rich

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

[Grant Taylor]

On 8/6/19 9:54 AM, Canek Peláez Valdés wrote:
> If it's computable it can be done, of course. Therefore it can be done, 
> currently. I don't think nobody has said it absolutely cannot be done.

 >.<

So it sounds like it's a question of /how/ compatible / possible it is.

It seems as if there is enough incompatibility / problems that multiple 
people are comfortable saying that it can't be done on some level.

> The thing is:
> 
> 1. How much work implies to get it done.
> 2. Who is gonna do said work.
> 
> The answer to 1 is "a lot", since (as someone mentioned in the thread) 
> it involves changing not only the init (nevermind systemd; *ALL* init 
> systems), but all applications that may require to use binaries in /usr 
> before it's mounted.
> 
> The answer to 2 is, effectively, "nobody", since it requires a big 
> coordinated effort, stepping into the toes of several projects, 
> significantly augmenting their code complexity for a corner case[1] that 
> can be trivially be solved with an initramfs, which it just works.

I don't currently feel like I can give a proper response to this.

1)  I don't have the time to lab this and try things.
2)  I don't want to further hijack this thread and start discussing what 
precisely is and is not broken.
3)  I question — from a place of ignorance — just how much effort there 
is for #1.

> Arguing against this trivial (and IMHO, elegant) solution is tilting at 
> windmills. Specially if it is for ideological reasons instead of 
> technical ones.

Please clarify what "this trivial solution" is.  Are you referring to 
initramfs / initrd or the 'split-user' USE flag?



-- 
Grant. . . .
unix || die

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

[Canek Peláez Valdés]

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

On Tue, Aug 6, 2019 at 5:54 PM Grant Taylor <
gtaylor@gentoo.tnetconsulting.net> wrote:
[...]
> > Arguing against this trivial (and IMHO, elegant) solution is tilting at
> > windmills. Specially if it is for ideological reasons instead of
> > technical ones.
>
> Please clarify what "this trivial solution" is.  Are you referring to
> initramfs / initrd or the 'split-user' USE flag?

The trivial solution (IMO) is to use an initramfs. Rich gave a much more
elaborated answer.

Regards.
--
Dr. Canek Peláez Valdés
Profesor de Carrera Asociado C
Departamento de Matemáticas
Facultad de Ciencias
Universidad Nacional Autónoma de México

[-- Attachment #2: Type: text/html, Size: 818 bytes --]

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

[Ian Zimmerman]

On 2019-08-06 12:28, Rich Freeman wrote:

> > Arguing against this trivial (and IMHO, elegant) solution is tilting
> > at windmills. Specially if it is for ideological reasons instead of
> > technical ones.

> Some of the solutions I've seen tossed out in this thread are more
> complex than just building your own initramfs from scratch.
> 
> An initramfs is just a userspace bootloader that runs on top of linux.
> Nobody has any problem with conventional bootloaders, and if you want
> to do anything with one of those you have to muck around in low-level
> C or assembly.

There is a difference, and that difference is the reason I dislike
initramfs, not one of the other possible reasons you hypothesize.  The
difference is that real Unix processes (not just kernel threads and not
just PID 1) survive from the initramfs stage into the "real Unix"
stage.  It's like being able to trace matter back before the Big Bang.

-- 
Please don't Cc: me privately on mailing lists and Usenet,
if you also post the followup to the list or newsgroup.
To reply privately _only_ on Usenet and on broken lists
which rewrite From, fetch the TXT record for no-use.mooo.com.

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

[Grant Taylor]

On 8/6/19 10:28 AM, Rich Freeman wrote:
> An initramfs is just a userspace bootloader that runs on top of linux.

I disagree.

To me:

  · A boot loader is something that boots / executes a kernel with 
various parameters.
  · An initramfs / initrd (concept) is the micro installation that runs 
under the kernel that was booted (by the boot loader).

The initramfs / initrd micro installation does the following:

1)  fulfills prerequisites (e.g. loads requisite drivers, initializes 
networking for and discovers storage, decrypts block devices)
2)  mounts root (and some other) file systems
3)  launches additional init scripts.

None of those steps include booting / executing an alternate kernel.

Remember that the contents of an initramfs / initrd is a micro 
instillation that simply includes the minimum number of things to do 
steps 1–3 above.

The initrd is literally an image of a block device with a root file 
system on it that includes the minimum number of things to do steps 1–3 
above.

The initramfs is a CPIO archive of the minimum number of things to do 
steps 1–3 above which get extracted to a temporary location (usually a 
ram disk).

Both an initrd and an initramfs are a micro installation for the purpose 
of initializing the main installation.  They are not a boot loader.

> Nobody has any problem with conventional bootloaders, and if you want 
> to do anything with one of those you have to muck around in low-level 
> C or assembly.

That's because a boot loader, e.g. GRUB, lilo, loadlin, do something 
different and operate at a lower level than system init scripts.

> There has been talk of gathering up all the stuff you need from 
> /usr to bootstap everything, and then adding some scripting to mount 
> everything.  The proposals have been to shove all that in / somewhere 
> (perhaps even in /bin or /sbin).  If instead you just stick it all in 
> a cpio archive you basically have an initramfs,

Not basically.  That /is/ what an initramfs / initrd contains.

> and you don't need to have cruft all over your filesystem to do it.

Actually yes you do need that cruft.

Let's back up and talk about what that cruft is.

It's the minimum libraries and binaries required to:

1)  Requisite libraries
      - C library
      - other similar / minimal / unavoidable libraries
2)  Requisite binaries
      - fsck
      - mount
      - networking utilites (for iSCSI / NFS / etc.)
      - other similar / minimal / unavoidable binaries
3)  Scripts to bring the rest of the system up
      - minimal init scripts to go from a post-kernel-execution (what 
was traditionally /sbin/init) to launching second stage init scripts

To me, all of these things are going to exist on the main installation 
/anyway/.  There is going to be minimal, if any, difference between the 
version put in the initramfs / initrd and what's in the main / (root).

So, to me, what you're calling "cruft" is core system files that are 
going to exist anyway.

If anything, having an initramfs / initrd means that you're going to 
have an additional copy of said core system files in a slightly 
different format (initramfs / initrd) that's not usable by the main system.

> There are already configurable and modular solutions like dracut which 
> do a really nice job of building one,

Yes.  We've had many different tools in the last 28 years of Linux and 
longer for Unix for making the management of the boot process simpler.

It comes down to loading the kernel from something and starting the 
kernel with proper parameters (that's the boot loader's job) and 
starting something (traditionally /sbin/init) from some storage somewhere.

> and they make your bootstrapping process infinitely flexible.

Nope.  I don't agree.

There have been many things that I've wanted to do in the past 20 years 
that initramfs / initrd aren't flexible enough to do.

But adding an init script that calls tools on the root file system is 
infinitely more flexible.  I'm not restricted to doing things that 
dracut (et al.) know how to do.

If I can boot the kernel, point it at a root disk, and launch an init 
system, I can do anything I want with the system.

Let me say it this way.  If I can put together commands to do something, 
I can get thee system to do it on boot.  I don't have to wait for dracut 
to be updated to support the next wiz-bang feature.

> If you want root to be a zip file hosted on a webserver somewhere 
> that isn't a problem.  If you want root to be a rar file on a 
> gpg-encrypted attachment to a message stored on some IMAP server, 
> you could do that too.  To make all that work you can just script it 
> in bash using regular userspace tools like curl or fetchmail, without 
> any need to go mucking around with lower-level code.  Then once your 
> root filesystem is mounted all that bootstrapping code just deletes 
> itself and the system operates as if it was never there (strictly 
> speaking this isn't required but this is usually how it is done).

You need /something/ to be your starting root file system.  For most 
servers / workstations / VMs / containers, that's a local directory 
structure.

Sadly, I think people have thrust additional (IMHO) largely unnecessary 
complexity into the init process just to be able to support more exotic 
installations.  Then, they have said "We want to be consistent in how we 
boot, so we need to use this more complex thing everywhere."  To which, 
many greybeards have responded "I don't need nor want that on my simple 
server."

If you /actually/ /need/ a micro installation to make your main 
installation available, then go for it.  But if you don't /actually/ 
/need/ a micro installation, well Occam's Razor / Parsimony.

> I doubt we'll see a /usr merge anytime soon, or any huge rush to 
> break a separate /usr completely without an initramfs.

Okay.

> However, there are already use cases known where a separate /usr can 
> cause problems without either an initramfs or some kind of early-boot 
> shell script (there have already been solutions tossed out for that 
> which are much simpler than the ones in this thread).

How does the "early-boot shell script" that you speak of differ from an 
init-script?

> The biggest example I've heard is bluetooth keyboards - that was what 
> made most of the zealots give up on supporting anything that could 
> possibly be needed for bootstrapping being in /, as bluetooth has a 
> bunch of deps and at that point you might as well shove gnome in /bin.

If you want to burden your init system with supporting things like 
BlueTooth, that's your choice.  I sure as hell wouldn't do that.

> So, for the forseeable future your system probably won't break if 
> you are using a separate /usr, but if it does the policy has been 
> established for a long time that nobody is obligated to fix it (nor 
> are they prohibited from doing so).

~chuckle~

> Really, though, you should take the time to appreciate an initramfs 
> whether you decide to use one or not.

You seem to be assuming that people /don't/ appreciate an initramfs / 
initrd.  When for me personally, I do understand and appreciate what an 
initramfs / initrd does.  Enough so that I know that the systems that I 
run don't /need/ one.

> They're a really elegant solution to the problem.

I wouldn't use the words "elegant" or "solution".  "kludge" comes to mind.

> Sometimes I think that half the objection is due to the fact that 
> they use cpio which is a bit obscure

You are free to think that.  I'm free to disagree with what you think.

> if they were tarballs people would be tearing them apart and playing 
> with them more.

I know many people that have played with them (initramfs and / or 
initrd).  Many of whom have looked at what they do and realized that 
they don't actually /need/ them to boot their system.  So they choose to 
not use them, thereby reducing unnecessary complexity in the boot process.



-- 
Grant. . . .
unix || die

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

[Rich Freeman]

On Tue, Aug 6, 2019 at 7:39 PM Ian Zimmerman <itz@very.loosely.org> wrote:
>
> On 2019-08-06 12:28, Rich Freeman wrote:
>
> > > Arguing against this trivial (and IMHO, elegant) solution is tilting
> > > at windmills. Specially if it is for ideological reasons instead of
> > > technical ones.
>
> > Some of the solutions I've seen tossed out in this thread are more
> > complex than just building your own initramfs from scratch.
> >
> > An initramfs is just a userspace bootloader that runs on top of linux.
> > Nobody has any problem with conventional bootloaders, and if you want
> > to do anything with one of those you have to muck around in low-level
> > C or assembly.
>
> There is a difference, and that difference is the reason I dislike
> initramfs, not one of the other possible reasons you hypothesize.  The
> difference is that real Unix processes (not just kernel threads and not
> just PID 1) survive from the initramfs stage into the "real Unix"
> stage.  It's like being able to trace matter back before the Big Bang.

They only persist if you allow them to.  Most implementations I've
seen don't leave anything behind.

Typically an initramfs will unlink everything inside, kill any stray
processes (if it even forks anything in the first place), and then
will exec the new init from the previous init.  That starts up init as
PID 1 with nothing else running, and no trace of the initramfs
remaining.

But, sure, you can stick a fork bomb in an initramfs and have it
create 10GB of junk in the ramfs as well so that you boot up a
crippled system if you really want to.

Unless something has changed the kernel is actually built with an
empty initramfs built-in by default which loads no matter what.  So,
the framework of an initramfs is always there, and the only thing that
changes is whether it does anything.

-- 
Rich

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

[Rich Freeman]

On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor
<gtaylor@gentoo.tnetconsulting.net> wrote:
>
> On 8/6/19 10:28 AM, Rich Freeman wrote:
> > An initramfs is just a userspace bootloader that runs on top of linux.
>
> I disagree.
>
> To me:
>
>   · A boot loader is something that boots / executes a kernel with
> various parameters.
>   · An initramfs / initrd (concept) is the micro installation that runs
> under the kernel that was booted (by the boot loader).

Bootloaders are just programs that run other programs, ultimately.  We
can argue all day about what kinds of programs count as each.  But,
there is no point arguing definitions.

> The initramfs / initrd micro installation does the following:
>
> 1)  fulfills prerequisites (e.g. loads requisite drivers, initializes
> networking for and discovers storage, decrypts block devices)
> 2)  mounts root (and some other) file systems
> 3)  launches additional init scripts.

So, an initramfs doesn't actually have to do ANY of those things,
though typically it does.

> None of those steps include booting / executing an alternate kernel.

Nothing prevents an initramfs from booting an alternate kernel
actually, though if it does it will need its own root filesystem
initialized one way or another (which could be an initramfs).

Linux bootstrapping linux is basically the whole premise behind coreboot.

>
> > and you don't need to have cruft all over your filesystem to do it.
>
> Actually yes you do need that cruft.

Sure, but you don't need it ALL OVER YOUR FILESYSTEM.  Some of the
proposed solutions in this thread involved sticking stuff in /bin and
so on.  An initramfs is nicely bundled up in a single file.

> If anything, having an initramfs / initrd means that you're going to
> have an additional copy of said core system files in a slightly
> different format (initramfs / initrd) that's not usable by the main system.

Absolutely true, which means it won't interfere with the main system,
as opposed to sticking it in /bin or somewhere where it might.

> > and they make your bootstrapping process infinitely flexible.
>
> Nope.  I don't agree.
>
> There have been many things that I've wanted to do in the past 20 years
> that initramfs / initrd aren't flexible enough to do.

Such as?

It is a linux userspace.  It can literally do anything.

> But adding an init script that calls tools on the root file system is
> infinitely more flexible.  I'm not restricted to doing things that
> dracut (et al.) know how to do.

You don't need to use dracut (et al) to have an initramfs.

In fact, you could create your super root filesystem that does all the
fancy stuff you claim you can't do with an initramfs, then create a
cpio archive of that root filesystem, and now you have an initramfs
which does the job.

> If I can boot the kernel, point it at a root disk, and launch an init
> system, I can do anything I want with the system.

Sure, but only if the kernel can find that disk without any userspace
code.  What if that disk is on the other side of an ssh tunnel?

> Let me say it this way.  If I can put together commands to do something,
> I can get thee system to do it on boot.  I don't have to wait for dracut
> to be updated to support the next wiz-bang feature.

If you know the commands to do something, why would you have to wait
for somebody else to implement them?

>
> > If you want root to be a zip file hosted on a webserver somewhere
> > that isn't a problem.  If you want root to be a rar file on a
> > gpg-encrypted attachment to a message stored on some IMAP server,
> > you could do that too.  To make all that work you can just script it
> > in bash using regular userspace tools like curl or fetchmail, without
> > any need to go mucking around with lower-level code.  Then once your
> > root filesystem is mounted all that bootstrapping code just deletes
> > itself and the system operates as if it was never there (strictly
> > speaking this isn't required but this is usually how it is done).
>
> You need /something/ to be your starting root file system.  For most
> servers / workstations / VMs / containers, that's a local directory
> structure.

Actually, for most of these the initramfs is the starting root
filesystem (just about all linux server installs use one).  Usually it
just mounts a simple filesystem on a local disk as root and then
pivots.

However, an initramfs frees you up from the limitation that it be
something that can be passed directly on the command line.

> Sadly, I think people have thrust additional (IMHO) largely unnecessary
> complexity into the init process just to be able to support more exotic
> installations.  Then, they have said "We want to be consistent in how we
> boot, so we need to use this more complex thing everywhere."  To which,
> many greybeards have responded "I don't need nor want that on my simple
> server."

Initramfs is popular because it is way more flexible:

1.  You can build a fully modular kernel so that you can use the same
kernel on every system but not be loading countless drivers for
hardware most systems don't use, while still being certain of being
able to boot any particular system.
2.  You have more access to labels/uuids/etc for finding the root
filesystem so that when one of your hard drive fails the kernel
doesn't just dumbly use the next one in sequence, assuming they're
even always identified in the same order.
3.  You can use "exotic" installations like iscsi and so on, which
seems pretty useful in an enterprise setting.

>
> If you /actually/ /need/ a micro installation to make your main
> installation available, then go for it.  But if you don't /actually/
> /need/ a micro installation, well Occam's Razor / Parsimony.

Except then you're tailoring your bootloader to individual systems.

Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same
kernel/bootloader/etc works everywhere, vs tailoring their boot
process to every individual host.

> > They're a really elegant solution to the problem.
>
> I wouldn't use the words "elegant" or "solution".  "kludge" comes to mind.

What could be more elegant?  It minimizes the complexity of the
kernel, which is why Linus generally prohibits the kernel from having
any more advanced root mounting logic, and why pretty much every Linux
system out there uses one.

-- 
Rich

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

[Mick]

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

On Wednesday, 7 August 2019 01:31:03 BST Rich Freeman wrote:
> On Tue, Aug 6, 2019 at 7:41 PM Grant Taylor

> > Sadly, I think people have thrust additional (IMHO) largely unnecessary
> > complexity into the init process just to be able to support more exotic
> > installations.  

I may be wrong but I thought the udev-usr-initrd complexity was deemed a 
necessity/ when bluetooth input and audio devices became more widespread.  The 
fact systemd gradually mushroomed to take over the OS is another more loosely 
related story.


> > Then, they have said "We want to be consistent in how we
> > boot, so we need to use this more complex thing everywhere."  To which,
> > many greybeards have responded "I don't need nor want that on my simple
> > server."

This is the main rub of these architectural /solutions/ being pushed onto the 
wider community by what amounted to corporate lobbyists, for /problems/ many 
of us never had.

> Initramfs is popular because it is way more flexible:
> 
> 1.  You can build a fully modular kernel so that you can use the same
> kernel on every system but not be loading countless drivers for
> hardware most systems don't use, while still being certain of being
> able to boot any particular system.

Unless you have no use for this.  Just as many *Gentoo* users do not need 
their kernel image blessed by Microsoft, RHL shims and what not.


> 2.  You have more access to labels/uuids/etc for finding the root
> filesystem so that when one of your hard drive fails the kernel
> doesn't just dumbly use the next one in sequence, assuming they're
> even always identified in the same order.

I may be missing something here ... but I think this is not related to the use 
of an initrd.  You probably won't even need a separate bloat-loader like grub2 
for this, at least not on UEFI systems.  Just add the root PARTUUID on your 
kernel line, inside the kernel.


> 3.  You can use "exotic" installations like iscsi and so on, which
> seems pretty useful in an enterprise setting.
> 
> > If you /actually/ /need/ a micro installation to make your main
> > installation available, then go for it.  But if you don't /actually/
> > /need/ a micro installation, well Occam's Razor / Parsimony.

I have not performed sociological research to confirm this, but I'd say to 
those of us identifying with the above statement Gentoo is a good fit.  For 
those in an enterprise setting, there are many other cookie-cutter corporate 
solutions applicable.


> Except then you're tailoring your bootloader to individual systems.

Yes, I don't *have* to use Gentoo on a large server farm, put a SLA in place 
linked to contractual payment thresholds, hack my own monitoring system and 
get 3 layers of insurance signed off.  Tailoring my bootloader(s) is something 
I do in my home-office environment, including 3 servers.


> Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the same
> kernel/bootloader/etc works everywhere, vs tailoring their boot
> process to every individual host.

Yes in (large) corporate deployments.  Some of them on Azure too.


> > > They're a really elegant solution to the problem.
> > 
> > I wouldn't use the words "elegant" or "solution".  "kludge" comes to mind.
> 
> What could be more elegant?  It minimizes the complexity of the
> kernel, which is why Linus generally prohibits the kernel from having
> any more advanced root mounting logic, and why pretty much every Linux
> system out there uses one.

I think the whole issue is a difference in use cases and where corporate money 
has been used to provide a narrowly focused solution to address corporate 
requirements, without particular attention/interest/care to what are 
statistically edge use cases.  Such edge use cases, e.g. separate /usr, no 
initrd or kernel images signed by Microsoft, different choice of bootloaders, 
etc. have been more concentrated on Gentoo than the one-size-fits-all binary 
distros.  RHL calls these "bespoke" deployments.  Yet when changes in udev 
brought about the necessity of an initrd in order to keep running a separate /
usr fs, I recall quite a number of gentoo user voices in this M/L alone 
objecting to the changes.  What is an edge use case for Fedora, is/was not so 
much of an edge use case in Gentoo.

Gentoo did not *have* to follow upstream changes, but yet again this could 
probably bring its ultimate stagnation/demise as devs would be spread too thin 
to keep developing Gentoo in a deviating path from the rest of the Linux 
trajectory.

Having used and still using other binary distros I'm grateful Gentoo's still 
here, but would really prefer it did not bend itself out of shape to 
accommodate solutions to problems I and others do not have, or when we do we 
may not even use Gentoo to solve them.

-- 
Regards,

Mick

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

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

[Neil Bothwick]

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

On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote:

> Actually, the quote in the first forum post you linked to has the
> following:
> 
> /sbin->usr/bin
> /usr/sbin->bin
> 
> That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and 
> combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it 
> also crosses bin & sbin as well as going opposite directions with the 
> links.  —  Yuck!!!

Actually, it combines them all into one. The second link is to bin, not
/bin. It's a relative link from /usr/sbin so this would put everything in
/usr/bin.


-- 
-- 
Neil Bothwick

Exercise daily. Eat wisely. Die anyway.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mick]

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

On Wednesday, 7 August 2019 11:48:09 BST Neil Bothwick wrote:
> On Mon, 5 Aug 2019 20:37:44 -0600, Grant Taylor wrote:
> > Actually, the quote in the first forum post you linked to has the
> > following:
> > 
> > /sbin->usr/bin
> > /usr/sbin->bin
> > 
> > That takes four directories (/bin, /sbin, /usr/bin, /usr/sbin) and
> > combines them into two (/sbin & /usr/bin and /bin & /usr/sbin) but it
> > also crosses bin & sbin as well as going opposite directions with the
> > links.  —  Yuck!!!
> 
> Actually, it combines them all into one. The second link is to bin, not
> /bin. It's a relative link from /usr/sbin so this would put everything in
> /usr/bin.

Yep!  It sounds like an amazing idea!  I vote we rename it $WINDOWS/ and see 
how fast someone can spin an image on Azure.  :p

-- 
Regards,

Mick

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

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

[Neil Bothwick]

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

On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote:

> > Actually, it combines them all into one. The second link is to bin,
> > not /bin. It's a relative link from /usr/sbin so this would put
> > everything in /usr/bin.  
> 
> Yep!  It sounds like an amazing idea!  I vote we rename it $WINDOWS/

As opposed to splitting binaries across four directories based on
arbitrary decisions made in the last century? :P


-- 
Neil Bothwick

DOS never says "EXCELLENT command or filename"...

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Mick]

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

On Wednesday, 7 August 2019 12:48:08 BST Neil Bothwick wrote:
> On Wed, 07 Aug 2019 11:58:52 +0100, Mick wrote:
> > > Actually, it combines them all into one. The second link is to bin,
> > > not /bin. It's a relative link from /usr/sbin so this would put
> > > everything in /usr/bin.
> > 
> > Yep!  It sounds like an amazing idea!  I vote we rename it $WINDOWS/
> 
> As opposed to splitting binaries across four directories based on
> arbitrary decisions made in the last century? :P

LOL!  You're missing the most important part:  across different fs and 
partition layouts.

Look, the pyramids were built before the last century, but that doesn't mean 
we should try to balance them upside down if they work fine as they are.  
Clearly different use cases have different requirements and correspondingly 
different optimal solutions.  Can I please keep my bin/sbin directories 
separate and ditto for /usr and its subbies?  :-)

-- 
Regards,

Mick

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

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

[Grant Taylor]

On 8/6/19 6:31 PM, Rich Freeman wrote:
> So, an initramfs doesn't actually have to do ANY of those things, 
> though typically it does.

I agree that most systems don't /need/ an initramfs / initrd to do that 
for them.  IMHO /most/ systems should be able to do that for themselves.

> Nothing prevents an initramfs from booting an alternate kernel 
> actually, though if it does it will need its own root filesystem 
> initialized one way or another (which could be an initramfs).

Agreed.

Though I think that's rare enough that I chose to ignore it for the last 
email.

> Linux bootstrapping linux is basically the whole premise behind 
> coreboot.

Sure.

But coreboot is not a boot loader or a typical OS.  coreboot falls into 
the "firmware" family.

> Sure, but you don't need it ALL OVER YOUR FILESYSTEM.

I'd be willing to bet that 75% of what's contained in an initramfs / 
initrd is already on the root file system.  Especially if the initramfs 
/ initrd is tweaked to the local system.

Taking a quick look at the default initrd of an Ubuntu 16.04 LTS, just 
about everything I see in the following output exists on the system.

/boot/initrd.img-4.4.0-87-generic has 1908 items in it.

129 of them aren't already on the installed system.  Consisting of:

51 /scripts   Probably initrd specific
61 /bin       May be in /sbin /usr/bin /usr/sbin on the local system.
6  /conf      Probably initrd specific
5  /etc
2  /lib
4  misc

Digging further, 29 of the 61 for /bin are in /usr/bin.  12 are in 
/sbin.  That's 88 out of 1908 files in the 
/boot/initrd.img-4.4.0-87-generic file that aren't already all over your 
file system.

> Some of the proposed solutions in this thread involved sticking stuff 
> in /bin and so on.  An initramfs is nicely bundled up in a single file.

So, you're saving 88 files (out of 1908) and storing 1820 additional 
copies of files that exist in a container that's not easy to work with.

Why‽

> Absolutely true, which means it won't interfere with the main system, 
> as opposed to sticking it in /bin or somewhere where it might.

How do the files that are needed for the system to operate, being placed 
where they need to be, interfere with the main system?

> Such as?

Allow me to rephrase / clarify slightly.

There have been many things that I've wanted to do in the past 20 yeras 
that the initramfs / initrd from the vendor did not support or was not 
flexible enough to do.

  · Not support root in LVM.
  · Not support root on LUKS.
  · Not support iSCSI disks.
  · Not support root on multi-path.
  · Not supporting the file system (tools).
  · Not support the RAID that (tools).
  · Not support ZFS.
  · Not support root on NFS.

These are just the some of the things that I've wanted to do over the 
years that the initramfs / initrd as provided by the distro did not support.

I have routinely found initramfs / initrd limiting.

> It is a linux userspace.  It can literally do anything.

Yes, /conceptually/ it's Linux (userspace) can do anything that Linux 
can do.  /Practically/ it can only do the things that the distro 
envisioned support for and included in their initramfs / initrd 
management system.

> You don't need to use dracut (et al) to have an initramfs.

(See above.)

> In fact, you could create your super root filesystem that does all 
> the fancy stuff you claim you can't do with an initramfs,

Sure.  I did.  (Time and time again) it was the machine's root file 
system doing exactly what I wanted it to do.

> then create a cpio archive of that root filesystem, and now you have 
> an initramfs which does the job.

Why would I want to copy / permute something that's already working to 
add as an additional layer, which I don't need, complicating the overall 
process‽

> Sure, but only if the kernel can find that disk without any userspace 
> code.

There's a reason I said "if".  The extremely large majority of the 
systems that I've administered over the last 20 years could do that.

> What if that disk is on the other side of an ssh tunnel?

That would be a case where you would actually /need/ an initramfs / initrd.

I'd like to hear tell of someone actually using a root disk that is 
accessed through an ssh tunnel.  Short of that, I'm going to consider it 
a hypothetical.

> If you know the commands to do something, why would you have to wait 
> for somebody else to implement them?

Because I have hundreds of machines that need to be supported by junior 
admins and sticking within the confines of what the distro vendor 
supports is a good idea.

Or more simply, sticking within distro vendor's support period.

> Actually, for most of these the initramfs is the starting 
> root filesystem (just about all linux server installs use one).

Remember, an initramfs / initrd is (or gets extracted to) a directory 
structure.

Just about all of the servers and workstations (mid five digits worth) 
that I've administered over the years end up with a SCSI (SATA / SAS) 
disk off of a controller with the driver in kernel.  Include file system 
and NIC driver too, and you're good to go without an initramfs / initrd. 
  That includes physical and virtual systems.

The containers that I've worked with also end up being a collection of 
files on a file system.

Nope.  Very few of them actually /need/ an initramfs / initrd.

  · LUKS
  · Multipath SAN

Those are the big reasons for a server / workstation to actually /need/ 
an initramfs / initrd.

BlueTooth is not an issue for the servers that I've administered and 
handily enough the notebooks that have had LUKS have also had a keyboard.

> Usually it just mounts a simple filesystem on a local disk as root 
> and then pivots.

Why even bother doing that if it's not actually /needed/?

> However, an initramfs frees you up from the limitation that it be 
> something that can be passed directly on the command line.

I've never really found what I can pass on the kernel's command line to 
be a problem.

I have had problems where the distro provided initramfs / initrd 
management system lost it's lunch at some things I wanted to put on the 
command line.  But Linux itself was quite happy with it.

> Initramfs is popular because it is way more flexible:

See above.  I've found them to be limiting.

> 1.  You can build a fully modular kernel so that you can use the 
> same kernel on every system but not be loading countless drivers 
> for hardware most systems don't use, while still being certain of 
> being able to boot any particular system.

That sounds like it's convenient for the distro maintainers.

> 2.  You have more access to labels/uuids/etc for finding the root 
> filesystem so that when one of your hard drive fails the kernel 
> doesn't just dumbly use the next one in sequence, assuming they're 
> even always identified in the same order.

I've been using file system UUIDs on the kernel command line for decades 
without problems.  I've not /needed/ an initramfs / initrd to do that.

> 3.  You can use "exotic" installations like iscsi and so on, which 
> seems pretty useful in an enterprise setting.

One would think.

Sadly, most enterprise admins that I've been around are scared to death 
of booting from the SAN.

The few places that I've seen do it are using Fibre Channel.  Which, 
handily enough, shows up as SCSI directly attached disk.

> Except then you're tailoring your bootloader to individual systems.

Not really.

My current employer has about fifty different model servers in the 
fleet, from about a dozen different vendors.  We keep about five storage 
drivers in kernel and things just work.

Former employers had about a hundred different models of servers from 
about twenty different vendors.  We had to keep about twenty drivers in 
kernel.

There really wasn't any tailoring.

> Most sysadmins will prefer the Ubuntu/RHEL/etc approach where the 
> same kernel/bootloader/etc works everywhere, vs tailoring their boot 
> process to every individual host.

I'm going to go out on a limb and guess that half of them couldn't 
actually tell me how a system boots, from the firmware through init 
scripts to a login prompt.

I'll go further out on a limb and blame that on ignorance and / or 
laziness.  Thankfully it's possible to remediate ignorance if the SA is 
willing.  Also, I'm referring to the bad laziness of I don't care if 
it's less efficient / requires more resources, if it saves me time to 
cut corners.

> What could be more elegant?

Not using something that you don't actually /need/.

> It minimizes the complexity of the kernel

No, it really doesn't.  It might minimize the kernel config.  /Might./

It's quite possible (and in many ways more secure) to run a kernel 
without modules.

> which is why Linus generally prohibits the kernel from having any 
> more advanced root mounting logic, and why pretty much every Linux 
> system out there uses one.

I can't think of a time in the last ten years where the Linux kernel 
couldn't mount root when the storage driver (and file system) was 
compiled in with proper parameters on the kernel command line.

Root on LUKS, iSCSI, software RAID 5; sure, those things need help. 
Virtually none of the server's I've supported needed any of those for 
root.  Other disks / file systems that were activated via init scripts? 
Sure.



-- 
Grant. . . .
unix || die

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

[Neil Bothwick]

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

On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote:

> > As opposed to splitting binaries across four directories based on
> > arbitrary decisions made in the last century? :P  
> 
> LOL!  You're missing the most important part:  across different fs and 
> partition layouts.
> 
> Look, the pyramids were built before the last century, but that doesn't
> mean we should try to balance them upside down if they work fine as
> they are. 

Why not? As long as it's optional and controlled by a USE flag :)

>Clearly different use cases have different requirements and
> correspondingly different optimal solutions.  Can I please keep my
> bin/sbin directories separate and ditto for /usr and its subbies?  :-)

The /usr / split makes sense when you want different filesystems,
something I used to do but don't have any need for now. I've yet to see a
convincing argument for the bin/sbin split in either location.


-- 
Neil Bothwick

I doubt therefore I might be.

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Kai Peter]

On 2019-08-08 09:43, Neil Bothwick wrote:
> On Wed, 07 Aug 2019 14:24:22 +0100, Mick wrote:
> 
>> > As opposed to splitting binaries across four directories based on
>> > arbitrary decisions made in the last century? :P
>> 
>> LOL!  You're missing the most important part:  across different fs and
>> partition layouts.
>> 
>> Look, the pyramids were built before the last century, but that 
>> doesn't
>> mean we should try to balance them upside down if they work fine as
>> they are.
> 
> Why not? As long as it's optional and controlled by a USE flag :)
> 
>> Clearly different use cases have different requirements and
>> correspondingly different optimal solutions.  Can I please keep my
>> bin/sbin directories separate and ditto for /usr and its subbies?  :-)
> 
> The /usr / split makes sense when you want different filesystems,
> something I used to do but don't have any need for now. I've yet to see 
> a
> convincing argument for the bin/sbin split in either location.

Let me jump back into this hi-jacked thread somewhere. Unfortunately I 
didn't found an answer to the future directions at gentoo regarding the 
usr merge. And my fear is that the merge will be forced. As I use gentoo 
as a meta distro really, this change _could_ be put _me_ into trouble. 
But my 'gentoo-lfs' is not the typical use case.

Now, even that there are my individual requirements behind, some short 
points of my POV to some points in the whole thread. All IMHO.

An initramfs is a elegant and - more important - a very flexible 
solution. It is not required, but it makes things easier. It could solve 
more things than having /usr at a separate fs or loading drivers. I 
would also define it as a bootloader (like Rich) in a chain. More 
abstract I would see a classical bootloader like grub as a kernel by 
itself.

I see 3 stages of security concerns of an initramfs:

1. trust yourself and build your own one
2. trust gentoo and use gentoo's initramfs
3. download one (from a warez site) and stay hacked

The usr merge itself is questionable workaround to consolidate things. 
Now, a consolidation is a good thing in general. But what is the real 
difference to have a symlink /bin against having a folder? I couldn't 
follow the given arguments.

The core issue is the under laying folder structure. And depending on 
this hard coded path's. We still relying at a 50 years old concept - and 
time was moving on. Don't ask, I haven't a solution (yet). Just the 
dream/vision of the perfect system :). One point of the vision is to 
have a core (linux) OS (e.g. an extended stage3) separated from all user 
programs (similar to a ring0 kernel isolation).

 From all exiting concepts and implementations the best parts should be 
used. Not sure if this is ever possible. But forcing users to use a 
solution which is not required by 99% of them is a very bad thing. These 
'1-percent-solutions' have to be optional.

Anyway, just an opinion beside the mainstream. I encourage people to 
have their own. :) It is not hard to create pro and con arguments. And I 
left enough room for misunderstandings.


-- 
Sent with eQmail-1.10.3 beta - a fork of djb's famous qmail