ruffsl
I’m a robotics researcher. My interests include cybersecurity, repeatable & reproducible research, as well as open source robotics and rust programing.
- 4 Posts
- 3 Comments
3·1 day agoIf there was a simple Debian based distro that I could declaratively manage via a single config file, I think I’d try it. I.e. not using Puppet or Chef that can only bootstrap a system state, but something to truly manage a system’s entire life cycle, including removing packages and anything littering the system file tree. But since there isn’t, I’m using NixOS instead.
Having a DSL to declare my entire system install, that I can revision control like any other software project, has been convenient for self documenting my setup and changes/fixes over time. Modularizing that config has been great for managing multiple host machines synchronously, so both my laptop and desktop feel the same without extra admin work.
Nixpkgs also bolsters a lot of bleeding edge releases for the majority of FOSS packages I use, which I’m still getting used to. And because of how the packaging works, it’s also trivial to config the packages to build from customer sources or with custom features. E.g. enabling load monitoring for Nvidia GPUs from
btopthat many distros don’t ship by default.
2·2 months agoI’m not the original author, even with the YouTube title being as is, but what do you mean? Perhaps relying that the desired services exist as nix packages, or that nix packages have desired defaults or exposes desired config parameters?
There are two other nix media server config projects I can think of, but I think this approach mostly facilitates the install, but not the entire initial config setup, given that a lot of the stack’s internal state is captured in databases rather than text config files. So simplifying the backup and restoration of such databases seems the next best thing to persist your stack configs with nix.
Looks like they introduce the use Traefik with NixOS here:
How does
Traefikcompare to a reverse proxy likeCaddy?