On that topic, has anyone looked at changing that message to something more informative?
bash: ./my-binary-from-the-Internet: No such file or directory
8 Likes
I don’t think thats a nixos specific error message, Pretty sure the dynamic libraries are trying to be accessed and just fail with that message.
EDIT: It’s unfortunate that it doesn’t specify the library that it failed to load, but rather the executable that you can verify easily does exist.
1 Like
It’s not NixOS specific but NixOS users are more likely to encounter it. It’s pretty confusing, especially when the invoked program is deep in a script so there is no direct references to it.
$ file rambox
rambox: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=23bf81ad05c6919e0a4de1c60628410fc1fb0d95, stripped
$ strace ./rambox
execve("./rambox", ["./rambox"], 0x7ffbffffa680 /* 74 vars */) = -1 ENOENT (No such file or directory)
strace: exec: No such file or directory
+++ exited with 1 +++
The kernel is returning ENOENT and glibc is probably pre-filling perror(3) with “No such file or directory”.
At that point the user starts wondering what the issue is since the file exists. Have to learn about the ld loader and how libraries are resolved on RPATH.
9 Likes
It seems that fedora used to have a patch for that, on bash 2 [1]. The error message it used to produce still yields results when searching the internet. It was /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory and generally hinted that 32-bit libs were not installed.
We could elaborate our own patch by relying on patchelf --print-interpreter to avoid most of fedora’s patch complexity around parsing elf structure. It would be quite easy to spot interpreters outside the nix store. We could then link to a relevant section in the nix manual. (Or even to this discussion :-D)
6 Likes
What I’d like to see is a tool to automatically write Nix builds for arbitrary things. So you could nix-package https://example.com/random-binary and it would output an expression like
with import <nixpkgs> {}
stdenv.mkDerivation {
name = "random-binary";
src = fetchurl { url = "https://example.com/random-binary"; sha256 = "..."; };
nativeBuildInputs = [ autoPatchelfHook ];
buildInputs = [ openssl ];
installPhase = "mkdir -p $out/bin; mv $src $out/bin";
}
Many smart auto-detection heuristics could be implemented in such a tool, such that ideally users would rerun nix-package to update the expression, not change the Nix expression themselves. If it can’t generate a working Nix expression without help, either the upstream should put some hints into their code so it can, or the tool itself should be adjusted so it can handle that case.
Over time such a tool should get smarter and be able to handle more and more packages automatically, to the benefit of everybody not having to continuously do the same things.
10 Likes
I don’t have the capacity to reply right as much as I’d like now, but I would like to signal my intense sympathy with the premise of this thread.
It’s more heavyweight but I don’t think anyone mentioned virtual machines as an escape hatch - though steam-run (as mentioned) might be entirely encompass that? (just entirely sidestep the whole issue)
sidenote: on the note of VMs, I believe there is work being done on some wayland stuff that might make guest windows usable as host windows, which might be kind of interesting.
1 Like
This works if the project explicitly links against a given library, so there’s a way to view exactly what the executable will try to load. But there’s plenty of times when an executable will do dlopen(..), and everything gets thrown out the window.
We could probably do that on a per-language basis, but the number of supported languages could increase over time. However, I would love to just do nix-package https://..., that would be a wonderful change-of-pace; even if I didn’t get to my desired end-state, but was able to get mostly there, it would still help with getting a working expression
Another thing we could do is check for missing linked libraries. As part of a channel release, the release will produce a small sqlite db which contains all the command names (this is where you get The program 'foo' is not installed, ...). We could do something similar for libraries, and be able to give helpful hints about missing libraries, and maybe another option to do --add-missing-deps to automatically include them.
6 Likes
I had the idea at some point of trying to do something like autoPatchElf with a FUSE filesystem, so dlopen and other calls try to load a library and the FUSE system makes things magically appear under you. Seems kind of crazy but it might work?
3 Likes
Maybe a better fit for you is an LSB/FHS distro, and just use nix the package manager and set of tools (nix-shell, etc). You will be able to leverage lots of the nice things about Nix whilst being well-supported for a lot software.
I sympathise with your struggle, but I don’t see NixOS changing it up anytime soon to be honest. If productivity is your target, then IMO you ought to select the distro which best helps you achieve that.
Having developed recently a couple of Node apps using NixOS, I can tell you buildFHSUserEnv was my best friend 
Hope this helps.
2 Likes
I don’t have time to read the thread, so i just answer the initial question:
- have a graphical installer where you can select your favorite DE or WM and basic settings (see RFC: Graphical installer for NixOS · Issue #21662 · NixOS/nixpkgs · GitHub)
- have a graphical editor for
configuration.nix(i don’t know how that could look like. good research topic ;))
See User-friendly NixOS distro? - #34 by davidak for previous discussions…
1 Like
I don’t know if this is what you intended, but that statement doesn’t seem to be welcoming to newcomers like me.
2 weeks.
But I switched to Manjaro Linux after a couple weeks, as I needed to get work done.
As a newcomer, it seems I don’t need to understand that syntax either in order to use the Nix language and functions, but I was curious. The hard part is what to do with the nix language or nixos itself, not the language which I was comfortable enough with after two weeks.
1 Like
I apologize, that was not my intention. I was trying to make a self deprecating joke.
4 Likes
I may have understood. In any case, I like what NixOS is trying to achieve, but there’s lots of hurdles and deep knowledge of both Linux and nixpkgs needed to start trying to be productive. I never had to deal with EFL patching before, which is handy to know.
The whole problem with Linux and C++ in general is it doesn’t have a nice package management system. Everything is ad-hoc, and the existence of “distros” is practically due to the need for package management solutions, and teams to manage the packaging of all applications.
It is the reverse of a modern package management ecosystem like NPM, where the application developer is responsible for packaging and shipping a package, then anyone else can consume it without replicating all of that work.
There’s a package manager called ied that takes NixOS inspiration (hashing dependencies), but the rest of ied’s behavior is just standard NPM, and it allows any package to depend on any version of any other package.
Now here with Nix we have a package manager that is trying to allow any package to depend on any version of any other package, but the issue is that the underlying system (FHS, etc) that each package is conventionalized on is completely in the way, and required Nix users to create sub-shells with fake FHS environments or patched ELF binaries. It’s basically hacking the very old system to bend it to newer ideas.
Instead, maybe the whole reliance on FHS packages should just be dropped, and instead something decoupled from FHS and ELF (and etc) would be a better path.
There’s package manager called Conan for C++ projects that sort of resembles NPM, but for C++. Maybe that, and NPM, can be looked at, and something better created, and then a new operating system built on top of it.
I’m not sure how Conan works exactly, but I know that each of my projects using Conan can have any dependencies they want regardless of version, and they just work, without me having to patch my shell, or without me having to be aware of how to patch ELF (I don’t know if Conan does that or not).
But the key thing about Conan is, it does not interfere with my overall operating system. It leaves my OS in tact, and I don’t need to continually tweak my working environment (like I do in NixOS) to run programs that depend on differing dependencies. That’s a huge benefit.
I see a better future in making an operating system that allows packages to be built independently, rather than all packages relying on globally installed packages.
I don’t know exactly what the solution is, but I believe it should be OS agnostic without depending on specific OS features, and any dependence on the filesystem only needs to happen at the location where a project is being built.
2 Likes
This statement sounds like a security nightmare to me. To be fair it is a trade-off: the app developer gets all the power so they can do things correctly (which OS package maintainers do not always do), according to their vision of what correctly means… and the app users end up with lazy app developers who don’t patch against the latest major exploit in included in their stack.
3 Likes
What you’re saying is something I somewhat tried to encode in my terse representation… Basically you have to be a dev and a Linux admin to use nixos full time and actually enjoy what it has to offer. (I mean my grandma can use it but then the nixos part would be useless). I’d give this warning to anybody to save their time. (Nixpkgs alone requires only programming experience…)
I’d like to point out, indeed that both ELF patching and FHS chroot/virtualisation while is indeed an ad-hoc hack as you pointed out, only necessary for packages that for one reason or other cannot be packaged properly in Nix – and usually this would mean they cannot be packaged properly in Connan (I would imagine) either.
E.g. Adobe reader is shipped as a linked binary, so we cannot link our own libraries hence the need to patch.
Patching steam, and all its applications would be too much work (if at all possible, because we don’t have access to the purchased content to package it), so we virtualise the FHS it expects.
So the way I see it, you would need the same hacks in other approaches too.
The benefit of a cross-language package manager like Nix is that applications can depend on e.g. C libraries, and this way you can capture that dependency too!
8 Likes
This is leveraging capabilities of a specific language framework, not really fair against a tool which is generic over all use cases.
I think this is a good example of the fundamental difference between nixos and other operating systems. In typical FHS operating systems, you start from a place of impurity, all of your system installation is dumped into a few directories which get mutated over time. In NixOS, you start from a place of complete purity, and you can “introduce” impurity with buildFHSUserEnv, and a few other tools as needed.
It blows my coworkers mind when i can switch between python interpreters with a single command. It’s only really possible because i don’t have to invalidate a system wide installation like you would need to do normally or in windows.
4 Likes
I keep wanting to do something like my earlier virtual machines idea for printer/scanner/device drivers. Can they somehow be run in a FHS container? I didn’t look into it much.
I’m not sure I see what you mean, a VM guest has it’s own set of drivers, typically for an abstracted device that the VM host maps to an underlying device – though there is PCI and USB passthrough. Sounds like what you need is help packaging a printer driver, perhaps have a look at <nixpkgs/pkgs/misc/cups/drivers> folder?
Have you opened an issue on GitHub to request help with packaging whichever driver you need?
1 Like