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.
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…
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.
I apologize, that was not my intention. I was trying to make a self deprecating joke.
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.
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.
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!
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.
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?
Maybe a better fit for you is an LSB/FHS distro, and just use
nixthe 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.
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.
Seems to exist here: GitHub - balsoft/nixos-fhs-compat: LSB&FHS compatibility for NixOS. Intended for containers and VMs.
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.
I can only say (with lots of experience in tooling with cmake and Conan). Conan is a package manager, but comes with a lot of quirks which Nix already solves, and better, and more reproducible. There are tons of things you can steer in Conan, package id, overrides in dependency chains, and also ELF patching is needed under the hood although its not really properly done, mostly RPATHs are removed (AFAIR) when packages get stored in the cache, so installing a package and executing an app inside relys on installing/buidling the package to the cache and the creating some runvirtualenv thing, which basically boils down to Conan creating a Nix equivalent shell where LD_LIBRARY_PATH is filled with all dependencies such that you app inside the package can run.
Conan is a beast and I still think from using Nix packaging a bit now, Nix solves it better, its more isolated. Less troubles, less corrupt build caches with wrong packages which were build on wrong architecture (not to mention the whole libc problem, which needs to be addressed sooner or latter an included into the package id (hash) which it does not at the moment). Nix is the total solution for dependency tracking. Yes it does ELF patching to set RPATHs etc to point to the correct /nix/store/... libs. But thats how it is. What would Nix make unbeatable is if it would somehow support Windows, but that is just a shithole into which no Nix maintainer wants to go… (no RPATHs, dependency resolution in dynamic linker at runtime is totally different)
We used Conan mainly for dependencies and when it came down to packaging to put the whole junk into a docker container, we relied on CMake with some Custom tooling (import libraries conan import to the predefined Cmake install location and using this to patch the ELF such that it is fully self contained (except libc and stdlib (optional). Basically what Nix already does when you put it in the store (except that its not a self contained package but Nix taking care of these when the derivation gets installed). Nix comes with its own caveats, that you need to go fully in, or leave it. So to package a C++ thing you need to write a flake.nix which build the package over a builder (calls CMake or any other tool) which is completely another workflow as people are used to on other Linux setups such as Ubuntu etc… everything is isolated, so you need to build all dependencies also with Nix)
You just opened a can of worms called glibc, dynamic linking and GPU drivers 
Anyhow, closest you can get to this is steam-run or GitHub - Mic92/nix-ld: Run unpatched dynamic binaries on NixOS
EDIT: noticed that I’m necroposting 
Since the necropost is already done, nix-ld is the best alternative to me as it basically recreates the loaders. And it is now in NixOs, you can enable it with
programs.nix-ld.enable = true;
And add missing libs via programs.nix-ld.libraries. Works great, even with npm etc that typically play poorly with nixos.