A comment there on LWN, from a Debian developer, adds useful context:
> [T]his is a misleading writeup of a Debian-internal announcement. One specific action that is mostly internal to Debian, which some developers wanted to push ahead with after the bookworm release, has been paused.
> On a merged-/usr system (which will include all Debian 12 and Debian 13 systems, both new installations and upgrades), both /bin/cat and /usr/bin/cat exist, but dpkg is only aware of one of those paths (/bin/cat in this case); in dpkg jargon, the other is said to be an alias. The specific action that should not proceed until further notice is: swapping the path that dpkg considers to be canonical, for example from /bin/cat to /usr/bin/cat.
In particular, the thing that this announcement pauses is only a shuffling of internal metadata. For users, /usr will already look merged either way.
The other bit of context is that this "pause" comes as Debian approaches its next major release, and they expect to unpause it shortly after that.
Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11
But more generally, Sun had a lot of smart people that cared deeply both about the *NIX Desktop and the general user experience. A trip through the PSARC archives[1] will show that things like the /usr merge were carefully considered and reasoned about. Some of those people are still working on Solaris today, although sadly, I'm no longer one of them.
The Linux and BSD folks should take advantage of the good things that Sun left behind and carry them forward wherever possible.
DISCLAIMER: I'm a former Solaris Principal Software Engineer so slightly biased ;)
Thank you for your service. Solaris felt more considered and reasoned than AIX and microchannel Linux I was learning in ~95 and so helped me learn more.
Ah, it's awesome you worked there. Thank you for context.
My "bad timing" comment was in reference to Sun getting sold in 2010. As an IT focused college kid, I realized there wasn't much value in learning Solaris system administration. That doesn't mean it didn't have amazing things as an operating system!
So, somebody imagined/wished that all distros will switch to /usr/* and them will ship / part ? :> I don't think so. Totally wrong direction.
And init binary in /usr is complete braindeadness...
Also MS behind anything means they are trying to get rid of your options, eg by complicating things into "enterprise level" and keep pushing windows as userware.
But there is other possibility: minimal root that is easy to manage, switch, etc. etc. and rest of the system :)
> But there is other possibility: minimal root that is easy to manage, switch, etc. etc. and rest of the system :)
Yeah, libostree ("git for operating systems binaries") benefits from merging /usr. It might even be a requirement to have merged /usr to be able to use it.
> I’m also confused why all system supplied data is in /usr instead of say /sys.
Wasn't that basically a historical accident? IIRC in very early UNIX, "/usr" used to be like the modern "/home", but they happened to have a big disk for that mount and started putting system files there.
The motivation is because systemd is compelling them to change it. Systemd decides how Debian may operate, and decides how users, processes, and files work, not the Debian Technical Committee.
There's a bunch of compatibly reasons why this helps maintain portability across Unixes. But my favorite reasons for this are how much nicer it makes managing & switching between Linux images:
> The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host.https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
And indeed, with systemd one can boot a whole system from practically any unpopulated root mount with a /usr image mounted on it.
Want to OS upgrade? Swap /usr & try it. /etc and /home and the other directories might have instance specific content, but the OS image is nicely set away & swappable in /usr. And one should be able to keep the same "instance" while swapping the image. It containerizes the OS image, separate-ish from the OS instancd, whereas before the OS was somewhat amorphously sprawled across multiple top level directories. It's a huge boon to manageability.
There are still many paths hardcoded into /sbin. /lib is expected to stay since the LDSO path for dynamic linking points there, removing it is not possible without breaking the ABI.
This is fixable: it only truly matters for /sbin/init, but it's nothing than can be fixed in a minute with the right kernel cmdline.
For the rest, a regex could replace /sbin by /usr/sbin in the package files
> /lib is expected to stay since the LDSO path for dynamic linking points there, removing it is not possible without breaking the ABI.
Maybe it's time to do that too? Android does just fine without /lib. Only the linker needs that, and changing the path to ld-linux should just require a kernel tweak.
But breaking the ABI could also be the opportunity to bring in android improvements, like the linkerconfig or namespaces!
I sincerely mean all of that. I don't see why we can't take advantage of android advances to facilitate having specific dynamic libraries to specific programs.
If you disagree, please explain your point because I think google did some genuine improvements for dynamic libraries.
The kernel has no idea about /lib (unless you're using the in-kernel firmware loader, which you really shouldn't be) - the rtdl path is present in every ELF object that depends on it, so the "kernel tweak" would be hacking the ELF loader to rewrite /lib (or /lib64) to something else.
The parent commenter is already suggesting "just run a regex", so it seems like a trivial extension to their simple solution to "just run patchelf on every binary on your system"
The in-kernel loader can't defer loading if, say, a module is loaded before the firmware is available. Instead it can be handled in userland - the kernel generates a request when it wants firmware, and the userland hotplug agent can satisfy that later
This is fixable and has already been fixed: Install NixOS or guix to live in a world where neither "/sbin" nor "/lib" exists.
NixOS has also reduced "/usr/bin" to containing only a "/usr/bin/env" symlink and "/bin" down to just "/bin/sh".
So, why not apply the same philosophy to any other linux distro? Well, debian or ubuntu or whatever has plenty of user-written bash scripts, aliases, etc that are _not_ managed by the package manager, and would promptly explode with that change, causing people to switch distros, never upgrade, and probably write angry articles online.
There's plenty of sites that let you download and install a deb which isn't in debian's packages (i.e. chrome, zoom, slack) which would also all break. There's third-party package managers, like steam (which downloads and runs executables) which would also break.
Of course they won't do that, they don't want to piss off their users for minimal benefit.
NixOS has just accepted that "download zoom-installer.sh" or whatever does not and will never work on their distro, and people deal with it. Other distros are unlikely to make that choice.
Android has ensured those also never work by limiting people to just the app store. In a sense, ubuntu + snaps is trying to do that for their distro, but it's neither been that well received, nor making quick progress.
/bin/sh is mandated by posix, so there’ll be a link to usr.
/bin/bash will be as well because /bin itself is a symlink to /usr/bin.
Though that’s a very dumb shebang to use and you should be ashamed: lots of systems don’t have it, or have an absolutely ancient system bash. By hard coding this you’re just making your scripts worse.
I think it is fair not to care if it isn't making a difference for you.
“/usr/bin/env bash” will keep the shebang working between a Linux and FreeBSD (and probably other *NIX) machines. This bit me at one point, and it just became a habit since.
Bash (if installed) is in /usr/local/bin there. Other interpreters often are too.
Man, I've tried to write POSIX-compatible scripts for a long time - twice as long as I'd probably have taken using bash features (using Python I'd probably have taken 1/10th of the time and it'd be way more maintainable now).
Python is in no way better maintainable than bash. If you'd used Python, most of your scripts would be broken right now. With bash, that just doesn't happen (to that extent).
Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.
Yep it's all systemd bunk. It reduces flexibility and promotes lock-in of systemd at the expense of everything else. It smells like a bunch of BS because it is.
/usr doesn't mean "user". It means "User Software Resources". I learned this from a good friend whose 70+ years old, and worked with Ritchie. My friend is also cited in K&R C.
/usr/bin and /usr/sbin should have always been the place to put "user software resources". And we're finally getting back to what it was originally.
/usr was the user directory before Thompson and Ritchie bought a new disk and mounted it as /home. The crazy names are really just a historical accident, not some smart acronyms.
60 comments
[ 3.3 ms ] story [ 130 ms ] thread> [T]his is a misleading writeup of a Debian-internal announcement. One specific action that is mostly internal to Debian, which some developers wanted to push ahead with after the bookworm release, has been paused.
> On a merged-/usr system (which will include all Debian 12 and Debian 13 systems, both new installations and upgrades), both /bin/cat and /usr/bin/cat exist, but dpkg is only aware of one of those paths (/bin/cat in this case); in dpkg jargon, the other is said to be an alias. The specific action that should not proceed until further notice is: swapping the path that dpkg considers to be canonical, for example from /bin/cat to /usr/bin/cat.
In particular, the thing that this announcement pauses is only a shuffling of internal metadata. For users, /usr will already look merged either way.
The other bit of context is that this "pause" comes as Debian approaches its next major release, and they expect to unpause it shortly after that.
What's the motivation of moving /bin to /usr/bin? What is gained? What is lost?
Solaris implemented the core part of the /usr merge 15 years ago already, and completed it with the introduction of Solaris 11
But more generally, Sun had a lot of smart people that cared deeply both about the *NIX Desktop and the general user experience. A trip through the PSARC archives[1] will show that things like the /usr merge were carefully considered and reasoned about. Some of those people are still working on Solaris today, although sadly, I'm no longer one of them.
The Linux and BSD folks should take advantage of the good things that Sun left behind and carry them forward wherever possible.
DISCLAIMER: I'm a former Solaris Principal Software Engineer so slightly biased ;)
[1] https://illumos.org/opensolaris/ARChive/PSARC/
My "bad timing" comment was in reference to Sun getting sold in 2010. As an IT focused college kid, I realized there wasn't much value in learning Solaris system administration. That doesn't mean it didn't have amazing things as an operating system!
/usr/bin only existed because of fast small mainframe hard drives and slower larger hard drives.
I don't understand why the direction is the way it is thou. getting rid of /usr/ seems like it would make more sense.
And init binary in /usr is complete braindeadness...
Also MS behind anything means they are trying to get rid of your options, eg by complicating things into "enterprise level" and keep pushing windows as userware.
But there is other possibility: minimal root that is easy to manage, switch, etc. etc. and rest of the system :)
Yeah, libostree ("git for operating systems binaries") benefits from merging /usr. It might even be a requirement to have merged /usr to be able to use it.
https://en.m.wikipedia.org/wiki/OSTree
Wasn't that basically a historical accident? IIRC in very early UNIX, "/usr" used to be like the modern "/home", but they happened to have a big disk for that mount and started putting system files there.
> The merged directory /usr, containing almost the entire vendor-supplied operating system resources, offers us a number of new features regarding OS snapshotting and options for enterprise environments for network sharing or running multiple guests on one host. https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
And indeed, with systemd one can boot a whole system from practically any unpopulated root mount with a /usr image mounted on it.
Want to OS upgrade? Swap /usr & try it. /etc and /home and the other directories might have instance specific content, but the OS image is nicely set away & swappable in /usr. And one should be able to keep the same "instance" while swapping the image. It containerizes the OS image, separate-ish from the OS instancd, whereas before the OS was somewhat amorphously sprawled across multiple top level directories. It's a huge boon to manageability.
Will it at least lead to the removal of /sbin and /lib?
This is fixable: it only truly matters for /sbin/init, but it's nothing than can be fixed in a minute with the right kernel cmdline.
For the rest, a regex could replace /sbin by /usr/sbin in the package files
> /lib is expected to stay since the LDSO path for dynamic linking points there, removing it is not possible without breaking the ABI.
Maybe it's time to do that too? Android does just fine without /lib. Only the linker needs that, and changing the path to ld-linux should just require a kernel tweak.
But breaking the ABI could also be the opportunity to bring in android improvements, like the linkerconfig or namespaces!
If you disagree, please explain your point because I think google did some genuine improvements for dynamic libraries.
The parent commenter is already suggesting "just run a regex", so it seems like a trivial extension to their simple solution to "just run patchelf on every binary on your system"
Why not? What options are there and what are the pros and cons?
NixOS has also reduced "/usr/bin" to containing only a "/usr/bin/env" symlink and "/bin" down to just "/bin/sh".
So, why not apply the same philosophy to any other linux distro? Well, debian or ubuntu or whatever has plenty of user-written bash scripts, aliases, etc that are _not_ managed by the package manager, and would promptly explode with that change, causing people to switch distros, never upgrade, and probably write angry articles online.
There's plenty of sites that let you download and install a deb which isn't in debian's packages (i.e. chrome, zoom, slack) which would also all break. There's third-party package managers, like steam (which downloads and runs executables) which would also break.
Of course they won't do that, they don't want to piss off their users for minimal benefit.
NixOS has just accepted that "download zoom-installer.sh" or whatever does not and will never work on their distro, and people deal with it. Other distros are unlikely to make that choice.
Android has ensured those also never work by limiting people to just the app store. In a sense, ubuntu + snaps is trying to do that for their distro, but it's neither been that well received, nor making quick progress.
/bin/bash will be as well because /bin itself is a symlink to /usr/bin.
Though that’s a very dumb shebang to use and you should be ashamed: lots of systems don’t have it, or have an absolutely ancient system bash. By hard coding this you’re just making your scripts worse.
But the issue I’m talking about is using the specific path /bin/bash, as that just reduces compatibility compared to going through env.
the /usr/bin/env bash thing always just seemed like pointless cargo culting to me. never had this problem
“/usr/bin/env bash” will keep the shebang working between a Linux and FreeBSD (and probably other *NIX) machines. This bit me at one point, and it just became a habit since.
Bash (if installed) is in /usr/local/bin there. Other interpreters often are too.
Where? POSIX says:
I don't get the proposed benefits?
It's the systemd gangs don't want to support the standard directory hierarchy and force every distro to migrate.
Debian is among the last to do these changes.
/usr doesn't mean "user". It means "User Software Resources". I learned this from a good friend whose 70+ years old, and worked with Ritchie. My friend is also cited in K&R C.
/usr/bin and /usr/sbin should have always been the place to put "user software resources". And we're finally getting back to what it was originally.