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

[Mick <michaelkintzios@gmail.com>]

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