Unlurker|Replay|About
The same AI request emits 8.5 times more CO2 in Texas than in Sweden (berget.ai)
•
Worry not, AI people! Greenhouse gas exemptions will be made for the future of work, maths and art, the salvation of the humankind, the genie that is out of the bottle, etc, if only at the expense of taxing your and your dog's fart.
•
And eating a single burger results in the equivalent Co2 emissions of 17,000 requests in Sweden and 2,000 requests in Texas. Reducing/stopping meat consumption and replacing it with healthy plant-based tofu, seitan, tempeh etc has a far bigger impact (and as a bonus, living beings don't have to suffer)
•
fallacy of relative privation
•
The reasoning effort knob is becoming a really important variable regarding how much impact AI models will have on energy consumption. Medium and max can differ by as much as two orders of magnitude in their token consumption. We also have to consider the amplification of compute demand that occurs by way of the tool calls themselves. Tokens are mostly a constant cost thing, but how they are interpreted can mean the difference between a 5 minute cpu bound operation and a 50uS cached database lookup. At some point, the CPU is going to become the bottleneck again.
•
This is why people in left wing areas need to oppose datacenters bans. Regulate them. Require green energy investments that more than offset their load. Use some of that flowing AI money for the betterment of society.
•
Less waste of resources is still waste of resources. How much of the AI generated content is actually useful, how much useless, how much harmful?
•
Datacenter wouldn't stop, and there would be some country or area which allows it. Unless they regulate the entire world, we should focus on lowering CO2 globally, and that means allowing datacenter in your neighour if your energy is better.
•
Yeah I don't understand why these new data centres are all in populated areas. AI isn't latency sensitive. Put them in some remote location surely?
•
> don't understand why these new data centres are all in populated areas Power connections.
•
We can pretend that international trade and energy price arbitrage doesn't exist to make us feel nice and happy; but the reality is a Watt spent in Sweden increases the marginal cost of energy by the same amount as a Watt spent in Texas. These things are tied together by foreign exchange, imported energy intensive goods, petroleum products and directly imported power. It's time we stop being naive about energy use.
•
I'm a bit confused. For one I am not sure why this must hold for something as difficult to transfer as energy, and I am not sure why it matters. Not all energy is the same, hence the title.
•
Sweden is not grid connected to Texas, well, nor is also any other grid in the USA actually. Smelting was placed near cheap hydro resources (and why Boeing built planes in Seattle) for good reasons. Just replace cheap watts with clean watts.
•
Because Sweden's clean energy capacity is fixed. Which means a "clean" Watt spent on inference is taking away a "clean" Watt that would have been spent on heating or steel. Which means Sweden needs to buy energy or energy intensive goods on the global market, which raises prices, which means Texas is being paid.
•
> Because Sweden's clean energy capacity is fixed By what? You're treating electricity as a globally-tradable good. It's not.
•
Perhaps they are mistaking Sweden with Norway (whose nearly 100% hydropower system is constrained)
•
It is .
•
> "Sweden's clean energy capacity is fixed" This is a weird assumption to make. Why would you assume they wouldn't just build out more capacity as demand increases? They certainly aren't buying electricity from Texas, this feels like a tortured argument you're just making to retroactively support whatever opinions you have on the pros or cons of clean energy.
•
> this feels like a tortured argument you're just making to retroactively support whatever opinions you have on the pros or cons of clean energy. My opinion that reality should take precedent over feel good lies?
•
Great writeup! I've done some work on Codecarbon [1] in the past, it's a pretty standard tool for measuring ML/AI workload emissions, it would be awesome to have your findings contributed to that project as well. [1] https://github.com/mlco2/codecarbon
Based on a newly released model for calculating this that is open sourced.
•
your web server is down, maybe switch to the github link in the meanwhile (you have ~ 4 minutes left)
The foolishness of "natural language programming" (1978) (cs.utexas.edu)
•
Possibly relevant: The experiment in designing a language that resembled natural languages (English and Japanese) was not successful. -[1]- William R. Cook, AppleScript, HOPL IV [1] https://dl.acm.org/doi/10.1145/1238844.1238845
•
Todays natural language program won't work tomorrow due to unstable nature of natural language. Apart of natural evolution of meanings, look at Orwellian limitations some (cloud) models impose on is that our natural language program become illegal . Due to topic or combination of words the program needs to be flagged and soon likely reported to three leter agency. Next, RMS would ask: can you make your own natural language program compiler from scratch? I know we have (very expensive) local models, but wait until GPUs get a propper online subscriptions to work and surveillance taps.
Agree. For me, that's exactly what happened. I work with the agents the way I'd work with a team of developers, not the way I use a compiler. Since the end of September, they've made about 970 commits to a project of mine, and I haven't read a line of its code. And like with a team, many programs could meet what I asked for, but I check the behavior of what they built, not the code directly. I think of it as working on the level of an engineering director, who also doesn't review code directly. Each agent shows me its change running in the app, in a short narrated screen recording, like in a launch review for the director. When it's not what I meant, I say what, and it goes another round.
•
If you like being a software tester or director, go ahead with it. However you can't prevent some other people from working as software developers who write and read code. Even with cars, you still walk. Even with factories, someone still craft handmade bags.
The LLMs don't replace compilers, they challenge the next generation of compilers. And they don't replace software engineers, they shift them into yet another metasystem.
•
Why do compilers worry about the challenge? Just call an LLM internally from a compiler if LLMs are better than compilers. In my opinion, LLMs don't challenge anything.
Docker is weird (codeandcake.dev)
•
I have recently discovered INCUS, very nice alternative to docker when a simple container is not sufficient https://linuxcontainers.org/incus/
•
Interesting read! Thanks. Though it would be better if it compared Dockers ways to say Podman, which does things a little different I think. For others, like me: Footgun: A footgun is a programming or system design term for a feature, tool, or API that makes it very easy for a user or developer to shoot themselves in the foot—meaning it causes self-inflicted damage or severe errors while working exactly as intended.
Lots of positive stuff in this thread which I won't bother repeating. Instead, I'll add a few ambivalent points: - Today, a lot of functionality still in Docker has been upstreamed into the (Linux) kernel, so containers can be much simpler (and rootless). Docker is still carrying around some of that cruft, which is what makes it slower and heavier than Podman. - As a devex technology, Docker/containers have been massively successful, but not as infrastructure. Containers never became secure enough to run multitenant workloads without some other form of isolation, so they ended up being redundant with KVM (or gVisor, or a similar second layer) in production a lot of the time. That second contradiction led to lots of inefficiency. For example, on Google App Engine, for years when you ran a deploy it would create a VM just to run a single container.
•
I would also point to no secrets primitive. K8s requires some sort of tool to have any hope of storing secrets in a way that isn't trivallly findable from the rest of the cluster. But, perhaps I am being too harsh, its not like there are secrets primitives in linux that are easily deployable to namespaces/cgroups.
I am a huge Docker fan! I would reiterate what several commenters have said already that it had a huge impact on my career. My question is relatively pedestrian compared to what others have asked already. I absolutely loved the "adjective-scientist/nerd" container names Docker generates. In fact, that is one of my most favorite things about Docker. How did that come about and who chose those combinations?
•
I'm glad you enjoyed that! We wanted a way to make container names reasonably unique and reasonably memorable by a human, so this was a fun way to do it. I picked the original combinations, then over time it became a ritual for contributors to propose fun new values. There's a fun little easter egg: the combination of "Steve Wozniak" and "Boring" is explicitly forbidden, because Steve Wozniak is not boring :) https://github.com/moby/moby/pull/4902
> Docker’s container runtime, runc, is written in Go. I worked at Docker from 2014-2019. The most important part is actually written in C. [I wrote a whole comment here about to explain how the hack works because I was too fixated on how technically incorrect "written in Go" is. Then I went back to read the rest of the article only to see that the paragraph immediately after this kind of explains it in its own way! Let that be a lesson to always finish reading the article before posting about it.]
•
Hi Josh!
The rootless Docker experience used to be pretty bad and it was less friction to use something that was rootless by default (like Podman). Has this changed?
•
it changed and its better now. rootless dockerd wants newuidmap/newgidmap + subuid range before it start, and cgroups only work with cgroup v2 + systemd. also, on a host that already has those, its fine on one without systemd, and podman is still less friction, mostly because there is no daemon to babysit
Hi, I'm the creator of Docker and came across this post. It's always fun to see other engineers think about how you designed a system. I haven't been involved in developing Docker in many years, but it's a fun trip down memory lane. I'm happy to answer any questions you may have.
•
Given all the popularity and use cases you know today. Is there any fundamental design choice you would have done differently?
We acquired a small team of Cambridge-based computer science & systems engineering wizards, called Unikernel. We then worked together to apply systems engineering to improving and expanding Docker in various ways. The most successful project that we worked on together was "project Piñata" which later became Docker for Mac. It turns out bundling a Linux VM in a native Mac app, and integrating it into the host filesystem, networking stack etc requires lots of magic.. Now, most of the Unikernel team were very active OCaml developers, and created MirageOS among other ocaml projects. While working on Piñata, they simply reached for the tools they were most familiar with.
•
(Unikernel cofounder here) When acquiring our company, Solomon took us to a remote farm in France for a week for an offsite, fed us fantastic food and wine, and the first prototype of that Docker for Mac VM was working by the end of the week! It took a few months to hack together the shell. There's a video of Solomon and the pinãta launch party on my blog ;-) https://anil.recoil.org/notes/cacm-docker-cover#getting-involved-in-docker There was a whole other slice of work we did for project Piñata too in the form of datakit ( https://github.com/moby/datakit ) that was well ahead of its time. I was looking at this archived code again just last week while thinking about agentic git workflows!
•
Hi Anil! Welcome to the 2026 Docker reunion thread :) How did I not know about this video until today! Hope you're doing well.
I generally agree with your comments, but do you really think that a language created by such luminaries as Ken Thompson and Rob Pike and endorsed by Google really needed Docker to "take off"?
•
Yes, see Plan 9, Alef, Inferno and Limbo, such luminaries as Ken Thompson and Rob Pike aren't always right. As for endorsed by Google, see Dart and Flutter, Android Things, Fuchsia. Now everything combined, plus Docker and Kubernetes, yes it was definitely a factor.
Oh gosh, the choice of language is such a context-specific design decision. The first versions of what became Docker were written in Python. The choice of Go was a mix of nerdy excitement ("it's like the best of Python and C!"), and adoption strategy: back then devops tools were segmented by language runtime: ruby, python or Java mostly. Shipping a compiled binary allowed us to be adopted by all tribes. None of these things can be transposed today, so I guess I can't answer... For what it's worth, my current project (dagger) is written in Go.
•
I interviewed Solomon about the Go history (plus some others) for this talk https://www.infoq.com/presentations/languages-cloud-native/ Actually there are some longer unedited versions I might release.
 Top