Hacker News new | past | comments | ask | show | jobs | submit login

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.



> There are still many paths hardcoded into /sbin

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!


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.


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.


I mean, we don't have to hack the elf loader if we just rewrite every elf binary using patchelf: https://github.com/NixOS/patchelf

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"


> unless you're using the in-kernel firmware loader, which you really shouldn't be

Why not? What options are there and what are the pros and cons?


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


Not sure if trolling...


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: