On Sun 12 November 2017 09:19:22 John Hughes wrote:
> On 12/11/17 04:24, Joerg Reisenweber wrote:
> > On Tue 07 November 2017 17:50:27 John Hughes wrote:
> >> The separation of / and /usr is a relic of really, really tiny disk
> >> sizes.
> >
> > Like, for example, ARMv7 systems with a 128MB NAND to boot from, keeping
> > /usr on a separate storage like SSD? Doesn't sound like an obsolete
> > ancient relic
> I have a N900, that is not news to me and has already been addressed by
> Adam Borowski:
> https://lists.dyne.org/lurker/message/20171108.052040.5cb5ca3d.en.html
>
> > In the last case I'm aware of where someone tried a stock
> > system with a split, Maemo,

Incorrect, they had a heritage of all stuff living on 240MB root-/ and thus not
really "tried" since the migration would have required a complete reflash
(instead of a apt-get install update)
A quote of well known infobot factoids:
>>>optification is a inventive duct tape workaround to reclaim space in fs
root, done due to the fact the systeminit *and* partitioning is FUBAR,
http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing/Installing_under_opt_and_MyDocs,
or ""OMG - I wish they looked into FHS and moved /usr to eMMC"",
http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE2 bullet1,2 and
fhs-2.3.html#PURPOSE16 dot3"<<<

> >the /usr split was deemed inadequate

yes, "inadequate" for an OTA upgrade of a deployed productive system to get
done without loss of user data, by push of a GUI button

> >and they
> > instead decided to move most stuff to /opt while stuffing the usual
> > places
> > with symlinks -- adapting packages enough to have / capable of booting
> > would
> > require too much work.

The "too much work" argument is a very embarrassing one - it's the genuine
duty of distro maintainers to take care of exactly such stuff. The argument
that something was "too much work" (for the distro maintainers, or even the
developers) is moot unless you're doing all that for yourself or for
developers instead of your users.
Claiming that a decision whether to put a package into /bin or /usr/bin (resp
*sbin*) was "too much work" is also outright silly, there's zero additional
workload in placing the package into the right location, except for the needed
knowhow and decision itself. It's just for the laziness of developers of
boot/init process when they demand to indiscriminately have access to *all*
existing binaries in /usr

/j