Linux

Another NixOS user (and minor package maintainer, if it matters) here. Essentially, NixOS is actually rather simple to write a configuration file for a particular program once you get the knack for the nix language and learn how to workaround the sandboxing. I would actually consider it substantially less involved as compared to (for instance) creating your own Debian package.

However, getting to this point will take a bit of effort, and this step is more or less obligatory to use software on NixOS, whereas it generally isn't (but still is a good idea) on other distributions.

(There is a learning curve to packaging stuff yourself.)

"Learning curve" is an understatement. Nix is one of the most poorly documented projects I've seen, next to openstack. Coming into it with no background in functional programming didn't help.

Maybe I shouldn't have tried to package openstack on nix.

But I've tried to package other stuff, like quarto, and that was a nightmare. Nixpkgs didn't have an updated pandoc and I spent an eternity asking around for help, to try to package it. An updated version just got pushed to unstable a few days ago. The same matrix channels I joined to ask for help have been discussing this since then. Props on them for getting it working, but anyone who says that you can easily package anything, is capping. You need to have an understanding of the nix language, nix packaging (both of which are poorly documented), and a rudimentary packaging ecosystem of what you are trying to package.

Don't even get me started on flakes vs nonflakes.

I still use nix-shell for all my development environments, because it's the best way for reproducible environments I can share I've found.

The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you're working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don't accidentally use features from after boost 1.61 for project A, because that's the stated requirement, but you need features from boost 1.75 in project B.

In a normal distribution, in order to set up an environment that has the proper version for project A you'd need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.

In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there's even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It's like a better version of venv, but for everything.

Well, for playing games I use the flatpak version of steam and it works OK.

For dev work, it's great overall. Especially its ability to create separate reproducible environments with whatever dependencies you need for every project. However, there are some tools (rare, but they exist) that don't work well with it, and if your dev work happens to need them, it can becomes a problem.

For day to day (i.e. web browsing), it works the same as anything, with one disadvantage: there is a disadvantage here: it downloads a lot more than other distros on update, and uses more disk space. The biggest difference between NixOS, and say Arch, is not how it behaves once it's up and running, but in how you configure it. Specifically, you have to invest a lot of time to learn how, and set up your system initially. But then reinstalls, and (some of) the maintenance, become easier.

It’s the probably the best distro for dev work imo. Nix in general is really nice for development. Games work fine — you can just install steam or putrid or whatever, and you can run normal binaries with steam-run.

To clarify, I was referring specifically to its ability to specify the full system configuration in its config file - not overall. But I haven't used blendos, and my impression is mostly from a quick look at their documentation. They have a snippet with sample configuration. There, they have a "Modules" section, but I couldn't find what modules are available, what options they have, how to configure them if we want to do something more complex than the available options.

Then containers are clearer: they have a list of installed apps, and then commands to bring them to the desired state (somewhat similar to a dockerfile). But even then, i imagine that if you have a more complex configuration, that's going to get clunkier.