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

51–60 of 78 posts

Re: Linux kernel will support $ORIGIN, sort of

#51

Post by aboardRat4 »

bobajeff wrote: post #45

Many people here seem to think this change will allow for people to package their Linux apps to be portable across distros/distro releases. If this is true then this a great! On Debian-based distros it kind of sucks when the version of a package is only available in a newer release so the only way to get it is either compile it yourself or upgrade your system. I remember trying to hack around this once by downloading…

>Many people here seem to think this change will allow for people to package their Linux apps to be portable across distros/distro releases.

There is no need to make binaries portable across the distros, because Linux is a source based OS. You can always just compile anything for your own system, just don't forget to submit the buildscript to the repo.

Re: Linux kernel will support $ORIGIN, sort of

#52

Post by skissane »

inigyou wrote: post #47
mort96 wrote: post #27

Earlier quoted context omitted.

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

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 “pid”, and to get the “pid” you need to call gettid (get thread ID). Other kernel interfaces also use the terminology “thread”, e.g. /proc/thread_self, set_tid_address, set_thread_area/get_thread_area, the CLONE_THREAD flag to clone, inter alia

Re: Linux kernel will support $ORIGIN, sort of

#53

Post by aboardRat4 »

Siyo wrote: post #23

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.

You can always set "RESOURCE_PATH" and load your files from there.

Re: Linux kernel will support $ORIGIN, sort of

#54

Post by aboardRat4 »

ksk23 wrote: post #18
charcircuit wrote: post #16

Earlier quoted context omitted.

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

Of course you can.

Re: Linux kernel will support $ORIGIN, sort of

#55

Post by setheron »

roblabla wrote: post #48
pas wrote: post #44

Earlier quoted context omitted.

still, eventually there's a need to support on one platform different ld.so/glibc pairs (even if they are API/ABI compatible) it seems nixos could set up a wrapper that invokes the right ld.so based on the executable. though at this point they could probably edit the ELF binaries and patch the fixed path to ld.so when nix is installing the program. yeah, it seems strange that this needs kernel support. but more eBFP…

> though at this point they could probably edit the ELF binaries and patch the fixed path to ld.so when nix is installing the program. That's exactly what they're doing right now - though instead of being "when installing the program", it's "when compiling the program". The problem with hardcoding the path is that it pins the "nix store" (where nix installs all of its programs) to a hardcoded location. If you want to…

(author) You did a great job articulating the points!

Re: Linux kernel will support $ORIGIN, sort of

#58

Post by reinitctxoffset »

seanhunter wrote: post #46
reinitctxoffset wrote: post #30

Earlier quoted context omitted.

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…

It's no different other than it's a layer of indirection which allows bash to change in a way that would not be possible if scripts directly referenced /bin/bash or /usr/bin/bash. The only thing you can't change is the /usr/bin/env binary itself but that's not something that changes very much if at all. On my nix box, bash is at /run/current-system/sw/bin/bash and "current-system" is a symlink to a particular build i…

You've just used a personal attack to shout down someone who disagrees in good faith over a distinction you simultaneously describe in your own words as "something you could achieve other ways" (yeah, more than a little bit) referencing an artifact that "is a symlink", "on my nix box".

The only thing I attacked are named instances of regrettable community malfunctions stripped of anything personal to an individual that hurt both current users of Nix and people who might experiment with systems they can reason about, saw an interaction like this, and did something less painful with their day. Because my evident and sincere concern for the future of Nix is framed as stark disagreement over a few particularly sacred cows.

At least on `comp.lang.lisp` you got your middle finger alongside a worthwhile education:

"There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished."

- Erik Naggum

Re: Linux kernel will support $ORIGIN, sort of

#59

Post by Siyo »

aboardRat4 wrote: post #53
Siyo wrote: post #23

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.

You can always set "RESOURCE_PATH" and load your files from there.

Sure, assuming this is your own software. The context of the article is on working towards a general approach to relocatable nix binaries so I don't think that's going to scale across nixpkgs.

Re: Linux kernel will support $ORIGIN, sort of

#60

Post by setheron »

sylware wrote: post #43

linux ELF code is loading the ELF loader only. $ORIGIN may not be a good idea since that would add more ELF complexity to the kernel. If we are honest with ourself, ELF is the core of the issue: for executables and dynamic libraries we _now_ know it is severely obsolete on modern hardware architectures. I am currently using my own format, excrutiatingly simple, no loader, basically a program segment, "userland syscal…

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.
Post reply on HN