> possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity

In the end, I think all distributions ends up with similar layers of abstractions and complexity, mostly regarding packaging, but sometimes also other components.

What I've found when using NixOS compared to Arch, is that if I screw up my Arch installation I either need to sacrifice my time to try to fix the screw up (which sometimes adds spending time just learning/reading about some concept I don't know about) or I need to recover from backups, so I can get back to work.

With NixOS screw ups, I simply choose the previous version on boot and I'm "recovered". Leads to me getting back to what I was doing faster, but missing the opportunity to learn my own personal stack better. But not every moment needs to be "understand everything 100%", which in Arch-land, tends to happen, otherwise you continue to screw up.

Although I'm still on the fence of upgrading to NixOS because the OS as an concept + it's own language is still not easy to learn, especially for more advanced usage, it's getting closer each day to just dump Arch and start using NixOS full time. Mostly because the reproducible nature of the OS.

One of the advantages is that packages just works on the contrary of the AUR where I had lots of problems for lots of packages that wouldn't just not build or work.

last major issue I had was when everything moved from /bin to /usr/bin.

One recent example was me trying out KDE Plasma. Usually I use AwesomeVM but the HN thread about the new Plasma version made me try it out in Arch. After the install and trying to use it for a while, I wanted to go back.

Uninstalling the package(s) is not enough, as it already has been overwriting bunch of stuff and changed configs that are not being rolled back after uninstalling.

Still to this day KRunner launches (via some d-bus command or something like that) when I do my Super+R shortcut, which usually runs the AwesomeVM launcher, not KRunner. Haven't figured out how to get rid of it yet, but got other stuff to do right now, so simply living with it for now.

With NixOS, I'd just reboot and select the previous version where KDE Plasma was never installed.

Another fun related feature: NixOS really only requires /nix and /boot to boot. So, some of us just nuke everything except /nix, /boot, and /home on boot:

https://grahamc.com/blog/erase-your-darlings

The problem was: in the AUR, lots of packages didn't built or launch, and even in the official repos, some packages were missing libraries or just not having the right versions.

I was tired of tinkering to get everything to work as I wanted.

I used Arch for a while before NixOS. Another problem I encountered with the AUR is that, since the AUR is not built as a single consistent system with Arch itself, often packages from AUR would start failing because some library was upgraded in Arch and the newer version was ABI-incompatible with the version that the AUR package was compiled with.

Why is partitioning not part of a config file, but done at installation?

The config file has this line:

  imports = [ ./hardware-configuration.nix ];

  fileSystems."/" =
  { device = "/dev/disk/by-uuid/14b5b22f-6cd2-4da5-a9a5-6ee74b76509d";
    fsType = "ext4";
  };

  fileSystems."/boot" =
  { device = "/dev/disk/by-uuid/7D69-81E5";
    fsType = "vfat";
  };

For the initial installation you actually have to set up the partitions and mounts inside the root filesystem manually similar to what you have to do to install Arch.

Then you run the install command. The install command sets up the system with a default (or customized) configuration and also generates the hardware-configuration.nix file so that it matches the root filesystem you have set up before running the install command.

All help is welcomed :).

The configuration.nix system configuration can be moved between systems, but imports a generated hardware-configuration.nix that really should not be moved between systems.

If you don't want user and system specific configuration to intermix by having user-specific software in your system configuration and you want to manage you the dotfiles in your home directory in the style of Nix there is another popular project called home-manager which enables that, but that's totally optional.

Having used NixOS for more than a week, I have the same but opposite feeling. If you don't mind the hyperbole, NixOS is a solution, Salt and similar as a substitute is duct tape. :)

Therefore Chef (they other tools are equivalent in my view) is IMHO not a good enough tool to manage dev environments.

I agree, but your and my definition of “good enough” is not the same as everyone else’s. These tools wouldn’t be as heavily used if folks didn’t feel they solved a problem they had.

Update: trying to install the same package in different versions at the same time is also a pain.

I perceive nix as a tool that removes a layer of abstraction and complexity - the FHS. Having an app working is easy. Having multiple apps share the same FHS is complex because of conflicting requirements. Without FHS, there is no shared dependency resource thus no conflicts. Multiple applications are just as easy as a single application.

I see NixOS as an easy way to re-install easily my system when I get a new machine or just to sync easily packages between my laptop and desktop (so they almost have the same things installed on them).

As for servers, I don't really see the point of nix as usually, pre-made and preinstalled images are already deployed. I think I'll still stick with Debian and all the usual software such as Docker for this usage.

As a result, working with docker images often needs special privileges which leads to complex situations involving docker-in-docker etc., which just shouldn't be necessary.

But it's also reached for as a solution for a whole heap of other things which are much better done in other ways.

I have not found this at all tbh.

And I've actually found the discoverability of the tricks used in nixpkgs to be pretty amazing. Sure the manual could always do with being more thorough (indeed it's always getting better), but again, in comparison, the quantity of stuff understandable from just reading the contents of nixpkgs and knowing basically one language is huge.

I compare it to a lot of the other systems I work with where just to decipher relatively simple setups people have created I have to understand cryptic combinations of terraform, Dockerfiles, bash, helm, github workflows, concourse pipelines, puppet/chef/ansible/..., travis.yml, Brewfiles... each of which being weirdly arbitrarily restricted and inevitably needing to call in yet another tool to fill in the gaps in their capabilities.