Linux kernel will support $ORIGIN, sort of • Hacker News Board

Re: Linux kernel will support $ORIGIN, sort of

#11

Post by rcxdude » Tue, Jul 21, 2026, 8:32 AM UTC

charcircuit wrote: post #10

Nix has caused so much busywork to be created through the entire Linux ecosystem. Rather than fixing their own project they force work upon so many others. Instead of looking for ways Nix could work with ensuring else they force everything else to be modified to work with Nix. You will constantly seem them trying to get projects to adapt a flake.nix or to replace bash scripts with a different shebang since they hardc…

>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 work sensibly due to the huge number of places where hardcoded relationships have been baked in.

Re: Linux kernel will support $ORIGIN, sort of

#12

Post by pm215 » Tue, Jul 21, 2026, 8:33 AM UTC

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 accidentally breaking existing #! lines that used to work.

Re: Linux kernel will support $ORIGIN, sort of

#13

Post by charcircuit » Tue, Jul 21, 2026, 8:35 AM UTC

dgrunwald wrote: post #7

nextaccountic wrote: post #3

I was confused on what $ORIGIN means, so, macroexpanding the article a bit https://fzakaria.com/2026/06/21/nix-needs-relocatable-binari... > The loader in Linux however natively supports the variable $ORIGIN which translates to “the directory containing the executable.” https://man7.org/linux/man-pages/man8/ld.so.8.html But, if ld.so supports $ORIGIN already, why does the kernel needs to support it also? Or rather, w…

$ORIGIN was only supported when the loader was looking for other dependencies. The loader itself (field PT_INTERP) is loaded by the kernel. So prior to this change, every program must hardcode the absolute path to ld.so. With support for an $ORIGIN-relative loader, each program could use its own copy of ld.so.

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.

Re: Linux kernel will support $ORIGIN, sort of

#14

Post by roblabla » Tue, Jul 21, 2026, 8:43 AM UTC

charcircuit wrote: post #13

dgrunwald wrote: post #7

Earlier quoted context omitted.

$ORIGIN was only supported when the loader was looking for other dependencies. The loader itself (field PT_INTERP) is loaded by the kernel. So prior to this change, every program must hardcode the absolute path to ld.so. With support for an $ORIGIN-relative loader, each program could use its own copy of ld.so.

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.

Re: Linux kernel will support $ORIGIN, sort of

#15

Post by HexDecOctBin » Tue, Jul 21, 2026, 8:45 AM UTC

charcircuit wrote: post #13

dgrunwald wrote: post #7

Earlier quoted context omitted.

$ORIGIN was only supported when the loader was looking for other dependencies. The loader itself (field PT_INTERP) is loaded by the kernel. So prior to this change, every program must hardcode the absolute path to ld.so. With support for an $ORIGIN-relative loader, each program could use its own copy of ld.so.

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.

Re: Linux kernel will support $ORIGIN, sort of

#16

Post by charcircuit » Tue, Jul 21, 2026, 8:49 AM UTC

rcxdude wrote: post #11

charcircuit wrote: post #10

Nix has caused so much busywork to be created through the entire Linux ecosystem. Rather than fixing their own project they force work upon so many others. Instead of looking for ways Nix could work with ensuring else they force everything else to be modified to work with Nix. You will constantly seem them trying to get projects to adapt a flake.nix or to replace bash scripts with a different shebang since they hardc…

>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 relationships bad for developers or users of the operating system? "Because they break Nix" is not a good excuse. Plenty of other operating systems work just fine with such things hardcoded, I don't see developers complaining about these hardcoded things, and moving things around can only make things more confusing for the user.

To me it looks like Nix picked a poor design and instead of going back to the drawing board and trying to come up with a better design they have gone all in on trying to force their bad design to work.

How much work do you think iOS or Android spend on app packaging / installation per year. Despite having millions of more developers and billions of more users they spend orders of magnitude less than NixOS does.

Edit: I can't reply since I'm rate limited.

Debian already supports installing multiple php versions.

You can use the update-alternatives command to set which one is default for the php command.

Via your web server's config you can config which php version a site will use.

Re: Linux kernel will support $ORIGIN, sort of

#17

Post by charcircuit » Tue, Jul 21, 2026, 9:03 AM UTC

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.

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

Re: Linux kernel will support $ORIGIN, sort of

#18

Post by ksk23 » Tue, Jul 21, 2026, 9:06 AM UTC

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…

You kind of argue it’s okay one cannot eg. Install two different versions of PHP on a Debian system. Nay!

Re: Linux kernel will support $ORIGIN, sort of

#19

Post by roblabla » Tue, Jul 21, 2026, 9:32 AM UTC

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.

How is that more valuable? It comes with two big pitfalls:

- It would still not allow downgrades to work properly

- It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together

Meanwhile, having different ld.so has many good use-cases, like simplifying development of ld.so itself, allowing them to swapped during updates in ways that are safer, etc...

And the eBPF binfmt support is a rather simple, generic mechanism that is likely to have many other use-cases beyond ld.so. So it's overall a pretty good resolution to the issue?

Re: Linux kernel will support $ORIGIN, sort of

#20

Post by wzdd » Tue, Jul 21, 2026, 9:38 AM UTC

My reaction was negative when I read the title (policy!), but the actual outcome was very reasonable. "Hey, can we add $ORIGIN to the VFS layer to support relocatable interpreters?" "You can already do that with binfmt_misc and ebpf, here's an example."

Then, later, a couple of patches to make binfmt_misc more ergonomic. Seems like a good outcome.