Live data from Hacker News

Debian still having trouble with merged /usr

lwn.net

101–110 of 310 posts

Re: Debian still having trouble with merged /usr

#101
post #19

Sigh ... gobolinux solved this quite elegantly over 20 years ago, and to this day most folks don't quite grok how simple and elegant their solution was.

From the Gobolinux homepage

> /bin is a link to /System/Index/bin. And as a matter of fact, so is /usr/bin. And /usr/sbin

So, they're doing exactly the same thing as Debian is doing on the default merged configuration ?

Issues seen on Debian are not the system using symlinks or not, but packages failing when exchanged between system that still had both /bin/ and /usr/bin as separate directories, as it was historically, and the new merged systems. Gobolinux being a from scratch built distro with no transition history, I am not sure how it can be seen as a better example here.

Re: Debian still having trouble with merged /usr

#102
post #50
post #43

Earlier quoted context omitted.

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.

it's not Workstation, it's Silverblue. Workstation is just like every other distro.

Re: Debian still having trouble with merged /usr

#103
post #96

Earlier quoted context omitted.

> 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…

Not only is that impractical (how can you reliably filter blindness before birth? I suppose you could test babies eyesight at birth and kill them if they're blind?), but what about the people who get blind during their lives? They are the vast majority of cases of blindness! It seems very odd to propose that the solution to a problem is to liquidate all people who suffer from that problem.

Fair points. Sometimes it just seems like it's futile to advocate for accommodations everywhere. I should be thoroughly used to it by now, though.

Re: Debian still having trouble with merged /usr

#104
post #9

I understand the problem dpkg is facing (can't know the canonical pathname for an object is, in some cases), but I have huge problems understanding why a symlink farm is preferable. The last thing I want to see on my Debian system is directories with hundreds or maybe thousands of symlink entries. There must be a way to let dpkg do its job if the directory-symlink approach is used instead, surely? (/bin -> /usr/bin)

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

Re: Debian still having trouble with merged /usr

#105
post #61
post #25

Earlier quoted context omitted.

What was the solution, and why is is simple and elegant?

There's a rather old review on LWN: https://lwn.net/Articles/66290/ It's essentially like Macos's /Applications directory, except where Macos supports the traditional POSIX fhs via a hidden /private root directory, Gobolinux hides these directories with a filesystem kludge.

Nice, thanks! I'll give this a little read over lunch :)

Re: Debian still having trouble with merged /usr

#106
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…

Everything that works well is structured like a monarchy. Maybe the west shouldn't be trying so hard to export democracy?

The reasonable explanation for that is that in a monarchy, ostensibly all bodies are working towards common goal (as dictated at the top). Whereas in a democracy, in many cases there exist bodies with equal power yet conflicting interests.

Monarchies seem to work well in cases where "the top" has interests that align with the interests of the subjects, and is well-informed. Jordan seems to be a great example. Yet history is full of examples of long-standing monarchy-type organizations where after only a short time of disconnect between the governing and the governed, the entire system fails. A Frenchman could probably provide good examples.

Re: Debian still having trouble with merged /usr

#107
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…

Wrong. Debian is a do-ocracy. Package maintainers have plenty of power to take decisions. The TC gets involved very rarely.

Re: Debian still having trouble with merged /usr

#108
post #89

Just in case anyone is wondering why we had (or used to have) /bin and /sbin directories as well as /usr/bin /usr/sbin here is my understanding of it. It is because on old Unix systems there frequently wasn't enough space to store /usr on the root disk. Therefore /usr was a separate disk which might not be available during boot. This meant that you needed to put all the binaries you needed for boot in /bin and /sbin…

Adding to this historical reasoning, it is to be noted that in traditional Unix, /usr was pretty much the equivalent of /home in Linux systems: the parent directory for user home directories, i.e. 'usr'.

The existence of /usr/bin can probably be explained by the reasoning that, just like nowadays Linux systems often have a really big /home partition, early Unix systems eventually ran out of space for whatever volume would hold /bin, and with 'reinstalling' not remotely as easy an option as it would be these days, storing an extra 'bin' etc. directory in the 'larger partition for user directories' became commonplace.

Re: Debian still having trouble with merged /usr

#109

Earlier quoted context omitted.

> 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…

My first experience with someone in your position was Geordi LaForge. I found it so inspiring how he overcame - though technology - his blindness and how his innovation became central to fulfilling his craft's mission and often securing the safety of its crew. I often wondered what would have become of him had he been born in an earlier age, without the technology to provide him with an alternative high-bandwidth, lo…

> My first experience with someone in your position was Geordi LaForge. I found it so inspiring [...]

To be clear, that's a fictional character in a fictional future that may or may not ever come. Sure, we can use assistive technology, e.g. screen readers, to enable us to work. But with our current technology, that requires cooperation from developers of platforms, applications, websites, etc., and as I said in another comment, advocating for that sometimes seems futile. We do sometimes make progress though.

> I absolutely believe that the 9999 other traits that you have to share should not be lost just because of a single non-optimal trait.

Of course you're right; thanks for that reminder.

Re: Debian still having trouble with merged /usr

#110
post #74

Earlier quoted context omitted.

> 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…

First of all I think Eugenics would/will quickly lead to something akin to runaway selection: people will make increasingly absurd decisions mainly driven by status markers / perceptual drift and the human race will breed itself into some mad corner. So I don't believe Eugenics is ever going to do what even its most ardent supporters imagine. Second of all the human race does not have some over-arching goals we need…

You could just have the government mandate a test, and any embryo that has markers (genetic or otherwise) of a chronic debilitating condition is not allowed to be brought to term. If parents do choose this, the kid will fall outside of the healthcare system for its condition and parents will have to foot the entire ongoing bill.

Eugenics does not automatically mean we all customize our embryos to be 2m tall geniuses with patterned body hair.

More of an aside, but I’ve always wondered where humans would end up if we did do unbridled genetic engineering. Is 2m the ideal height? 1.80m? 2.40m? What would we discover is the optimal IQ? Etc.

Post reply on HN