NixOS 19.09 | Hacker News Reader

NixOS 19.09

nixos.org

145 pointstrulyrandom25 comments

My experience is that the rolling "NixOS unstable" channel is more usable. The releases don't offer any improvement in security and have less maintenance effort overall. And despite the name "unstable", the breaking changes typically incubate in the staging branch first for a few months.

But that's using it on a desktop, maybe on a server releases are more useful.

I've used it on servers, its handy but the install process is pretty weak compared to some other OSes. A lot of the drivers were pretty behind so custom builds had to be made.

Nix on Ubuntu was pretty useful, I tried Nix on FreeBSD but was disappointed.

Two or three weeks ago I switched from Ubuntu to NixOS. I love it now -- but the first few days were rocky.

The first few times I installed it, once it was installed I could not connect to a network. Eventually I determined I could add these to `environment.systemPackages.pkgs`: ``` networkmanager plasma-nm ```

I also ran into a permissions issue -- when I migrated my data from Ubuntu I couldn't access most of it. I still have Ubuntu at work so I have to be able to move between the two. The solution was to discover that the default user id NixOS is 1001, whereas the default in Ubuntu is 1000. Adding this to config nearly solved that:

``` # User accounts. # Don't forget to set a password with ‘passwd’. users.users.jeff = { uid = 1000; # for compatibility with Ubuntu isNormalUser = true; extraGroups = [ "docker" "wheel" # for sudo "networkmanager" # for the plasma-nm widget, and # the privilege of changing settings (adding networks) "audio" ]; }; ```

I say nearly because NixOS won't let you change uid (at least via `configuration.nix`) for an existing user. I had to log in as root, delete the user, rebuild, reboot, then add the user with the options I needed, rebuild, and finally reboot again.

And between those two problems came the problem of trying to use MusNix as a channel (for apps to make music). I followed the instructions on MusNix's README.md and totally broke my system. I found an issue on MusNix's issue tracker with the same complaint, and the response was "are you using an old version of Nix?" But I was using 19.03, which at that time was the latest version. My system told me I had conflicting hardware configurations (some supposed-to-be-unique value was set in multiple places to distinct values), and it wouldn't let me rebuild until I fixed that, and I had no idea how, so I just reinstalled. (Later in that issue the solution seemed to be, "Don't use it as a channel, even though the README says you can.")

But each reinstall was much easier than the last, because (unlike Ubuntu or anything else I've ever used) you don't have to repeat the same set of actions each time. Instead your config script gets more complicated, and you just copy that into the new system, and it handles the rest.

There are still a few tweaks I do by hand, out of ignorance -- I set some KDE options manually, and ... hmm, maybe that's all. But I've read that even those can be copied from one system to another; they just require some digging, as they're scattered around rather than contained in a single place like you might expect.

Interesting. I was not aware of the staging branch. I thought that patches are always merged into master and then automatically trickle down to unstable once all of the integration tests pass.

How often do you find yourself performing a rollback? I've always stuck to the stable channel, but I may give unstable a shot if it doesn't break too often, as you say.

That was how it worked in the past, but it becomes frustrating because some changes result in many, many package rebuilds which hold up everyone else, or otherwise drains resources of the CI system, which would be better spent building existing packages. Staging is generally where changes that result in mass rebuilds go (or may introduce large instability) in order to keep the main branch "up to date".

Changes that are backwards incompatible (but do not result in mass rebuilds) can and will often just go to master directly. For example, NixOS module changes rarely result in mass rebuilds, even if it breaks an API -- but changing the default kernel version does. The latter would go to staging.

I exclusively use the unstable branch on all my Nix/NixOS machines. I rarely do rollbacks. But it's important to note that I'm a developer with commit access, so I can basically "just" fix things if they're problematic. Not everyone has that luxury. (Many Linux distro maintainers likely operate this way, I guess. :)

There have been events in the past where unstable has had changes that made rollback impossible. In particular, if the bootloader becomes unstable somehow, your rollback capabilities are toast (and you won't know until you reboot, when it's too late). But I don't think anything like that has happened in a long time...

Thanks for the detailed explanation. Sounds like I'll have to give unstable a shot soon.

> I exclusively use the unstable branch on all my Nix/NixOS machines. I rarely do rollbacks. But it's important to note that I'm a developer with commit access, so I can basically "just" fix things if they're problematic. Not everyone has that luxury. (Many Linux distro maintainers likely operate this way, I guess. :)

An important thing with NixOS is that since the whole distro is built from a monorepo, it's also very easy for an advanced user to just git clone and fix the problematic things too (and hopefully send a pull request!).

I would recommend anyone using NixOS in production to use the release versions. That's what I do on my servers..

Like for other distros, the point of releases is that they don't upgrade random software under your feet, resulting in unplanned behaviour changes and unplanned required maintenance.

Like for other distros, release channels get important upgrades and minor bugfix releases of upstream software.

NixOS releases are every 6 months, so that's frequent enough to have pretty up-to-date software most of the time. NixOS also makes it very easy to cherry-pick fixes from master and make custom changes (it's just a /git cherry-pick/ away), allowing to selectively upgrade things that you need for your use case.

The release announcement on Discourse: https://discourse.nixos.org/t/nixos-19-09-release/4306

There's usually something broken on my computer when I bump to a brand new release of NixOS, but I've never had rollbacks fail to recover from that. Then I just have to wait a few weeks before I try again :^)

Thats the magic of NixOS basically.

I've used a handfull of OSes regularly and I worked somewhere that used the Nix package manager, its pretty neat in a land of broken everything (most Linux distributions)!

Huh? All modern distris are very stable. Hadn't had problems with arch, Debian, Ubuntu it freebsd for years.

Not really, one mistake installing a package and you can have everything break. This is basically why containers/Docker and things like virtualenv exist.

I've had that break config files in $HOME in the past, but it's nothing ZFS can't deal with.

My experience is the same. Rollbacks never fail. Upgrades often break my desktop environment. Maybe I should just stop using GNOME, since KDE seems to be the better supported "fat" desktop environment. Not sure if cobbling together some kind of i3wm-type environment would simplify things or result in just another kind of fragile complication.

Can't really figure out why GNOME stopped working for me after 18.03. Wish there was some kind of guide/tool for validating that my configuration.nix was still sane with newer versions.

I remember GNOME support was spotty when I used it two years ago. I returned this year to NixOS 18.09 just before 19.03's release and GNOME's been solid throughout, and I'm using 19.09 now.

We rebuilt our netboot installer but we had to disable all but one of the consoles due to a race condition: https://github.com/prgmrcom/prgmr-image-source/commit/aaa8cc... This is a bug conceptually similar to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932416 Does anyone know offhand which nixos component we should file a bug against? Is it https://github.com/NixOS/nixpkgs ?

Yes, can you create an issue there with the details and CC me? ( @zimbatm ). I haven't worked on netboot but can point you towards the right people.

I see the list of "backward incompatibilities" is huge. Does this distro require a lot of maintenance compared to, say, Gentoo stable?

No. Nix requires much less maintenance than gentoo. The maintenance it does require is typically very fast. Gentoo builds everything from source and portage is not immutable the way Nix is. My experience running Gentoo (and I ran it during the GCC 3 -> 4 upgrade, which required a full emerge world) is that updates cane be slow, and prone to breakage, due to missing or clashing or outdated dependencies.

Nix is a dream come true. Due to the way the nix store keeps all dependencies separate and reproduces builds to a high fidelity, when you do need to build a system package (very rare, as most are just downloaded straight out of a binary cache), it will invariably succeed with few exceptions, and the resulting binaries will work correctly.

But the best part about nix vs portage is that it won't leave your system in a half way state. Upgrading NixOS means downloading or building a bunch of packages. This can be interrupted at anytime. At no point during the download or build will the old system become unusable. Nothing in the old system is overwritten. At the time you have everything built and are ready to change, the change occurs atomically and instantly. If the new system does not work, you can revert back to the old system atomically and instantly as well. In the rare case that the new system has made your computer unstable, you can reboot the system back into the old version without the need for a rescue CD or USB stick.

+1. It's been years since I used Gentoo, but I felt like it broke me, or required some sort of intervention once a month. Arch was much better, more like once every few months. So far Nix has not broken anything for me in a year of use.

OTOH, if you're like me, and want to update to get a new version of one package (and its dependency tree), it's a very common experience to find out that some completely unrelated option has changed in some backwards compatibility breaking way such that I never had to deal with when I ran Arch Linux.

You can use nix-env -i of course, but then you have a duplicate package (that can be out of sync and easy to forget about) and this doesn't work for anything with a systemd service.

I like that I can't really fuck up my NixOS installation, but I actively dread updating (although it's got a lot better in the last year). I'd love a NixOS alternative that took backwards compatibility a lot more seriously.

One of strengths and at the same weaknesses of Nix is that it is not very opinionated. That means there are many ways of doing the same thing. I'm wondering how were you backporting a new package.

For example pgbouncer version that was used was a bit older than I wanted, I was easily able to update the derivation and also enable c-ares name resolution by overriding the derivation like this:

  pgbouncer = pkgs.pgbouncer.overrideAttrs (oldAttrs: rec {
    name = "pgbouncer-${version}";
    version = "1.11.0";

    src = pkgs.fetchurl {
      url = "https://pgbouncer.github.io/downloads/files/${version}/${name}.tar.gz";
      sha256 = "0w3y53kwnkcm9fmf28zbjvqk6ivfic5f2k3nflvca1i8iaj2z044";
    };

    buildInputs = with pkgs; oldAttrs.buildInputs ++ [ pkg-config c-ares ];
  });

I'm not even talking about backporting, rather updating to the latest version in NixOS unstable means running nixos-rebuild switch --upgrade... And this often seems to fail due to non-backwards compatible changes. Sure, it happens more on unstable, but the software in stable is often too far out of date or worse, broken (e.g. by the download link expiring).

Updating the package is typically a means to an end—this month I had to upgrade emacs due to a melpa package update, and python due to a work script requiring 3.7.3—the last thing I want to be doing is maintaining my general system. Even writing an override feels a bit ridiculous (it's right there in the channel!).

What I inevitably end up updating my nix-env channels and using nix-env -i to install the new package. This works most of the time, but the insidious thing is that I usually forget that I even have this dynamically installed package, and never update it. That is, until it breaks my system in some subtle way.

So yeah, if something came out with all the benefits of NixOS (and I love the nix package manager, the safety it provides, and the pure functional declaration of all the dependency trees), but with the respect for not breaking backwards compatibility that you see in functional programming communities like Clojure, then I would be in love.

Reply on news.ycombinator.com