I use NixOS on a server and it is wonderful there where my needs are basic and on the well worn path.
But there's no chance I would want it on my development machine. Even something as simple as installing a python package that isn't in the main repo doesn't have a straightforward solution. There are half a dozen different approaches people take, almost none of them well documented. And most of them involve writing 50 lines of esoteric nix, your own derivation, or a complicated flake (which everyone says to use, but there isn't good documentation). Maybe it is great for those on the inside, but from the outside it looks like a disaster. And that's the last thing I want to deal with when I need a package installed to get my work done.
The main issue I had while using NixOS is that it has a small and somewhat broken set of packages. This is compounded by the very incomplete Nix documentation - its way too hard to create new packages.
NixOS is great in many ways, but it’s really quite difficult to use. Anything that requires use of the command line is a no-go for everyone but hardcore enthusiasts. Even I, who have contributed to Nixpkgs, wish I could just stick to a GUI sometimes. Not to mention how NixOS breaks assumptions software has about your computer and therefore makes development much more difficult than it really needs to be.
While I agree with most of your comment and am writing this on my NixOS desktop, installing is a breeze only if you don't want to encrypt your root partition or don't want to use it on a macbook or something that mature OS'es usually do quite nicely out of the box.
I have my bookmarked set of gists to guide me through these things and it took me days to get it right the first time.
Also nixpkgs are a bit of a mess, you usually get a version of a package someone has bothered creating a PR for. This might be very old or bleeding edge. For specific versions you can be SoL. It is of course fairly easy to have your own .nix of the package and PR's are usually accepted quickly but the repo usually doesn't keep previous versions.
And then there is a whole world of pain regarding language specific packages. Python is especially painful for me.
It took me ages to find the page which hints at nix-shelling projects but this is a pita and requires a completely new workspace setup that is not compatible with people that don't use Nix.
Regardless I love NixOS, but to say this is perfect, not even close.
I can see how it would be a good system for ruby or python packages, or a docker replacement.
But it seems it isn't able to blindly mirror stuff from pip, for example? Or to just package any linux under the sun, like Docker can? You'd have to have a nix-specific version of every package you want to use.
And then, the first time you hit upon a package it doesn't have, you have to develop and maintain your own version of it (as far as I understand?). This sounds like a lot of work for someone who wants packages to just work, so they can focus on other things.
I remember using freebsd at some point. The annoyance of not being able to just grab a deb from random sites and install them far outweighted any benefits I got from a cleaner OS organization and some extra features. Nix feels the same way.
I am not saying nix is a bad idea or that it'd have no benefit. Just that, for non-enthusiasts and non-early adopters like myself, it's dead in the water until there is some major support behind it.
I use NixOS daily, and the rough areas now are mostly lack of really thorough documentation and dealing with software that is not packaged for Nix and has an unclean way of getting built. It's surprising how many pieces of software have hardcoded paths to e.g. Python binaries.
My temporary fix for the latter is using a Docker with Arch for quick and dirty one-time things.
I, like many other NixOS users, fully understand your sentiments. Let me explain why I stick with it and use it in all of my computers.
First off, I have a quite special environment for work. I like to customize many aspects of my desktop, and having my environments on other machines to work similarly is a tedious task, especially when having more than two computers you use daily. NixOS solves this issue very well.
What makes it hard is how docs are not that great for Nix or NixOS. What all of us have to do is to read other people's dotfiles and the nixpkgs monorepo to understand how things work and what can you do with it. It is extremely hard in the beginning, even for people like me with over 20 years of Linux experience. It took me about six months to finally being able to get it.
There are some new terms you hear when you first start using NixOS. One is flakes, that is very vague and academic at first, but when you understand what it does it is almost as hard to go back to Nix without them as it is for seasoned NixOS user to go back to using other operating systems. With flakes, you have two files:
- `flake.nix` lists inputs, such as git repositories, of nix build instructions for fetching packages and functions to your system.
- `flake.lock` is like your normal `Cargo.lock` that sets the exact commits of all inputs, frozing the versions of all software in your system.
This means I can mix things really nicely in my system. I can use the master branch of Sway, the pgtk version of Emacs with Wayland support from the emacs version control (not even master branch) and mix and match things from different NixOS versions. I can even fork the NixOS monorepo, do some changes and add them to all of my systems before the my PR gets merged.
The `flake.lock`, which I commit to my repository, forces every single computer I have to use exactly these versions of the software with the configuration I give. It will always lead to the exact same result when I `nixos-rebuild switch`. When I want to update my packages, I go to the repo and say `nix flake update`, then switch to the new versions and only if everything worked with the new packages, I commit the `flake.lock` and it works everywhere else the same.
The other nice thing I learned, is while at first the nixpkgs feels like a crazy mess and hard to grasp, it is actually one of the best package repositories I've used. Being a package maintainer is easy and a PR that follows good coding standards gets merged to the main repository no matter how experienced Nix developer you are. See my first package I started to maintain:
These 23 lines of nix will fetch the package with the given tag from GitHub, check the file download SHA256 sum matches the given, check the vendored libraries SHA256 sum matches the given and then will just use the system `buildGoModule` function to compile the package and put it to your system. When their CI catches changes here, it will build a binary cache for the derivation, so most users won't even need to compile anything, but get a binary derivation with exactly the same result as compiling it by themselves.
And it's easy to see what gets added to your system. You can see the repo and read the code. You can use your editor, go on top of `buildGoModule` call and jump to definition, and you can read the definition what the function does. Now some users are running bots that just go through many packages in the nix repo, change the versions and SHA sums if they have updates and automatically generate pull requests, saving the maintainers the work to do it manually.
I understand this is not for everyone. But I hope I also could make you understand why there is no way of going back to systems like Arch Linux, Ubuntu, Windows or macOS after getting some proper taste how to do things with NixOS.
Well nixos is really great if your package and options are already thought through by the maintainers, although you might have to read through nixpkgs for options. It's more painful if you need X compiled with Y enabled and it needs to rebuild (might be slow on vps), and if your package isn't included at all, it can be a pain to add a new one and get all the dependencies included.
Once it works though, it basically never breaks - you can always pick an older working version.
Oh and it eats disk space like there's no tomorrow if you have multiple generations retained.
I actually dropped NixOS after using it for 2 years. It's just not practical for day to day work unless you want to be messing around with Nix config or fighting shared lib issues all the time. I'm using OpenSUSE atm and couldn't be happier - yeah it's a lot more click ops, but I get to work so much faster and everything just works. Fedora is another good option. (If you want to know, the breaking point for me was trying to get QtCreator working properly on NixOS which I sunk about 2 hours into before giving up - but took me about 5 mins on OpenSUSE to install).
Nix, the package manager, is _amazing_ though, despite the wonky language. I use it for providing hermetic/reproducible environments for my dev projects. You create a shell.nix, auto load it with direnv, and the development environment is 100% replicated for everyone doing dev in that repo. Hook it into your CI too and now you have an identical dev environment everywhere. It's like virtualenv on steroids for any kind of project/tooling.
You're missing out. Nix is a fantastic package manager with features that apt (and similar) simply do not have. NixOS is not perfect yet, but it's very usable, and quickly improving.
I'm not sure NixOS users are that different from users of other distros, all want a tool that properly manages their systems (rather than random packages being scattered everywhere).
I love Nix and NixOS personally... but it's been a tough sell at work, unfortunately.
Even with simple shell scripts... it's so easy to invoke programs with GNU extensions and later find they fail on a co-workers macos machine. And I often have a shell.nix sitting right there that defines the complete dependency closure; very frustrating to not be able to use it.
This probably goes against the flow, but I tried NixOS on a VPS and I found the tools to be inscrutable. Was so confused about Nix packaging and whether to use Flakes.
I'm not saying it solves every problem for everyone, but have you looked at Nix? I've found it to be great for portability (at least on other Linux distros), and you can easily install anything from stable nixpkgs packages to Git repos. I'm currently using it to manage OS packages and development dependencies for some of the projects I work with (a couple at Work™).
I strongly disagree. Creating a Nix package is significantly easier than creating, e.g.: an Arch package, from my experience. packageOverrides is really nice too.
Yes. I switched from Ubuntu to NixOS ~18 months ago. I am so much happier with NixOS than ubuntu. Its the easiest packaging system I've used where you can easily mix and match stable and unstable packages without worrying about a huge mess of dependencies. I also find myself much more empowered to upgrade packages for security patches myself since I know that I can add an overlay to update the package and everything will just build.
And yet... there's so much I just don't understand. Doing simple overlays is relatively easy, but anything of moderate complexity really becomes frustrating.
It makes it quite difficult to recommend NixOS when the chasm between being able to use it vs being able to understand it is so wide.
I've tried using Nix a few times. The idea is in principle not bad, but the actual deployment for, say... an API endpoint? Horrendous.
Problems include:
1. Scripts deployed almost never appeal to /usr/bin/env, they tend to hardwire interpreters to /bin/sh. This flat out doesn't work in NixOS, and the Nix team is ideologically opposed to maintaining a compat layer for specific cases like this.
2. Compiled binaries are compiled to this SPECIFIC version of Nix. That may not seem like a bad thing, but the reality is that it's very abusive to work with. Your binaries cannot even be invoked becuase they cannot find their links (including, you know, the C bootstrapping lib). This means you can make an executable on your dev box, try and push it to prod, and because prod doesn't have something like a dtrace library the entire system is incompatible with your executable.
3. There are tools to assist with these problems, because they're so common. However, they themselves are full of edge cases they don't solve for that they're very hit-or-miss. While this isn't bad in and of itself, it tends to make the established userbase very unsympathetic and often very formulaic when you approach them with more subtle linking issues. This can be quite frustrating.
I found the entire system somewhat unworkable. I also feel like Docker or Rocket solves a lot of the practical problems I have there, despite protestations. Container images are perfectly reproducible, but also easy to update. They also tend not to rip themselves apart if you, in a moment of intellectual weakness, give a slightly confusing order to the nixos package manager and rip your system in half.
But there's no chance I would want it on my development machine. Even something as simple as installing a python package that isn't in the main repo doesn't have a straightforward solution. There are half a dozen different approaches people take, almost none of them well documented. And most of them involve writing 50 lines of esoteric nix, your own derivation, or a complicated flake (which everyone says to use, but there isn't good documentation). Maybe it is great for those on the inside, but from the outside it looks like a disaster. And that's the last thing I want to deal with when I need a package installed to get my work done.
reply