He didn’t explain it well. The whole system lives on a ymal file and is easy to read. Documentation as code. If you have a working system then you’re set, it’ll never break. Adding software uses it’s own dependencies and will never break other software. It also has roll back features like snapshot/btrfs, during bootup you can go back to a previous version of your system. With the ymal file it makes it easy to clone the setup from others or for other systems of yours in the future, just have to generate a hardware file in most cases.
Yeah, that’s what I wanted to communicate! But, there is a spot for this OS: you’ve been a programmer for decades now, you still love Linux and you’ve customized every piece of your desktop and programming environment. Now, NixOS gives you the possibility to write one config to configure everything: from your system daemons to the desktop wallpaper, from the editor theme to the kernel boot parameters. And when you store a lock file, the same configuration that worked correctly in one machine, will work exactly the same in another computer.
So, you have a workstation, maybe another workstation in the office and a laptop? You change something in your setup, and this setup gets replicated exactly the same in every other machine when you push your changes to the version control. This is very nice, especially if you have a highly customized emacs, vim or helix as your editor, and like to try out new tools outside of coretools for the CLI lyfe.
Another thing, where you don’t even need NixOS (just the nix package manager installed in your Linux, Mac or Windows machine), is how you can configure your project dependencies with it. Now, you run a business that develops software with maybe Rust and TypeScript, or Go and Javascript. You need a special version of OpenSSL or a certain version of Rust. The project then has the nix flake in it, and nix-direnv. The devs enter the directory and nix installs every single tool needed for the project correctly for everybody. The same version, the same config, everything streamlined for the whole team. If the env works correctly for one dev, it works for everybody.
I hope this answers why you’d like to put some effort to learn it. It’s hard in the beginning, but there’s a huge payback for certain use cases.
I understood maybe three things in your reply so NixOS probably not for me.
He didn’t explain it well. The whole system lives on a ymal file and is easy to read. Documentation as code. If you have a working system then you’re set, it’ll never break. Adding software uses it’s own dependencies and will never break other software. It also has roll back features like snapshot/btrfs, during bootup you can go back to a previous version of your system. With the ymal file it makes it easy to clone the setup from others or for other systems of yours in the future, just have to generate a hardware file in most cases.
Yeah, that’s what I wanted to communicate! But, there is a spot for this OS: you’ve been a programmer for decades now, you still love Linux and you’ve customized every piece of your desktop and programming environment. Now, NixOS gives you the possibility to write one config to configure everything: from your system daemons to the desktop wallpaper, from the editor theme to the kernel boot parameters. And when you store a lock file, the same configuration that worked correctly in one machine, will work exactly the same in another computer.
So, you have a workstation, maybe another workstation in the office and a laptop? You change something in your setup, and this setup gets replicated exactly the same in every other machine when you push your changes to the version control. This is very nice, especially if you have a highly customized emacs, vim or helix as your editor, and like to try out new tools outside of coretools for the CLI lyfe.
Another thing, where you don’t even need NixOS (just the nix package manager installed in your Linux, Mac or Windows machine), is how you can configure your project dependencies with it. Now, you run a business that develops software with maybe Rust and TypeScript, or Go and Javascript. You need a special version of OpenSSL or a certain version of Rust. The project then has the nix flake in it, and nix-direnv. The devs enter the directory and nix installs every single tool needed for the project correctly for everybody. The same version, the same config, everything streamlined for the whole team. If the env works correctly for one dev, it works for everybody.
I hope this answers why you’d like to put some effort to learn it. It’s hard in the beginning, but there’s a huge payback for certain use cases.