Hacker News Reader

Comment by eeh | Hacker News Reader

As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.

NixOS is great for:

* shortening the divide between the user and upstream: not just release lag, but also the ability to contribute to upstream. NixOS makes it trivial to write a patch and deploy it your system, something I wouldn't usually bother with Debian, for example, because the same process was so frictionful.

* configuring services

* packaging ad-hoc code/scripts

View on HN

> As a keen NixOS user/contributor, if your only needs are i3 and Firefox, then I do not recommend NixOS to you. ~Any distribution can meet your needs.

I really disagree with this. NixOS is also great for simple use cases like this because it's robust. I know a lot of people who switched to Linux, need to get something to work, follow some online tutorial/directions blindly, and just break shit pretty badly.

This isn't contrived: even seemingly-inoculous commands like "pacman -Sy" on Manjaro/Arch can fuck your shit up (it basically amounts to a partial upgrade).

NixOS doesn't let you break shit like this. (Literally, upgrades are atomic and packages can never have missing dependencies.) And, even if somehow you did, you then have a nice configuration.nix to quickly get back up to speed.

Sure, but Debian/Ubuntu/Fedora all provide great experiences for "I just want some packages installed".

Fedora nowadays has btrfs-level rollbacks, which although this doesn't interact well with cfgmgmt (unlike NixOS's excellent rollback support), it's perfectly fine for an end user.

Unfortunately I have to disagree.

I tried to setup a simple NixOS machine this week. From this experience I couldn't manage to install any GNOME extensions via the browser plugin because of some Firefox manifest location that conflicts with the way the NixOS store handles it - there is some workaround in some tickets, but it made me wonder how many other applications are in need for specific workarounds. I then enabled flatpak via the OS configuration, but the first installed app couldn't launch because of some obscure error with gstreamer. I changed to fedora and could setup anything without any of those issues.

I really want to like NixOS (I still do), but I now consider it more for a server environment than a casual desktop environment.

You can use NixOS on the desktop -- it has a lot of benefit (including atomic upgrades/rollbacks). But it only really works well if you manage everything through Nix. Other mechanisms such as the ones that you mention tend to break very often.

I just gave up using Flatpaks with NixOS and install GNOME extensions through Nix.

This is a benefit, but other distributions are catching up. For example, Fedora Silverblue has an immutable root filesystem and provides atomic upgrades/rollbacks through OSTree. Ubuntu 20.04 supports making ZFS snapshots as an APT pre-installation hook and thus also support rollbacks.

And don't forget OpenSUSE, which has been making btrfs snapshots before and after every upgrade for years(?) now. OpenSUSE doesn't seem to ever get the recognition it deserves.

Patching your Debian is not hard: http://beza1e1.tuxen.de/articles/ubuntu_itch_scratch.html

No, but it's cumbersome.

Let's say your patch doesn't get in in time for Terminator 0.96 (following the same example), or it's not relevant for upstreaming. Now you need to go through the same process again to upgrade. So much for `apt-get upgrade`. And it gets even worse if your change breaks binary compatibility: now you need to find and rebuild all packages that depend on it too!

The beauty of NixOS here is that you patch the "repository" instead, so will get applied on top of the current version as long as the patch applies cleanly. And all of Nix's usual logic applies for rebuilding dependendees as required.

The steps in that blog post aren't difficult, but it doesn't include all the steps and assumptions:

* how do you roll that dpkg out to your fleet? Now you need a deb archive?

* "For Debian the tool is called reportbug". Note that reportbug is a CLI tool to send an email to Debian's bug tracker, whose status/tags are then also controlled by control emails. It has a notoriously difficult learning curve.

* Many Debian packages expect patches via email, rather than the more familiar git-based approaches. Some Debian packages do accept patches via git, I'm aware. Hopefully the package you're filing a patch against does.

* The blog post also misses out the work the Debian package maintainer has to do: use their own approach (and there are multiple) for doing a package release/signing. NixOS? It's a PR that's built by CI. Like how we usually handle software systems.

* You've patched a single version. What happens when a new package is released but your patch didn't make it in?

IME, after years of using Debian I made a few but barely any patches against Debian because of the frictions involved. The frictionless experience of NixOS has made me more active.

Reply on news.ycombinator.com