3,205 karma · joined July 24, 2009
<https://tools.simonwillison.net/svg-render#%3Csvg%20font-fam...> <https://tools.simonwillison.net/svg-render#%3Csvg%20font-fam...>
- I was having trouble embedding the SVGs as links, and ChatGPT recommended Simon Willison's SVG Renderer as a workaround.
Just my 2 cents on the pelicans benchmark: I think it might help if you were a bit more explicit about not taking this one benchmark too seriously. I know you say that at times, but at other times (such as the comment I'm replying to) you elide it which can read as a seriousness about the benchmark.
> Based on actual auction clearing prices and quantities and uplift MW, inclusion of existing and forecast data center load growth resulted in a combined total increase in capacity market revenue for the 2025/2026 BRA, the 2026/2027 BRA, and the 2027/2028 BRA of $23,100,955,341.
This is the increase in revenue to PJM from adding datacenter customers, and includes both the amount that datacenters paid as well as the amount that other customers paid due to higher prices from datacenters. So Fortune calling it an increase to "the public" means that they didn't read the report they are using as their source and are probably just repeating what they thought someone else meant.
Bloomberg in the past worded it as "data centers will add at least $23 billion to customer bills" in April and "added a minimum of $23 billion to customer bills" in February. Which while technically correct (datacenters are customers) seems meant to be misleading. And now that's the number that's getting thrown around as the increase to "the public".
The part I don't get is that the journalists could just give the actual number for the quantity that they are referring to (the amount that non-datacenters paid due to higher rates due to datacenter loads): when I calculated it a few months ago I think it was something like $16 billion rather than $23 billion. I feel like the story would have the same impact if the headline number was $16B as $23B, but $16B has the benefit of not being a misrepresentation of the situation.
---
Also I would definitely recommend checking out the PJM BRA report. It's a bit dense but not too hard to follow, and my personal takeaway was that the PJM market is just very dysfunctional and they are blaming the datacenters instead. I thought SemiAnalysis had a good analysis of it: https://newsletter.semianalysis.com/p/are-ai-datacenters-inc...
Personally I think it's necessary to run opencode itself inside a sandbox, and if you do that you can see all of the rejected network calls it's trying to make even in local mode. I use srt and it was pretty straightforward to set up
Your [ORGNAME] chats aren’t used to improve our models
The Google Workspace privacy hub is similarly easy to read and clear that they don't train on your data: https://support.google.com/a/answer/15706919So they definitely understand that people want to hear that their data isn't being used for training, and they know how to say it clearly and reassuringly. Which makes the omission of that in their consumer products more telling in my view.
page 21, says Arizona 2015 golf course irrigation was 120 million gallons per day, citing the US Geological Survey.
https://dgtlinfra.com/data-center-water-usage/
says Google's datacenter water consumption in 2023 was 5.2 billion gallons, or ~14 million gallons a day. Microsoft was ~4.7, Facebook was 2.6, AWS didn't seem to disclose, Apple was 2.3. These numbers seem pulled from what the companies published.
The total for these companies was ~30 million gallons a day. Apply your best guesses as to what fraction of datacenter usage they are, what fraction of datacenter usage is AI, and what 2025 usage looks like compared to 2023. My guess is it's unlikely to come out to more than 120 million.
I didn't vet this that carefully so take the numbers with a grain of salt, but the rough comparison does seem to hold that Arizona golf courses are larger users of water.
Agricultural numbers are much higher, the California almond industry uses ~4000 million gallons of water a day.
I find "1 liter per kWh" to be a bit hard to visualize, but when they talk about building a gigawatt datacenter, that's 278L/s. A typical showerhead is 0.16L/s. The Californian almond industry apparently uses roughly 200kL/s averaged over the entire year -- 278L/s is enough for about 4 square miles of almond orchards.
So it seems like a real thing but maybe not that drastic, especially since I think the hyperscaler numbers are better than this.
1. Go to their enterprise site
2. See what privacy guarantees they advertise above the consumer product
3. Conclusion: those are things that you do not get in the consumer product
These companies do understand what privacy people want and how to write that in plain language, and they do that when they actually offer it (to their enterprise clients). You can diff this against what they say to their consumers to see where they are trying to find wiggle room ("finetuning" is not "training", "ever got free credits" means not-"is a paid account", etc)For Code Assist, here's their enterprise-oriented page vs their consumer-oriented page:
https://cloud.google.com/gemini/docs/codeassist/security-pri...
https://developers.google.com/gemini-code-assist/resources/p...
It seems like these are both incomplete and one would need to read their overall pages, which would be something more like
https://support.google.com/a/answer/15706919?hl=en
https://support.google.com/gemini/answer/13594961?hl=en#revi...
At some point they updated their privacy policy in regards to this, but instead of saying that this will cause them to train on your data, now the privacy policy says both that they will train on this data and that they will not train on this data, with no indication of which statement takes precedence over the other.
[1] https://openai.com/index/openai-o3-mini/ [2] https://www.vals.ai/benchmarks/aime-2025-03-24
You just have to use the models yourself and see. In my experience o3-mini is much worse than o1.
2.0 Pro is also still "experimental" so I agree with GP that it's pretty odd that they are "releasing" the next version despite never having gotten to fully releasing the previous version.
He's one of the few people I've seen address what I think is the key difficulty with this sort of stuff: that you can think think that you're addressing procrastination/perfectionism when actually you are engaging in it (with a target of fixing your procrastination/perfectionism). It's a difficult situation to break out of, because it seems like any effort to break-out would necessarily have this sort of grasping, but I think he (and Buddhist meditation) talk a lot about that key challenge.
> I have a dream for the Web [in which computers] become capable of analyzing all the data on the Web – the content, links, and transactions between people and computers. A "Semantic Web", which makes this possible, has yet to emerge, but when it does, the day-to-day mechanisms of trade, bureaucracy and our daily lives will be handled by machines talking to machines. The "intelligent agents" people have touted for ages will finally materialize.
I quoted this from https://en.wikipedia.org/wiki/Semantic_Web since the original reference was a book that is not openly accessible. Also I think it's funny that he's talking about agents in exactly the same way that people do now.
I notice this myself a bit when I switch from a fullsize monitor to a laptop screen.
I'm not taking a position here, and I'm not saying even that these stances are necessarily contradictory, but just that the blanket argument "X shouldn't get to be secret because I don't think they have a legitimate reason" doesn't differentiate between these two cases.
But actually Kagi is quite good and definitely worth it. I have regained the expectation that when I search for something I will find the thing that I want, and I hadn't realized how much I had lost that with Google. It's hard to demonstrate this because I think it's an accumulation of many small improvements, so I encourage people to give it a try and see for themselves.
I do worry that this won't last forever -- for example, I think the AI features are being provided below-cost to gain market share, and it does worry me that they're spending so much money on these tshirts. But I can always switch away later so I don't worry about it that much.
This (wanting higher density) is the opposite of the trade-off that I was expecting. In my (limited and out of date) experience, power was the limiting factor before space, and I believe AI racks have very high power draws already.
I would have guessed this would be because larger nodes would be better for AIs tight communication patterns, but they specifically call out datacenter space as the constraint. Curious if anyone knows more about this
But this nogil version is the first time we have an actually working GIL removal. All of the other ones were incomplete to the point of being non starters, and mostly served as discussion material. This is an actually working implementation which deals with the subtle issues that the other projects didn't even get to, and has gotten to the point that it's a technical possibility to commit it to main (though obviously with a huge migration to think about). So in this sense this is a very different discussion than all of the previous discussions about the GIL
As for this particular issue I think this wikipedia page is relevant: https://en.wikipedia.org/wiki/Impredicativity
- They absolutely do have to serialize, usually via pickle. I'm pretty sure objects are not sharable between subinterpreters and there is not a plan for that. The main reason people think subinterpreters are good ("you can just share the memory!") is not actually true.
- They don't require any changes to the C interface because those changes were already made, and a fair amount of cost was paid by C library maintainers. So it's true, subinterpreters are at an advantage in this regard, but that's more of a political question than a technical one