The local optimum still seems to be: Let LLM of your choice generate a polars script that reads the spreadsheet and explores them for you.

My partner recently used that "pattern" at work to find outliers and interesting metrics in years of excel reports. Data they were working hours for. Now available in a single human language query.

I don't think the HN crowd understands how many million jobs are primarily staring at excel reports and copying values between forms, pdfs and spreadsheets.

As long as no attestation is used, you only have to store the private key, credentialId and userHandle (basically the server generated ids of the passkey and the user). That's not to different to writing down username and password.

And the sad truth is: Most people have no password manager at all. They are used to re-generate new passwords every time they want to log in! I'd wager that on some websites the vast majority of people are loggin in by pressing "I forgot my password".

Bitwarden lets you export your vault, and the export contains the private key in plain text. There is virtually no difference to writing down a password on a piece of paper. Well, I guess a passkey is a lot longer than the avg password.

This changes if attestation ever becomes widespread. Which will only happen if Apple does a U-turn on their stance.

Let's treat git as a SHA1-keyed object storage. The problem is that we currently use SHA1 both as database key and as hash for integrity validation. At first, I would have only changed the latter.

Local: Request object with key x (SHA1). Remote: Here are the bytes for key x (SHA1) with hash SHA-256. Local: Validate the bytes vs SHA-256.

Local: Store the following bytes with key x (SHA1). Remote: Check if key x has ever been stored in the database. If so check that the SHA-256 of the new bytes matches the SHA-256 stored under key x. The only thing the repo has to keep is a LUT from stored keys (SHA1) to hash (SHA-256). The prevents SHA1 collisions from being stored.

The SHA1 key then just becomes a convenient alias for an object. The only restriction is that you can't have two objects with the same SHA1 in a repo. We already kinda do this when we refer to commits with the first few chars of the SHA1. If there is a "collision" git already detects it and asks you for more characters.

Finally, you can convert the internal representation of the tree to SHA-256. If some legacy client requests aliases via SHA1 you use the LUT, new clients request the SHA256 directly.

Am I missing anything obvious here?

DSC is just the "card up the sleeve" for DP1.4, you can push it all the way to 4K 240hz HDR. So there is little incentive to switch to DP2.1 for OEMs.

To dump some ideas on you: I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively.

I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points).

Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another.

This in combination with matklad's ideas about seperating TaskSend from ThreadSend (https://matklad.github.io/2023/12/10/nsfw.html) would solve most of my async pain points.

That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.

Imagine if MyTrait comes from core/std. Adding an opt-out bound like ?Sized (or ?Move) is a breaking change for any generic code that relies on Sized/Move. But you want some traits from std to be open for !Move types.

For example, should Iterator::Item be Move or ?Move

If you leave it as Move, you can't create any iterators over !Move types. If you change it to ?Move, then functions using generic iterators can't assume that the elements of an Iterator are always moveable. Which is a breaking change compared to now.

The most critical trait is probably Deref. Using !Move types without `Deref::Target: ?Move` is painful, because calling any method on boxed types relies on Deref.

The point of !Forget is ensuring that once the owner goes out of scope the destructor must be guaranteed to run. An infinite loop is not a problem, cause the new thread will never leave its scope. Ref-cycles are a problem, cause you can create a ref-cycle. Then the program flow leaves the scope which will run the drop on all RC's but not the drop on the inner type.

I would highlight that there are many cases where you CAN move an object safely until a certain operation requires the object to "stay put" in place.

Pin allows for that by tying the object to the place only when required. That's why Pin relates to both the object and the place.

Meanwhile, !Move types can't ever move. The object has to remain in the inital place it was constructed in. !Move requires in-place construction and emplacement to be ergonomic at all.

In Europe. Still cleaner than the US, China, India, Japan, and the world avg:

https://ourworldindata.org/grapher/carbon-intensity-electric...

Coal and gas are down 50% compared to 10 years ago despite the shut-down. Nevertheless, shutting down the last few ones was bad.

  fn foo(namedParam internalName: bool) { // use internalName here }

  fn foo(unnamedParam: bool)

https://eur-lex.europa.eu/legal-content/EN/ALL/?uri=CELEX:52...

> 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.

The redispatch was not extraordinary: https://energy-charts.info/charts/power_redispatch/chart.htm...

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.

Source: I work on this stuff.

> You can use any credential manager you choose.

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.

>> There is no passkey certification process

> 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?

[0] https://github.com/keepassxreboot/keepassxc/issues/10406#iss...