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

71–78 of 78 posts

Re: Linux kernel will support $ORIGIN, sort of

#71

Post by p_l »

myrmidon wrote: post #42
mort96 wrote: post #34

Earlier quoted context omitted.

The Windows situation is way different: every process is supposed to link against kernel32.dll, that's the public interface to the kernel. In Linux, glibc is just one of many C stdlib implementations, you can have many versions of glibc on the same system, etc.

Sure, but if you want dynamic loading from your c stdlib (which is defensible IMO), and you want the behavior/implementation to match with the loader, then you need some kind of coupling somewhere no? You could have a very slim libdlopen that is used by both loader and libc, but I don't really see how that's any improvement/much different.

That's how Windows handles it - the OS libraries are language runtime agnostic and do not export language specific symbols nor need them, and language runtimes are distributed often separately.

So your C stdlib does not have dlopen() (in fact, it's not really part of C stdlib in POSIX anyway!) but you can link with standard OS-level ABI to OS-provided runtime services like "find a library and symbol from it" - AmigaOS did something similar.

Re: Linux kernel will support $ORIGIN, sort of

#72

Post by matheusmoreira »

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…

> why can't the kernel leverage ld.so and do this entirely on userspace?

Because Linux is completely independent from its user space. There is no "the loader in Linux", it just happens that GNU wrote one and it's widely used.

Re: Linux kernel will support $ORIGIN, sort of

#73

Post by charcircuit »

erooke wrote: post #70
charcircuit wrote: post #63

Earlier quoted context omitted.

I suggest you take a look at Fedora Silverblue. It accomplishes all 3 of those goals.

I don't see how it achieves goal #1, what am I missing?

Can you precisely describe what the goal of #1 is. For flatpaks an app's dependency can be specified with a sha256 of the artifact or a specific commit of the dependency.

Re: Linux kernel will support $ORIGIN, sort of

#74

Post by sylware »

setheron wrote: post #61
setheron wrote: post #60

Earlier quoted context omitted.

I would love to learn more about this; I'm deeply interested in replacing ELF with something either simpler or maybe leveraging sqlite for much of the functionality.

Feel free to email me! (author)

Once I have something satisfying, I'll post the "RFC-like" draft and preliminary reference toolchain on HN (well, if I can since HN is going 'whatwg cartel' web engines only then I may be blocked for good). For the moment, I am 'testing' all that while writting my own wayland compositor for linux (that's why I will try to build mesa AMD vulkan driver for this format... or stick to wl_shm in the end).

Well, for a new executable and dynamic library format, the computer language syntax complexity and its runtime complexity do matter A LOT, c++ is massive pain, and since, if I am not mistaken, sqlite is going microsoft rust, that's bad omens since microsoft rust syntax seems to be now as brain damaged than c++ syntax... but with an even worse runtime (unless all that is not actually true, I have not checked). That said, ISO f*cked up C with things like '__thread' which requires some level of OS support.

Re: Linux kernel will support $ORIGIN, sort of

#75

Post by anglesideangle »

charcircuit wrote: post #63
roblabla wrote: post #22

Earlier quoted context omitted.

> 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 softw…

I suggest you take a look at Fedora Silverblue. It accomplishes all 3 of those goals.

silverblue doesn't accomplish goal 3 either... if you need conflicting dependencies to interact in the same environment (i.e. outside a container)

Re: Linux kernel will support $ORIGIN, sort of

#76

Post by _nalply »

skissane wrote: post #52
inigyou wrote: post #47

Earlier quoted context omitted.

A surprising number of things in Linux are transparent to the kernel as they are implemented in user space. For instance, the Linux kernel doesn't support multithreading. It only supports processes sharing an address space. Which is what most people call threads - but in the kernel, they are just processes that happen to share an address space.

> the Linux kernel doesn't support multithreading. It only supports processes sharing an address space. Which is what most people call threads - but in the kernel, they are just processes that happen to share an address space. This isn’t really true. It is just that internally, the kernel calls the thread ID “pid” and the process ID “tgid” (“thread group ID”). But the getpid system call returns the “tgid” not the “pi…

I found grandparent's post still useful because it caused something to click in my head. I then researched and found that threads and processes share a lot of functionality. In the kernel both processes and threads are represented by `task_struct` instances.

So, respectfully, you shouldn't dismiss grandparent with "This isn't really true".

Re: Linux kernel will support $ORIGIN, sort of

#78

Post by skissane »

_nalply wrote: post #76
skissane wrote: post #52

Earlier quoted context omitted.

> the Linux kernel doesn't support multithreading. It only supports processes sharing an address space. Which is what most people call threads - but in the kernel, they are just processes that happen to share an address space. This isn’t really true. It is just that internally, the kernel calls the thread ID “pid” and the process ID “tgid” (“thread group ID”). But the getpid system call returns the “tgid” not the “pi…

I found grandparent's post still useful because it caused something to click in my head. I then researched and found that threads and processes share a lot of functionality. In the kernel both processes and threads are represented by `task_struct` instances. So, respectfully, you shouldn't dismiss grandparent with "This isn't really true".

It is true that the Linux kernel partially unifies the concepts of process and thread into "task"

It is false that it doesn't have the concept of processes and threads, or the distinction between them

What I was saying "isn't really true" is the second claim, not the first claim

Post reply on HN