No idea how the military analogy works but: large companies scale up by "in sourcing" their supplier's functions. Facebook collects their own metrics instead of using datadog. Their own logs instead of Splunk. Facebook's own high cardinality traces instead of Honeycomb. Own datacenters instead of buying from AWS. Own database(s) instead of Oracle.
And then, since you have all these integrated functions, you can spend headcount optimizing datacenter spend down. Hire a team to re-write PHP to make it faster literally pays for itself. Or kernel engineers. Or even HW engineers and power generation. And on the product side, you can do lots of experiments where a 1% improvement in ad revenue pays like the entire department's wages for the year. So you do a lot of them, and the winners cover the cost of the losers. And you hire teams to build software to run more experiments faster and more correctly.
The brakes on this "flywheel of success" is the diseconomies of scale outweighing the economies. When the costs of communicating and negotiation are higher internally than those external contracts you previously subsumed. When you have two teams writing their own database engine competing (with suppliers!) for the same hires. When your datacenter plans outpace industrial power generation plans. When your management spins up secret teams to launch virtual reality products with no legs.
There is only one problem with Meta: Facebook itself is like a TV show that has ran its course. He's riding off what he purchased: Instagram and WhatsApp, but being a product thief he cannot create anything new.
> I host meetups for indie founders, and several attendees earn their living through solo businesses. When I go to conferences like Microconf, I meet lots more.
> It for sure is but it's being ised to refute an affirmative assertion, not make it's own assertion.
To refute assertion you need to claim negation of that assertion, which is assertion in itself, as every negation can be rewritten to become affirmation, and vice versa.
This is not true. Producing a counter example to an assertion refutes the assertion.
While you can certainly argue that such a counter example entails the negation of the original assertion, that is not the same thing as claiming the negation of the assertion.
Putting forth an argument or demonstrating a counterexample is not the same as asserting all of the logical consequences of that argument.
The second statement doesn't actually imply that all cats are black but it does refute that all cats are white. It doesn't make it's own claim about all cats, it just adds an anecdote that doesn't conform to the first statement.
I misread the title as "proof work" not "proof _of_ work." The analysis makes sense, but has kinda always been true. So mostly depressing rather than insightful.
But part of me has been wondering for a while now whether proofs of correctness is the way out of the NVIDIA infinite money glitch. IDK if we're there yet but it's pretty much the only option I can imagine.
Yeah, it's pretty broad consensus that the Chinese opium epidemic was really on the parents. 19th century Chinese parents really dropped the ball there, and no further considerations or blame should be placed.
My parents are retired. How exactly do they come into play?
I'm actively avoiding Shorts, Reels, and whatever else with those mechanics precisely because they pull you in and snap an hour is gone with nothing of value to show for it. It's so totally different from regular long form videos.
We regulate addictive substances too, even for adults and without relying on parents. The amount of productivity and quality of life lost to these platforms must be staggering in aggregation.
One of the benefits of the move to app ordering is that I know for certain the order-taker got it right. And I can bookmark the custom order for later reuse.
Now it's just down to the kitchen to fulfill the order correctly, and while it's not 100% it's a lot, lot better.
It's always the kitchen for me across food places (in Australia). Ending up with pickles when I removed them. Ending up with coke zero instead of coke. But the worst is ending up with anything mock meat!
> I watch tons of bike races and highlights on youtube TV and then almost all my ads are for cars, generic laundry detergent, and obvious scam crap products, anything but something bike related
If I had to guess, niche products for niche interests have small ad budgets, but the random detergent ad buyer is happy to bid on anyone's eyeballs. You can't target ad buys that don't exist!
On the other hand, before I bought YT premium I was regularly getting ads for Chevron gas in Spanish (which I don't speak), and would be unsurprised if YT ad enshittification drove premium sales.
Every six months or so, someone at work does a hackathon project to automate outage analysis work SRE would likely perform. And every one of them I've seen has been underwhelming and wrong.
There's like three reasons for this disconnect.
1. The agents aren't expert at your proprietary code. They can read logs and traces and make educated guesses, but there's no world model of your code in there.
2. The people building these apps are unqualified to review the output. I used to mock narcissists evaluating ChatGPT quality by asking it for their own biography, but they're at least using a domain they are an expert in. Your average MLE has no profound truths about kubernetes or the app. At best, they're using some toy "known broken" app to demonstrate under what are basically ideal conditions, but part of the holdout set should be new outages in your app.
3. SREs themselves are not so great at causal analysis. Many junior SRE take the "it worked last time" approach, but this embeds a presumption that whatever went wrong "last time" hasn't been fixed in code. Your typical senior SRE takes a "what changed?" approach, which is depressingly effective (as it indicates most outages are caused by coworkers). At the highest echelons, I've seen research papers examining meta-stablity and granger causality networks, but I'm pretty sure nobody in SRE or these RCA agents can explain what they mean.
> The key insight: individual session failures look random. But when you cluster the hypotheses, failure patterns emerge.
My own insight is mostly bayesian. Typical applications have redundancy of some kind, and you can extract useful signals by separating "good" from "bad". A simple bayesian score of (100+bad)/(100+good) does a relatively good job of removing the "oh that error log always happens" signals. There's also likely a path using clickhouse level data and bayesian causal networks, but the problem is traditional bayesian networks are hand crafted by humans.
So yea, you can ask an LLM for 100 guesses and do some kind of k-means clustering on them, but you can probably do a better job doing dimensional analysis first and passing that on to the agent.
Great points, but I think there's a domain confusion here . You're describing infra/code RCA. Kelet does an AI agent Quality RCA — the agent returns a 200 OK, but gives the wrong answer.
The signal space is different. We're working with structured LLM traces + explicit quality signals (thumbs down, edits, eval scores), not distributed system logs. Much more tractable.
Your Bayesian point actually resonates — separating good from bad sessions and looking for structural differences is close to what we do. But the hypotheses aren't "100 LLM guesses + k-means." Each one is grounded in actual session data: what the user asked, what the agent did, what came back, and what the signal was.
Curious about the dimensional analysis point — are you thinking about reducing the feature space before hypothesis generation?
And then, since you have all these integrated functions, you can spend headcount optimizing datacenter spend down. Hire a team to re-write PHP to make it faster literally pays for itself. Or kernel engineers. Or even HW engineers and power generation. And on the product side, you can do lots of experiments where a 1% improvement in ad revenue pays like the entire department's wages for the year. So you do a lot of them, and the winners cover the cost of the losers. And you hire teams to build software to run more experiments faster and more correctly.
The brakes on this "flywheel of success" is the diseconomies of scale outweighing the economies. When the costs of communicating and negotiation are higher internally than those external contracts you previously subsumed. When you have two teams writing their own database engine competing (with suppliers!) for the same hires. When your datacenter plans outpace industrial power generation plans. When your management spins up secret teams to launch virtual reality products with no legs.
reply