I've been itching to try a new operating system and I'm planning to get a very cheap chromebook so I figure now is a good time to try and use nix as a daily driver. At least as daily as I am.
Nix attracted me because I've always wanted a system where things can be installed and rolled back with ease. There have been many instances of trying to get something to work and I've installed a boatload of stuff and ultimately I failed. I give up the installation but now I have a bunch of jank strewn across my system. It makes me break out just thinking about all the garbage everywhere. I've thought about doing things inside virtual machines but that always felt heavy and a bit stupid. It would require me to get comfortable with the VMs when all I really want to do is hack together packages.
Nix has been on my radar but it's only recently when I decided that I wanted a laptop that I really gave it time.
Nix is absolutely a shitshow in regards to documentation and the official way to do things. I still don't know what the correct path is as of Jan 2024. This is a crazy feeling in something that seems popular in my eyes. There seems to be the regular nix way of doing things and the flake system. I'm not sure what the difference is yet but it looks like the world is settling on the flake system much to the chagrin of nix developers. From the github issues and others' summaries, it sounds like the flake system was introduced as an experimental way of using nix but was promoted heavily. Now flakes are an integral part of nix but because it's experimental, it can have breaking changes. However because of how integral it is, development of flakes is now debating if breaking changes should be allowed.
The core idea is that by creating an experimental feature, promoting it heavily by influential members of the community, they have gone around the RFC process and created a second way of getting a feature implemented. If flakes become official and they don't have any breaking changes, then they give this second way credibility as a way to get things done. This makes the RFC process optional which is a bad thing.
This issue has resulted in the official docs not mentioning flakes but the community around nix is very much all about flakes. The disjoint is mesmerizing.
Now with that backstory, you can see why Nix is so confusing. I have 13 tabs open and a VM spun up so I can try out nix before I install it on to my laptop. This reminds me of my [Arch] days when I practiced an arch installation before doing the real thing. Then it was because there was so much documentation and the arch wiki was a fantastic source of knowledge. This is for a very different reason in that I don't know what the hell I'm trying to learn.
As frustrating as it is, it is quite fun and it has echos of an older time so I think I'll give nix a real shot and see if I can piece together how it works. If it goes well, it will also aid me in my meanderings into running random software and general hackery. You can follow my attemp to install nix [here]. This will be in qemu using the bios way of setting things up. I am planning to write another installation journey when I install [nix on my chromebook].
(1978) Nix thesis - A 281 page PhD thesis
(2010) NixOS thesis - A 38 page paper
(2023) Summary of the Nix thesis - Blog post
lol
I think it would be good to write down what I think nix is based on what I've read so far. I'll be able to look back at this and see how much of it I got right and how much of it I got wrong. It might also give some clue about how to teach nix to somebody.
Nix looks like and sounds like nvm on steriods. nvm is a node version manager that lets you install and run multiple versions of node. I wrote an article outlining how nvm works and how you can do what nvm automates, manually.
The core idea is that you install things to a central place and then do some path munging to use the right version of things. This is what I think the essence of nix is. However instead of javascript, it's for everything. This means that packages need to be changed internally as compiled programs have links to dynamic libraries they expect in certain places. These certain places are going to be in a central store under nix.
This seems to be why nixpkgs exist. I'm guessing that nixpkgs need to link to the central store as otherwise you can't have multiple versions symlinked in something like /usr/local/lib.
Nix also seems to be some way of doing something like ansible. You describe the state of your computer and nix will make it match that description. This is where nixlang seems to come in though I'm curious how a language can build an artifact. You describe all the steps and out comes an executable. This reminds of the zig build.zig file. It's a zig file and it gets compiled just like regular zig code. However it has all the logic to do stuff like adding paths and including libraries. I wonder if the language of nix is similar to the zig build functions.
NixOS seems to be the culmination of all of nix. Take the idea of nix and make it the entire operating system. You describe the operating system and all the packages there and you get a very specific build that can be recreated easily. Almost like a virtual machine image. I wonder if an image might be better.
In summary:
Nix - nvm
Nixlang - zig'z build.zig is written in zig
NixOS - image of a computer
Somewhere in there is ansible.