Hacker News Reader

Comment by traceroute66 | Hacker News Reader

Honestly, I have to say I'm in two minds about NixOS.

Conceptually its a great idea, but I'm a bit worried about the possibility of all-mighty failures caused by adding the extra layer of abstraction and complexity. Its a bit like messing around with the buzz-word-of-the-day Kubernetes compared to just getting the job done with a good old fashioned VM.

Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS.

Also, sometimes its nice to have the warm fuzzy feeling of using a software vendor's supported package build on a supported OS (e.g I'd rather run a package from the official Postgres repo then mess around getting Postgres working on NixOS).

View on HN

I'm running NixOS in a VM, trying to evaluate if it's worth switching from Arch to NixOS before making the leap.

> 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.

I too was using Arch before and a friend convinced me to do the leap and I don't really regret it.

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.

how do you break Arch so bad these days?

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

Keep trying out new things, new things don't work as I want so I wanna go back to how things were and have to manually "rollback" stuff (see deleting files, changing configs). Also managed to screw up the bootloader and partitions on more than one time. I'm not gonna pretend I'm an expert, I just want a simple system, which Arch really is. But sometimes too simple, requires a lot of reading and understanding, which is usually not a problem, but sometimes it is.

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.

I feel like the problems you're citing (inability to simply roll back, etc.) aren't really Arch problems specifically—you'd have them in any traditional distro (like Debian) too, right?

Oh yes, absolutely, I'd surely screw up equally often if I was using Debian, Ubuntu, Fedora or any other distribution, if not more. I was just comparing Arch to NixOS as Arch is my daily driver, while I'm evaluating the switch to NixOS.

I even "DE hopped" using NixOS, trying out 3+ different DEs for fun, and once I was done I just had to revert to an older generation, no nasty leftovers.

I use NixOS unstable on my desktop/work machine, but when I just started using NixOS, I even regularly hopped between the latest stable release and unstable.

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 issue wasn't the system broke, in fact, my system was doing pretty much alright.

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.

The problem was: in the AUR, lots of packages didn't built or launch,

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.

Out of curiosity what do you think of how Arch and NixOS compare to Debian or Ubuntu? (I'm asking to help me calibrate against what you're saying since I've used all of these except NixOS.)

Imho, Arch is a similar style to Debian/Ubuntu but different package manager and slightly different semantics in a few places. NixOS is radically different and if you can make it work for you, you’ll likely be much happier after the learning curve. If however your needs are just outside the norms enough, NixOS could also just as well be very frustrating. It’s one of those things you’ve gotta try and invest a reasonable amount of time in, which might not pay off, but if it does, could pay off big (or so the marketing pitch goes).

Thanks!

Something I don't really understand coming from arch, how am I supposed to handle the system installation?

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

I have used NixOS only for a year so I'm no expert but I try to answer.

The config file has this line:

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

This file hardware-configuration.nix is typically generated semi-automatically during the installation. It has stuff like

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

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

AFAIK you can include these details in configuration.nix if you happen to know them. But most of the time these are so hardware-specific details that you don't want to write them manually. Does it make sense?

That's an accurate description. I just want to add some info how the install process ifself works so people get a better picture of it.

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.

There is something called nixpart: https://github.com/NixOS/nixpart but it's very immature as per as https://github.com/NixOS/nixpkgs/pull/21403

All help is welcomed :).

My understanding of it that you really want to have two different configurations, one that is system/hardware specific and one that is "user" specific. So let's say I have a desktop + laptop I want to run NixOS with, I'd want the hardware config to be different on them, but with the same user-land config. Hence the installation config is usually automatically setup at installation time, and then the user config is put in place.

This is about right but let me clarify a bit.

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.

> Given solutions like Salt are around that can manage reproducible builds anyway (in conjunction with PXE installs), I see limited applications for NixOS.

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. :)

Salt/Chef/Puppet/Ansible/etc are generally “good enough” tools and work for many needs, but over time cruft will inevitably happen (unless you frequently start from a clean base image). NixOS tries to avoid that by making it difficult to accidentally do a one-off outside your tooling and/or install things that unintentionally (or intentionally) stomp on other installed things in your system.

I used to manage the development environments of several hundred developers using Chef. It kind of worked, but would not very well support configuring files in the users home directory for example. Also setting up services locally needed for development (RabbitMQ, Tomcat etc) became much easier with Docker. I switched to Docker for that purpose, and most of the chef scripts became unnecessary. What the nixos package manager can easily solve is managing configuration files in the users-home (using home-manager), as well as installing different versions of different tools at the same time. You can even go as far as using direnv to automatically provide the tools (jdk, nodejs, gradle etc) when entering a given project just checked out from git.

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

> 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.

They used to solve some problems in a way that was good enough at that time. Nowadays setting up services, where you have to take care of avoiding port conflicts, is much easier with container technology. Modifying config files in the users directory is in my experience a pain because chef was not designed to do that. You have to do all kind of workarounds to get permissions right. Just using Chef for abstracting from which package manager you use also does not fully work because package names can be different between Linux flavors. Chef also requires a ruby installation, which itself is a problematic large dependency which might conflict with another ruby version on the system.

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

Having worked with these tools, in comparison Salt/Chef/Puppet/Ansible are a collection of footcannons wrapped in the guise of a solution. The entire idea of trying to manage a fleet of stateful OS installations and stay on top of it all once it gains the slightest hint of complexity is a fallacy.

> failures caused by adding the extra layer of abstraction and complexity

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.

Yup!

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.

It's a shame to me how docker has come to be seen as "the usual software", as it's really just another layer of duck tape which uses OS features to pretend that arbitrary build processes are "reproducible" (when actually the way most Dockerfiles are written, they are most certainly not).

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.

Docker’s build process sucks, but that’s not the point of Docker—the point is that it’s a standard image format for containers which allows for orchestrators like Kubernetes to exist without caring about the internal details of any given container (e.g., what language it uses). It does pretty well in that regard, and you can even use Nix to build Docker images. Nix’s value proposition is reproducible builds, and while it does reproducibly build software, writing those definitions is incredibly hard (though the difficulty varies widely from package to package).

No, I absolutely acknowledge the value of a "docker image" as, essentially, an interchange format.

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

Unfortunately today there aren’t many better options. Building images with Nix is great in theory (as Nix in general is great in theory), but it implies packaging one’s own app with Nix which is an enormous burden in most cases. There are other projects emerging that give us better image build systems than Docker, but none are well-tested at this point such that their tradeoffs are understood. This is a real pain point in the ecosystem, and it will be interesting to see how it resolves.

> packaging one’s own app with Nix which is an enormous burden in most cases

I have not found this at all tbh.

I’ve tried this personally, and we attempted it as a team professionally and in both cases the juice was deemed not worth the squeeze. In particular, we were constantly packaging low-level transitive dependencies for C projects, and ultimately you had to not only know how to build your own package, but also any package for your entire dependency tree. If your dependency tree doesn’t involve any C dependencies (or if Nix definitions already exist for them) then you probably won’t run into so many issues (which is likely to be the case for Go, Haskell, etc—languages that don’t have a heavy emphasis on C dependencies and probably those that can be statically linked) but for Python, Node, etc you will probably have problems. None of this is to speak about the dearth of documentation or the difficulty using nixpkgs as a reference.

I tend to find unmet dependencies to be an opportunity to package that dependency and upstream it. Even keeping the package private in situations where that's not appropriate feels like less work than the alternative of manual management.

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.

Reply on news.ycombinator.com