I made a simple electron app to download podcast files. I needed an easy way to sync with a mp3 headphones that registers as a usb drive.

This is truly remarkable. Congratulations!

Going to try this later.

Assuming this was user tested in hand with your wife, it’s nice to this kind of project built for a real user.

So often, these tools lack usability because they’re built generically any use case. Here, it was designed for your wife’s bakery.

The process to build a site/app like this will only get easier and more defect-free over the coming months.

Can you post the STL files for the shell and Arms?

Great project.

Sure. I will add them on github later today. The repo is currently in a very messy state. I would like to clean it and provide detailled assembly steps but I have to much work currently. Hopefully I can do this in a couple of months.

Done. Added stl files to the repo.

What do you get if you multiply six by nine?

42!

I was looking for Astral’s future plans to make money. Simonw already answered in another post [1] tldr - keep tooling open and free forever, build enterprise services (like a private package registry) on top.

[1] https://news.ycombinator.com/item?id=44358482

Good thing to highlight. I'm not sure I'd bet on the game plan, but uv is an incredibly useful tool which I also wouldn't have bet on. Hopefully Simonw is right, and Astral can maintain as is.

the fact that there are 3 "hopefullys" in the paragraph that explains the strategy doesnt inspire much confidence.

I dont think there is enough money in package registries to pay for all of the VC investment in astral.

Well, that's basically the core of Anaconda, and it's working for them.

That said, I've checked Anaconda's site, and while it used to be "Anaconda [Python] Commercial Distribution", "On-Prem repositories", "Cloud notebooks and training"... during the last year they've changed their product name to "Anaconda AI Platform", and all it's about "The operating system for AI", "Tools for the Complete AI Lifecycle". Eeeeh, no thanks.

not sure i hold out much long term hope for them either. both of these companies can eventually make money in a way that isnt shady - just not enough money to satisfy their VCs.

I’ve hit similar problems with their Ruby gRPC library.

The counter example is the language Go. The team running Go has put considerable care and attention into making this project welcoming for developers to contribute, while still adhering to Google code contribution requirements. Building for source is straightforward and iirc it’s one of the easier cross compilers to setup.

Install docs: https://go.dev/doc/install/source#bootstrapFromBinaryRelease

Go is kinda of a pain to build from source. Build one version to build another, and another..

Or rather it was the last time I tried.

I think that's how most languages bootstrap.

Is your plan to stick with a hashing algorithm for tenant sharding, or allow for more fine grain control to shift large tenants between and shards?

Hot shard management is a job in of itself and adds lot of operational complexity.

I've been thinking about other algorithms as well, like range-based. We can definitely override the algorithm for hot shards. Ideally, we match what Postgres does with partitions: range, hash, and list. That way, we can shard both inside Postgres (e.g. with postgres_fdw) and at the proxy.

I think the first step is to add as much monitoring as possible to catch the problem early. There is also the dry-run mode [1] that you can try before sharding at all to make sure your traffic would be evenly split given a choice of sharding key.

[1] https://pgdog.dev/blog/sharding-a-real-rails-app#dry-run-mod...

If you want to imply some likelihood for it to be proven, you might write “yet to be proven”. Language subtleties…