Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel will support $ORIGIN, sort of

fzakaria.com

Post reply on HN
Print view View original

21–30 of 78 posts

Re: Linux kernel will support $ORIGIN, sort of

#21

Post by dspillett »

charcircuit wrote: post #17
roblabla wrote: post #14

Earlier quoted context omitted.

Not with NixOS. ld.so is tied to a version of glibc, in ways that can be subtly incompatible. And nixos can have multiple glibc version installed on a single machine. Besides, it allows for upgrades/downgrades to be done in a way that's much less error-prone.

>in ways that can be subtly incompatible There is much more value to be had in making glibc properly backward compatible so you can have a single one that can be used with everything than trying to make it so that you can swap everything around, creating extra complexity and compatibility risks.

> […] in making glibc properly backward compatible […]

You could only do that going forward though, and would be stuck, at least for a time, with the historic versions that still need extra handling. In an ideal world that wouldn't be needed, but in an ideal world you'd not need multiple versions of glibc at all so we aren't there.

Support in the kernel means that it will work even if applied to old packages that for some other reason need a held-back version of glibc. As mentioned elsewhere it also gives the feature to #! directives in scripts too.

Re: Linux kernel will support $ORIGIN, sort of

#22

Post by roblabla »

charcircuit wrote: post #16
rcxdude wrote: post #11

Earlier quoted context omitted.

>Rather than fixing their own project they force work upon so many others. Nix has put in a ton of work to make their project work, and the assumptions in the rest of the ecosystem have been fighting every step of the way. And I would argue they've been changing it for the better, considering that if you were to just 'try to make nix work' you'd probably mainly come to the conclusion that it was impossible to make wo…

>and the assumptions in the rest of the ecosystem have been fighting every step of the way There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them." >due to the huge number of places where hardcoded relationships have been baked in. And why are hardcoded relationship…

> There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them."

It's not really arrogance - it's just a different way to design a system. NixOS wants a few things:

1. An input-addressed dependency system

2. Easy and robust rollback/upgrades

3. Different versions of software/libraries/services coexisting on a single machine.

A lot of this is just impossible to have together with the way software were written, so NixOS made the changes necessary for them. When it became obvious it might be useful to other people, they upstreamed it.

I do agree with you that the whole `#!/usr/bin/env bash` shebang shenanigan is kinda ass (my personal nixos machine has a `/bin/bash` alias because there's not enough time in my life to care about this issue). But I also think that NixOS is right here, shebangs requiring a full path is just a terrible design in a multi-user world. If different users want to have a different bash implementation, they should be able to!

---

Fundamentally, I think the NixOS OS design is actually beautiful. It's taking most of what makes modern phone OS so reliable (read-only system, A/B partitions, etc...), and bringing their ideas in a shape that is coherent with desktop/server OS design.

Re: Linux kernel will support $ORIGIN, sort of

#23

Post by Siyo »

I wonder if something equivalent exists for loading other kinds of assets. Take files that would normally live under `/usr/share`. References to these files are typically hardcoded with an absolute path as well. It's usually possible to relocate them at build time by specifying a different absolute prefix, but making them relative the conventional way would likely require patching.

Re: Linux kernel will support $ORIGIN, sort of

#24

Post by inigyou »

stabbles wrote: post #6

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables. Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

The kernel never looks at PATH, that's why. It's a shell construct.

Re: Linux kernel will support $ORIGIN, sort of

#25

Post by mort96 »

roblabla wrote: post #14
charcircuit wrote: post #13

Earlier quoted context omitted.

Each program having its own loader is an anti pattern. Such a requirement is overkill. You can have a single loader that supports everything on the system.

Not with NixOS. ld.so is tied to a version of glibc, in ways that can be subtly incompatible. And nixos can have multiple glibc version installed on a single machine. Besides, it allows for upgrades/downgrades to be done in a way that's much less error-prone.

"ld.so is tied to a version of glibc" is such a horrible GNUism.

Re: Linux kernel will support $ORIGIN, sort of

#26

Post by VorpalWay »

HexDecOctBin wrote: post #15
charcircuit wrote: post #13

Earlier quoted context omitted.

Each program having its own loader is an anti pattern. Such a requirement is overkill. You can have a single loader that supports everything on the system.

Unfortunately, Glibc and loader are linked together intrinsically in the Linux ecosystem. So, if you want to be able to launch a program reliably, shipping your own loader and libc might actually be the only way.

Glibc is backward compatible though, they even have symbol versioning to provide multiple versions of the same symbol. So as long as you have the same or a newer version of glibc (than what was built against) you should be good to go. And I don't remember hearing about breakages for this.

Other libraries on the system is far more hit and miss, but glibc is quite compatible.

The other way around is harder though, you can't take a program built against a newer glibc and run it on an older version. So you generally need to spin up a container with some LTS distro and build your binary in it if you want it to be maximally compatible. (However, zig apparently is able to deal with this by shipping a mapping between glibc versions and symbol versions and doing the linking themselves. You can even use zig to link rust code using cargo-zigbuild and get that benefit.)

But if you want to be maximally portable: static linking against musl. Though beware that many things are slower in musl, such as the allocator.

Re: Linux kernel will support $ORIGIN, sort of

#27

Post by mort96 »

inigyou wrote: post #24
stabbles wrote: post #6

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables. Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

The kernel never looks at PATH, that's why. It's a shell construct.

... and the question was: "Why doesn't the kernel look at PATH"

It's not a "shell construct" either, the standard execvp libc function looks at PATH.

Re: Linux kernel will support $ORIGIN, sort of

#28

Post by stabbles »

mort96 wrote: post #27
inigyou wrote: post #24

Earlier quoted context omitted.

The kernel never looks at PATH, that's why. It's a shell construct.

... and the question was: "Why doesn't the kernel look at PATH" It's not a "shell construct" either, the standard execvp libc function looks at PATH.

Indeed, it's a libc construct.

Re: Linux kernel will support $ORIGIN, sort of

#29

Post by chuckadams »

pm215 wrote: post #12
stabbles wrote: post #6

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables. Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accid…

> plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does)

glibc is what deals with PATH, not the shell. On Linux, it's execvp(3) in libc which is implemented in terms of execve(2) in the kernel, but POSIX doesn't make a distinction between syscalls and library functions, so a kernel could implement either or none directly.

Re: Linux kernel will support $ORIGIN, sort of

#30

Post by reinitctxoffset »

seanhunter wrote: post #9
reinitctxoffset wrote: post #8

Earlier quoted context omitted.

You have the right idea but the wrong specifics. The boundary you're alluding to isn't the kernel/userspace boundary, it's the `libc` boundary, which is admittedly privileged by convention if not by Ring 0. On most Linux systems this is regrettably `glibc` (in a container where you get to choose everyone chooses the superior option of `musl`), on all Darwin systems this is `libstandard`. This thread is more concerned…

That’s a weird rant which is manifestly false. On Nix the benefit you get from the incompatibility is the system can roll forward and back while it’s running so you can do big changes (eg updating or rolling back) the entire system without affecting running processes. You can also run groups of processes in isolation with different sets (or versions) of packages from the rest of the system. It’s fair to argue about w…

The privileged path is already there. `/usr/bin/env` is no different from `/bin/bash`, `/bin/sh`, or any other ELF artifact at a known place. The argument is made, the argument is spurious. It is made in the other direction regarding the driver run path, just as religious, opposite ruling from purity court. No one even knows why, the trail goes cold in a mysterious 2012 commit about Mesa, it's literally a performance to bring the plane cargo back. Receipts for claim: #141803.

Disagreeing with you doesn't make something a rant. If it's not clear how deep my Nix expertise is I will demonstrate it to any level you like: I'm just as entitled to an opinion as you are and I would appreciate it if the nixpkgs community was a little less rude to anyone who disagrees with some dogma no matter their knowledge. The nixpkgs community is not regarded as healthy or friendly after an internecine faction war that split three ways twice, producing four implementations none of which work, and if that reputation is ever going to mend, it will be because less than every Nix person has precisely zero chill the nanosecond anyone disagrees with them about anything.

Post reply on HN