[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

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

> > # 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.)

⣾⠁⢠⠒⠀⣿⡁ A dumb species has no way to open a tuna can.
⢿⡄⠘⠷⠚⠋⠀ A smart species invents a can opener.
⠈⠳⣄⠀⠀⠀⠀ A master species delegates.

Reply to: