[diggan]

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.

[jaemoe]

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.

[eepp]

how do you break Arch so bad these days?

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

[diggan]

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.

[mehrdadn]

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?

[diggan]

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.

[siraben]

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.

[microtonal]

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

[jaemoe]

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.

[microtonal]

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.

[mehrdadn]

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

[jsjohnst]

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

[mehrdadn]

Thanks!

[smallpipe]

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?

[knlje]

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?

[mschwaig]

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.

[RaitoBezarius]

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

[diggan]

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.

[mschwaig]

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.