Hmm, that’s just the initial configuration, though, right? If you want to roll out updates to the config, you would presumably use Salt or similar (like they have a config field in that generator).
That’s also an improvement for this use-case over your average Linux distro, especially because MicroOS is immutable as well, but NixOS is still a big step further into this direction.
I guess, what I really wanted to say in my previous comment is that NixOS isn’t just immutable, but rather also declarative.
You define your system config and then it makes it so the system matches that configuration, whether it’s a new system or a previously installed system.
So, it’s not just a script where you need to describe how to apply or unapply a change, but rather the entire OS declared in a config file (and a ton of defaults).
The big difference is that you know the state of a system, when you apply a configuration. It is written into your configuration file.
Whereas with a distro which is merely immutable, even if you completely prohibit users from making changes, you still have the problem that someone might’ve been on vacation while your script contained a line to e.g. modify some config file.
If you update that line before they return, then you better hope your new modification logic can deal with whatever is on their system.
With a declarative system, this cannot happen, because the contents of that specific config file would be defined in your NixOS configuration file. No matter when you do the sync, the up-to-date contents will be put in there correctly.
(And yes, I know, if you get your scripts right, you can achieve similar results. The point is that you don’t need to.)
They are both declarative. The main difference is NixOS has the package build system built into its package management vs Microos which uses zypper and the Open Build System for package building.
Both have declarative config files you either activate via command or get automatically referenced on reboot.
For microos it both ignition, AND combustion.
I’ll be honest though both have been a total pain in the ass (I say with love they are still opensource and Linux in the best of ways).
There is a tool kit for sle micro (and I assume microos too) called elemental that builds them from ContainerFile/DockerConfig files that just feels more sane to me. If it gets too complex for a containerfile I’m doing something wrong anyways imho. That said I do really like NixOS/Guix ability to have the dev build tool, package build tool, distro build tool, and sysadmin tool all be the same language.
MicroOS would be good also.
They have a tool to help build the config file prior to installing, and a tool to build the iso.
https://opensuse.github.io/fuel-ignition/
Hmm, that’s just the initial configuration, though, right? If you want to roll out updates to the config, you would presumably use Salt or similar (like they have a config field in that generator).
That’s also an improvement for this use-case over your average Linux distro, especially because MicroOS is immutable as well, but NixOS is still a big step further into this direction.
I guess, what I really wanted to say in my previous comment is that NixOS isn’t just immutable, but rather also declarative.
You define your system config and then it makes it so the system matches that configuration, whether it’s a new system or a previously installed system.
So, it’s not just a script where you need to describe how to apply or unapply a change, but rather the entire OS declared in a config file (and a ton of defaults).
The big difference is that you know the state of a system, when you apply a configuration. It is written into your configuration file.
Whereas with a distro which is merely immutable, even if you completely prohibit users from making changes, you still have the problem that someone might’ve been on vacation while your script contained a line to e.g. modify some config file.
If you update that line before they return, then you better hope your new modification logic can deal with whatever is on their system.
With a declarative system, this cannot happen, because the contents of that specific config file would be defined in your NixOS configuration file. No matter when you do the sync, the up-to-date contents will be put in there correctly.
(And yes, I know, if you get your scripts right, you can achieve similar results. The point is that you don’t need to.)
They are both declarative. The main difference is NixOS has the package build system built into its package management vs Microos which uses zypper and the Open Build System for package building.
Both have declarative config files you either activate via command or get automatically referenced on reboot.
For microos it both ignition, AND combustion.
I’ll be honest though both have been a total pain in the ass (I say with love they are still opensource and Linux in the best of ways).
There is a tool kit for sle micro (and I assume microos too) called elemental that builds them from ContainerFile/DockerConfig files that just feels more sane to me. If it gets too complex for a containerfile I’m doing something wrong anyways imho. That said I do really like NixOS/Guix ability to have the dev build tool, package build tool, distro build tool, and sysadmin tool all be the same language.