On Mon 13 November 2017 00:18:15 Adam Borowski wrote:
> On Sun, Nov 12, 2017 at 09:36:17PM +0100, Joerg Reisenweber wrote:
> > 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 what exactly developing an init system (which is unrelated to making a
> distribution) has to do with this?
>
> > and you want to mount a filesystem via WiFi (what a weird idea)
>
> What's wrong with this?
>
> > *before* you mounted /usr/
>
> Most large companies use a non-trivial method of authentication, sometimes
> downright bizarre.
>
> >, 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
>
> Have you _tried_ doing so? Or even listened to anyone who did?
>
> Supporting every use case -- even just use cases widespread in the wild --
> is a massive task. That your machine at home is content with a particular
> setup doesn't make it worthwhile to provide a separate scheme just to cater
> for that special snowflake. A generic, powerful and low-effort scheme
> exists (initrd) thus doing it the hard way is a waste of time. What's most
> important, not _your_ time.
>
> > 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.
>
> And what exactly systemd has to do with this? Newsflash: Debian does _not_
> run systemd inside initrd.
>
> > > 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
>
> It's way more than 5 people whose packages get run before remote (and even
> local) filesystems get mounted. And those people are tired with jumping
> through hoops for no benefit.
>
> > > 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?
>
> initrd acts _before_ the filesystem /bin/init is on is even mounted.
>
> It is possible to run a separate copy of systemd inside initrd, Red Hat
> does so.
>
>
> Meow!
I can't see a single word of yours in your whole reply that is faintly related
to the original topic which been "have /usr/ in a separate volume that gets
mounted early in boot/init process, as opposed to keeping /usr/ on rootfs
because some nitwits think they don't need to care about dependencies in their
*EARLY BOOT* processes they develop/maintain"
No need to try and explain to me what's an intrd and how it works, rather it
seems your expertise and understanding on the whole init process and volume
mounting and dependencies in that is sub-par.
Oh wait, there's one:
>It's way more than 5 people whose packages get run before remote (and even
>local) filesystems get mounted. And those people are tired with jumping
>through hoops for no benefit
yes, this 100% proves my point: incompetence, laziness (even to the point of
refusing to differentiate between remote and local and particularly /usr/ fs
mounts) and a lack of understanding what "One Universal OS" implies.
Could you please list a few of thos processes/packages that *need* to get
started before the init process mounted /usr/? And explain to me what it is
that those processes need from /usr/ (thus introducing more complexity and
failure vectors into early boot) and why it can't get implemented the right
way by avoiding those dependencies to /usr/ stuff instead? Or at very least
those developers presenting their rationale/problem to the public so the one
particular lib or whatever could get moved from /usr/ to / since their
rationale got evaluated and found sound by public scrutiny?
``for no benefit´´ is totally moot, the benefits of keeping /usr/ separation
had
been elaborated on ad nauseum already. Ignoring all this by calling it "no
benefit" is a very autistic approach
/j
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
