Re: usrmerge -- plan B?
On Wed, Nov 21, 2018 at 08:56:58AM +0100, Marco d'Itri wrote:
> On Nov 20, Adam Borowski <kilobyte@angband.pl> wrote:
>
> If you are seriously concerned with the small issuses caused by the
> transition to merged-/usr then I have a better proposal.
> Plan C: just stop supporting non-merged-/usr systems since these
> problems are caused by having to support both, and there is no real
> benefit in doing that other than pleasing the few people who are scared
> by changes.
Yes, that's much better than status quo. Plenty of risks and unneeded
work, but it at least has a chance. Supporting both is madness.
> > * move binaries to /usr/bin one by one, without hurry. If it takes 10
> > years, so what?
> If it takes 10 years then we will have to wait 10 years to deliver an
> enabling technology for important features.
Uh... what "enabling technology", what "important features"?
Despite repeated requests, I have yet to hear a compelling reason. All the
talk is about "how" not "why".
A cost-vs-benefits analysis is needed.
> Also, I seriously question that this would be practical: moving a binary
> requires coordination with all other packages using it, while the switch
> to a merged-/usr is transparent.
Well, can use a symlink if you really want to move a binary. It could use
a common debhelper script. But I have doubts even that makes much point.
> If you believe that a 10 years timeframe for a change is totally OK then
> you obviously do not care about it, so you what you are really arguing
> for is doing nothing.
If you want me to care about it, please explain what can I gain.
> > * /bin would be left populated with nothing but /bin/sh, /bin/bash and
> > whatever else POSIX demands.
> There are no benefits from a merged-/usr scheme as long as there are
> system binaries outside of /usr.
And those benefits would be...?
There's a reference to "system snapshotting" for which merged-/usr is
neither sufficient nor necessary. I religiously use system snapshotting for
many years, without issues.
> > Another question is, why?
> It has been documented here long ago: https://wiki.debian.org/UsrMerge .
It talks a lot about "how" without a word "why".
> > main reason is compatibility with Solaris -- which hasn't been relevant for
> No, it's not the main reason. It's not even an interesting reason, it's
> just an example showing that this kind of setup has been tested for
> years and is nothing new.
> You are misconstructing the arguments in favour of merged-/usr to be
> able to dismiss them easily.
Sure, please then provide a man not built of straw whom I can fight.
> > a long long time. Even the other distribution (Fedora) that has done the
> > split is rapidly following Solaris into obscurity (the whole RPM world has
> > gone to 20% of web servers from 65% a few years ago, other server uses seem
> > to be alike[2], Red Hat has been gobbled up). This leaves mostly claim #4:
> WTF? Fedora is not relevant, it's RHEL that matters and it switched to
> a merged-/usr. If you are seriously claiming that RHEL is "fading into
> obscurity" then we obviously lack a common ground to discuss anything.
I am seriously claiming that RHEL is in the place Solaris was in 2010.
Rapidly falling user share (like Solaris, it was ubiquitous in the past!),
acquired by a company known for wringing dry a small number of lucratious
customers -- just like Oracle. This very scenario has repeated in the past
for a number of other Unices. Some developers (including The Lennart)
already sound like they're mulling jumping ship <rumour warning>.
If going from 65% to 20% usage (including Fedora, CentOS and SLES) in the
only category we can reasonably measure isn't "serious", I don't know what
is.
But, we're not RHEL, we're not Fedora. We're not even Devuan nor Ubuntu,
so there's no need to look at anything but: "will this benefit us? our
users?".
> > # Fact: The /usr merge makes sharing the vendor-supplied OS resources
> > # between a host and networked clients as well as a host and local
> > # light-weight containers easier and atomic. Snapshotting the OS becomes a
> > # viable option. The /usr merge also allows making the entire
> > # vendor-supplied OS resources read-only for increased security and
> > # robustness.
> > -- which is untrue as a system with /etc and /var out of sync with /usr is
> > broken. There are attempts of reducing /etc but I have seen nothing about
> > /var.
> These are few examples of the features that a merged-/usr system
> enables. /etc and /var do not just get "out of sync", so your argument
> is wrong.
Ok, please tell us more about those features then. "Why" not "how".
(But at least we both agree there's no way to support both merged and
unmerged -- so this flamewar already made a step forward.)
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.
Reply to: