Three Years of Nix and NixOS: The Good, the Bad, and the Ugly
Three Years of Nix and NixOS: The Good, the Bad, and the Ugly
A review of Nix/NixOS after using it on all my machines for three years. I'll cover what works, what doesn't, and why it's the first OS that's stuck with me.Pierre Zemb's Blog
like this
Irdial
in reply to ikidd • • •traches
in reply to ikidd • • •Flipper
in reply to traches • • •atzanteol
in reply to Flipper • • •Phoenix3875
in reply to traches • • •OhVenus_Baby
in reply to Phoenix3875 • • •Cyberwolf
in reply to OhVenus_Baby • • •OhVenus_Baby
in reply to Cyberwolf • • •So what the main hassle of switching is that you have to run your hardware file to update for your new hardware, then inside your Nix config rarely will I ever have to edit things (maybe UUIDS if totally new machine fresh nix install/but I usually ssd swap for ease of transition and speed, or even clonezilla multiple drives and use as needed) even drivers for example. I've got auto scripts setup to run that will automatically pull any drivers or updates from the base system nix update to any drivers.
There's really only two files you ever have to touch that I've used. Nix hardware, nix config. Once hardware is updated for which system you on you'll never touch that until you boot a new machine with different hardware. If you setup nix how it's supposed to be. Nix config is your master file. A single backup of that and when setup correctly. I can boot like I never left my machine. I'm talking librewolf still has my accounts open and logged in. VPN works. It's all seamless damn near.
You have to learn to play within nixos sandbox meaning understand what your capable of doing and do it all inside config. With a few auto scripts, and 3 or 4 common commands on desktop page for whatever you wanna do and its terminal and memory hands off. I've what I call dumb Monkey commented my entire config and its in order if boot process from power on machine to boot, etc to shutdown.
A regular distro still poses many many more challenges when hardware swapping. You have different files to remember fstab, etc etc which can lead to mental memory load and system clutter if you didn't build and maintain a perfect system from the beginning with stuff like files, sym links, all sorts if tweaks you've made over time.
So I switched to nix to mitigate those things. Now I've made a master config file copy, auto updates, backups, etc is all automated in the background now. All contained in my nix config. It's supremely stable. Mental load is zero. Fills my use case. Immutable.
You have nothing to lose and only to gain. Pick any desktop environment and setup to your liking. I came from windows, to mint, to full custom nix all my apps, browsers, luks, apparmour, firejail, the whole stack.
I've tried live boots of many other distributions but this is the cleanest, leanest, most manageable of them all. My only true concern is project lasting long-term. For now. Aside from not having GUFW. I'm happy. I think there's just a lot if misinfo and lack of hands on use from most people or incorrectly setup systems to utilize how nix should be ran. I think that should iron out over time.
iopq
in reply to Cyberwolf • • •msherburn33
in reply to Cyberwolf • • •nixos-rebuild build --target-host "user@host"
and it works across different architectures too (e.g. build on your fast x86 machine and deploy to a slow RaspberryPi).feddup
in reply to traches • • •iopq
in reply to feddup • • •feddup
in reply to iopq • • •Ephera
in reply to traches • • •I feel like setting up a new machine is just the easiest to explain.
Personally, I find dotfiles messy, as you often just want to change one or two settings, but you always carry along the whole file with all kinds of irrelevant other settings. This also makes it impractical to diff two versions of those dotfiles, especially when programs write semi-permanent settings into there.
I guess, your mileage will vary depending on what programs or desktop environment you use.
For example, I love KDE, but they really don't do a good job keeping the config files clean. Nix Plasma-Manager generally fixes that, and for example allows defining the contents of the panel in a readable form.
OhVenus_Baby
in reply to Ephera • • •I think you over complicating your view here. I daily nix. Your not carrying a bunch if dot files. You have one. A single nix. Config. That's it. It's not big, long, messy, what so ever. I have mine commented by section from boot order to auto updates and backups. Your talking about 150 lines of extremely short and almost self explanatory code. I came from mint having never used nix. I figured it out doing a custom luks install and the whole custom build from scratch in no time.
Your diff issue is overblown. The edits you make are small and you cannot get lost in multiple configs unless your doing entire system writes which you would never do. I use a dead light weight diff GUI or terminal. This has to be one if the cleanest, maintenance free distros I have ever used.
It doesn't seem you have truly driven Nix with this take. No program writes directly to your config, even if there was say your temp scenario you reboot and temps would wipe away like you never did them unless you rebuild nix config. Most of your concerns would fall away once you really drove nix to see how it functions.
∞🏳️⚧️Edie [it/its, she/her, fae/faer, love/loves, null/void, des/pair, none/use name]
in reply to OhVenus_Baby • • •Ephera
in reply to OhVenus_Baby • • •OhVenus_Baby
in reply to Ephera • • •OhVenus_Baby
in reply to traches • • •I've used nixos exclusively lately. It's been awesome. No system scatter, clutter. It'd immutable. There's very slight driver hassle (you don't have GUI for drivers so a simple terminal command fetches everything you need.) in cinnamon. I came from mint. I have all basic commands in executable files on desktop for ease of hassle. It's not about rebuilding the system. Its about being hands off. Next to zero maintenance because not much in your system gets altered. I went for a full custom install from terminal. The only thing I personally miss being GUI is a firewall like UFW or GUFW.
Overall its more rock solid and workable than likely every distro I have ever tried. The feature set is nice, easy rollbacks, fucking cake backups. All you have to know is your entire system lives on one small editable file called nix. Configuration. Keep it in a micro SD or USB or any backup and it's as if you never left. Any changes you want you simply tweak in the config then reboot. If it breaks then select your previous gen number on boot and your exactly where you was before.
I diff my edits and keep copies, run auto backups, and more. It's so hands off that I haven't found a better replacement yet. My single biggest concern is long-term viability in the project.
dinckel
in reply to traches • • •This is a good example of what people consistently overlook/misunderstand, when it comes to Nix.
Obviously you can remount a /home, or just pull the dotfiles from a personal repo, but the strength of Nix is also in that I can re-create my entire config exactly how it is defined. If i were to setup a machine completely from scratch, with a mature enough config, it will get me from 0 to my exact desktop completely unattended.
But there are also many more advantages to it, at least in my eyes. Let's take trying/tweaking new packages as an example. Yesterday I pulled an old repo for an Outer Wilds mod. The thing needs a dev environment, and a mod manager for the actual game. A
nix shell
got me both, I finished my work, and when I exit out of fish, both are gone, just as I wanted them to be.Another good example would be partial os updates. I've used Arch for almost 9 years before switching to Nix, and pretty much a top3 Arch rule is not doing partial updates, or partial rollbacks. In case of a breakage, I would have to manually redownload an older version of a tarball,
pacman -U
the package, and then hope i'm not cooked. In the case of gcc incompatibilities, it can quickly become a massive pain in the ass. My nix flake would never experience this problem, because I already have two different scenarios available - either i build based on an older lockfile from my git repo, or I create an overlay for a specific input I need, so that it still pulls what it needs, and doesn't interfere with the rest of my systemiopq
in reply to traches • • •traches
in reply to iopq • • •iopq
in reply to traches • • •traches
in reply to iopq • • •Ephera
in reply to ikidd • • •Personally, the stepping stone I needed to know about is Nix Home-Manager, which basically allows you to manage your dotfiles independent of the distro. From what I understand, if I do switch to NixOS, I'll continue using this code with just some minor tweaks.
But yeah, I agree with the verdict in the post. I like it a lot, but I would not have made it past the initial learning curve, if I didn't happen to be a software engineer. Sysadmins will probably be able to figure out how to put it to use, too. But it's just not for non-technical Linux users.
OhVenus_Baby
in reply to Ephera • • •utopiah
Unknown parent • • •utopiah
in reply to ikidd • • •~/.bashrc
file (and a few others) if not just remounting/home/
in the new installation every few years.like this
gonzo-rand19 likes this.
9488fcea02a9
in reply to utopiah • • •One of my machines i've been just upgrading in place since debian 8. No need for new installation
Debian isn't barbaric at all.
like this
gonzo-rand19 likes this.
trevor (he/they)
in reply to utopiah • • •The biggest downside to containers vs. Nix for me is that Nix can produce binaries for Linux and macOS, whereas docker only helps with Linux unless you can perform literal magic to cross-compile your project on Linux for macOS.
Containers also don't give you reproducible environments, and Nix does.
That said, Nix documentation is ass, so I usually end up going with containers because they require far less suffering to get working because writing a containerfile is much easier than guessing how to hobble together a Nix flake with a mostly undocumented language.
SavvyWolf
in reply to ikidd • • •Skipped to the "ugly" part of the article and I kind of agree with the language being hard?
I think a bigger problem is that it's hard to find "best practices" because information is just scattered everywhere and search engines are terrible.
Like, the language itself is fairly simple and the tutorial is good. But it's a struggle when it comes to doing things like "how do I change the source of a package", "how do I compose two modules together" and "how do I add a repo to a flake so it's visible in my config". Most of this information comes from random discourse threads where the responder assumes you have a working knowledge of the part of the codebase they're taking about.
OhVenus_Baby
in reply to SavvyWolf • • •atzanteol
Unknown parent • • •atzanteol
in reply to trevor (he/they) • • •Of course it does. 🙄
trevor (he/they)
in reply to atzanteol • • •atzanteol
in reply to trevor (he/they) • • •But for like 99% of development teams "repeatable" is Good Enough(tm).
trevor (he/they)
in reply to atzanteol • • •So, containers do not get you reproducibility.
For dev environments, repeatable is okay. If you want actually reproducible binaries that you can ship, Nix is better fit for that purpose.
elucubra
in reply to ikidd • • •frozencow
in reply to elucubra • • •It is part of snowflakeos.org/, though I don't know about its developments atm.
GitHub - snowfallorg/nixos-conf-editor: A libadwaita/gtk4 app for editing NixOS configurations
GitHubiopq
in reply to frozencow • • •elucubra
in reply to ikidd • • •phantomwise
in reply to ikidd • • •I've been stuck on Nix for two weeks because I thought it would be a good idea to put a distro I had never used but that wouldn't break on my backup laptop in case my main one ever broke. I just couldn't force myself to install debian, not that I have anything against debian, it's just... kinda boring, while Nix seemed very interesting. IT SEEMED LIKE A GOOD IDEA AT THE TIME I SWEAR.
Guess what happened... I broke Arch. Then I reinstalled and the next day the laptop broke. Then the next day I tried to get my data back and the hard drive broke. So, backup laptop with Nix for two weeks...
But...
- It's not Arch. Not Nix's fault, but I kept hearing that it would be "like Arch but declarative"... and it's really not 😑 Everything seems over-complicated vs as simple as possible.
- I absolutely hate the language.
- What's with those error messages from hell???
- And speaking of hell, every language that can't just use indentations like YAML instead of cluttering the code with {} and [] and () should have been relegated to the darkest pit of hell 20 years ago. But points to Nix for being less awful than JSON (the comma on every line but not the last thingy make me want to build a time machine to go murder the grandparents of whoever thought it was a good idea)
- Packages are out of date even in the unstable branch (I know it's unfair since it's not trying to be a rolling release... but... but...)
- Where are the source packages? Is that an Arch only thing? I liked having packages that automatically use the latest git commit without needing to manually install from source and manually reinstall each time I want an update like a medieval peasant... 😭
- Nix packages are weird. Even someone who's terrible at coding like me can read Arch PKGBUILDS... I miss you Arch 😢
- Apps not working because of paths that don't exist on Nix... what do you mean I need to patch the package myself? 😭 But at least there's steam-run, great preserver of what's left of my sanity.
- ~~Can't wrap my head around installing some stuff like VSCode extensions (the advice I got was "don't bother just do it imperatively...)~~ (Edit: Finally figured it out!!!)
- Wiki is often sparse on info and not very helpful if you don't already know what you are doing (and I clearly don't 😅)
- Hidden configs. Some stuff works on its own like pipewire even though I haven't installed or configured it (I went with a minimal install that just gave me a tty then build from there, no DE), and how it's already configured is not in the default config files. It's very confusing not knowing why some stuff works and how it's configured by default.
But it's kinda growing on me. Like mold. Or cancer. Brain cancer.
nullpotential
in reply to phantomwise • • •phantomwise
in reply to nullpotential • • •nullpotential
in reply to phantomwise • • •phantomwise
in reply to phantomwise • • •Bluefruit
in reply to phantomwise • • •phantomwise
in reply to Bluefruit • • •eecobb
in reply to phantomwise • • •a Kendrick fan
in reply to eecobb • • •phantomwise
in reply to eecobb • • •Succinctly : "OH GOD MY EEEEEYES"
I'm not a fan of nested parenthesis... but aside from that I don't know much about the language, is it more convenient? Does it also suffer from the error messages from hell problem?
a Kendrick fan
in reply to phantomwise • • •Check out Guix_System_Distribution, it's just like NixOS but uses a Scheme dialect which is a better language.
GNU Guix transactional package manager and distribution — GNU Guix
guix.gnu.orgthedeadwalking4242
in reply to a Kendrick fan • • •msherburn33
in reply to thedeadwalking4242 • • •Having one
}
too many or too few is a pretty common issue with Nix and feels very similar to Lisp, even when the rest of the language is quite different.msherburn33
in reply to a Kendrick fan • • •While some people love putting Lisp in everything, I really don't get it. Guix is far uglier than Nix in the language department. Scheme is not a configuration language and thus has none of the nice things that Nix has (multi-line string handling, defaults, lazy evaluation, inline expression, etc.), instead you get multiple levels of macro spaghetti. Furthermore, Guix forces you to turn everything into Scheme, where you can just use plain Bash in your Nix build steps, in Guix that is all Scheme.
I had spent a lot of years with Scheme before starting with Guix and then spend quite a few years with that, but even after all that switching to Nix just felt so much better instantly. Instead of trying to hack a DSL onto of Scheme you just get a language that's actually build for the task.
SkaveRat
in reply to phantomwise • • •en.wikipedia.org/wiki/Douglas_…
American computer programmer
Contributors to Wikimedia projects (Wikimedia Foundation, Inc.)lapping6596
in reply to SkaveRat • • •phantomwise
in reply to SkaveRat • • •HayadSont
in reply to phantomwise • • •Sure, some packages are outdated. But in terms of percentage of up-to-date packages, it's (AFAIK) the best out of any distro repo. And that's perhaps even more impressive of a feat when realizing it also sports the biggest repo. For actual stats: repology.org/repositories/stat…
Repository statistics - Repology
repology.orgphantomwise
in reply to HayadSont • • •iopq
in reply to phantomwise • • •msherburn33
in reply to phantomwise • • •It's reproducible, so random updates are a no-no. You can however just dump the Git URL in your
flake.nix
inputs and then override thesrc
of the package with that. The source gets updated when you donix flake update
next time. Something like this:phantomwise
in reply to phantomwise • • •Finally managed to enable VSCode extensions without doing it imperatively or using home manager I'm so happy I could cry 😭 😭 😭
It actually wasn't even that bad, I'm just terrible at understanding documentation I guess
atzanteol
in reply to trevor (he/they) • • •You absolutely do. If you build a container and publish it you will pull down that exact thing every time. How is that not "reproducibility"?
You no what though? Scratch that - who gives a fuck? Bit-for-bit reproducibility takes far more effort than it's worth anyway. Even NixOS isn't completely reproducible. It's a false goal.
It's well more than good enough you mean.
Nobody really needs that.
utopiah
in reply to trevor (he/they) • • •Feels very arbitrary. Why would I care about say MacOS versus FreeBSD or say NeXTSTEP (just to be provocative)?
Anyway I'm being pulled away from the actual argument, the "bare metal" argument is about performances, isn't it?
utopiah
Unknown parent • • •trevor (he/they)
in reply to atzanteol • • •steeznson
in reply to ikidd • • •aim_at_me
in reply to steeznson • • •smiletolerantly
in reply to steeznson • • •Think about it like this:
steeznson
in reply to smiletolerantly • • •Sibbo
in reply to ikidd • • •iopq
in reply to ikidd • • •steam-run
it and it just workssmiletolerantly
in reply to iopq • • •SolarBoy
in reply to smiletolerantly • • •This command will just run an executable file on nix. Normally only executables which are installed from the package manager will work.
appimage-run
is another option. Which can be used to run, you guessed it, appimagesiopq
in reply to SolarBoy • • •SolarBoy
in reply to iopq • • •iopq
in reply to utopiah • • •gedhrel
in reply to trevor (he/they) • • •utopiah
in reply to iopq • • •msherburn33
in reply to ikidd • • •Let me disagree there, the language is trivial. It's just JSON-lookalike with expressions, with a lot of nice touches that make using it much easier than all the alternatives (e.g. sane multi-line string handling, lazy evaluation, default values, powerful key/value sets, etc.). The only real stumbling for me when first encountering it was realizing that functions can only take a single argument (which can be a key/value set) and that functions are literally just
:
(e.g. (a: a + 5) 6 => 11). That's easily missed if you just look at a file without reading the documentation.The thing that makes it hard is just the complexity of the actual package collection, your configuration contains literally your whole system, and it's not always obvious where to find the thing you need, since sometimes it's a plain package, sometimes it is a
services.foobar.enable = true
and sometimes you have to fiddle with override or other package specific things. Knowing thatsearch.nixos.org/ exists is half the battle here.
There is also the lack of static typing that can lead to rather verbose error messages, but it's not like many other configuration formats have that either.
NixOS Search
search.nixos.orgheraplem
in reply to msherburn33 • • •There are a few gnarly things about Nix, even for someone who's familiar with Haskell (the most similar language to Nix that's even close to mainstream).
builtins
) is extremely sparse. You basically have to depend on at leastnixpkgs-lib
if you want to get any real work done._type
field or some such.${
or''
? I have to look them up every time.SolarBoy
in reply to msherburn33 • • •Using a language server like nixd also helps a lot with auto completing packages and options in your config.
Apparently people are also working on the nickel configuration language to address some of the nix limitations and difficulties.
trevor (he/they)
in reply to gedhrel • • •I'm not quite sure why you think pointing out someone's confidently incorrect claim that containers do give you reproducible environments means that I fetishsize anything?
But if you genuinely want to know why reproducibility is valuable, take a look at reproducible-builds.org/.
I was quite happy to see that Debian and Arch have both made great strides into making tooling that enables reproducible packages in recent times. It's probable that, because of efforts like this, creating reproducible builds will become easier/possible on most Linux environments, including traditional container workflows.
For now though, Nix Flakes are much better at enabling reproducible builds of your software than traditional containers, if you can suffer through Nix not being documented very well. This article covers some more details on different build systems and compares them with Nix Flakes if you want more concrete examples.
FWIW, I think that containers are awesome, and using them for dev environments and CI tooling solves a lot of very real problems ("it works on my machine", cheap and easy cross-compilation for Linux systems, basic sandboxing, etc.) for people. I use containers for a lot of those reasons. But if I need to make something reproducible, there are better tools for the job.
Reproducible Builds
reproducible-builds.orgchaospatterns
in reply to ikidd • • •I really want to like Nix. The idea of declaratively defining my entire system sounds great. I can manage it with Git and even have multiple machines all look the same. I can define my partititioning once and magically get a btrfs disk working. Wow!
But I find the language confusing no matter how many times people say it's easy. I have a lot of experience with other programming languages so maybe it just doesn't mesh. It also gives terrible error messages that are hard for me to understand. And Nixpkgs is unpredictable for what version I'm going to get. One of the services I installed ended up being a release candidate version which was a surprise. What if I don't want the latest version of Docker? How do I pin it? Do I have to duplicate part of Nixpkgs? It just feels like a monorepo where everybody has to be on the same versions. Why on earth do the Nix language docs start by introducing math expressions instead of here is a simple self contained thing that installs one program. Here's how you configure it. Here's how you expand. Why does the dependency graph seem to pull in so many unnecessary dependencies? For example, I tried to build a minimal Docker image (which Nix looks to be a very good fit for), but I couldn't figure out how to strip out dependencies that likely were only used during build for a dependency.
I still like the idea and have managed to get my server defined entirely with NixOS which is very cool, but I can't recommend this to my tech friends because if I'm confused they will be more so.