Live data from Hacker News

Debian still having trouble with merged /usr

lwn.net

131–140 of 310 posts

Re: Debian still having trouble with merged /usr

#131
>Improved compatibility with other Unixes/Linuxes...

A quick check reveals that OpenBSD presently has separate /bin and /sbin. FreeBSD also has a separate /lib. Exactly what were the other Unixes/Linuxes that this was supposed to improve compatibility with? I hope was not just Solaris...

Re: Debian still having trouble with merged /usr

#132
post #15

Earlier quoted context omitted.

Quoted post unavailable.

One problem that the Weimar Republic suffered from is that there were too many small parties. Absorbing them is easy if you are the trump of the 30s and are willing to use violence behind the scenes to intimidate anyone who opposes you. Also, it helps to have connections with people who hate democracy in important political positions. https://en.wikipedia.org/wiki/Weimar_political_parties

[deleted]

Re: Debian still having trouble with merged /usr

#133

Earlier quoted context omitted.

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

[deleted]

Re: Debian still having trouble with merged /usr

#134
post #97
post #7

Earlier quoted context omitted.

I'm quoting the article: "Debian took a more incremental approach, in part because it strives not to make wholesale changes to users' systems like those required by a flag-day upgrade to a merged /usr. In 2016, the ability to voluntarily switch to that scheme was added, then some attempts were made for newer versions of the distribution to be installed with a merged /usr by default. [...] The location of some files w…

Linux development in the present era is very heavily driven by Red Hat's needs and desires, and I don't think they have this problem because they don't support upgrading from one release to the next using the package manager - you have to reboot into the installer and do a kind of reinstall in place. So they can just require that all packages only have files in the non-symlinked directories after the flag day. Debian…

Are you talking about major RHEL upgrades? That's purely a support/business decision, not technical.

I've been upgrading my Fedora systems between major versions with yum/dnf for as long as I can remember. It just works.

Re: Debian still having trouble with merged /usr

#135
post #26

Earlier quoted context omitted.

They're talking about things that distro maintainers care about, namely servers. They are primarily not concerned with your workstation.

Lennart Poettering, the author of the proposal and creator of e.g., systemd, avahi, and pulseaudio, definitely cares about workstations, I'd say.

His workstations, and not to be snooty about it either, it's just like some people prefer crunchy peanut butter, and some people ruin their lives with creamy.

I liked init systems of yore. I don't ask to toss out systems because its very useful in some settings, however, I prefer the init systems we had, when it comes to my personal workstation preferences.

Re: Debian still having trouble with merged /usr

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

It should also be noted that, while this change is Linux-specific, it does not directly break software which also targets BSD or nix-like OSs. Files that were previously in /usr/bin or in /bin can now be found in EITHER of these locations, since one symlinks the other. So no previous expectation was really broken. Only software built on merged systems fails to run on unðmerged systems. This should not really happen,…

Debian didn't "choose" anything. It's just a bunch of people who wanted merged-/usr to become reality created a tool to convert a system until a project-wide decision is made. The decision has been made ultimately, but the dpkg maintainer blocks it from being implemented.

Re: Debian still having trouble with merged /usr

#139
post #39

Earlier quoted context omitted.

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 can't deny Python's success, but I wouldn't hold it up paragon of change management, either. 13+ years after the release of Python 3 and 2+ years after 2.7's EOL, I'm still dealing with Python dependencies that don't work on Python 3 because maintainers preferred to pretend that Python 3 wasn't happening and that Python 2.7 would be around forever. It's confusing as heck trying to figure out what I should even expe…

What sorts of packages are these though? I've not had a single problem with anything practical in years.

Re: Debian still having trouble with merged /usr

#140
post #105
post #61

Earlier quoted context omitted.

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 :)

I recently did something similar refactoring XDG endpoints to get rid of the standard home layout. I was quite surprised everything just worked, and there wasn't an issue of directories being recreated in their original locations or file templates being missing. Quite liberating if you ask me.
Post reply on HN