5 ms·

I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes

I'm not sure. Well, I mean, there are weird folks out there who may start doing large-scale things without understanding what they're building upon (Kubernetes is not exactly an OS, but is a notorious example), but they could make the same mess with any technology. They're just unlikely to pick Nix, NixOS or NixOps (or any alternative to it), because mainstream tutorials won't cover it [yet]. The deployment and learning process is not that different from, say, Arch Linux, or even Debian. You still learn the higher-level interactions (pacman/apt/nixos-rebuild), divert to individual programs, then dive in (.ebuild/dpkg-buildpackage/nix), then learn even finer details as you get hit with nuances. NixOS is absolutely not LFS, where you really go bottom-up. And nixpkgs is covering more and more every day. Just an anecdote example: I've started with run-of-the-mill tutorial approach on setting up NixOS on single machine, and ran than for a while. Then I've realized my configs are a non-DRY mess and I want to manage my systems in organized fashion, so I've spent a significant amount of time unifying the configurations so I could manage and deploy it with deploy-rs (thinking of switching to colmena now, but that's not relevant). And only at that point I've realized that I'm missing some fundamental bits like signing (aka why nix-copy may fail, and how to deal with this without the trusted-users "see-no-evil" hack), or exact operation of substituters (aka, essentially, binary caches). Because with local nixos-rebuild it's all sort of hidden and I never had any issues. What makes Nix/NixOS different are its fundamental principles, not how one approaches it. Starting somewhat more low-level than with "just works" tools is just a popularity issue: more rough edges, so one needs to learn how to polish them.

0x69420 3y ago
well, an anecdote for an anecdote: reading the definitions of nixos modules became a matter of course for me when i started doing strange stuff that didn't quite fit into the authors' expectations, and those module definitions contain the implementation, i.e. exactly where files are placed and what's written to them. i learned things about how a distro is put together that i never had any reason to look into in the past. but i wasn't referring to how a system is put together at that level; i was referring to how a system is put together with the tool at hand, i.e. nix. and yes, you're right, that is top-down from the latter to the former > What makes Nix/NixOS different are its fundamental principles, not how one approaches it. you'll have no disagreement from me here; i was referring to what qualitatively hooked me, not making any statements about fundamental design
- drdaeman 3y ago
  Ah, my apologies, I think I've misunderstood you. Yes, absolutely, I agree - reading definitions of those modules is how one learns Nix. Documentation is okay, but it doesn't cover neither the essential theory like patterns, practices and idiomatic approaches, neither implementation specifics (how some particular config file or startup helper script is generated). Although, to be fair - reading source code of how things work is not really specific to Nix. It's just that Nix doesn't stop at packaging and also provides declarative configuration, so there's much more to read in nixpkgs than inside some .deb source (which typically stops at providing a generic systemd unit or rc script). But if someone would be using some other declarative configuration tooling - I'm sure they'll also do a lot of deep diving into the definitions, reading the source code. It's just that Nix is outstanding in this regard - I suppose I can, but I surely wouldn't want to use Terraform, Chef or Ansible for what it does.
dlahoda 3y ago
nix rebuild does ssh on remote machines all possible ways, why colmena? if you need cloud infra, can use terranix. base image from nixos generators. reconfiguration nix remote rebuild.
- drdaeman 3y ago
  This is definitely an option. But isn't colmena just a nice wrapper on top of the same things nixos-rebuild uses (nix-build, nix-copy, etc) plus some nice-to-haves for easier eval REPL? I mean, yes, I suppose I can use `nixos-rebuild --fast --build-host foo --target-host foo --flake ".#foo" switch` and maybe even wrap that in a the flake itself (`flake run .#deploy-foo`), but why should I reinvent this wheel, if I can just `colmena apply --on foo` and let it do what I mean? I definitely will consider nixos-rebuild if colmena won't support something I want. Just like I'm currently considering trying out colmena because deploy-rs can't do `activate test` and messes up `/boot/loader/loader.conf`, which I don't fancy as I want to eventually have a "one-shot reboot into a new generation and if something fails too badly, watchdog will eventually panic (or I'll ask someone to cycle the power) and reboot back to a good generation" ultimate magic rollback. Worst that would happen is that I'll learn a new tool (aka learn what it can't do for me) and won't use it. No cloud infra here, all bare metal and one tiny auxiliary VPS.

0x69420 3y ago

well, an anecdote for an anecdote: reading the definitions of nixos modules became a matter of course for me when i started doing strange stuff that didn't quite fit into the authors' expectations, and those module definitions contain the implementation, i.e. exactly where files are placed and what's written to them. i learned things about how a distro is put together that i never had any reason to look into in the past. but i wasn't referring to how a system is put together at that level; i was referring to how a system is put together with the tool at hand, i.e. nix. and yes, you're right, that is top-down from the latter to the former > What makes Nix/NixOS different are its fundamental principles, not how one approaches it. you'll have no disagreement from me here; i was referring to what qualitatively hooked me, not making any statements about fundamental design

drdaeman 3y ago
Ah, my apologies, I think I've misunderstood you. Yes, absolutely, I agree - reading definitions of those modules is how one learns Nix. Documentation is okay, but it doesn't cover neither the essential theory like patterns, practices and idiomatic approaches, neither implementation specifics (how some particular config file or startup helper script is generated). Although, to be fair - reading source code of how things work is not really specific to Nix. It's just that Nix doesn't stop at packaging and also provides declarative configuration, so there's much more to read in nixpkgs than inside some .deb source (which typically stops at providing a generic systemd unit or rc script). But if someone would be using some other declarative configuration tooling - I'm sure they'll also do a lot of deep diving into the definitions, reading the source code. It's just that Nix is outstanding in this regard - I suppose I can, but I surely wouldn't want to use Terraform, Chef or Ansible for what it does.

dlahoda 3y ago

nix rebuild does ssh on remote machines all possible ways, why colmena? if you need cloud infra, can use terranix. base image from nixos generators. reconfiguration nix remote rebuild.

drdaeman 3y ago
This is definitely an option. But isn't colmena just a nice wrapper on top of the same things nixos-rebuild uses (nix-build, nix-copy, etc) plus some nice-to-haves for easier eval REPL? I mean, yes, I suppose I can use `nixos-rebuild --fast --build-host foo --target-host foo --flake ".#foo" switch` and maybe even wrap that in a the flake itself (`flake run .#deploy-foo`), but why should I reinvent this wheel, if I can just `colmena apply --on foo` and let it do what I mean? I definitely will consider nixos-rebuild if colmena won't support something I want. Just like I'm currently considering trying out colmena because deploy-rs can't do `activate test` and messes up `/boot/loader/loader.conf`, which I don't fancy as I want to eventually have a "one-shot reboot into a new generation and if something fails too badly, watchdog will eventually panic (or I'll ask someone to cycle the power) and reboot back to a good generation" ultimate magic rollback. Worst that would happen is that I'll learn a new tool (aka learn what it can't do for me) and won't use it. No cloud infra here, all bare metal and one tiny auxiliary VPS.