Re:Git at Any Scale
by 10000truths on Thursday August 20, 2026 @07:19PM
(#49381612)
The product is proprietary, but the interface and semantics are documented and freely available. "S3-compatible object store" is a commodity at this point, so it makes sense to treat it as a primitive building block for a distributed system. Of course, each implementation will have its own set of idiosyncrasies and limitations, so you'll still have to make sure that any such divergent behavior doesn't interfere with your own system requirements.
[ Parent
| on HN ]
Re:Git at Any Scale
by mananaysiempre on Thursday August 20, 2026 @07:31PM
(#49381710)
Less of a commodity at this point than a few years ago, what with Minio immolating itself to be reborn as, excuse my French, AIStor.
Which is not to say that TFA’s approach is invalid or uninteresting, but the mechanics of how “an S3” works are really obscure to those of us not in the know.
Re:Git at Any Scale
by 10000truths on Thursday August 20, 2026 @08:03PM
(#49381953)
If you're looking specifically for self hosted S3-compatible object stores, then yes, the selection of available options is smaller. But an object store's ability to self-host is orthogonal to its compatibility with S3's interface and semantics.
Re:Git at Any Scale
by doodlesdev on Friday August 21, 2026 @12:22AM
(#49383758)
I'd argue that S3-compatible isn't exactly what you'd need though. You'd need S3-compatible with similar latency characteristics for read and write, with four nines of availability and 10+ nines for durability. [0]. Their metrics are, quite honestly, absolutely impossible for most engineering teams and companies to ever achieve, no matter how hard they work at it. In essence, what I mean is Cursor could migrate Origin out of Amazon's S3, but they'd lose a lot of reliability and/or performance in the process.
[0]: https://aws.amazon.com/s3/ (Click on Durability and availability)