[HN Gopher] I stopped using NixOS and went back to Arch Linux
___________________________________________________________________
I stopped using NixOS and went back to Arch Linux
Author : birdculture
Score : 24 points
Date : 2026-03-11 18:20 UTC (4 hours ago)
(HTM) web link (developic.dpdns.org)
(TXT) w3m dump (developic.dpdns.org)
| lobofta wrote:
| The sad thing about this read is that none of the criticisms are
| necessarily leveled as Nix as a system, but are purely about how
| the ecosystem is managed.
| the_real_cher wrote:
| Counterpoint, I have been using Nix for several months and have
| no problems.
|
| I use LLM's ALOT for the config file which is in a custom nix
| DSL. I couldn't imagine how long it would take before LLM's.
|
| But with an LLM I'm pretty happy with nix.
| dangus wrote:
| Everything I've heard about NixOS...well, it sucks. Sorry.
|
| The ideas behind it are interesting. The reality of living with
| it, the benefits are basically minimal/none and you have to learn
| a whole big thing that isn't applicable anywhere else.
|
| In the container era it makes even less sense.
| joshmoody24 wrote:
| I've been using NixOS for the last year and have loved it.
| Rebuilding doesn't fail for me nearly as often as it does for the
| author. Running nix garbage collection frequently isn't a big
| deal and can easily be automated. The network usage is a fair
| point. But IMO a small price to pay for keeping all of my devices
| perfectly in sync and running into weird "works on my machine"
| issues way less frequently.
| craftkiller wrote:
| My rebuilds fail all the time, but that's self-inflicted. I
| build my whole system from source with the nix binary cache
| disabled and optimizations for my processor enabled, so it
| seems like every update I have multiple failures which range
| from transient issues like GNU's savannah being down to
| persistent issues like software suddenly not compiling with
| `-march znver4`.
|
| Reading the blog, they complain about compile times, which
| makes me wonder if their issues are similarly self-inflicted.
| The average user shouldn't need to compile software due to the
| nix binary cache. So they must have been either modifying
| packages or enabling optimizations.
| hurricanepootis wrote:
| I wish Arch could learn some lessons from NixOS packaging. One
| thing that really bothers me about Arch is how many pain points
| there are in the packaging tooling. Furthermore, I wish AUR
| packagers used utilities like namcap and chroot building to check
| their packages before pushing their slop onto the AUR; whenever I
| use new software from the AUR, I check the PKGBUILD to see how
| well it was made.
| k_g_b_ wrote:
| Compared to other Linux distribution's package tooling Arch's
| is pretty nice and painless, I think.
|
| Agreed with namcap/chroot - I think there should be even more
| mandatory checks on pushing stuff to AUR. But even so -
| regarding your last point: you absolutely need to check all
| PKGBUILDs from AUR or potentially get malware.
|
| https://bertptrs.nl/2026/01/30/how-to-review-an-aur-package....
| is a nice recent article by one of the maintainers that follows
| up on last year's AUR malware.
|
| The final point sums it up, though: the AUR was built without
| the security mechanisms - technical and social - we want and
| need today.
| nbf_1995 wrote:
| I think this is a mostly fair criticism of nixos. Nixos has a lot
| of powerful tools, but if you don't need them, they can get in
| the way. Some assorted notes:
|
| > unless you run nix-collect-garbage periodically
| nix.gc.automatic = true; nix.gc.options = "--delete-
| older-than 10d";
|
| > the constant cycle of rebuild - fix - rebuild - fix - rebuild
|
| I've found this useful to eliminate the rebuild loop:
| https://kokada.dev/blog/quick-bits-realise-nix-symlinks/ It lets
| you make the config of the program you choose a regular mutable
| file instead of a symlink so you can quickly iterate and test
| changes.
|
| > In contrast, Arch Linux simply downloads prebuilt binaries via
| pacman or an AUR helper
|
| _If_ a binary exists. A lot of AUR packages I used to rely on
| didn 't have a binary package (or the binary package was out of
| date) and would have to build from source. On nixos my machines
| are set up to use distributed builds
| (https://wiki.nixos.org/wiki/Distributed_build). Packages that do
| need built from source get built on my server downstairs. The
| server also runs a reverse proxy cache so I only need to download
| packages once per version.
|
| Distributed AUR builds _are_ possible on arch, but they require a
| lot of setup and are still fragile like regular AUR builds, your
| only choice of dependencies are what 's currently available in
| the repos.
|
| > On my machine, regular maintenance updates without proper
| caching easily take 4-5+ hours
|
| It sounds like the author may be running the unstable release
| channel and/or using some heavy unstable packages. Which might
| explain a lot of other problems the author is having too.
|
| Back when I used arch, I found that as time went on, my system
| would sort of accumulate packages. I would install $package, then
| in the next version of $package a dependency would be added on
| $dep. When I updated, $dep would be installed, then eventually
| $package would drop the dependency on $dep, but $dep would remain
| installed. I would periodically have to run pacman -R $(pacman
| -Qtqd | tr '\n' ' ') to clear out packages that were no longer
| required.
| craftkiller wrote:
| > When the new configuration finally builds, more ofen than not
| some component randomly stops working after reboot
|
| Good thing you're using NixOS where rolling back to a working
| version is as simple as a reboot, instead of Arch Linux where
| your options are: 1. If it's a boot issue, dig
| out a live USB for recovery 2. If it's a package, try
| rolling back piecemeal by installing old versions from
| /var/cache/pacman 3. Once rolling back piecemeal breaks
| your system more because of the mixing of package versions, pin
| your packages to a specific day in the arch rollback machine and
| pray your whole system downgrades cleanly
|
| I used to live that life. After a couple failed downgrades I
| started exclusively using the arch rollback machine for my work
| machine so nothing would update and break before I had a chance
| to test the updates on my personal machine.
|
| > Huge update sizes
|
| Yeah, the optimize store option to replace duplicate files with
| hardlinks really should be a default, and automatic nix garbage
| collection should probably be put in the initial automatically-
| generated config so new users are aware of it. Also `nix-collect-
| garbage -d` behaving differently from `sudo nix-collect-garbage
| -d` despite being a trusted-users was quite the surprise.
|
| I used to be able to brush this off by "storage is cheap" but AI
| has driven up the cost of SSDs.
|
| > In contrast, Arch Linux simply downloads prebuilt binaries via
| pacman or an AUR helper
|
| That is also the case on nix. If you are compiling software
| yourself, then you must have changed some settings to cause it to
| build from source, which is not even an option on Arch Linux. Nix
| having the completely optional ability to customize your packages
| is a positive, not a flaw.
|
| > why not use Gentoo Linux instead
|
| On nix my entire system is defined in my nix config, including
| all my settings, all my scripts, and all my packages. I use
| impermanence to wipe my disk on every boot except for the a
| handful of folders that I tell it to preserve across boots. The
| combination of those two creates a deterministic system. Nix is
| so much more than just being able to compile your software.
| MadVikingGod wrote:
| While I too love the promise of Nix, I never was able to handle
| the configuration of nix. And at this point I've given up on it.
|
| What I wonder is if there is a medium between Nix's build
| everything from the ground up, and the traditional get everything
| delivered. I've been excited about the Fedora Atomic collections,
| silverblue etc., as it gives me a lot of the roll back and
| isolation of nix with the workflow closer to a regular fedora or
| arch. I'm not saying that everything is roses, but I've been able
| to use it more than I ever got out of a nix.
___________________________________________________________________
(page generated 2026-03-11 23:01 UTC)