Regular Ryzen parts are still reasonably relevant for server use! They support ECC, so there's nothing immediately disqualifying them - see the rebranded "EPYC" 4005 series, for example.
A company like Hetzner isn't going to care an awful lot whether they deploy one big SP5 server or four small AM5 ones for the VM instances they rent out: the only thing that matters is TCO per performance.
Want to stick four NVMe SSDs, a 25Gbit NIC, 256GB of ECC RAM, and some OOB module on a Ryzen board? No problem whatsoever. Want to do the same with an Apple CPU? Ehhh, that's going to be slightly more challenging...
But who's going to filter out the good AI contributions from the bad AI trolls and bargain-bin-model slop?
With AI there is an infinite stream of contributions to curate. No human is ever going to volunteer for that, so unless you keep AI contributions very tightly restricted you'll rapidly lose all human contributors. At which point nobody is left to ensure only good contributions get in, so it is only a matter of time before it devolves into a giant pile of crap.
Besides, who's going to pay to run those AIs? Good models aren't free, so you are effectively turning it into a pay-to-win project. You can be absolutely certain that some tech billionaires are going to burn a few million to have "good AI" constantly rewrite their pages the way they want it.
So why have we stopped building pyramids for thousands of years? We have the technology and knowledge to do it, so where are all the new pyramids? And no, that Las Vegas monstrosity doesn't count.
You might be surprised to learn that not all challenges are purely technological. The biggest challenges with such megaprojects are political, economical, and social. A Wikipedia clone is completely worthless if nobody is willing to contribute - it would just be an empty database!
I agree, but I think the reason why we don't build pyramids today is because it would be a huge waste of resources. I guess you don't think much of Las Vegas-- me neither-- but the sphere is pretty darn impressive. There are all kinds of examples around the world with amazing architecture. The Hoover dam, the Golden Gate bridge, etc. If the Egyptians could have done these things they would probably not have built pyramids.
As an aside. When the Eifel Tower was built it was considered tacky by many and assumed to be temporary. Maybe some of the most remembered things of our time will be taken for granted. Maybe some huge data center will be a museum.
> And no, that Las Vegas monstrosity doesn't count.
Why doesn't it? The owner isn't buried in it?
> The biggest challenges with such megaprojects are political, economical, and social
Indeed; this is why we moved on from piling rocks in a formation that didn't fall down easily, and put all those things you list into cathederals, hydroelectric dams, the Apollo missions, etc.
> Indeed; this is why we moved on from piling rocks in a formation that didn't fall down easily, and put all those things you list into cathederals, hydroelectric dams, the Apollo missions, etc.
Several hours later, I realise we have many things which would seem like much more impressive versions of the pyramids, in the event of the collapse of industrial civilisation followed by a second renaissance and future archeological digs looking at us as we looked upon the tombs of Tutankhamen: artificial hills made by covering landfill likely contain a lot more precious metal than a pharaoh's tomb.
I guess it is because pyramids were built at a time of tyrranical supreme leaders with 100% of power and wealth concentrated in themselves. That and fashion
Wikipedia became popular despite its programming. Anyone who has ever tried to edit a Wiki page knows its editor is absolute garbage, for example. Want to create your own basic DIY wiki in 2026? Just set up a GitHub Pages which auto-accepts pull requests, you'll be up and running in less than 30 minutes.
Besides, nobody is forcing to to use the current programming paradigms. A classic LAMP stack will still work.
Okay, but why would they? And who's going to consume?
If anyone can trivially create, every creation is meaningless. There is no billion-dollar business in abandoned Minecraft servers, so why would this suddenly change when you force people to put on an expensive VR headset to visit them?
> If anyone can trivially create, every creation is meaningless.
Everyone has always been able to trivially create. We live in an attention economy, not a creativity economy. Meaning you can create crap (or ai slop) and people will consume it if you know how to get their attention.
Attention is what gets money. Creation is just fuel for attention. Quality is a part of the equation, but much less important than people generally believe.
Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?
Sure, it's nice that you can technically handle it, but to me it sounds like at that point something has gone absolutely horribly wrong in the way you set up your agents. Last time I checked, GitHub was intended as a platform to upstream finished work items, not a realtime cross-agent chat channel.
Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
How about introducing rate limits instead, nudging people to not have agents push every individual single-line changes to GH, but instead have them collaborate as a local cluster and only upstreaming PR-sized chunks of finished work?
If you still need thousands of pushes per second you'd be looking at millions of lines of code, and at that point you're looking at an insane monorepo which is growing at a rate of terabytes per day, and which basically instantly becomes unusable due to being impossible to clone or check out.
My understanding is that forks on GitHub share the same storage in the GH backend.
It's not unreasonable to imagine thousands of commits per second to the kernel, especially if you consider that bots might be watching LKML and applying patches to various forks.
> Handling thousands of git pushes per second implies thousands of issues, thousands of PRs, tens of thousands of comments, thousands of Actions runs, and dozens of releases. How's that part of their infra going to scale?
For each issue my agent might raise 5 independent PRs as experiments.
Further, the more changes there are, the more important it is that they don't conflict, which means smaller changes, which means even more changes.
Bots interleaving typos, single line whitespace fixes, single dependency bumps, etc.
A different way of looking at this is that it gives GitHub a huge amount of headroom. The architecture they're describing sounds more efficient at lower rates too, it's not like better throughput and efficiency only benefit repos that are reaching the maximum limits.
Plenty of people (and agents), me included, use commit-and-push as an equivalent to "Save". You spill coffee on a day of unpushed work once, you stop caring about dogma like "commits should be finished, testable, reviewable units of work with discrete, human-readable descriptions" and start treating your Git remote as your backup system.
Besides, you can push amends to your branch, or describe/review/squash your changes at PR merge time anyway, so what's the harm of a zillion pushes? Other than "GitHub engineers have to invent a novel database", that is. But that's probably enrichment for them.
> Sorry, but thousands of pushes per second, per repository?! In what world could that possibly seem like a sound idea?
The only conceivable scenario that I can imagine leading to this volume of writes is a push-based GitOps repository for a huge cluster holding a large volume of apps, each one with many services. Each commit in one if these services triggers a commit to the gitops repo to update the reference to the new container image, which in turns triggers a deployment update.
There is no software project on earth that justifies a rate of changes in magnitudes of dozen of commits per second. This is a symptom of a huge problem, not a sign of times. Even in monorepo mania this sort of thing is inconceivable.
But that's also what you get with vibecoding: lots of output from people who do not have a clue about what they are doing.
Anthropic is renting GPUs and calling it technology.
Sure, they have some flashy models, harnesses, and tooling around it, but their competition isn't that far behind - and some of that competition is 100% free. Their moat is closer to a puddle, to the point that there are entire companies built around the concept of dynamically routing requests either to them or their competitors.
Anthropic is the market leader in a rapidly-evolving market, where customers can and will jump ship the second a competitor's model looks shinier or cheaper.
> Anthropic is renting GPUs and calling it technology.
While you can imitate the style of my response by ignoring all of the technical details, you've still ignored all of the details.
WeWork was not a technology company. Anthropic is. You even admit it, but you want to hide your actual argument ("the technology is a commodity") behind an irrelevant rhetorical flourish.
It's fine to argue that Anthropic's business is bad. You don't need to make a ridiculous, unsuitable metaphor on top of it.
I didn't claim the valuation is reasonable. I said that the comparison with WeWork is ridiculous.
> The problem with WeWork's IPO wasn't that they aren't a tech company. It's that they didn't have a good enough business model.
No, they had a fine business model - there are many other companies using it today (including WeWork). It just wasn't worth a technology company multiple.
(Let's also not forget the mountain of crazy things - such as the founder leasing his own properties to the company at sweetheart rates - in the WeWork S1, that actually torpedoed the offering. Anthropic's listing is nothing like WeWork. Nothing. Not even remotely.)
One slight problem with that: drivability is actually better.
Let's say you have space for two lanes. You can either a) install two car lanes, so >95% of people drive, or b) install one car lane and one bike lane, so 75% of people cycle. Which one is more drivable? Hint: it's the one with significantly fewer cars.
Similarly: car infrastructure takes up a lot of space. If your destination is 10% closer because cycling means far less car infrastructure is needed, you'll actually end up driving there faster.
A street's car traffic capacity is far less important than its total traffic capacity, and the last-mile driving speed is a rounding error on the whole trip. If you like driving, you should be in favor of building more bike infrastructure!
Bidirectional dedicated bike paths are usually at least car-sized. They will fit a regular plow just fine. Monodirectional bike lanes usually lack separation from the rest of the road, so they get plowed for free as a side-effect of plowing the car lane.
A company like Hetzner isn't going to care an awful lot whether they deploy one big SP5 server or four small AM5 ones for the VM instances they rent out: the only thing that matters is TCO per performance.
Want to stick four NVMe SSDs, a 25Gbit NIC, 256GB of ECC RAM, and some OOB module on a Ryzen board? No problem whatsoever. Want to do the same with an Apple CPU? Ehhh, that's going to be slightly more challenging...
reply