4 ms·

> Nix optimizes for local configuration yes yes yes yes yes. nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed loc

> Nix optimizes for local configuration yes yes yes yes yes. nix makes deployment feel bottom-up, not top-down. you understand how a system is constructed locally before you (optionally, if it's in your job description) graduate to doing devops stuff with it. that was the singular thing that hooked me; the functional reproducible stateless referentially-transparent cacheable stuff was just what kept me on board.

drdaeman 3y ago
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.
  - 3y ago

drdaeman 3y ago

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.
- 3y ago