I think NixOS is too good for me

1

I have a laptop privided to me by my employer. The OS is Ubuntu 22 with some customisations. And I’m not allowed to reinstall it.

I am using this laptop to develop a flake. A proprietary tool for our development processes. While doing that, I frequently face some weird issues:

While these things are a huge pain to debug,I’ve embraced them — Nix is hermetic, so I have to setup the environment myself.

But! How many of the same issues would I find on NixOS? I feel like it’s already tailored to Nix and things will “just work”. And that’s bad. That means that while it would work for me, it wouldn’t work for everyone else in my company.

Though Nix is supposed to be hermetic, it seems like there are a lot of Platform specific quirks that could influence it.

Recently I bought a new laptop. I really want to use NixOS. It might be a smooth sailing for me, but I fear that it will hide errors from me and leave my flake broken for everyone else who doesn’t use NixOS. I know I could test the flake on my corporate laptop once in a while, but that not the same as developing and debugging in the same environment.

2

The thing is, you’re already in that state. Every ubuntu installation will have its quirks. You need specific installed applications, and depending on what modifications you make to /etc the system will behave completely differently. It’s very hard to have a fully documented ubuntu installation. You’re likely not in fact developing in the same environment as everyone else.

The entire idea behind nix/NixOS is that by using these systems, you are forced to document your dependencies. Your coworker’s system isn’t rendering Cyrillic characters correctly? Well, just open the flake.nix and it tells you exactly which packages and env variables need to be set for that to work.

Furthermore, NixOS isn’t exactly “tailored to nix”. For each of the points you list:

Your library loading is messed up. This is likely because of some configuration on your end, which may eventually cause problems with ubuntu updates too. Running this on NixOS wouldn’t change this, except for potentially not having whatever issue is currently on your system.

This is simple sudo configuration. Using sudo in scripts is generally bad practice; you should execute the script itself as the user that should be doing what it does.

You can edit your NixOS sudoers config to set the same setting if you’re worried about this. This has nothing to do with “being tailored to nix”, though - you’d run into the same problem on any distro with less liberal sudoers configuration.

If rendering cyrillic characters is really important, you should document this requirement as part of your docs; ubuntu may happen to set LC_ALL to a UTF-8 language by default, but this is not true for all systems.

nix’ hermeticity is showing you a bug in your docs, this wouldn’t work on NixOS either.

This should no longer be true with NixOS 25.05 if I understand the mesa changes correctly. On NixOS, this just works, but yes, graphics drivers are (were historically?) one of the few things that aren’t easy to separate from the host platform.

Ultimately, yes, NixOS will be more different from your coworker’s systems than running another ubuntu system with morphing configuration. This isn’t itself a problem though; if you have more heterogenity in the systems running your code you’ll run into a lot of the hidden integration issues your applications have, and actually fix them, instead of being yet another company that’s stuck exclusively targeting a decade-old ubuntu LTS because you’re relying too much on its specific quirks.

3 Likes
3

I think the mesa problem on non-NixOS might be less severe now, but it surely didn’t disappear.

4

Do you think it’s a lost cause if other people aren’t able to patch the flake themselves? Would they constantly get distribution-specific issues? I initially wanted to use Nix to make a “write once, run everywhere” type of developer environment.

But how could that be possible?! You saying
that shatters my whole worldview. Isn’t Nix supposed to be hermetic? Isn’t it the whole point? Why would system libraries interfere with the derivation?

Same thing here. Are you implying Cyrillic characters would have worked if Ubuntu had set LC_ALL var? But Nix shouldn’t be able to read my system’s env variables, should it?

What about it? Did something change in 25.05? I’ve missed it.

I always assumed Nix was “write once, run anywhere” package manager. Do I have a wrong mindset about all of this? How should I approach Nix?

I might need to read something. I am familiar with the language and flake structure, but I might be missing some general knowledge about how Nix works under the hood.

5

It is! However, to achieve this nix needs to tightly control the runtime environment.

You can’t take a binary, run it in a nix-controlled environment, and then take it to a completely unmanaged environment, and expect it to behave the same in both.

If you use nix shells to try and control the environment, the develop shell still lets certain details leak in for developer convenience (e.g., potentially LD_ vars). To get a more clean shell, use the --pure arg.

Even then, your mileage will vary if you explicitly call out to host binaries with absolute paths or read host config files. This is precisely why NixOS generally avoids having fhs directories, so that it is impossible to accidentally depend on those things.

Your builds are unaffected by this, since those are sandboxed. Nix is primarily a build tool, not really a package manager. So nix is really about asserting that your builds will always work, not that your binaries magically always behave the same way no matter how you configure them - that’d usually not be what you want anyway.

6 Likes
6

I believe the point here is separation of libgbm, so that part is pure now and only the rest remains impurely loaded from /run/opengl-driver/ (which is NixOS-specific):

1 Like
7

Kinda… Applications from Nixpkgs that link against libgbm, stopped requiring to be used against Nixpkgs’ Mesa’s DRIs. I didn’t try it myself, but setting GBM_BACKENDS_PATH should be enough to make those (OpenGL and EGL) apps run in FHS Linux. While Vulkan apps should be working even before that since its loader uses the XDG_DATA_DIRS to search for ICDs that will point to the right place in all scenarios. Apps depending on libglvnd without libgbm should have always worked too.

The biggest gain of this change actually is setting a different version of Mesa than the one from Nixpkgs on NixOS without workarounds. Just set hardware.graphics.package overriding the source to whatever 24.3+ revision you want.

8

I think the drivers themselves (and libGL*) still depend on some libraries, so you may get a clash. Even glibc does not have two-way binary compatibility (major downgrades commonly do not work, only upgrades).