I was so disappointed that Valve chose Arch as their base for SteamOS. SteamOS is excellent, and all the work they do has gone back upstream to make Arch and Linux gaming better, but I feel like it was a missed opportunity. I've always thought that NixOS (and immutable distros like Fedora Silberblue etc) are perfect for embedded or consumer appliances. I feel like a bit of help from a company that actually uses NixOS in a mass market product would really push it over the edge in terms of usability.
I think people are unfairly downvoting this comment, but I do want to drill into your point (1) a bit. You're right that you can't really do a delta patch in NixOS. But I feel like that is so so so important these days with active supply chain attacks. I don't want a 200kb change to a core library that is "claimed" to be backward compatible to be able to make its way into my codebase. In an ideal world sure, there would be some way to prove that the update doesn't break anything and isn't malicious, and that is certainly possible for some limited subset (provers like Rocq, OS functionality like BSD Pledge, etc), but for now this is mostly based on trust.
What does my codebase mean, though? A normal desktop OS doesn't require app devs to issue updates for any change to any library and it would be extremely insecure to do so. The OS is better maintained than the apps.
Redownloading everything doesn't protect against supply chain attacks. Those can still happen, no problem.
Reflecting on it, I guess my OS config has turned into a codebase. I have a single Nix closure that includes all my OS config, all the services running on it, and all the small utilities that need to be compiled from source (either because they are something I wrote, or something that isn't packaged in Nixpgs). I'm not sure whether this is considered best practice or not. To your point though, I would be unaware if an upstream maintainer released a security patch for something that I'm compiling from source, because I am pinned to a specific Git commit. On the other hand, I can just point an LLM at my Nix source, and ask it to scan it for security issues periodically. I do this from time to time with one of the smart models, but it might be an interesting experiment to set up a daily scan with an inexpensive or even a local model.
I think it depends on what they want it for. I can imagine NixOS being perfect for user workstations for example, as an alternative to Windows workstations managed with Active Directory.
I imagine you have a lot more experience than I do packaging for NixOS and other distros given your product, but in the few cases that I've needed to run a binary, I just wrap it with a flake and it's done. I also stay on NixOS stable, so I avoid the sharp parts of "bleeding edge". In my experience as a desktop user, I've never had a failed rollback since using NixOS as my primary OS since around 2016. However, whenever I try to use it as a server OS, I often do hit the pain point you mentioned around statefulness. More specifically, the happy path is extremely happy, but once you need something off the happy path, you find yourself creating some really ugly glue to get it to interface with the happy path. The pattern I've settled on is using Podman quadlets for most services, but that isn't without pain either. Then you find that you've become a Unix sysadmin, managing different UIDs for rootless podman, different network domains, dealing with permissions issues, etc. I'm currently experimenting with microvm.nix to see if that will be cleaner, but no conclusions yet.
Very interesting that Fable took more creative liberties. Have you tried giving Fable the same task, but also specifying that it implement a pixel-perfect design? I think that I prefer the Fable implementation. I find the UI elements in the Fable implementation to have more contrast, which feels more usable to me. I also like how the right padding on the "Book Your Escape" CTA in the upper right matches the top and bottom padding, which I think is an improvement over the mockup.
All of these are using a build skill which specifies rules for building it, requirements to create a pixel perfect implementation, and tooling to help in that process. Here's the build skill / instructions I pasted in to both of them:
> Create a web page implementation from the following instructions:
> You are an elite frontend engineer and design-to-code specialist. The design image is the primary source of truth; your code is the translation layer. Do not reinterpret or "improve" the design into something generic — reproduce it faithfully.
Thank you for sharing this. I was just using OpenAI's Product Design plugin[1] to create designs but it just didn't reproduce it in code faithfully so will need to try this.
http://impeccable.style/ also just released their latest version which has some image->html conversion. They just released a couple days ago and haven't had a chance to try, but I suspect theirs is a bit more robust than mine for pure LLM instructions. Worth trying and comparing it with mine.
You can programmatically update DNS whenever your dynamic IP changes. One issue though is that some residential ISPs prohibit webhosting in their terms.
