Re: [gentoo-dev] usr merge

[Joshua Kinard]

On 04/10/2016 08:14, Rich Freeman wrote:
> On Sun, Apr 10, 2016 at 7:55 AM, Joshua Kinard <kumba@g.o> wrote:
>>
>> Create like, a table on the Wiki or some kind of metadata property per-package
>> that can contain a boolean or tri-state flag indicating whether it works or
>> doesn't work (or kinda works) on split-usr.  Or a tracker on Bugzie.  Something.
>>
>
> I'm sure there will be a tracker for packages that don't work on a
> merged /usr.  (We are already on a split /usr.)
>
> Honestly, I'm still not quite sure why we're even having this
> discussion.  I don't think anybody actually intends to make any
> changes at all.  If they do, they should issue some kind of plan and
> indicate what they're looking for from everybody else.

Agreed.  A plan is most definitely needed if we ever choose to pursue a policy
of only supporting non-split-/usr installs, especially if we want to handle
cases like mine where we try to make migration of existing installs possible or
not.


[snip]

> It seems to me that we're just having a general discussion about the
> pros/cons of a /usr merge.  That is nice, but people are getting
> worked up because they think that somehow whoever "loses" this
> "discussion" will get something shoved down their throats or won't be
> able to have something nice.

"General discussion" -- hah!  Maybe it's the way Thunderbird is displaying it,
but I have five distinct, top-level threads in my gentoo-dev folder for this
discussion.  I think we left "general" back there after we broke through the
plaid barrier.

That said, I don't really think there are any pros or cons of split or merged.
 Largely, what's being discussed is the after-effects of what once was a common
approach to filesystem layout.  Myself, I only went the split-usr route because
of habit, itself which started because when I set up my first Gentoo system.  I
studied both the then-Gentoo Security and Debian Security manuals, which
indicated a split-/usr layout had certain advantages in that you could limit
capabilities via mount options.  Mainly, /usr didn't need devices, so "nodev"
was common there.  Along with /var having "noexec" and "nodev".

I've pretty much stuck to that layout approach since then out of habit.
Certainly, I've got a few VMs where I have just /, /boot, and /tmp as my only
partitions, and there's no real noticeable difference except what's in /etc/fstab.

---

I think where the problem ultimately arises is a subtle conflict between
filesystem semantics and system-design philosophy against the Linux kernel's
device architecture and management.  It's long regarded that /bin and /sbin
contain system-level binaries, and /usr/bin and /usr/sbin being for almost
everything else.  A.k.a., a two-level binary installation hierarchy (and the
BSD's extend this with a third level under /usr/local).

From the kernel angle, you have a monolithic kernel design where device drivers
run in kernel space most of the time.  This worked okay with traditional,
static devices that didn't change a whole lot and whose resources could be
determined at boot-time, before userspace is brought up.  But once the Linux
ecosystem needed devices that can come online from userspace or need their
resource determination to be dynamic (e.g., for hotplugging), we went to the
approach that the kernel needs to get out of managing devices altogether, and
thus came up with udev for device management from userspace.

Since udev is supposed to run from userspace, but kinda needs to interface with
the kernel a lot, the split between what's system-specific and what's not
clashes with the two-level file system layout.  This wasn't anything new...this
conflict has existed elsewhere for a long time (namely in X11), but it came to
a head when udev maintainers (and later, systemd maintainers) questioned the
approach, and largely decided it wasn't worth it, and a merged filesystem, with
/usr not separate, was simpler and more elegant.

---

But really, does it matter where the binaries all live?  It's just a design
decision.  Every OS had a different approach, such as NetWare running virtually
everything out of SYS:SYSTEM, and Windows out of C:\WINDOWS.  Heck, for the
longest time, you could *not* install Windows on anything other than the first
partition of the first drive, because software literally hardcoded filespec
strings as "C:\WINDOWS\...".  And even why C:, the third letter of the
alphabet, for the first fixed disk?  Because A: and B: were reserved for
systems that needed two floppy drives.  Yay MS-DOS!

If it were possible to give every binary and file out there a unique name, you
wouldn't even need directories.  You could have a totally-flat namespace with
all files of any kind under /, and let security models handle who sees/accesses
what.  But in that setup, would you even need "/"?


> Almost every big change that has become popular in Gentoo just started
> out as another alternative, and support grew organically.  I don't
> really see the need to reach some kind of consensus here.  I'd love to
> have an option of a /usr merge and a migration path.  I'd love to see
> it as the default, but that is a different discussion, and if it is
> optional then it is also a less contentious discussion whichever way
> it goes.

I don't think there is a viable migration path that can cover all scenarios.  I
have one of the simpler disk layouts, with MD-RAID to merge separate physical
disks into /dev/md* and then my unencrypted filesystems live there.  Certainly,
my /usr partition on those systems is big enough that I could cp /* into /usr,
then change my root= parameter to the kernel to have it treat my /usr partition
as /.  That'd be the simplest method for me, but it would leave me with a ~3GB
block of dead diskspace on those systems.

The only real way forward for migration would literally be to back the / and
/usr filesystems up (minimum), blow away the filesystem (and RAID or whatever
else) layouts, redesign it, then restore.  For some people, this would only
take a few hours.  Others, it'd be days, if not longer.  Some probably wouldn't
mind the time investment.  Others (like me), just don't have the time (or
motivation) to do such a task right now.  That is really my only issue here.

I guess the saving grace is UNIX filesystems in general are trivially easy to
backup/restore (or migrate, etc).  I migrated a Windows install once and
discovered that Windows records disk serial numbers in the Registry, which it
used to quickly find the disk with C:.  Took me several hours to figure that
out, then to build a BartPE disk that I could use to edit the specific registry
hive and delete those serials.  Then, unsurprisingly, Windows just shrugs and
uses the new disk serials as defaults and records them in place of the old ones.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
6144R/F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic