Learn a dynamic lazy functional programming language first and then start building a flake without much help or documentation because that’s what you should be doing and the default installation doesn’t use that mechanism. The docs you find will assume you understand category theory already.
About few years later you are a god and there is no way you’re going to use anything else ever again.
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.
Nix hype has been high the last several months for some reason despite it being around for awhile. I think DevOps guys are just now discovering it or something.
Disclosure: I haven’t used it. I’ve just watched a few videos and have been following the hype. Someone correct me if I’m wrong.
My understanding is that it is similar to the idempotency that Terraform brings but on a OS, packages and code level.
Basically you define (in a file) everything you want on the OS from packages to settings to custom repos and it installs everything so even if something goes sideways and say your server gets hacked, you just start over not from scratch or hopefully a clean fallback image but with everything you need installed out of the gate on a fresh install.
Can also be super useful for ensuring your whole team is using the same setup. No more reading a manual for this one obscure firewall that some random guy setup. Your firewall (or whatever else) was installed and configured out of the box, plus it is the same org wide.
With flakes, you can also lock the project or your system to an exact commit of the nixpkgs repo, meaning you get the same versions until you update the lock file. It’s like a npm or cargo lock file, but for the whole system.
The nix packages define how to build and configure it, so the build part is like Gentoo. It has a powerful cache setup, so you rarely need to really build anything. Need a custom kernel though? Define your patches in your config and it works exactly the same until you update it.
How is Nixos? Are there clear advantages over a traditional Linux distro?
Learn a dynamic lazy functional programming language first and then start building a flake without much help or documentation because that’s what you should be doing and the default installation doesn’t use that mechanism. The docs you find will assume you understand category theory already.
About few years later you are a god and there is no way you’re going to use anything else ever again.
Source: been a user for the past four years.
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.
Nix hype has been high the last several months for some reason despite it being around for awhile. I think DevOps guys are just now discovering it or something.
Disclosure: I haven’t used it. I’ve just watched a few videos and have been following the hype. Someone correct me if I’m wrong.
My understanding is that it is similar to the idempotency that Terraform brings but on a OS, packages and code level.
Basically you define (in a file) everything you want on the OS from packages to settings to custom repos and it installs everything so even if something goes sideways and say your server gets hacked, you just start over not from scratch or hopefully a clean fallback image but with everything you need installed out of the gate on a fresh install.
Can also be super useful for ensuring your whole team is using the same setup. No more reading a manual for this one obscure firewall that some random guy setup. Your firewall (or whatever else) was installed and configured out of the box, plus it is the same org wide.
With flakes, you can also lock the project or your system to an exact commit of the nixpkgs repo, meaning you get the same versions until you update the lock file. It’s like a npm or cargo lock file, but for the whole system.
The nix packages define how to build and configure it, so the build part is like Gentoo. It has a powerful cache setup, so you rarely need to really build anything. Need a custom kernel though? Define your patches in your config and it works exactly the same until you update it.