Hacker News Reader

Comment by Zeetah | Hacker News Reader

Great experiment!

Let's say you have 15 programs installed. You use programs 1-5 multiple times a day, 6-10 every few days, 11-15 every couple of weeks.

The AI makes a change. It rebuild the image. Things are working.

A few days later, you go to use one the 10-15 programs that haven't been used for a week or two and it doesn't work. The change could have been that day or a couple of weeks ago. How do you remedy that? Thanks in advance for your insights.

View on HN

That's a real scenario and it's happened to me. The key is that NixOS keeps every previous generation — so when I discover program #12 is broken, I can nix store diff-closures to see exactly what changed between generations, or just boot into the last known-good generation from GRUB. In practice I do two things: I keep a quick smoke-test habit after rebuilds (open a couple of the less-used apps), and the git history tells me exactly which .nix change touched what. Since every rebuild is a commit, git bisect works on your OS the same way it works on code. It's not perfect — I've definitely had the "wait, when did this break?" moment. But the recovery path is always under a minute, which makes the cost of experimentation very low.

Can those smoke tests be included as part of the build?

You could build up a test suite of example workflows that run on every build.

Yes absolutely! Please have a look at my nixos-config I really would love to get feedback from others

For sure that is possible.

Reply on news.ycombinator.com