This is one of the reasons most renewable generation gets a much lower price per kWh than, say, gas. The exception is rooftop solar which is very expensive per kWh, but it still viable because it feeds in directly to the consumer, so it reduces expenditure at consumer rates, rather than selling at wholesale. Even with all this renewables still work out as cheaper, and given the falling cost of batteries and renewable generation that is likely to remain true.

If you feed real patient data into an AI, that would require ethical approval. If you use an ai afterwards if would not

It is not a new idea. Some of the next gen designs for nuclear have integrated thermal stores. Concentrated solar power plants have done the same thing.

But this sort of thermal plants still makes sense. If grid electricity prices routinely go low because os generation consumption mismatch, then you can heat them up for little. It might even make sense to build them larger at nuclear power plants. You could turn the grid backwards and use external wind or solar to heat the nuclear store. After all, nuclear power plants have really good grid connectivity, turbines, cooling and all that you need to turn heating into sparks. The heat doesn't need to come only from nuclear power.

The bell they made on the first attempt cracked. So, the answer is they cooled it down as slow as possible.

Rust supports one compiler, with another for bootstrap and GCC on the way.
It does support no float platforms with the nostd option. Not everything works in that environment.

Curious, which platform for Rust works only with a commercial compiler?

My assumption is that the rust in Linux code would package as crates so that you can just import the bits you need.

I haven't seen the part where they can pull in any crate. Do they,

I think you mean external dependencies. As far as I understand all the code needed to build Linux is in the tree. Only the rust standard library is "external". That the rust builds into several crates doesn't seem a worry to me.

Why would you get so angry about such a statement. In a decades time, we might see Rust starting to replace C. We might not. The story is just giving an idea of time scales. Decades not years. Or maybe never.

In languages which do not have a defined packaging systems, many alternatives have appeared. Java and Python are good examples, where it has historically been a bit of a mess. C has no defined packaging system also. This can make it challenging to work out which libraries will actually be used when C is compiled or run, short of just running the compiler.

Cargo is a really nice feature of rust. Easy to develop against, easy to compile against.

The processes associated with the grid are not designed well, unfortunately. The one that you use to get permission to connect the grid is designed for large generators, such as gas or nuclear power stations. Even a small grid scale battery has to go through a slow queuing system before it can be considered and that bungs everything up.

The article also talks about zonal pricing. At the moment, you pay the same wholesale price where ever you are, meaning there is little incentive to put the batteries near the wind farms.

On top of all this, planning permission for cabling is also very slow. We are currently building a HVDC subsea system from Scotland to England because this is easier than getting permissions to go across the borders. And newer wind farms often have two onshore connections so you can choose where to send the power.

So, it is happening. But "fast" is not a word you would give to it.

In the case of a supply chain attack, this would impact on the binaries on rustup for example. But this is not the only way to bootstrap rust.
There are other versions of the binary available, which would make rolling back to a previous version entirely possible. Either way this has nothing to do with reproducible builds in so far as I understand the term -- that the same source code will produce the same byte-identical, binary when built.

As for the lack of multiple implementations making bootstrapping harder, maybe. This is why mrustc exists. Having a specification is probably not going to help unless the specification leaves the development.

The point really is to think about what the solution is. A substation went down. So, have redundant power substations? Well that had that. And a result of which, following the fire, they were able to restore power, running on the two substations that remain.

The problem is that when the power went down, their systems shutdown and rerouting took time. So, what would be needed is redundancy that can switch in milliseconds, or you will have to reboot. And even then, what happens if the backups get taken out. That happened with this event also.

That isn't reasonable. It makes much more sense to use the normal procedures for a closed airport. That happens routinely anyway. It makes no sense to spend money to prevent an airport closing for a day due to a once in an life time fire, when it closes down two or three times a year due to fog.

The fire knocked out the backups and the grid supply from one of the redundant substations. This wasn't the problem.

> I think you may have mixed me up with the other guy.

I did. Apologies! I think my post still makes sense, even if it is answering a completely different point.