There's a trick to dealing with this: don't build off-grid solar-only datacenters in areas that get so little sun in the winter.

Most datacenters can be built in locations that can be connected to the grid, so do that. Then you'll get access to solar and wind generation, and storage systems, from a wide geographic area. You don't have to limit yourself to just on-site solar.

So, about 192 batteries with 0.75 GWh of capacity? But that's if you were powering the datacenter exclusively from solar power; in reality you'd obviously have wind turbines, which can generate power overnight (and tend to generate more in winter than in summer, which balances solar), so you wouldn't need to power it exclusively from batteries overnight.

For comparison, the US brought about 35 GWh of grid storage online last year -- about the weight of 45 Arleigh Burke class destroyers, if it was all in Tesla Max-Power batteries. So one destroyer's worth isn't actually that much, and one datacenter doesn't even need that much in the first place.

Nobody is failing to get that it's dark at night. We're pointing out that wind, solar and batteries can, when combined, cope at reasonable cost even though it's dark some of the time.

Yes, they are. Electric bike owners typically get more exercise than non-ebike owners, because they tend to use their bikes more often and to go more distance on them.

> If being propelled along on two wheels by a motor led to good health,

It doesn't, so the fitness of motorbikers isn't relevant here.

Or rather, that he was writing one that could be written with a leak. You can't access freed memory if you never free memory, and short programs can often get away with that.

A recursive resolver isn't necessary on the client; you can use a stub resolver to fetch records via an upstream recursive server and then validate them locally. Supporting a domain outside of the normal DNS hierarchy would require pinning a key as a signing root, but that's doable in the same way that adding custom CAs to TLS clients is.

But if you actually look at how the electricity they use is generated, the percentage of it that comes from coal is going down.

I mean... you can use solar panels to generate the electricity the EVs use while plugged in. The big advantage is they can be installed near to where your car is charging, completely bypassing the transmission network. The other big point is that solar is intermittent, so you'll often need to pair it with batteries, and those help a lot with a bad mains grid.

Also, battery chargers in general (whether grid battery, home battery or EV chargers) represent a huge dispatchable load that can be scaled up or down more or less freely, which lets you avoid blackouts by turning off demand instead. That just shifts load around, so they're obviously going to need to build more capacity either way, but having lots of dispatchable load available makes the grid both cheaper and more reliable if you take advantage of it.

I'm not trying to say that powering every vehicle in your country by electricity is trivial, because it's not... but it's a lot easier to keep the lights on when a big chunk of your load is battery chargers. Especially if you can run the lights from the batteries.

At an average of 12000km/year and 0.2 kWh/km, an EV is about 6.5 kWh/day, or equivalent to a ~275 watt constant load. I don't know if I'd call that a shitload. To give a sense of scale, the US generates 35 kWh/day/person (or ~1.45 kilowatts) of electricity.

Of course, India currently generates only ~3.9 kWh/day/person (~160 watts), but only about 4% of them currently even own cars; if they were all electric it would average ~0.26 kWh/day/person which is only about a 7% increase in their total electricity generation. (About 20% own motorbikes or mopeds, which use much less energy than cars. That's another advantage India will have, if they can keep two-wheeled vehicles the primary transport mode at least until they're done electrifying.)

That part isn't much of a hurdle. Here's a machine on a v6-only network:

$ wget -4 https://slashdot.org/
Resolving slashdot.org (slashdot.org)... 104.18.4.215, 104.18.5.215
Connecting to slashdot.org (slashdot.org)|104.18.4.215|:443... failed: Network is unreachable.
Connecting to slashdot.org (slashdot.org)|104.18.5.215|:443... failed: Network is unreachable.

$ wget https://slashdot.org/
Resolving slashdot.org (slashdot.org)... 64:ff9b::6812:5d7, 64:ff9b::6812:4d7, 104.18.5.215, ...
Connecting to slashdot.org (slashdot.org)|64:ff9b::6812:5d7|:443... connected.
HTTP request sent, awaiting response... 200 OK

Slashdot is v4-only and v4 fails because no v4, but I can access it over v6 just fine. This is the machine I'm posting from, if you wanted any more evidence that dropping v4 doesn't mean losing access to v4-only sites.

From a technical perspective that's no hurdle at all. Deploying v6 doesn't break the existing v4 on the network, so you can still reach those sites over v4. It's only a hurdle if you want to drop v4, but even then it's not a major one because you can connect from v6 clients to v4 destinations via NAT64.

This way around doesn't really work though. When a client on the LAN wants to connect to 2001:db8:abc:def::1001, what IP does it put in the v4 packet's destination header? You need to be able to send packets with the v6 header format over the LAN, because that's the format that has space to put the IP you're sending the packet to in it.

There's a way to use v6 to handle that situation more simply, even without any of those people supporting it. You can put a NAT64 router onto the internal network, and have it map the internal v4 into a unique per-company (or per-machine) v6 prefix. (An SBC running OpenWRT or Linux can do the job, using TAYGA or Jool.) It would mainly only help for connecting to those devices from outside, but for remote monitoring that's what you need.

If you got your own v6 allocation (for the sake of argument, 2001:db8:abc::/48), you could use:

2001:db8:abc:1::192.168.1.x (aka 2001:db8:abc:1::c0a8:1xx) for one company, then
2001:db8:abc:2::192.168.1.x,
2001:db8:abc:3::10.100.200.x,
2001:db8:abc:4::192.168.10.x,
2001:db8:abc:5::192.168.1.x

and so on for different companies, so none of the v6 ranges overlap even when the v4 ranges do. Then you could VPN into those NAT64 routers simultaneously, without needing to do anything to resolve the RFC1918 clashes on your end (because from your perspective the networks use non-clashing v6 ranges rather than clashing v4 ranges), and monitor them all from a single host. You would probably still need to use a v4 range that doesn't clash with the corporate network, but that part is mostly their problem.

If the corporate network supported v6 then they could arrange for inbound routing to work, which might eliminate the VPN, and you should still put "support v6" on your list of requirements for new components and pester the suppliers of your existing components, which will improve the situation over time... but you could still use this approach even if all of those were v4-only.

The cost includes building solar panels and wind turbines in Morocco to generate the power that's being exported, so it's generating a bit more than nothing. It's also supposedly about half the cost of generating the same power with nuclear, and building solar panels in the Sahara desert has some obvious advantages over building them in the UK, so I don't think it's that stupid.

That doesn't show a local DNS server. It shows local machines using mDNS, which the typical home user does have.

It's actually quite common for home routers to run a local DNS server (dnsmasq integrates one and is very common on Linux-based routers). I don't know if it's enough to qualify for "typical", but it's not that unusual for home users to have a real DNS server running too, not just mDNS.

They got rid of coal, but their gas use is also going down and their renewable use is going up. There's another country I could name that did do what you're claiming, but not the UK.

They also spend about £2.2 billion/year specifically on a fund that helps poor people not freeze to death, which is about $40/capita. LIHEAP in the US, which I think is the rough equivalent, is $6.1 billion/year which is about $18/capita. Not only is that less than half the amount, but the entire federal staff responsible for implementing it have been fired and this year's budget request is requesting $0 for it.

Are you sure you're thinking about the right country here?

Not really. The phone system is based around variable-length addresses, whereas v4 is fixed to 32 bits. It's not just the packet format, but also related protocols like DNS and DHCP, and basically all software; everything stores v4 addresses in a fixed-width field. You can't just add a prefix onto v4 and have it work with everything like you can with phone numbers -- you need to do basically all the things v6 is doing to get longer addresses.

(And if you're doing that, it makes sense to add enough new addresses that you don't need to immediately turn around and do it a second time straight afterwards. Doing it once is proving to be hard enough as it is.)

Because you probably want to connect from your home network to places on the Internet.

The way that works is that the machine on your network sends an IP packet with the remote machine's IP in the header. The src/dest address fields in the header of v4 packets are too small to fit a v6 address (which is sort of the whole reason we needed a new protocol in the first place), so this requires a revised header format that has enough space, i.e. v6 packets.

Nobody is saying that your home network can't use v4, it just also needs to use v6 so that these packets work.

Just uh, don't set the graph to show the 3-month average. Then again, dropping by 0.2% per month consistently for seven months straight is pretty stable...

There's probably some variation in which months of the year people buy cars so maybe the 12-month average is the correct place to look? But except for 2024 the previous years don't show a similar decline.