Pray for all those scripts out there that assume /bin/sh or /bin/bash exists. Sounds like they only have a couple more years of error-free life
> 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:
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.