Live data from Hacker News

Debian still having trouble with merged /usr

lwn.net

41–50 of 310 posts

Re: Debian still having trouble with merged /usr

#41
post #32
post #20

Earlier quoted context omitted.

Comments section is only two levels deep and we have already arrived at Godwin's law.

I don't compare you with a nazi, but you should understand that minority's can take over a country, that's what the nazis did but also the communists in romanov-russia...china is more complicated. It's something completely different, but maybe "nazi" is a red flag for you in comments...because not comfy. EDIT: And more actual, the Taliban's in Afghanistan, an absolute minority but the one with weapons, training, conn…

Godwin's law is not exactly a law, but an observation. Your comment is justified, because the current zietgeist is "majority wrong and minority right" and your comment is highlighting the dangers of such a process.

Re: Debian still having trouble with merged /usr

#43
post #36

I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name). I long for a day where PATH=/bin is all we need.

There is a comment on the LWN article about that: https://lwn.net/Articles/890306/ > First, technical challenges: HURD tried to move from /usr to / and had quite a bit more trouble with it, and that trouble warned against trying it on a larger scale. It's much easier to move from / to /usr than from /usr to / ; fewer things break. > Second, consolidation: moving into /usr gives us a single directory containing all fi…

The A/B system upgrade idea is intriguing. And kinda painfully obvious, in hindsight. Why don't the distros that have merged /usr do that already?

Re: Debian still having trouble with merged /usr

#44
post #31

I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name). I long for a day where PATH=/bin is all we need.

Not everything is a binary. Also having everything system specific live under a single path means easy backups, easy immutable trees that can be A/B swapped for seamless and online updates with easy rollbacks. No more wondering where the various tools live since everything lives in /usr/bin and more.

The original point of a non-merged /bin (and /sbin) was to contain essential binaries for system recovery and early boot, that should be available even when a separate /usr/ partition is not yet mounted. Keep in mind that the approach of booting from initrd is quite non-idiomatic and used only for convenience wrt. a generic distro install; you're generally meant to recompile your kernel so that it can mount / directly at boot and find everything it needs there, without requiring to mount either a ramdisk or a separate partition. This means that early-boot stuff must live there in order to get the benefits of separate partitions in the first place.

Re: Debian still having trouble with merged /usr

#45
post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

> tyranny of the minority this is a trendy thing too, very often minorities who felt ignored, are now pushing to get more because of the tiranny of the majority had flaws (but to me is mostly unavoidable due to the natural economies of scale it grants). I don't know how one can design a social system where you balance both in the right way.

> the tiranny of the majority had flaws (but to me is mostly unavoidable due to the natural economies of scale it grants).

In a different context, this is a source of frustration for me as a (partially) blind person advocating accessibility for blind people. The world is designed around the assumption, correct for most people, that people have the high-bandwidth, low-latency sense of sight. And that does lead to the most effective interface for most people. That assumption is so thoroughly baked into everything that I sometimes think it might have been better if, through some kind of eugenics, I and people like me (blind from birth) had never been born at all, so the world could go on with that assumption (as it mostly does anyway) without leaving us out. I know eugenics is a taboo idea though, and it has its own problems.

Re: Debian still having trouble with merged /usr

#46
post #28
post #11

Haven't used debian or debian based systems for many years. They do too much "automagic" things behind your back and thus tend to brick themselves, especially during major updates. Not really sure how they got so popular. The packaging ecosystem is also kinda mess.

Huh? I have the opposite experience. Major upgrades always went flawlessly for me. With the rolling testing-Release on my workstation/laptop, I sometimes run into dependency problems during upgrades. But these can always be solved by a few standard techniques. Not really beginner-friendly, but quite reliable. I have had many more problems when upgrading Ubuntu installations.

If you are running testing, it doesn't get security updates except through regular package migrations from unstable, so I recommend pulling in security updates from there manually or automatically. At least Firefox and Linux have regular security fixes in unstable, so you might want to use apt pinning to use the unstable versions. You can also use debsecan to automatically and temporarily pin security uploads to unstable using the technique mentioned here:

https://wiki.debian.org/DebianTesting#Best_practices_for_Tes...

Re: Debian still having trouble with merged /usr

#47

I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round? Let's keep our binaries out of /usr! (as a first step to remove /usr altogether, since it has a confusing name). I long for a day where PATH=/bin is all we need.

> I'm surprised that they are pushing to remove /bin and keep /usr/bin. Why not the other way round?

That is explained in the “Case for the usr merge” essay: having all the readonly system stuff under a single root directory makes the system much easier to manage, and simplifies useful scenarios like having the system on a network share, or sharing the host’s read-only across guests: with a merged usr, you just have to manage a single mount point or directory rather than half a dozen which must be kept in sync.

Also /usr is not just /usr/bin. Sbin, and lib (and lib64, and lib32) are also part of the usr merge.

Re: Debian still having trouble with merged /usr

#48
post #39
post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

How much of Python's success is down to the BDFL(-delegate) approach of governance? It seems a lot of projects have adopted it and Python's PEP system for managing new features. I wonder if Debian could use a similar sort of elected presidential system.

I am of the opinion that BDFL style governance is best in software. In the real world the problem is a bit more hairy, but if you have an issue with a tyrant in open source, you can just fork the project.

A BDFL solves the bureaucracy problem (they mandate, everybody implements) and the big ego problem (the biggest ego is at the top by definition). Also BDFL can have vision, something a committee will never have.

In my humble opinion, people like Torvalds and Jobs are the secret to wildly successful software.

Re: Debian still having trouble with merged /usr

#49
post #4

Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. Debian is the very example of it. Case in point: other distros forced the usr migration and very few problems were had. Debian put the idea through a committee, of course a minority wanted to keep the old behaviour so Debian decided to su…

> Democracy is pretty decent, but comes with some big flaws: tyranny of the minority, enormous amounts of back-and-forth to get anything done, big egos at any level can stop progress. The problem is not in democracy itself as a concept. In both the open-source world and in society itself, the problems arise only when the demos (the population) either grow disinterested in democracy or is small in numbers. As for "tyr…

>> As for "tyranny of the minority" - I hope to never see that phrase again. Protections for minorities in democracies exist for a very good reason.

I digress, but how are these protections an inherent feature of democracies. Even in a democracy (most democracies are representation democracies) people can vote for policies which may discriminate against people. This would be again democracy in action.

Re: Debian still having trouble with merged /usr

#50
post #43
post #36

Earlier quoted context omitted.

There is a comment on the LWN article about that: https://lwn.net/Articles/890306/ > First, technical challenges: HURD tried to move from /usr to / and had quite a bit more trouble with it, and that trouble warned against trying it on a larger scale. It's much easier to move from / to /usr than from /usr to / ; fewer things break. > Second, consolidation: moving into /usr gives us a single directory containing all fi…

The A/B system upgrade idea is intriguing. And kinda painfully obvious, in hindsight. Why don't the distros that have merged /usr do that already?

I think they do, Fedora's workstation product is meant as an appliance and I think it uses ostree to do something like the A/B upgrade thing.

Some folks also do something similar using LVM, BTRFS or ZFS snapshots on various distros.

Many users prefer the flexibility of package managers to appliance installs though, so having both types of installs is still a good idea.

Post reply on HN