If you don't trust those (which is somewhat fair these days, given how easy it's become to generate fake imagery), you can always go there and see them for yourself. Or, since they're visible from space, launch a satellite to take your own photos.
I was anticipating a response along the lines of "where's the evidence that those pictures are real and not AI-generated?".
The source I have handily available is [1], which shows an increase of 38 TWh generated from solar in June from 2024 to 2025 and 30 TWh from 2025 to 2026. That's a mean of 52 GW and 41.7 GW respectively, which (at a capacity factor of 0.17, apparently around the average in China) is about 307 and 245 GW of installed capacity -- which roughly agrees with the original claim.
I'd argue that China has done far more work than the US have on reducing emissions. It's just that they also have a large rural population that's rapidly modernizing at the same time, and the increased energy use per capita from that is overlapping with their emissions reduction. The EU and US both went through that stage decades earlier, and it seems unfair to hold it against China for doing the same.
For example, there's been a massive drop in overall poverty in China over the past two or three decades [1]. Two decades ago they had tens of millions of people that didn't even have access to electricity [2], and half a billion people without access to clean cooking fuels [3]. They've had a 3.4x increase in car ownership [4] in the same period that the US had a 1.2x increase [5], a significant and growing share of which are electric [6] compared to the small and not growing share in the US.
On the energy generation side, China has built 5x as much low-carbon generation the US has over the past decade [7] despite the latter's economy being 50% bigger, and their CO2 per kWh is dropping faster [8] (especially over the past two years...).
It looks to me that the bulk of the US's emission reduction has come from switching from coal to gas, which is happening purely due to their relative costs. I guess it is a real reduction in emissions, but it's not decarbonizing. What happens when they run out of coal plants to convert? I feel like the US has just got lucky with timing and the cost of coal vs gas, whereas China has got unlucky with the timing of their standard of living improvements.
The top level "x% change in emissions" figure is too simple to capture any of this detail. I think it's mostly a coincidence that the figure is about the same for the three groups at the moment -- at some point China will finish raising its standard of living to western levels everywhere and, if nothing else changes, their emissions will start heading downwards faster then everyone else's. People will probably be surprised but the indications are that it's already happening, it's just being hidden for now.
(As for the EU, I didn't really look at many of their stats. My general feel is that they've spent a reasonable amount of effort, but a lot of it has been on efficiency improvements -- which are welcome, and they benefit everybody which means that some of their effort unfairly shows up under other people's figures, but which might actually have been counter-productive [9] without the associated actual decarbonization of electricity generation.)
If only they would do NAT64, so you could drop v4 without losing the ability to connect out to v4-only hosts. That would be sufficient in a lot of cases.
(Oh, and fix their stupid "on-link /56 but we lie to you and claim it's your /64" setup while they're at it.)
On the other hand, if Android supported IA_NA we would probably be seeing ISPs in the wild handing out /112s and going "But it's 2^16 IPs! We're being so generous, what could you possibly have to complain about?", so it's quite possible that adding support would be to the detriment of all Internet users.
Android does now support IA_PD, so the people who need to track IP use via DHCPv6 requests should now be happy. (We'll just put aside the question of whether doing that even makes sense in a world where devices can be told to use any IP.)
It was never going to be a clean cut, which is why we didn't design it for a clean cut and instead developed a bunch of approaches to transitioning to it that deal with the real-world problems of the transition.
What more do you want from it?
What could they have possibly done differently to make you happy with it?
> people who either worked for the likes of Google who were aching for a globally unique identifier per device
v6 doesn't give you globally unique device identifiers. Devices get IPs from the network in v6, just like they do in v4. You're either thinking of MAC addresses or perhaps things like HIP (https://datatracker.ietf.org/doc/html/rfc7401). I guess there is Mobile IPv6 which allows you to take your address to another network, but then there's also privacy extensions which prevent your machine from using the same IP for very long, so it's still not a unique identifier for your device.
With one exception, extension headers are not examined or processed
by any node along a packet's delivery path, until the packet reaches
the node (or each of the set of nodes, in the case of multicast)
identified in the Destination Address field of the IPv6 header.
That seems like the opposite of needing to know all possible extension headers in order to route a packet.
The issue is that the extension headers can be used for nefarious purposes, such as hop-by-hop routing. So your fast hardware-based border routers might be EH-agnostic and transmit packets to your core network. And then a helpful Linux box that implements all of IPv6 in software would reflect the traffic right past your firewall.
Implementing the EHs in hardware is expensive, as you need to do conditional checks. So routers just drop them.
The killer software is one-off custom things that are written for an audience of one user, or maybe a small handful of them. The software is on their computers, where you don't see it.
None of it does anything particularly amazing, but that's kind of the point -- the programs that people are generating are for the use cases that are too personal, trivial or specific for anyone to have bothered making a software package for.
There's nothing stopping you from giving each stack its own IP, making the kernel only responsible for routing.
I don't think it's a good idea to put more of the stack than necessary into each individual program though, because then you're reliant on each program implementing everything correctly and you have to worry about bugs and security issues in every single program you're running rather than just in the kernel.
Considering that even something as simple as opening a socket (which involves calling one function to give you three numbers which you pass unchanged to a second function) is largely a clusterfuck in existing programs, I don't trust them to implement the whole TCP stack.
The performance hit for running an emulated CPU would be significant, to the point that it wouldn't really be the same argument.
I was thinking more along the lines of network namespaces -- although actually, I should have been thinking of TUN interfaces. Any packets sent into one of those are delivered to the attached program, which can do what it likes with them. Those are usually used by e.g. OpenVPN for L3 things, but nothing stops a program from handling the L4 headers.
If you don't trust those (which is somewhat fair these days, given how easy it's become to generate fake imagery), you can always go there and see them for yourself. Or, since they're visible from space, launch a satellite to take your own photos.
reply