[rgoulter]

The author mentions it in the conclusion, but I think "nix package manager on non-NixOS Linux" would be the best of both worlds.

You'd avoid the friction of having to deal with software that doesn't 'just work' on NixOS, but still be able to make use of things like devenv.

Though, an understated benefit from using NixOS is that the specific fixes taken are now available "as code".

[tombert]

A lot of people say this, but honestly this kind of sounds like someone who doesn't understand the ethos around NixOS. NixOS isn't just a vanilla Linux distro with Nix preinstalled

The whole point of NixOS is that the entire system is managed by Nix. The entirety of everything is declarative in your configuration file(s) and the entire system can consistently be rebuilt from the configuration. The root system is immutable after being built and as such it is trivial to snapshot.

This isn't just a trivial implementation detail, it changes the entire way that you use the computer. Boot parameters, drivers, installed programs, everything is done via configuration, as opposed to installing Nix on Ubuntu where most stuff is still managed haphazardly and mutably.

You might not think that's good or worth it, but I dispute the notion that installing Nix on a non-NixOS distro gives you the "best of both worlds". They're very different things.

[rgoulter]

OP had a situation where software he wanted to run didn't work with NixOS.

If OP wanted the benefits of the Nix package manager (e.g. per-project development environments, using Nix to build container images, etc.), and didn't want the friction of "how do I run this software on NixOS", I think it's straightforward that using Nix on a non-NixOS distro is a practical choice.

[rowanG077]

Using nix on non-NixOS definitely has benefits, I don't think that's disputed. But it's not "the best of both worlds" as the things NixOS gives are immense and not at all fully provided by just using nix on another OS.

[beepbooptheory]

One would think so but then you find out even more issues crop up with certain software.. Maybe things have changed but I found that anything that relied on opengl and such would need special workarounds to run on non-NixOS when I tried.

This was perhaps only an issue with launching from nix shell.. but it caused enough friction for me that I ended up switching. It's much easier to use, e.g., steam-run/appimage-run/nix-alien/plain-ole-npx for all special cases on NixOS than the vice-versa issues on non-NixOS imho.

[xorcist]

The whole point of NixOS is to make packages a special case of configuration. Running nix elsewhere doesn't do that and for configuration there are more mature tools. It would be like using Ansible(/Salt/Puppet or other similar tools) without any of the upside those have. Don't be afraid to use those tools though, they're great.

[Ericson2314]

That is the whole point of NixOS, but NixOS is not the whole point of Nix.

I personally think these issues sound one-off to me, and sticking with NixOS should be fine. But other OS + home manager is completely valid and a great way to use Nix more casually.

[jowea]

> You'd avoid the friction of having to deal with software that doesn't 'just work' on NixOS

I'm not sure what type of software you're talking about, but Linux native software usually works with 'steam-run', which is really the "pretend to be Ubuntu" command.

[rgoulter]

> I'm not sure what type of software you're talking about...

The original post mentions several examples where he ran into friction. (Monitoring/tracking software, pinentry-kwallet, playwright, tableplus).

A popular escape hatch for NixOS (or other immutable distros) for commandline tools is distrobox. https://github.com/89luca89/distrobox

Another good tip mentioned on the NixOS wiki FAQ is nix-ldd with the dependencies from steam-run.

Still. The benefit of having a declared system configuration does come with the cost of having to put in that effort up front; and a steeper learning curve for knowing how to get around those difficulties compared to more typical distros.

[throitallaway]

Software that has only dynamically linked binaries available for it (and no source) are one such example. The main Azure CLI tool is built in Python but it downloads binaries for certain actions on the fly if it needs them. These are a major PITA (or impossible) to get working correctly on NixOS.

[tombert]

I agree it's annoying, though if you need dynamically linked stuff, there's always the FHS environments [1]. You can also do an FHS shell if you don't want to make a package.

There's also nix-ld [2], which allows you to directly run unpatched binaries.

[1] https://github.com/NixOS/nixpkgs/blob/master/pkgs/by-name/bi...

[2] https://search.nixos.org/options?channel=unstable&show=progr...

[dangus]

I feel like the Atomic Linux approach is already a better fit for desktop usage. Flatpaks for most user software along with other options to install packages with different methods if there are special/legacy requirements.

I think the only negative aspect of the approach is the sheer quantity [1] of package installation options available.

[1] https://docs.bazzite.gg/Installing_and_Managing_Software/

[xorcist]

Flatpaks are a potential security disaster where people learn to install software of questionable provenance, not much different from other desktop operating systems where users learn to click past the warning to install binaries found on random web pages.

[akimbostrawman]

People will do that anyways if not from 3rd party repos like incredibly popular AURs or PPAs then good old curl | sh.

Flatpaks at least have a sandbox that can be easily configured to protect the user, does not require elevated privileges and get some limited vetting on flathub. Not to mention additional security feature like portals.

[dangus]

I feel like flathub and many App Store-like programs that install flatpaks do a good job showing app permissions, whether the apps are OSS, and whether the developer is verified.

I don’t see how it’s significantly different than the status quo on Windows/Mac.

[mhitza]

Flatpak makes it very hard to see who packages what. There are apps that look official, buy are built in third-party repositories.

With distributions packages, there's a bigger barrier to entry which is at least better in avoiding sneaky malware from easily creeping in.

[dangus]

For one thing, barrier to entry is not a security feature. Malware has made its way into paid app stores.

I think someone running Linux wants low barrier to entry as a reason to use the system. They want a system built by communities and not by corporations with walled garden toll booth business models.

But this point is extremely weak either way when you compare to the Windows barrier to entry which is effectively zero. Or you can compare flatpak to Mac users installing software with Homebrew.

I think if you look at flathub there are very good explanations on each piece of software regarding whether the author is verified, what the license and code availability status of the package is, and which permissions are being used when installed. It seems to use relatively strong language to describe permissions features as potentially unsafe.

[tom89999]

But its used to create the illusion that linux can be used by typing handymen.

[akimbostrawman]

Flathub is VERY transparent which packages are not verified and unlike system packages they come with sanboxing which if correctly configured (also transparently displayed) can mitigate malicious access.

[Propelloni]

You could take a look at guix [1], it's very much like nix, but is available as a package manager for other distros.

[1] https://guix.gnu.org/

[Cu3PO42]

Guix is also a great project and I don't want to dissuade anyone from using it, but Nix can also be used as a package manager only.

[eikenberry]

Does it allow you to install/run graphical apps that require GPU access? That's my biggest annoyance right now with using Nix packages on my Debian (stable) system, they just don't work for everything.

[microtonal]

You can often set up /run/opengl-driver to mirror NixOS and it will work. For instance for CUDA:

https://danieldk.eu/Nix-CUDA-on-non-NixOS-systems#make-runop...

[Ericson2314]

Nobody switched to Guix for easier driver support lol