rutrum

For example, compose2nix lets you build nixos configuration for containers defined in a docker compose compose.yml. But this step happens offline. You have to first ad hoc generate the config from the compose.yml and then use that generated output in your config.

It seems obvious to me that the best user experience would be to write a flake/module that let's you just point to a compose file directly in your config. On rebuild, it would parse the compose file and build the appropriate config.

But I've not really seen that. These projects that convert from one package mamagement scheme or config file to another (xxx2nix projects) work using this preprocessing step. More examples include pip2nix and cargo2nix.

Given how common this pattern is, I suspect there is something preventing generating at rebuild time from being feasible, or at least easy. Does anyone have ideas for why this is? Thanks.

I'm looking to spec out a new NAS. I have a relatively small media collection, that I hope to grow as I digitize more family VHS tapes etc. Right now I have around 4 TB of data, shared across an external drive and my internal ssd.

Whats the best path forward on drives in this new NAS? I've heard advice for buying one big 20TB drive over multiple smaller drives. What's best for mitigation of drive failure? Is that even a concern? If I do multiple drives, should I use RAID?

I'm a little new to this. If you have resources for learning some best practices I'm all ears.

The gist is you write macros/automations/scripts to play the MMO based on your logic.

I decided to do it in bash/curl/jq to make it extra fun and learn some tools I use occasionally but only withheavy man page referencing. After some playing I might be a bash-scripting pro.