Yep, that's the whole point. Pix transactions are designed to be instantly settled, even across different banks. The central government bank enforces this, as well as other rules (e.g. Pix between two individuals can't have fees, etc).
You might want to try out self hosting hydra! It's pretty sweet for your usecase (building and caching Nix stuff, in a smart way). It can even run arbitrary commands (e.g. moving a release branch)
Your comment was very interesting to read!
I wanted to chime in and mention that "Life is Strange" has a lot of this "what choice did you make?" book club-like feel to it, it's pretty fun to talk about!
Yup! Worked great for the few months I used it. I think it's kinda funny how much simpler the Nix package is when compared to upstream's dockerfiles lol
I'd definitively recommend it, though! I think the frameworks are pretty nice, do keep in mind they are all more like microframeworks (think flask, not django). If you like writing Rust code and building your own scaffolding is not something you hate, definitively try it out!
I've worked on the server side with Axum and Rocket; both are pretty nice. I love SQLX to write queries that validate at build time, and had quite a blast using Maud to write HTML within Rust code.
I'd say the type system is awesome to help model your problems and make sure invalid states can't be represente
The biggest drawback is big(ish) compile times/feedback loops; I can get it down to around 2s on a project that builds SCSS and bundles assets within Rust, but it (and any other compiled language, really) can't beat the fast iterations interpreted languages give you.
I have a mix of x86_64 and aarch64 machines and, damn, NixOS makes it so freaking easy. Most of nixpkgs works on both architectures. You can even use your machines as remote builders and/or use binfmt to transparently run/build stuff through qemu.
When I was helping out a friend with his free oracle aarch64 server, I got baffled on how ARM feels like a second class citizen on most distros.
The server's timezone is not even relevant. By using timestamptz, you include the timezone together with the timestamp, meaning you can be absolutely sure that the time stored is indeed UTC! You avoid the mistake of mixing up local times and UTC and forgetting to convert them.