rubiquity

And they are making great progress on the software side. ROCm 10 is significantly better than 7.x

Continuing the never ending trend of Sys Admins/DevOps/SRE job title holders with skills in specific tools rather than foundational skills always wondering why they are out of a job every 5 years.

Nice I started a timer for how quickly a "well actually, SRE at google" would show up and you did not fail to deliver.

> The point of SRE is to have a team dedicated to scaling/resilience to balance the tension between product pushing to ship features.

Sounds like a cultural issue. Google should look into that.

SRE was always a lame job description and so was the entire "DevOps" movement we had to suffer through during ZIRP. Real ones are oncall for the systems they build.

First signs that Search revenue might be peaking.

I may be one of the few to use Crystal in anger for long running programs but unfortunately we had to do away with it because of longstanding issues in the runtime where exceptions at the wrong time during I/O bring the runtime to a halt. It's been a few years so I don't have the github issue off the top of my head anymore. I'd like to think that if they could redesign the language again they would not have exceptions and destructors/finalize.

It's a great language for CLIs though. I'm glad to see the team still pressing on.

the absolute best one: systemd

Well, yeah I guess that just about sums it up.

I went the opposite way and went back to Intel after many many years on AMD. I snagged a Xeon 654 Granite Rapids ($850) for a new workstation geared towards local inference. I don’t need a ton of CPU cores and all Granite Rapids have 8 memory channels where as you need very high end Threadrippers (9975wx for $4000) for an equivalent due to their CCD design.

As a bonus Granite Rapids is super power efficient and runs much cooler than my previous TR and Ryzens. Intel seems to be doing good things again! My only minor complaint is that P2P doesn’t work on my multiple GPU setup because every PCIe5x16 lane has its own dedicated root to the CPU, but all that bandwidth is useful for MoE models that are offloaded to RAM.

No model will ever figure out how to make a ling tight wall.

RIP. I always think of him for his performance in Home Alone 2.

This feels defensive and reactionary after Ramp started getting deeper into AI.

Boy am I feeling this. I had my eye on building a new Threadripper machine, which requires DDR5 RDIMMs. Much to my surprise while happily building out a parts list one fine evening I learned that these are going for between $500 and $1000 for one single 16GB module right now. I think I'll hold off and squeeze a few more years out of DDR4 and PCIe 4.0.

I love what you all do! I don’t have any to submit. Enough time with consensus teaches you to avoid it unless it’s really, truly needed.

My experience as well. LLMs also struggle with Rust's many abstractions and offerings but you can know that if it compiles it is data race free and work with the LLM to use better abstractions over time.

Zig is also good at this but requires more up front design (thread-per-core, static allocation, etc.) and consistent checks to verify rules are followed.

etcd has had numerous liveness and safety bugs, with one happening as recently as December of 2025. Would you consider that a correct implementation?

You may be interested in knowing that the largest managed Kubernetes service in the world (AWS EKS) ripped out etcd for in favor of their homegrown consensus service for large scale EKS clusters: https://aws.amazon.com/blogs/containers/under-the-hood-amazo...

Thank you. I don't know why this is so complicated.

But they are misreading what I said. My original post is clearly about Go. What they wrote is also ambiguous.

> The antithesis author states:

> "we’ve found bugs in every Raft implementation we’ve tested, including HashiCorp Raft, Aeron Cluster, OpenRaft, and MicroRaft"

What are they implying by citing that? That every language has a Raft implementation with bugs? Yes that's probably accurate because lots of people make Raft implementations for fun and learning. Again, Go does not have a single Raft/Paxos implementation that is rock solid. I have seen many in C++, Java, and Rust that are doing tens of millions of requests per second in production for over a decade.

Is their point that Go is not the only language with this problem? My post already points out the track record is that Go is the problem for writing correct code in highly critical domains.

The intersection of the set of Raft libraries Antithesis tested and all Raft libraries in existence do not fully overlap. I personally have worked on multiple proprietary ones that Antithesis would not have access to.

You're misreading what I said. I didn't say other languages don't have buggy Raft/Paxos implementations, just that Go is yet to yield a single correct one.

Matches my experience as well. Go fans have conflated "can easily make something concurrent" with "does concurrency well." Go's primitives for concurrency should almost never be used directly and Engineers below a certain skill level shouldn't be allowed to use them directly ever for long running production code.

As another example, Go still has not yielded a correct implementation of Raft or Paxos while there are dozens in Java, C++, and Rust. Antithesis found some more bugs in HashiCorp's Raft implementation recently[0]. I'm sure etcd still has some kicking around.

Maybe this is a "don't throw the baby out with the bath water' problem but the general evolution of Go has been lackluster. I reach for Rust, Zig, and modern Java instead depending on the specific needs and constraints.

0 - https://antithesis.com/blog/2026/finding-bugs-in-raft-implem...

There isn't. I'm 15% body fat, eat healthy (avoid saturated fats, prioritize fiber), exercise 5-6 times per week, and have hypercholesterolemia. I, along with my parents, have very high LDL and ApoB and nothing I can do about it in terms of diet, exercise, or weight.

I'm also not uncommon. They suspect as much of 30% of the population could be like this. There's a lot of ignorance in this thread.

Heidi's more abstract work on generalizing consensus as grids/matrices of intersecting registers is geoemtric.

I think it's fair to say they had achieved product-market fit when their revenues were growing deep triple digits month over month. What we're seeing now is that perhaps they have achieved profitability or at the least a more sustainable balance sheet.

This was already known to be true by Heidi Howard’s research that yielded Flexible Paxos[0], Relaxed Paxos[1], and her more general thesis on Distributed consensus[2] as a whole

0 - https://fpaxos.github.io/

1 - https://dl.acm.org/doi/10.1145/3517209.3524040

2 - https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-935.pdf

AWS has CLIs and SDKs in many languages.

People laugh at this, myself included in the past, but it works. I remember scoffing at AWS partnering with Deloitte and Accenture over a decade ago. My exact thoughts were "Our technology is great, why do we need these people to sell it?", and it turns out that selling to enterprises at scale is a lot more like an American high school experience than anything else.

This is what I ended up doing. A 2.5G switch for the few devices that can use it and a 1Gbit+PoE switch for all the other PoE and 1Gbit and less devices.

I use Pi at home and Claude Code at work (no choice). I use bone stock Pi. No extensions.

You should try it out. I'm incredibly impressed with Qwen 3.5 27B for systems programming work. I use Opus and Sonnet at work and Qwen 3.x at home for fun and barely notice a difference given that systems programming work needs careful guidance for any model currently. I don't try to one shot landing pages or whatever.