Half a presentation I had in my company about NixOS

home page

Heh, no, as much as I am flattered, it certainly lacks the home-page grade polish. Though if anyone gets to making a video introduction course marketing NixOS to newcomers, I could help with the writing part.

all hail the new red-flake linux (maybe next year)

Pff, you wish. But if 30 more people know NixOS exists that can’t be bad.

“A shiny transparent mineral with the highest hardness in the world”. Diamonds are hard, describing them isn’t.

And NixOS is a Linux distro. Neither describing nor even scientifically defining diamonds should be hard, explaining what’s the deal with them is.

1 Like

“Diamonds are minerals” (correct, but not enough)

Here’s how I would elevator-pitch NixOS:

“A Linux distro with reproducible package builds and easy rollbacks”.

(There’s other features, but you don’t want to obscure what’s important)

1 Like

You can watch the recording to find out why I wouldn’t take either of these properties as an explanation of NixOS. This or take Debian and install that apt hook that creates btrfs snapshots of / on every transaction. =)

1 Like

Sometimes I put Nix talks on for background noise or to settle down at the end of the day, as a way of keeping an eye on how and where Nix is received in the wider tech community. I’ve seen a lot of intro-to-Nix talks. This is one of my absolute favorites. :smiley:

I’ve been daydreaming lately about how if NixOS could sustain LTS releases, it would allow for a nice workstation OS with escape hatches, kind of similar to Fedora Silverblue. You could link each LTS release into a location like /lts/1.0, or into a bunch of directories like /usr/1.0, /lib/1.0, etc. The versions of libraries in an LTS are supposed to be ABI compatible and have identical behavior across updates, so users could link against and refer to paths in those locations ‘from outside the Nix world’ without running into trouble. SIlverblue has Flatpak as an escape hatch, but a similar system built around Nix would also naturally have Nixpkgs (which is nice because Flatpak is a little heavyweight, Flathub doesn’t contain many (any?) CLI utilities, and sandboxing is unnatural for a lot of common CLI utilities).

This would be really nice for allowing Nix-at-your-own-pace, like users get on macOS and non-NixOS Linux, on top of a base system built and managed like NixOS. It would confer the additional advantage of allowing multiple versions of the stable base system to be installed side-by-side, which might be interesting to companies like Red Hat and their customers as a way of easing transitions between major releases.

There’s also another possibility with such a system, probably of little interest to Acolytes of The Nix Way™ like us, of ports systems that target individual stable releases as their base systems. For people who just want a stable OS that works (and may or may not be interested in functional-style package management) and enjoy a clear separation between the base system and user software, like you get on macOS or *BSD, this could be a real benefit. What some people like about Homebrew or MacPorts or Pkgsrc is that they’re ‘simple’ to use (in a familiar, imperative way), and packages are not isolated, but those systems don’t (or try not to) affect the base OS, and if they misbehave you can easily blast them away entirely. One of the pains users of such ports systems go through is that they can break and/or require lots of rebuilding when the base system is upgraded. With a base system based on stabilized/long-lived releases of Nixpkgs, much of that breakage could be ameliorated. At the same time, the isolation that Nix packages have would help immunize the base system against meddling by those kinds of ports systems, even when the base OS relies on a runtime (say, Python) that users of ports systems might want to manage via those ports systems. Immutable root filesystems that still rely on the FHS, like current applications of OSTree, are cool, but they don’t share that virtue.

The missing piece for all this, of course, is a (probably smaller) fork of Nixpkgs with long-lived branches where stable releases of software get backported security patches.

Maybe it’ll never happen, but imo applying Nix or a deeply Nix-like approach to distros with long-lived releases like RHEL would allow for some really cool downstream possibilities.


This doesn’t make Debian reproducible. And isn’t btrfs still a bit unstable?

Agreed, that doesn’t make Debian reproducible in the NixOS meaning of it (not even close) and btrfs could have better data recovery and raid stability. Yet my point was that you’ve specifically picked “reproducible builds” and “easy rollbacks”, two qualities of NixOS that just don’t add up to NixOS. So you can’t just give these two to my audience of that day and expect them to arrive at NixOS and not Debian with snapshots. =(


I like that Nix leaves rollbacks open no matter what filesystem you use.

I think btrfs is pretty good these days, though with the only remaining stability concern being the RAID 5 write hole. On NixOS, OS files (the contents of /nix/store) are protected from partial writes in two ways:

  1. Switching to a new config is an atomic filesystem operation, since it’s a symlink change; even if there is a partial write due to a power outage, the partial write wil
  2. Nix provides tools good tools for verifying and repairing the contents of the Nix store

I’ve actually lost power during a nixos-rebuild switch. My Nix DB was corrupted (I just rm’d it and then everything was fine), but every single program on the system was in working order. And you get this on a system that, unlike OSTree, doesn’t strictly require a reboot for any update to take effect.

So there is a way forward from that conversation about how NixOS brings you different benefits and even protects you from some kinds of filesystem corruption no matter what filesystem you use (my power loss during upgrade was on ext4). But the way forward is a rabbithole, and layer after layer of ‘but it’s more than that! here’s an example’ doesn’t still doesn’t necessarily provide a compelling overview in the end.

Looks like there’s already some awareness of/interest in NixOS on the OSTree side. Do you have any idea how many Nixers there are at Red Hat, or how many people there are interested in experimenting with NixOS or a functional package management approach?

how many Nixers there are at Red Hat

A handful, which is less than I’d love to see.

how many people there are interested in experimenting with NixOS or a functional package management approach?

IDK, that’s pretty general. Hopefully more now then last week? I was presenting mostly to my peers from the Linux Security crowd though.

1 Like

How would Debian with snapshots achieve reproducible builds?

Debian’s effort to achieve reproducible builds is orthogonal.

1 Like

4chan’s /g/ is arguing about NixOS all the time (If you don’t know what it is, don’t google and click on it willy-nilly – it’s pretty NSFW)

I’m looking forward to the day Debian is fully reproducible and has rollbacks.

A few more thoughts about how some of the distro maintenance work carried out by companies like Red Hat and related features might be nice in the Nix world:

  • ABI stability may not matter for packages in Nixpkgs, but it would be nice for using Nix to generate or otherwise supply runtimes for third-party software
  • sometimes end users want stability of behavior, so they don’t want to be confronted with the latest changes to the KDE or GNOME user interface every few months or whatever. In that case, maintaining older viersions provides some value for them
  • It’s true that Nixpkgs neatly elides the need for complex dependency solvers and version constraints internally, but when you are working outside Nixpkgs (i.e., on a personal or company project), often you want to pin a specific version of that package but you are essentially forced to think about versions of Nixpkgs. This has led to the creation of things like the Nix package versions search tool, and the sophisticated machinery in the mach-nix Python packaging tool that searches through past copies of Nixpkgs to find versions of Python packages satisfying given constraints. It would be nice for there to be some standardized tooling for this, even if Nixpkgs doesn’t need it, imo.
    • it might also just make things a bit neater and more unified when we do occasionally need more than one version of a package in Nixpkgs. Maybe we’d end up with version constraints in the relatively low-stakes way that they appear in other source-based package management systems like Portage and Pkgsrc
    • this is still different from the universal reliance on version constraints to navigate global package namespaces in binary package management systems like RPM!
1 Like

I don’t think /g/ represents the tech community so much as posters who see what operating system or other software they use as a basis for identity formation, or just making jokes. More than just NSFW, I find the kind of discussion that happens on /g/ to be extremely shallow. That’s why presentations at tech companies and the discussions surrounding such presentations are much more interesting to me.

True. But anonymity has its benefits. People are more willing to criticize things.

Very enjoying talk. You’re an entertaining presenter. I especially enjoyed the part where you got upset at how easy the filesystem configuration was. I vaguely recall feeling that way when I was looking into NixOS years ago … “they must be glossing over the details because it can’t be that easy!” :grinning_face_with_smiling_eyes:


Thanks, your comment also made me recall my epic struggle to run Nix on Android. My usual road to figuring out the.thing.I.wanted = myWay; isn’t a walk in the park or even a rollercoaster ride, but a single sudden abrupt freefall. Sometimes I’m not even at my PC at that moment! Wonder if it’s just me or a recurring problem with Nixers. Can the lack of the steady problem-solving progress mess up dopamine release regulation? =)