nicois

In Australia, the real value of these big batteries is not necessarily to provide emergency power, but more to respond in milliseconds to variations in demand and to smooth out the 5 minute spot market.

Having a sink and a source for spikes aids grid stability and somewhat helps to reduce the need to build more infrastructure to handle transmitting power from the generators during those peaks.

It also helps avoid the viability of gas powered generators which are very expensive and carbon intensive.

I just finished my second read of The Rise and Fall of the Third Reich. It's quite engaging, and also quite helpful to juxtapose against current political events, both to identify the similarities (media control) and divergences.

Rereading the Lies of Locke Lamure. If only the sequel were half as good as it...

could graphene support multiple duress PINs?

feds: "unlock your phone or else" victim: "um, you're stressing me man. It's either 1234 or 4321, I forget. One of them wipes the phone, the other will unlock it."

Whichever PIN they try, it wipes the phone, but the feds can't claim it was deceitful, just unlucky.

One missing feature: deferred message propagation. As far as I understand, while messages will be rebroadcast until a TTL is exhausted, there is no mechanism to retain in-transit messages and retransmit them to future peers. While this adds overheads, it's table stakes for real-life usage.

You should be able to write a message and not rely on the recipient being available when you press send. You should also be able to run nodes to cache messages for longer, and opt in to holding messages for a greater time period. This would among other things allow couriers between disjoint groups of users.

If the idea is to have devs implement each kata, wouldn't it be more effective to provide not only automated tests, but also code which should be used as a basis for each challenge?

For example, if supporting a dev tag to serve assets from the filesystem, why not include a simple webserver which embeds the contents?

This would allow aspiring gophers to go straight to the high value modification of a project rather than effectively spend most of the time writing scaffolding and tests.

This is exactly what I want when baking bread: I have a fixed sequence of steps, spaced quite far apart, and this is pretty much perfect: a series of relatively short breaks when autolysing and kneading, then waiting 10 hours overnight, then waiting 75 minutes after proofing.

I'm not sure how well this will work on a mobile; the service worker might be stopped after a few hours, particularly with the screen off overnight

This would be more impactful if we could see the cost to US purchasers was actually 39% more. Sadly some manufacturers spread the cost across all consumers, which actually means non-US customers are actually paying some of the tariff costs too.

Is there a risk that this will underemphasise some values when the source of error is not independent? For example, the ROI on financial instruments may be inversely correlated to the risk of losing your job. If you associate errors with each, then combine them in a way which loses this relationship, there will be problems.

Nit-picking, but a high signal to noise ratio is desirable, indicating low levels of noise compared to signal, not the reverse.

Despite what you get in Australia being pretty reliable, it's too expensive to justify quite yet. My 8kW solar is connected to a Fronius inverter, but until I find a less expensive option I can justify adding a battery.

A 13kWh system is over $AUD10k, and the ROI is on par with the expected lifespan of the battery.

If sodium cells can bring the price down to $AUD100 it would indeed be a massive game changer.

It would be interesting to know how effective Profile Guided Optimisation is here.

I've also found htmx a great way to retain server side rendering with minimising the recalculation cost of client changes.

By avoiding needing to add lots of client side logic to still get very low latency updates, it's given me the best of both worlds.

The way Django's template system works also makes it so easy to render a full page initially, then expose views for subcomponents of that page with complete consistency.

On a tangent, Django's async support is still half-baked, meaning it's not great for natively supporting long polling. Using htmx to effectively retrieve pushed content from the server is impeded a little by this, but I slotted in a tiny go app between nginx and gunicorn and avoided needing async he'll without running out of threads.

Doesn't this model fail to account for seasonal variations in the locus of the sun? The optimal angle will vary across the year, whatever the latitude.

Maybe I'm missing something, but i would use a simpler algorithm which doesn't need ML. On day 0, plug in the latitude and allow the system to traverse the range of angles, finding the optimal one at the time - ie: yielding maximum power. Let it run 3-5 times during the day, then fit those points to the theoretical path of the sun across the sky. Now your system is calibrated, without needing any other input. As the seasons change, the system will always know which angle to face for optimal power.

Which is the cause, and which the effect? Was apple's incorrect autocorrect causing them to go to the wrong place initially, or did they autocorrect list get built from the incorrect attempts?