I rely on podman for my "devcontainers": https://github.com/evertheylen/probox. If anyone can point me to the weak points in my setup I'd appreciate it!
If you're looking for a language that aims to solve the "two-language problem" like Mojo, but want something more open, more mature and less influenced by VC funding, check out Julia: https://julialang.org/
I used Julia a lot when I was studying statistics (which I dropped out of) back in 2015, but I recently (like last weekend) came back to it to write a prototype of a supervised learning model, and I have to say, coming back to it was pure joy. And my model prototype was indeed fast enough for me.
Now I will probably rewrite the model in rust if I want to do anything with it (mostly for the web assembly target as I want this thing to run in browsers) but I will for sure be using Julia for further experimentation. Lovely language.
Funny you should say that... there was recently a very interesting announcement for a Julia-to-WASM compiler and a full-stack signals-based web framework:
This is cool! But AFAIK bun promises to be a one-stop-shop for all your JS/TS dev needs, while Perry is "just" a compiler from Typescript to native executables.
From what I can find Postgres 17 [1] introduced incremental backups to pg_basebackup, refined in 18, but nowhere near the full featureset of pgBackRest. Is that what you meant? Having builtin incremental replication to a S3-compatible storage would be great.
You can of course take a SQL dump that is version-independent, but if you're serious about creating backups, you want to take backups of the actual on-disk format of the WAL, because that's more efficient and also the only practical way to get point-in-time recovery. (For the efficiency, you could alternatively also take ZFS snapshots, which will work independently of the Postgres version, but those also don't give you PITR.) The WAL format is a Postgres implementation detail and therefore tools wanting to read and write it need maintenance whenever the format changes (which can happen on major version releases).
> Maintaining a data center is much more about solving real-world challenges. The cloud requires expertise in company-specific APIs and billing systems. A data center requires knowledge of Watts, bits, and FLOPs. I know which one I rather think about.
I find this to be applicable on a smaller scale too! I'd rather setup and debug a beefy Linux VPS via SSH than fiddle with various propietary cloud APIs/interfaces. Doesn't go as low-level as Watts, bits and FLOPs but I still consider knowledge about Linux more valuable than knowing which Azure knobs to turn.
Not really, I used it to develop against a "real" postgres database for a node backend app. It worked fine and made it pretty easy to spin up a development/CI environment anywhere you want. Only when inserting large amounts of data you start to notice it is slower than native postgres. I had to stop using it because we required the postgis extension (although there is some movement on that front!).
And it is the right thing to do as otherwise the question to which day a train belongs will be confusing. Just take it %24hours before intersecting trains.
It is also how I personally record time spans. It makes it much easier as you do not need to deal with the case where the start is larger than the end time and you can only have a single date field.
reply