On Sun 12 November 2017 19:45:02 Adam Borowski wrote:
> On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> > 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
>
> The work involved is not just "zero", it's _massive_. Have you looked at
> how extensive dependency chains can be for complex setups? Try mounting a
> filesystem over wifi that requires a fancy authentication daemon.

Sorry, I think when you take up on the task to develop and maintain an init
system, and you want to mount a filesystem via WiFi (what a weird idea)
*before* you mounted /usr/, and then you claim that's *too much work* aka too
complicated for *you* to accomplish this the right way and thus you need all
/usr/ in root, then really so sorry to tell you I think you're simply not up
to the task at hand
Anyway thanks for proving my point that it's just about laziness (or - now I
have to add - maybe mere incompetence) of the systemd cabal and freedesktop
folks and other proponents of /usr( in rootfs.


> Every
> involved package, and every library recursively depended upon by one of
> those packages, would need to be moved to /{bin,sbin,lib}/.
>
> Debian, with its north of 1000 developers, decided that, despite trying,
> it's a lost cause. Do you think Devuan with 5 can do better?

Yes, since those 5 understand that the other 995+ don't give a damn about
where /usr/ lives since their apps get started *after* init and mount of
filesystems


stopping to read here...
>
> And if all you want is merely separate /usr, the whole extra cost is
> installing "tiny-initramfs" which includes a trivial initrd whose features
> (and complexity) are limited to:
> * CPU microcode
> * /usr
> * root=UUID
> * root on nfs in some configurations
> * _very_ minimal module loading, with no real automation. This is usually
> inadequate for distribution kernels, you need to recompile your kernel
> with required pieces statically.
>
> At least microcode is mandatory on any modern x86 CPUs,
>
...since this is *obviously* completely unrelated to mounting /usr/
Why don't systemd and "friends" mount /usr/ via such minimal ramdisk?


> or you risk severe
> data loss issues that differ by CPU sub-model. You may think that just
> because without microcode your machine boots, all is ok. It's not. Even
> worse, the documentation for problems fixed by microcode updates is sparse
> at best and non-existant in most cases.
>
>
> Meow!

catfood
whatever
/j