I plan to use this for testing changes to my boot units.
In theory, plain old generations allow you to safely test changes to boot units, by allowing you to jump to the previous generation. In practice, this involves remembering which generations have known-good boots.
Specialisations will allow me to run a stable and candy track, on per generation.
Please do. I get the impression that not many people use --profile-name, and I live in fear of them taking it away. It needs critical mass. Two of us should be enough!
This makes testing changes easier in other ways too: when I make experimental changes, I'm reluctant to commit them until I know they're working, since I like being able to checkout an old commit and know it boots. In practice this means I end up with a dirty checkout, and uncertainty on which changes have been tested.
In theory I could manage this with git rebasing and/or tagging, but in practice I lose confidence in whether I've accurately tracked.
With specialisations, I'd comfortably commit an experimental change to my canary track, even though it might break, safe in the knowledge that the stable track continues to boot.
This makes me nostalgic for Trusted Solaris. Nearly identical motivations, but also allowed for runtime context switching (even within running X11 sessions) without a reboot.
It combined Zones, ZFS filesystems, Crossbow network virtualization, a modified X11 server, and an auth framework to glue it all together.
I don't know how widely Trusted Solaris was ever adopted, but I know that I haven't seen it in use in many years. Maybe this particular NixOS strategy will gain more traction.
If Nix(OS) just had a better documentation ... sigh. Using it feels more like discovering stuff, not utilizing it properly. It's like an adventure, not a tool. Neither is bad, but I think the other way around it would benefit the project.
This seems really dangerous. Wouldn't running garbage collection on the nix store while in the work partition clean out nix paths required by the home partition's install, and vice versa?
Nix and NixOS has an incredible number of features and use-cases that have almost no documentation around. The only way to discover those, it seems to me, is to look up people's nixos configurations on GitHub etc.
Beginner level blogposts (that are plenty) talk about the same few features like ad-hoc development shell.
The problem is that this isn't a feature that it supports, it's just that someone noticed the way you can combine the existing features leads to this possibility. It's the same with a programming language - until someone noticed that you could use javascript and web browsers to make a PDF viewer or an email client, maybe there was no documentation about how to do that.
I think it's not so much a problem of Nix/NixOS, but a consequence of the power of composability. For the next n years, people will keep discovering new things you can do. As the knowledge spreads, people will work out how to document the features and present them in ways that can be easily grasped. But the final success of NixOS will be when every distribution adopts more and more NixOS-like composability and NixOS is well understood and even boring, like the final success of Unix.
NixOS for busy developers ain't for the faint of heart.
But I am extremely faint of heart, and I love NixOS.
The trick is that I'm not a developer, and I happen not to need to ask it to do anything complicated or non-standard. I expect lots of other people are in my position (although maybe not many of those people read HN).
I plan to use this for testing changes to my boot units.
In theory, plain old generations allow you to safely test changes to boot units, by allowing you to jump to the previous generation. In practice, this involves remembering which generations have known-good boots.
Specialisations will allow me to run a stable and candy track, on per generation.
What other usecases do specialisations improve?