But but it's "written in Rust™" it is "safe" to use, and it has lots of tests! Surely the author has written lots of Rust before in the past? /s
We are in the era where anyone can call themselves a "software engineer" and never checks or understands the code or writes the tests (or knows what to test for) at all.
themgt 3 hours ago [-]
We've created Walinux, a Linux that runs as a durable object in S3, so it's diskless, serverless, transistorless, electricity-less, scales to zero and infinity simultaneously, and can be traded as an NFT ape. Mathematicians are dumbfounded.
The thirty-five thousand other "S3-backed CLI tool for AI" projects are now obsolete.
pelagicAustral 3 hours ago [-]
What would be really cool would be to host apps in your own brain, that way we can harness the power of your own heart to run the stack.
How did this project get more than 1000 stars in just a few days? Are GitHub and Ycombinator (both company and chatbot-community) just fake and manipulative?
skrebbel 3 hours ago [-]
Because it was made/vibed by the Shopify CEO who has a pretty good twitter game
inigyou 1 hours ago [-]
Uh, obviously yes to both?
lloydatkinson 3 hours ago [-]
Even the README… ugh.
> no state that matters
gravypod 58 minutes ago [-]
Is there a market for an actual GitHub competitor now that everyone is looking around and is very angry about stability?
inigyou 55 minutes ago [-]
There are already several but it turns out that network effects dominate all else, so there is not and never will be a market. Just like Sourceforge, nothing will replace it!
zoobab 1 hours ago [-]
Tarballs over FTP was better.
the_alchemist 8 hours ago [-]
I'm confused by the usage of the word consensus in the explanation, to me it seems like a last-write-wins strategy, no consensus involved?
brunes 2 hours ago [-]
The description came from an LLM. It's slop.
drifkin 7 hours ago [-]
the compare-and-swap prevents out-of-sync instances from stomping on the source of truth manifest
baalimago 8 hours ago [-]
I am working on a very similar mcp server which allows agents to communicate and share notes without race conditions, using git and s3 as the driver [0]. Funny how "inventions" like these pop up independently.
There's a git server, it's installed when you install git, and it really does work very well.
> every instance is a disposable cache that revalidates with one conditional GET. No database, no Redis, no gossip, no leader, no node identity.
Git famously doesn't use that either...? What is the point?
> "just put the repositories on NFS" failed at every large host that tried it
Yeah, that's a terrible idea. You can just host Git on a server or two. Where's the limit? How much does it scale to put a single 64 core server with a 10 gbit link on a local network and put ONLY git on it? Is that really that slow and bad? You can give it 20+ TB of RAID storage for VERY cheap. What is the limit you're hitting? 200ms ping to it from across the world? Is that the issue we're solving?
> walgit takes that as-is, and adds what a monorepo on small machines needs: serving refs and web pages for a repository whose packs will never fit on the instance (a remote reader over HTTP range requests), keeping commits and trees local while blobs stay in the bucket (the history pack), and moving clone bytes out of the server entirely (bundle-uri: fresh clones and catch-ups are static files the bucket or a CDN hands out).
So it's about monorepos that, for some reason, have blobs large enough to be impossible to serve via range requests, shallow clones, etc? Are people committing binary blobs of 1TB+ to their git? There's Git LFS, that hooks up an object store (like S3) to git for large files.
As an aside, I kind of adore that Tobi's latest post on his website, from 2019, talks about shopify's carbon emissions, meanwhile today his github is full of AI slop projects and enabling others to "vibe" even harder. He also missed that his clanker wrote an announcement post; https://github.com/tobi/walgit/blob/main/docs/announcing-wal...
The blog article explains why this is needed — that is, needed by any git-based code forge that wants to scale to many, many repos.
gexla 2 hours ago [-]
My understanding was that it was totally an experiment to create something that works like Cursor's Origin or whatever it's called. Just the idea of it is probably not something you would care about for your own usage.
ljm 3 hours ago [-]
The irony is that S3 is a database, so the first assertion that there is no database is fundamentally incorrect.
inigyou 1 hours ago [-]
Pedantically the .git folder is a database, but so is S3.
brunes 2 hours ago [-]
You're debating with AI slop...
Tobi didn't write any of this. He probably has never even read it.
We are in the era where anyone can call themselves a "software engineer" and never checks or understands the code or writes the tests (or knows what to test for) at all.
The thirty-five thousand other "S3-backed CLI tool for AI" projects are now obsolete.
see: https://news.ycombinator.com/item?id=48661938
> no state that matters
[0]: slivingdoc.dev
There's a git server, it's installed when you install git, and it really does work very well.
> every instance is a disposable cache that revalidates with one conditional GET. No database, no Redis, no gossip, no leader, no node identity.
Git famously doesn't use that either...? What is the point?
> "just put the repositories on NFS" failed at every large host that tried it
Yeah, that's a terrible idea. You can just host Git on a server or two. Where's the limit? How much does it scale to put a single 64 core server with a 10 gbit link on a local network and put ONLY git on it? Is that really that slow and bad? You can give it 20+ TB of RAID storage for VERY cheap. What is the limit you're hitting? 200ms ping to it from across the world? Is that the issue we're solving?
> walgit takes that as-is, and adds what a monorepo on small machines needs: serving refs and web pages for a repository whose packs will never fit on the instance (a remote reader over HTTP range requests), keeping commits and trees local while blobs stay in the bucket (the history pack), and moving clone bytes out of the server entirely (bundle-uri: fresh clones and catch-ups are static files the bucket or a CDN hands out).
So it's about monorepos that, for some reason, have blobs large enough to be impossible to serve via range requests, shallow clones, etc? Are people committing binary blobs of 1TB+ to their git? There's Git LFS, that hooks up an object store (like S3) to git for large files.
As an aside, I kind of adore that Tobi's latest post on his website, from 2019, talks about shopify's carbon emissions, meanwhile today his github is full of AI slop projects and enabling others to "vibe" even harder. He also missed that his clanker wrote an announcement post; https://github.com/tobi/walgit/blob/main/docs/announcing-wal...
The blog article explains why this is needed — that is, needed by any git-based code forge that wants to scale to many, many repos.
Tobi didn't write any of this. He probably has never even read it.
PicoMQ also showing up today, a Durable Streams implementation on object store (S3). https://news.ycombinator.com/item?id=49421806 https://picomq.com/
Celld, a Durable Objects implementation, is also heavily heavily using conditional put, for all manners of coordination. https://news.ycombinator.com/item?id=49185430 https://celld.dev
Longstanding SlateDB is built around it too! https://news.ycombinator.com/item?id=41714858 https://slatedb.io/
Yet another fine example here! Data comes in, we make sure we don't overwrite work, we write what we have.
And it has since Terraform v1.11
Amazing he still codes. But likely more experiment than prod level.