On Wed, Nov 21, 2018 at 08:56:58AM +0100, Marco d'Itri wrote: > On Nov 20, Adam Borowski <kilob...@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.