Seeing as you don’t understand that notation but are still using nixos, that kind of (but not completely) invalidates what I said…
How long have you been using nixos?
Outside of the nix language I have zero functional programming experience, nor had I ever taken a theoretical math class back in my days as a student. While the manual has this notation to explain functions the manual also has examples to explain every function. My eyes glazed right over this notation as there was never any need to understand it.
I have been using NixOS as my daily driver since around 17.03 - 17.09 and never once had the inclination or need to run a trivial google search and find out how to read that.
3 Likes
The rejection you got there was a lot 
, but I believe it was well based.
A good thing NixOS could provide is a thing like steam-run, an isolated environment to run these programs. I believe that would help a lot of people just entering NixOS and even current users.
Something like that would help productivity when you’re in a pinch.
9 Likes
It seems like making a alias to steam-run and publicizing it a bit would go a long way.
6 Likes
And remove the actual steam runtime from it, since it is unfree and not needed for other binaries.
Edit: I mean remove it from that “alias” / copy, not from the original steam-run of course.
9 Likes
I propose fhs-run as the command name, and have a similar surface to an ubuntu desktop. It will be a pretty big closure size, but at least most things would run.
There’s been too many times when the only missing dependency was libstdc++.so.6
21 Likes
That name sounds fine and matches the already existing concept name, so that’s good. Another name I thought of was lax-run to indicate this isn’t our normal strictness.
7 Likes
Would implementing lsb-run that strictly implements LSB, and lax-run that extends lsb-run with additional common runtime things be feasible? (Maybe steam-run could also extend lsb-run?)
3 Likes
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