
NixOS 19.09 - trulyrandom
https://nixos.org/nixos/manual/release-notes.html#sec-release-19.09
======
Mathnerd314
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.

~~~
trulyrandom
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.

~~~
aseipp
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...

~~~
delroth
> 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!).

------
FRidh
The release announcement on Discourse:
[https://discourse.nixos.org/t/nixos-19-09-release/4306](https://discourse.nixos.org/t/nixos-19-09-release/4306)

------
danharaj
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 :^)

~~~
equalunique
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.

~~~
Shoue
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.

------
sn
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...](https://github.com/prgmrcom/prgmr-image-
source/commit/aaa8cc9191a09b919970435a1014133a4cc576c9#diff-
ca4dbb1b337305513751f4ecdc3714a7) This is a bug conceptually similar to
[https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=932416](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](https://github.com/NixOS/nixpkgs) ?

~~~
zimbatm
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.

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

~~~
tathougies
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.

~~~
socksy
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.

~~~
takeda
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 ];
      });

~~~
socksy
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.

