Live data from Hacker News

I stopped using NixOS and went back to Arch Linux

developic.dpdns.org

21–30 of 30 posts

Re: I stopped using NixOS and went back to Arch Linux

#21
post #15

It's unfair to act like NixOS just breaks "randomly" or is inherently unreliable It's essentially deterministic and fully reproducible. Issues with Bluetooth, electron etc as described are essentially irrelevant to NixOS and have to do with your configuration

It's possible I have no idea what I'm talking about, but my understanding is that nixos relies on fetching things from third party URLs which may simply die. I feel a bit misled by the promises of nixos, because I cannot actually take the configuration files in 10 years and setup the system again due to link rot. I was also under the impression that I could install DE's side by side on nixos and not have things like…

Every system and package manager will be affected if it cannot download source code to build a package.

NixOS less so, because pretty much all source downloads that are not restricted by license are a separate output that will therefore be stored on (and downloadable from) NixOS cache servers.

I'm not sure what your expectation for this is in general, nobody can just wish into existence data that is just gone.

Re: I stopped using NixOS and went back to Arch Linux

#22
post #15

It's unfair to act like NixOS just breaks "randomly" or is inherently unreliable It's essentially deterministic and fully reproducible. Issues with Bluetooth, electron etc as described are essentially irrelevant to NixOS and have to do with your configuration

It's possible I have no idea what I'm talking about, but my understanding is that nixos relies on fetching things from third party URLs which may simply die. I feel a bit misled by the promises of nixos, because I cannot actually take the configuration files in 10 years and setup the system again due to link rot. I was also under the impression that I could install DE's side by side on nixos and not have things like…

> NixOS is very impressive but the marketing around it feels misleading. The reproducible claim needs a giant asterisk due to link rot.

It's a valid concern, though perhaps worth mentioning you will be able to restore your 10-year old config as long as the files downloaded from now-broken links are still in the Nix cache. Of course in practice, this is only useful to large organizations that have resources to invest in bespoke infrastructure to ensure supply chain integrity, since any `nix store gc` run will immediately wipe all downloads :(

Re: I stopped using NixOS and went back to Arch Linux

#23

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

>Good thing you're using NixOS where rolling back to a working version is as simple as a reboot, instead of Arch

I feel like Nix user always leave out that you can simply use a filesystem with snapshots like btrfs or ZFS and gain the same resilience against possible breakage and even beyond just update issues.

Re: I stopped using NixOS and went back to Arch Linux

#24

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

>Good thing you're using NixOS where rolling back to a working version is as simple as a reboot, instead of Arch I feel like Nix user always leave out that you can simply use a filesystem with snapshots like btrfs or ZFS and gain the same resilience against possible breakage and even beyond just update issues.

Yeah if my arch breaks, i just reboot into a snapshot. It's not a problem, really.

Re: I stopped using NixOS and went back to Arch Linux

#25

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

>Good thing you're using NixOS where rolling back to a working version is as simple as a reboot, instead of Arch I feel like Nix user always leave out that you can simply use a filesystem with snapshots like btrfs or ZFS and gain the same resilience against possible breakage and even beyond just update issues.

So I do run ZFS with automatic snapshots through zrepl, but I think a shortcoming of relying on that on Arch Linux is your user data. If the issue is immediately apparent after an update, then you absolutely can just roll back and be fine. But if it takes you a week before you discover something isn't working, then rolling back isn't as straight-forward because you're potentially losing any modification to your files made in the past week. You could partially mitigate this by storing your $HOME on a separate dataset, but not everything ends up in $HOME (for example, everything related to docker, your secureboot stuff, your bluetooth pairings, your wifi networks, lvfs, journald, your systemd timer statefiles)

On NixOS my user files are completely separate from my programs/system files. I can roll one back without impacting the other. This is further guaranteed by impermanence which wipes my disk on every boot except for the folders I specify should be preserved, all of which end up storing their data under a separate ZFS dataset through bind mounts. So programs/system files are read-only under /nix and my user data is under /persist and bind-mounted to wherever I need them. So I am 100% certain that none of my user data is comingled in the same dataset as my programs/system files.

Re: I stopped using NixOS and went back to Arch Linux

#26
post #8

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/…

In using your server as a proxy cache, do you just include the server as a nix cache substitutor, or simply use a MITM approach using something like squid proxy?

If the former, via substitutor (or if also using a remote builder), how do you manage when moving portable clients outside your LAN? E.g. traveling with your laptop? Do you tunnel back home, have a toggle to change substitutor priorities?

I find it the default timeout for unresponsive substituters excessively long, as well as the repeated retries for each requested derivation annoying, rather than it recalling and skipping unresponsive substituters for subsequent derivations in the same nix switch/build invocation.

Re: I stopped using NixOS and went back to Arch Linux

#27
post #26
post #8

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/…

In using your server as a proxy cache, do you just include the server as a nix cache substitutor, or simply use a MITM approach using something like squid proxy? If the former, via substitutor (or if also using a remote builder), how do you manage when moving portable clients outside your LAN? E.g. traveling with your laptop? Do you tunnel back home, have a toggle to change substitutor priorities? I find it the defau…

The server is configured as a caching reverse proxy (just nginx with cache.nixos.org as upstream) which I think is similar to squid proxy.

Outside my LAN I do have the ability to tunnel home, but depending on the connection and the updates I just deal with the timeouts, or just wait until I get home.

I think technically you can override substituters using cli options but its not ideal. There are several proposals for configuring timeouts per substituter but none of them are merged yet.

Re: I stopped using NixOS and went back to Arch Linux

#28

Earlier quoted context omitted.

>Good thing you're using NixOS where rolling back to a working version is as simple as a reboot, instead of Arch I feel like Nix user always leave out that you can simply use a filesystem with snapshots like btrfs or ZFS and gain the same resilience against possible breakage and even beyond just update issues.

So I do run ZFS with automatic snapshots through zrepl, but I think a shortcoming of relying on that on Arch Linux is your user data. If the issue is immediately apparent after an update, then you absolutely can just roll back and be fine. But if it takes you a week before you discover something isn't working, then rolling back isn't as straight-forward because you're potentially losing any modification to your files…

Its true that with datasets there can be edge cases like /etc/ but the overwhelming majority of issues are apparent on first boot, anything else can be separately backuped up for a rollback or just fixed with troubleshooting.

Re: I stopped using NixOS and went back to Arch Linux

#29
post #15

It's unfair to act like NixOS just breaks "randomly" or is inherently unreliable It's essentially deterministic and fully reproducible. Issues with Bluetooth, electron etc as described are essentially irrelevant to NixOS and have to do with your configuration

It's possible I have no idea what I'm talking about, but my understanding is that nixos relies on fetching things from third party URLs which may simply die. I feel a bit misled by the promises of nixos, because I cannot actually take the configuration files in 10 years and setup the system again due to link rot. I was also under the impression that I could install DE's side by side on nixos and not have things like…

> I installed KDE, and then installed Sway and Sway overwrote the notification theming for KDE.

That sounds like you are using the nixpkgs modules to install the desktop environments (programs.sway.enable) rather than only installing the packages (environment.systemPackages = [pkgs.sway];). Both are valid, but there is a key difference:

The packages themselves cannot cause such conflicts because each package is just a separate folder under /nix/store. Nixpkgs modules both install the package _and_ configure additional settings which means that modules can interact with each other and possibly cause conflicts.

You can see it in the source for nixpkgs. This config block is applied whenever programs.sway.enable is true: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

It installs the sway package here: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

But it also edits other settings like adding sway to the display manager session packages list: https://github.com/NixOS/nixpkgs/blob/0590cd39f728e129122770...

What surprises/confuses me is: sway doesn't have notifications. You have to install your own (personally I use mako). So I'm wondering if this was a much greater change like system-wide gtk/qt theming, or did you also set up a notification daemon for sway and perhaps it was the module for _that_ which altered your KDE notifications.

(Just to be clear: I believe you that your notifications looked different, I'm just wondering about the mechanism through which they were altered.)

Personally, I don't like surprises so for 90+% of my config, I only install the packages (environment.systemPackages) rather than using the modules (programs.sway.enable) but that does mean I am essentially re-inventing the module for each package inside my own config which is a lot more work and requires a lot more nix proficiency.

Re: I stopped using NixOS and went back to Arch Linux

#30

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.

Back when I used arch, I would use aurutils which has a flag for building the packages in a chroot. It won't prevent bad PKGBUILDs from being written, but at least they'll fail to build on your machine! aurutils was also nice since it creates a regular pacman repo, so you end up installing the final built packages the same way you install any other package.
Post reply on HN