[erikw]

I'd be interested to hear more about how you're using NixOS if it isn't something you've already written about. My guess is that you're mostly leveraging the declarative configuration and immutability for internal infrastructure use. What I'd love to see would be consumer devices using NixOS, allowing updates (especially security patches) to be deployed to endpoints without too much fear that it will brick something. I think that would allow companies to more inexpensively maintain their IoT devices throughout their lifetime. I imagine a device where it could automatically revert to the last working generation if a new config fails for some reason.

[jjnoakes]

NixOS probably helps with this, but it isn't a requirement - some devices already have a dual-root-type setup where they update the inactive root, boot into it, and the boot sequence doesn't mark it permanently active until it boots properly, reverting to the original root if something goes wrong.

I think if more devices aren't doing this kind of thing then the cost might not make sense to them at all. Perhaps they aren't bricking devices often, or perhaps their support load is low.

But I'm only speculating. I'm all for more NixOS if it helps people.

[_red]

>dual-root-type setup where they update the inactive root, boot into it,

Fedora-IoT effectively does this with rpm-ostree + greenboot.

Greenboot specifies a series of directories under /etc that organizes your custom scripts (scripts that must not fail, scripts that may fail, scripts to run on success, scripts to run after previous failed, etc) then it marks your current ostree as either being active or auto-rollsback into previous.