nixos-config VS nix

I use Nix/NixOS. My system state is a direct result of my config that is declared in a bunch of text files. For example, leaf packages that are installed system-wide are declared here: https://github.com/Atemu/nixos-config/blob/e646c4ec1aac80cfdf7b8c79debcfaee70237018/packages.nix

If it matters, my distro is NixOS and here's the machine's system config: https://github.com/Atemu/nixos-config/blob/95f9bb201ab4c2ab95fb3089909f5951a0646699/configs/HEPHAISTOS/default.nix

If something really goes south, I can have my entire system rebuilt automatically almost to the bit within 5-20min (mostly dependant on Internet speed) because my system is reproducible from just a bunch of text files.

Here's my desktop configuration to give you an idea: https://github.com/Atemu/nixos-config/blob/0e97d9af632852e7440563a9b5976663e61071b7/desktop.nix

If you want to know more: https://nixos.org/ Here's how such a system declaration can look like: My current desktop configuration, packages "installed" system-wide.

If you're looking for a way to restore your system configuration should your drive go kaput, perhaps look into declarative means of configuration instead. With those, your system is defined by a few text files and restoring or duplicating it is trivial. If you want to stay with Arch (great distro), imperative tools like Ansible, Puppet or Chef should work. If you want to try greener pastures, look into NixOS which is what I use. All I need to restore my machine is a few text files like this one (I just clone the git repo).

It only takes https://github.com/Atemu/nixos-config/blob/master/configs/HEPHAISTOS/default.nix#L14 and all these settings are applied: https://github.com/Atemu/nixos-config/blob/af0960a7f7b0d6b9d775015c63a107ede6f63c82/desktop.nix

Here's the list of packages available in all my systems or my desktop configuration to give you an idea.

Set it up once precisely the way you like it, run forever. You only need slight tweaks every now and then to keep up with progress. On how many machines you want with as much shared configuration you want, any time you want. If your NixOS boot drive died, you could have a working NixOS system that's exactly[3] like the old one in a matter of minutes depending on your internet and hardware speed. (Without user data of course.) All you need is one (or a few if you prefer) lean text files that can and should be tracked in a git repo like this on: https://github.com/Atemu/nixos-config

> https://github.com/NixOS/nix/pull/9911#issuecomment-19252073...

As we covered in my last post, NixOS is a amazing Linux distribution for creating stable and declared environments. Now while this is amazing for a desktop setup, it is also perfect for a home-server or home-lab.

(Nix itself is slowly chugging along with Windows via MinGW - https://discourse.nixos.org/t/nix-on-windows/1113/108 and https://github.com/NixOS/nix/issues/1320 , for example.)

Nix is a cross-platform package manager. It uses the nix programming language. Nix and NixOs are often used in the same context, but while the first is a package manager, the latter is a linux distribution based on nix.

Today I want to talk to you about Nixos. What is it? Nixos is a declarative and reproducible OS, partly taking the words used on their own page. What does that mean?

Software developers often want to customize:

1. their home environments: for packages (some reach for brew on MacOS) and configurations (dotfiles, and some reach for stow).

2. their development shells: for build dependencies (compilers, SDKs, libraries), tools (LSP, linters, formatters, debuggers), and services (runtime, database). Some reach for devcontainers here.

3. or even their operating systems: for development, for CI, for deployment, or for personal use.

Nix provision all of the above in the same language, with Nixpkgs, NixOS, home-manager, and devShells such as https://devenv.sh/. What's more, Nix is (https://nixos.org/):

- reproducible: what works on your dev machine also works in CI in prod,

- declarative: you version control and review your configurations and infrastructure as code, at a reasonable level of abstraction,

- reliable: all changes are atomic with easy roll back.

Hopping from one distro to another with a different package manager might require some time to adapt. Using a package manager that can be installed on most distro is one way to help you get to work faster. Flatpak is one of them; other alternative are Snap, Nix or Homebrew. Flatpak is a good starter, and if you have a bunch of free time, I suggest trying Nix.

- it reduces bloat, because you can generate an environment or OS image with only the software needed to run a specific program or service

My guess is that a big efficiency gain would come from the second point, because you don't waste CPU on code that you don't use.

Does this make sense? Has anyone explored this?

[0]: https://nixos.org

1) Setting up the development environment - I currently use devcontainers for most things, but may also dig into nix -> isolated, portable, repeatable development environment 2) Exploring Echo - understand routing, requests, response, etc. 3) Incorporate Templ - integration with Echo, template composition, etc. 4) Integrating TailwindCSS - config for use with Echo/Templ, development cycle, deployment, etc. 5) Add in HTMX - endpoints, template structure, concepts, etc. 6) hyperscript for interactivity - client side interactivity