• 2 Posts
  • 26 Comments
Joined 2 years ago
cake
Cake day: June 10th, 2023

help-circle




  • Your summary of the language is spot on. I still hope that more distros take inspiration from the declarative config and try to move in the direction, or nix supports a better language in the future. I think that ultimately that’s what the average linux user would want. The ability to still customize in a safe manner. Silverblue, and others, are and will remain a great option for the new or indifferent user.

    On your point about the transient phase, nix actually does that by default already. It installs everything at a separate path and then flips over in one go. You can even pick the mode, either try to do a live switch as you describe, or on boot. I don’t know if I see many benefits to images there.

    I am at a second place now that uses NixOS in a corporate setting, and it is much easier than maintaining the CoreOS images, or similar. I’ve had some many broken builds of CoreOS images because something goes wrong between the custom packages and the base CoreOS images, I would rather just run an Ansible script at this point. Also, you end up using the exact same test suite for NixOS images as for your other images, so the same guarantees end up being met.



  • No, I fully understand it. But if you build the whole system where every package is isolated, none of the packages interfere with each other, and every package is tested across a wide array of architectures, you can just as safely put together your ideal OS setup and don’t have to deal with being locked into very simple and bare system.

    The right place for immutable OSes is if you’re using it as a server for container workloads, where you will never customize the base system. Or if you never want to customize your system. Yes, you can customize the system image, but it breaks all the guarantees that the images gives you because the packages themselves are not isolated and by bumping a wrong dependency for a custom packages you can still break the whole system.











  • I use it to share environments with a small team. Just have distrobox specific Docker files and we can all spin up the same distrobox environment locally.

    We end up having a different base docker file (e.g. our distrobox one has editors and stuff), but we all share the same project specific docker file. That same project specific file gets used in CI/CD and deployment, but with a minimal base. So all in all, I would say it’s even better than Vagrant because we run the same system in production.