How to make NixOS so easy that people can be productive up front, without having to first learn the nix language?

Development
34

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
35

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
36

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
37

See also GitHub - edolstra/dwarffs: A FUSE filesystem that allows tools like gdb to look up debug info files via HTTP

38

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 :slight_smile:

Hope this helps.

2 Likes
39

I don’t have time to read the thread, so i just answer the initial question:

How to make NixOS so easy that people can be productive up front, without having to first learn the nix language?

  1. 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)
  2. 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
40

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
41

I apologize, that was not my intention. I was trying to make a self deprecating joke.

4 Likes
42

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
43

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
44

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

45

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
46

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
47

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.

48

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
49

Have you seen de-generate yet? Looks IMHO very similar to what you are proposing.

2 Likes
50

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 can’t speak for others, but at least in my case the whole reason I switched to NixOS was because of the killer feature of declaratively describing my base system. And I was not disappointed–I absolutely love NixOS for that. I do also enjoy being able to use e.g. nix-shell to fire up different environments quickly, but it’s not the reason I really care about Nix. I care about Nix because of NixOS.

So, personally, what I’m looking for is almost the opposite of what you’re describing. I want Nix to manage the base system, and then “get out of the way” and just let me build and run the software I want. If I switched to another distro as you suggest I would gain the “get out of the way” experience to some extent1, but I would also be losing most of the reason I’m using Nix in the first place: NixOS.

I understand that’s not actually the point of NixOS. And “just use another distro, because that’s not what NixOS is meant to be” is a perfectly reasonable response.

But I think that may be where some of the people on this thread are coming from: they’re looking for an OS that is itself pure, reproducible, and doesn’t degrade over time due to mutability, but that can still interact with and utilize the outside “dirty” world of software relatively transparently without compromising its own purity. NixOS feels tantalizingly close to that with tools like steam-run, and at least in my case that’s extremely enticing.

1 I’ve actually had a lot of trouble running and/or building certain projects on more traditional distros as well. I do really love Nix for that as well: if something’s a pain to build, at least I only have to solve it once, not over and over every time I’m on a new system.

15 Likes
51

I get this use case. As mentioned already in this thread the PR that meant to provide the option was closed. So it seems that the maintainers have taken a stance on this issue – and to be quite honest, I would be pretty excited about that feature (and likely would use it, for example, at work where building SOEs is a pain and using something like nixos would solve so much IMO).

Maybe someone with the stamina and right attitude could either revitalise that PR, or perhaps turn it into an overlay so that it lives outside of the common nixos codebase, but individuals could opt in? I guess though that would be some kind of happy medium, it would perhaps not meet the original goal of this thread which is: make it easy up-front. Turning that into an overlay or explicit opt-in would arguably make things even more confusing.

2 Likes
52

Seems to exist here: GitHub - balsoft/nixos-fhs-compat: LSB&FHS compatibility for NixOS. Intended for containers and VMs.

2 Likes
53

I’m now using docker to run programs from others as a sandbox and as a developping environment for dirty works, and I wrote a script to make things easier.

If you are familier with docker, maybe this share will help:

The main idea is run docker container with /nix and ~/.config etc mounted into the container.

This is much easier than buildFHSUserEnv which need you to figer out dependencies to run a program, and also provide a sandbox (a layered filesystem) so everything dirty will be isolated from your NixOS.

1 Like