@0xabad1dea that's nothing, you should hear about google3 and Piper

@0xabad1dea what's the quote from Art of War go? "when your opponent is making a mistake, do not interrupt them", something like?

@0xabad1dea honestly I'm pretty amused that they think they can do better than git with vibe coded slop. Human engineers made a system that isn't efficient enough? Simply tell the human-engineer-code-thief to plagiarize something faster! Surely this will result in a version control system that meets their needs, rather than a steaming pile of security vulnerabilities that only works intermittently by random coincidence!

@0xabad1dea They don't need a git, they need a NULL device.

I think storing their updates in the NULL device would solve a large number of problems for everyone....

@0xabad1dea but number go up, may be wrong number, but still go up

@0xabad1dea Actually reading that it seems they've just written a client/server version control system.

Those have their advantages especially in corporate environments but they're hardly new, as someone who wrote and maintained one back in the day.

@0xabad1dea

They have unlimited tokens to burn. I'm sure Claude can vibe-code them a new SCM in a couple of days. Bug-free of course. /s /s /s

#AI #Insanity

@0xabad1dea

the US military learned the hard way that if you think that a commercial off the shelf solution (COTS) didn't solve your problem, it usually meant that you hadn't understood the problem well enough, not that you needed an expensive custom solution made just for you.

@0xabad1dea Same energy as the time Facebook decided to reimplement the Android app loader inside their own app because it got too big for older models to successfully start.

They also surpassed the vm methods limit for good measure while they were at it.

https://www.slashgear.com/how-facebook-fixed-its-gingerbread-dalvik-problem-04272478/

@0xabad1dea This looks like an example of how having so much VC funding you can throw resources at anything ("oh, let's just write our own git") is a huge handicap for keeping your eyes on the prize.

@0xabad1dea I know that is a very unpopular opinion on Mastodon, but this makes perfect sense. As we move from human-driven to AI-driven software development, many of our assumptions about what constitutes clean software development practices will have to change, i.e. adapt to new bottlenecks and characteristics. Whether moving to thousands of concurrent commits is one such change, I do not know, but it is definitely within the realm of possibility and should, in my mind, not immediately be discounted.

@jones “one beer feels good, two beers feels great, the doctors telling me not to chug thirty thousand beers a day need to reevaluate their assumptions about how fun it is to be drunk”

@tony I’m not sure what you’re “actuallying” because the architecture of the vcs is completely irrelevant to the actual problem here

edit: I see now you sent multiple separate replies, sorry I got a lot of them

@raphaelmorgan they may well have come up with something that indeed does handle 30k commits per day better than git, at the cost of whatever tradeoffs. It may or may not randomly corrupt all their data in three months, but separate from that: the real problem is that they have 30k commits per day. That is completely unreasonable for their scale and it's quite clear that most of those commits are just Claude doing random unsupervised churning and no human even knows what it is or does.

It's an exponentially growing house of cards.

@gothodile if Anthropic took advice from me, I'd have fixed the world already

@0xabad1dea my favorite Piper fact is the devs added deliberate logic to ensure the system never generates any "interesting" changelist numbers (round numbers, digits of pi or e, repeated digits etc etc. they were very thorough). Because internal devs kept writing shell scripts to compete to get changelist #400000000 or whatever, generating hundreds of disposable changelists and overloading the servers the entire workforce depended upon just to get some minor nerd cred

@fraggle @0xabad1dea

I'm sorry, people were doing what?

@remmy @0xabad1dea Piper is Google's internal clone/rewrite of Perforce using its own infrastructure. They have a single monorepo called google3 that stores almost all of the source code for the entire company's products. I don't know how many engineers that is nowadays, but certainly O(10,000s) all using one repo. To make any change you create a "changelist", kind of like a PR in Git terms. Changelists are assigned as a monotonically increasing quantity. So when the company would get close to some significant epoch like "changelist #100000000" a bunch of engineers would all run shell scripts creating hundreds of new changelists to get the nerd cred of being the one to create that one special changelist number.

@fraggle @remmy @0xabad1dea

................Why in *THE FUCK* would you *reimplement* *Perforce*?

@fraggle @remmy @0xabad1dea One time back in the late-80's/early-90's it was my job to config and admin a P4 SVCS for internal use. For a DOS/Win3.1 app.

And I miss simple "change-lists".

I'm sure there are people competing for CI/CD build number magic, burning cycles in some DC.

But it is stunning that Google is using P4-like SVCS.

@jab01701mid @remmy @0xabad1dea if you ever use or have used Gerrit, its strange workflow might make more sense when you look at it through this lens. It's basically reproducing the Google internal Piper/Perforce workflow on top of Git

@emc2 @remmy @0xabad1dea as I understand it, rewriting it was easier than changing the workflow of every engineer in the company and migrating all the infrastructure that had been built on top of it. TBF it did have some genuine quality of life improvements over the original Perforce ("client in the cloud" virtual filesystem etc)

@fraggle @remmy @0xabad1dea

Migration from Perforce to git is pretty painless. I did several such migrations some time back. It's installing a plugin and then running the migration command.

It is certainly less pain than actual *using* Perforce for even a planck unit of time

@emc2 @remmy @0xabad1dea well, the maintainer of Git has been a Google employee since 2010 and they haven't been able to do that. So perhaps not as simple and painless as you might think

@emc2 @fraggle @remmy @0xabad1dea git would be a legitimately bad choice for what Google are doing - you can’t have everyone needing to pull every change anyone in Google made to get the one change they do care about in a subset of that. Also distributed version control makes no sense in a company where to my understanding it’s not permitted to have source checkouts on your local device.