It's the one thing I miss from Swift when I'm using literally any other language. Interal and external parameter names. I would love for Rust to adopt:
fn foo(namedParam internalName: bool) { // use internalName here }
fn foo(unnamedParam: bool)
> Consequently, in the case of portable batteries included in products covered by Regulation (EU) 2023/1670, the removability and replaceability obligations set out in Annex II of that Regulation prevail over those set out in Regulation (EU) 2023/1542.
The ecodesign law (spare part but 1000 cycle exemption) pevails over the batteries law.
Negative prices have no effect on grid stability. It just means that the day-ahead market was cleared below 0, i.e. for every consumer (buyer) there is a producer (seller) selling at this price. The market is still balanced with consumption==production.
Now, you can ask the question: Why are so many producers willing to sell below 0? That has to do with misplaced incentives. For older or home-installed renewables there is a feed-in tarrif which guarantees a fixed revenue at all times. So there is an incentive to sell even for negative market prices. Newer installations can't opt for the guaranteed revenue model with revenue during negative prices any more.
Redispatch follows afterwards, if the market result clashes with physics: The physical grid can't transport the power from producer to consumer. There was no unusual amount of redispatch during easter.
> It just means that the day-ahead market was cleared below 0
No, it doesn't. The article is explicitly about intraday-prices. So day-ahead clearance made invalid assumptions about generations and consumption that were not met during the day. This kind of miscalculation does require additional (costly) redispatch measures to mitigate the overproduction, and it can affect grid stability.
You are right that intraday went even more negative than day-ahead. But I disagree about the rest of your comment. A spread between day-ahead and intraday does not imply additional redispatch. Only some of it might have been countertrading by the grid operators.
> This is currently being defined and is almost complete.
>> no signed stamp of approval from on high
> see above. Once certification and attestation goes live, there will be a minimum functional and security bar for providers.
Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
Unclear how this quoted comment relates to what I was replying to (which was about exporting / backing up your credentials).
But I'll respond.
> Will I always be able to use any credential manager of my choice? Any naturally also includes software that I might have written myself. And would you be in support of an ecosystem where RPs might block my implementation based on my AAGUID?
If a website were to block your custom software's AAGUID for some reason, you can change your AAGUID.
AAGUIDs in the consumer passkey ecosystem are used to name your credential manager in account settings so you remember where you saved your passkey.
Which I would be careful with. I can use any authenticator that the RP accepts. I could totally see a future where banks only allow certain authenticators (Apple/Google) and enforce this through AAGUID or even attStmt. Similar to the Google Play Protect situation.
At that point, those banks/services would enforce vendor lock-in on me. The reality would be: I can use iOS or Android, but not a FOSS implementation. This restriction is not possible with old-school passwords.
For DP adoption it's too late. They should push for USB4 / Thunderbolt 4 instead. We are in the phase where about every new laptop has USB4. Connecting your laptop/phone to a TV might be a selling point. I'd love that for hotel TVs.
The source and the sink need a HDCP-licence. Both devices have embbed keys that get exchanged to estabish a encrypted channel. Without the licence you can't get the required key material.
AFAIK, you can even sell HDMI devices without HDCP. Practically though, every entertainment device needs HDCP support.
That's a really subtle version of the deadlock described in withoutboats FuturesUnordered post [0]
When using “intra-task” concurrency, you really have to ensure that none of the futures are starving.
Spawning task should probably be the default. For timeouts use tokio::select! but make sure all pending futures are owned by it. I would never recommend FuturesUnordered unless you really test all edge-cases.
I'm also surprised how often the preemptive vs. cooperative angle gets ignored in favor of the stackful vs stackless debate.
If you choose a non-preemptive system, you naturally need yield points for cooperation. Those can either be explicit (await) or implicit (e.g. every function call). But you can get away with a minimal runtime and a stackless design.
Meanwhile, in a preemptive system you need a runtime that can interrupt other units of work. And it pushes you towards a stackful design.
All those decisions are downstream of the preemptive vs. cooperative.
In either case, you always need to be able to interface with CPU-heavy work. Either through preemption, or by isolating the CPU-heavy work.
reply