[adamtulinius]

We migrated from Debian+Ansible to NixOS to easier be able to ensure consistency across servers. Rolling back and forth is really easy for most things.

It's also the most convenient system I ever worked with for creating custom packages, which is lucky, because NixOS does have fewer pages compared to other distributions.

[pxc]

To supplement and illustrate your claim about NixOS being easy to package for, I'd like to share an example:

I've been using NixOS more or less exclusively for ~2.5 years now. Whenever I want to run software on NixOS which is not already in Nixpkgs, I package it (if I want it bad enough). This week, for example, I packaged KSmoothDock so that I could try it out.

This is the whole thing:

    { mkDerivation, lib, fetchFromGitHub
    , cmake, extra-cmake-modules
    , plasma-framework, kwindowsystem }:

    let
      version = "5.9";
    in

    mkDerivation {
      name = "ksmoothdock-${version}";
      src = (fetchFromGitHub {
        owner = "dangvd";
        repo = "ksmoothdock";
        rev = "v${version}";
        sha256 = "1fbghyd079xk4q5na8msna5zkfg85c4ksyfqy524v2pm96dyl2dr";
      } + "/src");

      nativeBuildInputs = [
        cmake
        extra-cmake-modules
      ];

      buildInputs = [
        plasma-framework
        kwindowsystem
      ];

      postPatch = ''
        substituteInPlace CMakeLists.txt \
          --replace /usr/share/ share/
      '';

    }

It didn't feel like much work and I think it only took a few minutes. In this case, I was able to base the package definition on another 3rd-party dock for Plasma, so it was even easier than usual to get started. I just copied the other package and changed the package name and location of the source code, and everything worked. I then cleaned up by consulting the README for the project and removing as many extraneous dependencies as possible, and smoothed over a quirk, which was pretty painless.

Once you get a feel for the docs (and the Nixpkgs source, just because it's a treasure trove of examples), packaging for/with Nixpkgs is usually pretty easy, and the results pretty readable.

I should also add that the range of packages already included also seems to me to have improved a great deal over the years that I've been using NixOS. And I think once NixOS gains support for Snap packages and Flatpaks (the latter is in the works and has been making good progress recently), it will become a much more viable desktop OS for those unwilling or unable to deal with packaging the odd missing application.

[buovjaga]

> NixOS does have fewer packages compared to other distributions

It's not bad, though: https://repology.org/repository/nix_stable

Haskell and R packages will be added soon to give a more complete picture.

[adamtulinius]

You're right, it's not bad, but chances are one will need to do a bit of packaging work if using NixOS for many different or complicated things.

But as I said, it's all in all really nice to work with Nix.

[hollerith]

>It's also the most convenient system I ever worked with for creating custom packages

Is Arch Build System one of the systems you've ever worked with? (I found ABS very convenient.)

[Nullabillity]

Coming from Arch I love NixOS for two reasons:

- No separate AUR that some packages are arbitrarily located in

- Not having to care about binary packages: they are just transparently downloaded and used if available

Pacaur makes the AUR a bit more palatable, but you still notice the split.

[adamtulinius]

Nope, I haven't. Last time I ran Arch as my personal OS, a normal update bricked the system after a week. :P

My experience is mostly with deb and rpm before Nix.

[majewsky]

When was that? I think I had stuff like this when first looking into Arch ~8 years ago. It's now been my daily driver for about 6 years, and I haven't had my system bricked. I have had a few updates that broke stuff, which could be solved through a downgrade, but no bricking.

So maybe the Arch maintainers got more disciplined, or maybe I just got better at not breaking things. Probably both.

[paride5745]

You really do not want to use Arch for production, enterprise systems.

[hollerith]

OK, but I still want an answer to my question -- to help me decide what distro to choose for personal use.

(I already get that the design of NixOS prevents the system's ending up in an incoherent state, which will happen on Arch eventually if you wait long enough between upgrades.)

[vertex-four]

I've developed packages for ABS before, and it's nice. What nix's model gets you is (a) largely avoiding complex bash scripts, and (b) a pile of tools for working with packages that you don't want to install semi-irreversibly. nix-shell, for example, will put you in a shell inside the build environment, and you can run the build steps yourself and see what the outcomes are. nix-build will build a piece of software and create a symlink to the output, but not install it into your user's package namespace.

One of the nice things is that you can install many things without having to sudo - the build is run by a daemon and sandboxed. nix-shell can also be used to create a shell in which a given package set is installed - you can use that to use a piece of software as a one-off or create a development environment that doesn't pollute your general system. Tools like home-manager[0] can help with managing your home directory in a similar way to NixOS's management of your system, too - I have redis and postgres installed using home-manager to run as my own user on demand under systemctl.

[0] https://github.com/rycee/home-manager