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
