They added the Nix directory in SteamOS 3.5 and linked it to the User partition, so now Nix survives SteamOS updates without any workarounds, which is part of why I tried using it.

The more ive learned to code and the better I’ve become at solving my own problems on Linux, the more I’ve been absolutely fucking bewildered about how so many people can spend so much time and effort into projects they care deeply about and fail to include even the most basic of necessary instructions. Like “this one simple step is crucial and you can’t do fuck all else if you don’t do it”, kind of necessary

I think they want people to use the things they built, right? And yet, here’you are in a Kafkaesque nightmare with no visible exit, seemingly alone as if you’re the only person to ever actually need the crucial but of instructions necessary to make this thing work.

You wonder: am I just an idiot? Iss everything else in on something that I just don’t get? So you spend hours pissing into the wind as Google tantalizingly dangles tangential words at you, having become the internet equivalent of a bully snatching away the toy you brought for show and tell while swearing THIS is the last time, and you soldier onwards for hours, determined that you’re going to get this fucking thing working even though you know that for the sake of your sanity and our limited time on earth the better choice would be to give up. You make a point to leave a comment about your struggle on GitHub, just in case someone else finds themselves in your position one day, feeling less like an accomplished problem solver and more like someone who’s had to pop their own dislocated shoulder into place after dropping a piping hot pizza and falling on black I d. You’ve learned something, you’re more self reliant, this will be less serious in the futurre, but you can’t shake this weird feeling growing ever more insistent, a question you just can’t seem to answer: why? You’ll never know, and though it bothers you, you set to work trying to get this new image generation model to make you some anime women with comically oversized tits and worryingly unnaturally thin waists.

Right but like “be able to do anything” requires you to have Flakes enabled

deleted by creator

It tends to get your software out there and used faster if you bootstrap the packaging

It’s fine to provide some sort of “official” binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.

My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.

it’s easy on most distros

It all depends on what you’re used to and how cursed the project’s build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn’t want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.

On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

It’s the same for NixOS. When I encounter something that somehow isn’t packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.

Nix doesn’t do anything special when launched.

The way it works is very simple - instead of e.g. /usr/lib/libssl.so.3, binaries use /nix/store/openssl-…/lib/libssl.so.3. This is done at build time, not runtime.

Having every application load their own version of a library into memory is bloat.

The applications have binaries and libraries bundled for multiple arches. I wasn’t speaking to the package manager.

IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.

None.

The last time I looked the NIX solution to secure boot keys was to disable secure boot

Are we talking about Nix or NixOS here now? These are entirely different things.

Nix on non-NixOS does not care whether that OS can do secure boot or not.

As for NixOS: https://github.com/nix-community/lanzaboote

(Not sure what you’d actually want to achieve with “secure” boot as it doesn’t protect you against anything on its own.)

The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me.

The current support for secure boot in NixOS is rather experimental still. It’s the same as any other distro that hasn’t applied to RedHat to get their shim signed with a M$-trusted key, so I don’t really see your point here.

That aspect is also being worked on as we speak.

I didn’t care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run.

That’s your ignorance’s fault, not any distro’s. If you can’t be bothered to plug in your own keys, you limit yourself to the set of distros that are indirectly officially approved by M$.

I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at “you figure it out yourself” complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn’t understand, approached in ways I found useful.

If you need your hand held, the Nix ecosystem won’t be for you. It’s not really approachable by people who can’t research things in its current state.

Nothing wrong with that but Nix just isn’t at the point where mere mortals can reasonably be expected to be able to use it.

Pretty much, yes. Although most of the guides install nix via curl. You can find the recommended installation procedure on the official nix website.

What I’m right now also realizing is that i switched things up. nix-shell -p curl creates a shell with the curl command temporarily available. If you exit this shell it’s gone. I use this all the time if if i don’t want to pollute my system with programs I only use once. If you want to permanently install something you have to use nix-env -iA nixpkgs.curl. But don’t take my words for granted, since I have never tested this on a non-nixos machine.

Note: You can also see how to install something by clicking on the package title in the nixpkgs repo.

I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.

It’s probably one of the simplest things you can do with it that isn’t really possible with other package managers and also doesn’t require explaining any internals, I guess that’s why.

I could also tell you about easily being able to build statically linked binaries or cross-compile (or both) with the same package definition without having to do any extra work, that might be more impressive.

The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).

Yeah, and neither of them considered that it might be important to deal with software written in other languages. Want to link against a C library in a Rust project? Run some tool as part of NPM build step? Screw you, install it manually from elsewhere or your build fails. The only one that I know does do this is OCaml’s OPAM, which does have a lot of non-OCaml software packaged. (Also at least the latter three seem to be only for setting up the language itself. What is this, a package manager for a single package?)

Not to mention Docker.

Meh, Docker is kind of a joke. Sure, it solves the problem of dependencies, but in possibly the stupidest way possible bar shipping a VirtualBox image. A lot of prebuilt images are x86_64 only. It needs to run a Linux VM on Mac and Windows (tbf Nix doesn’t have a native Windows version at the moment either, you need to run it in WSL, but people are working on that). So that means running at native performance on an ARM Mac, which are quite common for development I think, is out from the start. It also adds a lot of complexity to your environment due to wrapping everything in a container if you just want to have a couple tools. You don’t get your nicely configured shell, other system tools, anything else inside the container. I haven’t ever tried it but you probably also need special support from any IDE you want to use.

(And not to mention most Dockerfiles being absolutely not reproducible, but you can solve that… with Nix :^) )

• GUI app shortcuts work in neither of the OSs

On Linux I think you need to link ~/.local/share/applications to home-manager’s share/applications. Not sure about Mac, its GUI kind of hates symlinks and Nix uses a lot of symlinks. Spotlight doesn’t read anything behind symlinks at all, for example, and Launchpad resolves them so after a package update it will not pick up the new versions because it’s still looking at the old path.

• error messages are about as readable as the ones you get for C++ templates

Unfortunately true, yeah. I also think this isn’t really a problem that can be solved due to Nix being a dynamically typed language that has everything be an expression (so there’s no fixed structure whatsoever) and also using lazy evaluation everywhere. Three components that all decrease the capability for useful error messages and debugging, and together… yeah it can get pretty bad.

• a lot of troubleshooting searches to unsolved GitHub issues

Really? This hasn’t been my experience at all. There’s a couple like that, sure, like the build sandbox on Mac, but they’re rare. And usually people in the community channel know a workaround :^)

Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.

apt install foo && apt remove foo

That’s essentially what nix-shell -p does. Not a special feature of nix, just nix’s way of doing the above.

Actually using it though is pretty convenient; it disappears on its own when I exit the shell. I used it just the other day with nix-shell -p ventoy to install ventoy onto an ssd, I may not need that program again for years. Just used it with audible-cli to download my library and strip the DRM with ffmpeg. Probably won’t be needing that for a while either.

The other thing to keep in mind is that since Nix is meant to be declarative, everything goes in a config file, which screams semi-permenant. Having to do that with ventoy and audible-cli would just be pretty inconvenient. That’s why it exists; due to how Nix is, you need a subcommand for temporary one-off operations.

Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.

The last time I used it, I needed arandr just to create a layout with a new monitor. Why would I install it, use it, remove it, and then auto remove the leftovers when I can just run a single line to use it once and forget about it? My old installs were littered with random crap like that that I’ve used once and forgot to remove.

The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup).

Here’s the last time I used it: I needed to compile some rust binary but I don’t have rust or cargo installed. Since the repo has a nix flake, I was able to clone it, cd into the directory, run “nix develop”, and start compiling. Much easier than having to find and install all of the compile time dependencies, and then remove them a minute later.

Besides that, there’s a reason why python has different 20 venv packages: they’re all crap. Nix is a better alternative and leaves you with a single dependency for every OS.

Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.

Declarative package management definitely has it’s benefits, and nix has been growing in that space ever since they’ve added the option to generate docker images from nixos configs. It’s not meant to replace docker, just to give you an option to create finely tuned base images.

GUI app shortcuts work in neither of the OSs

Home-manager on Debian: no manual set up was required.

error messages are about as readable as the ones you get for C++ templates

They can get overly long, but perfectly raadable if you start from the bottom.

All in all nix seems like a pretty concept but not too practical at the moment.

Nixos sure, but with nix I get the same bleeding edge userland packages on Debian and whatever else I’m running at the time. It’s just a list of packages, but it makes life so much easier.

Virtualenvs for everything that don’t duplicate resources and are reproducible.

Nixpkgs: the official nix repository

Nix shell: only creates a venv with extra packages

Nix develop: full environment configuration on top of nix shell, so you can for example set up project specific envars

Besides that, nix can also work for regular userland packages as an:

• imperative package manager (same style as apt install)

• declarative package manager (you make a list of packages, nix/home-manager ensures they’re installed)

The selling point for me is that I can just write a list of packages, and have the bleeding edge versions installed on top of Debian. I can git that list and have all of my packages available on every device, no matter the os or distro.

For development, yeah you’re supposed to use it like that, as opposed to installing dependencies systemwide. I don’t think you can even really do that on NixOS.

However, it has nothing to do with security though, but rather dependency isolation, so you can use one version of library X for one project and another for the other without them conflicting.