yoshuaw

I thought this was a good explainer on what In-toto is, when to use it, and how it's different from e.g. Sigstore:

https://nesbitt.io/2026/05/24/signing-is-for-the-bad-days.ht...

Sodium-ion batteries are now also finally coming to market (CATL Naxtra) [1]. This gives me a lot of hope for the future.

[1] https://www.electrive.com/2026/06/26/catl-targets-up-to-2000...

My favorite base 10 clock is Neralie: http://wiki.xxiivv.com/site/time.html

The Neralie clock has two groups of 3 digits, called the beat & the pulse. A beat contains 1000 pulses, and equivalent to 86.4 seconds. A day is 1000 beats, or a million pulses.

Worse specs? Sure. Worse value? I don't think so. Worse accuracy? Perhaps not either.

A price of 30 EUR makes this sensor really easy to pick up. For the same price as one Aranet (~180 EUR) the typical household can place a sensor in every room of the house. Which provides far more accurate readings for the whole house than just one high-end sensor in one room.

This is just days after EU courts ruled private jet construction counts as a "green investment": https://www.reuters.com/business/environment/eu-court-says-p...

Mozilla is currently prototyping this in the browser [1] and measured 45% reduced overhead compared to calling DOM APIs through JS glue. The Chrome team has also expressed their interest. That's not a guarantee it will ever land of course; but I'm cautiously optimistic we'll get there eventually.

[1] https://hacks.mozilla.org/2026/02/making-webassembly-a-first...

Seconding this. Writing .wast files by hand is kind of fun as a novelty, but it's in no way something I'd want to maintain interfaces in.

Declarative interfaces via the WIT format are so much more readable in comparison; I'm really happy that's the direction we took for the component model.

Thank you!

Hey everyone, we just published the announcement post for WASI 0.3 on the Bytecode Alliance blog:

https://bytecodealliance.org/articles/WASI-0.3

The current link is just the release notes and covers only the interface-level changes. The announcement post goes into more detail on what's new in WASI 0.3, how it differs from WASI 0.2, and includes examples.

If you want compilers to be able to natively target browsers and access the browser DOM APIs, then you need to define some kind of contract between browsers and compilers on how to call APIs in one from the other. That is what the Wasm Component Model provides.

Perhaps some people are happy to keep the status quo where each call between Wasm and the browser needs to roundtrip through a JS glue layer. But personally I'm excited about a future where that is no longer needed.

I'm personally quite excited for Matter Casting. I haven't actually looked into the details of casting protocol itself, but I've been really enjoying my Matter devices at home and would love for my screens and speakers to integrate with the standard as well.

I've found old buildings to have generally worse air quality than newer buildings because of a lack of mechanical ventilation.

For the past seven years I've been urging people to stop using `select!` in async Rust code and use dedicated structured control flow primitives instead. Correct use of `select!` cannot be guaranteed by the compiler [1], and so it's unsurprising it leads to bugs.

For the first example the better option would be to use the `race` operation [2]. For the second it would be better to use `ConcurrentStream` [3]. Many (but not all) of the issues people have with cancellation in async Rust can be improved with the advice: "don't use select!".

[1] https://blog.yoshuawuyts.com/futures-concurrency-3/#issues-w...

[2] https://docs.rs/futures-concurrency/latest/futures_concurren...

[3] https://docs.rs/futures-concurrency/latest/futures_concurren...

The other side of the story here is also worth considering: native support in browsers provides a stable compile target for language toolchains. It'd be really nice if targeting the web from e.g. Kotlin, Swift, or Rust becomes just a matter of passing the right flag to the compiler.

I think it's less about unlocking new scenarios per se, and more about making existing scenarios better. If given the choice I'll generally prefer to write my code in Rust. But with native Wasm Component-based DOM bindings that same code will now run twice as fast.

This is the same author who found and reported ABI incompatibilities between clang and gcc: https://faultlore.com/abi-cafe/book/trophies.html — Given these incompatibilities have since been addressed, I think it's fair to say there were indeed issues with C.

A lot of us are our own instance admins, with our own accounts being the only accounts associated with our domains. I don't self-host though; I pay a dedicated hosting provider to handle this for me. This means I end up having a very similar relationship to my Mastodon provider as to my email- and cloud storage providers.

I always forget the order of precedence for FnOnce/Fn/FnMut

The way I remember the ordering is by thinking about the restrictions the various Fn traits provide from a caller's perspective:

  1. FnOnce can only ever be called once and cannot be called concurrently. This is the most restrictive.

  2. FnMut can be called multiple times but cannot be called concurrently. This is less restrictive than FnOnce.

  3. Fn can be called multiple times and can even be called concurrently. This is the least restrictive.

If we're talking sanitation tech: I'm personally really excited by the further miniaturization of (far)-UVC light sources [1]. Far-UVC lamps deactivate airborne pathogens, but cannot penetrate the human eyes or skin making them generally safe to use.

Right now they do require rather bulky lamps (Krypton Chloride), but last I checked there had been promising advancements in producing far-UVC LEDs [2]. Which should make installation and deployment of far-UVC both more practical and economical in the future.

[1] https://en.wikipedia.org/wiki/Far-UVC

[2] https://ece.engin.umich.edu/stories/ece-spinout-company-ns-n...

I couldn't agree more. And in the rare cases where destructors do need to be created inline, it's not hard to combine destructors with closures into library types.

To point at one example: we recently added `std::mem::DropGuard` [1] to Rust nightly. This makes it easy to quickly create (and dismiss) destructors inline, without the need for any extra keywords or language support.

[1] https://doc.rust-lang.org/nightly/std/mem/struct.DropGuard.h...

The differences in regional prices are interesting to me. From a recent article comparing BYD's offerings [1]:

The BYD Dolphin EV sells for the equivalent of around $16,500 in China, while in Germany, with the same battery pack, it’s over $37,400, or more than double the price. The Seal costs around $30,300 in China, while a similar version currently on sale in Germany is over $48,000. Reuters found Dolphin prices outside China between 39% and 178% higher, while those for the Seal ranged between 30% and 130% higher.

Affordable EVs are here already, though access to them is not evenly distributed.

[1] https://insideevs.com/news/718036/byd-major-ev-markup-prices...

Some anecdata from my kitchen, which has an air quality monitor positioned approx. 4 meters away from the stove:

- Most days when cooking PM2.5 doesn't exceed 5ppm.

- I accidentally burned some vegetable oil this week, and PM2.5 shot up to around 70ppm.

- I fried up pancetta a little too hot a few months ago, rendering the fat entirely, and both PM2.5 and PM10 went up to >999ppm.

Aren't the entities who manage relays the ones who broker access to the network? E.g. if you subscribe to a relay, you must also subscribe to their moderation decisions.

Say if Bluesky (the company) bans someone, that person could still have the keys to their data, but their feeds will no longer be "re-broadcast" by that company's servers - right?

Running a relay is not expensive anymore [...]

$30/mo is $360/yr, which for most people is a prohibitively large sum of money. That would make Bluesky access more expensive than even the most expensive Netflix subscription; closer to the cost of a cellular plan.

For comparison: for my Mastodon account I pay $5/mo or $60/yr to a dedicated hosting provider. This puts it in the same ballpark as paying for a private email host or a VPN subscription.

It's hard to tell honestly. I studied psychology for two years in uni, and I dropped out rather disillusioned about the field. Some of my least favorite aspects included:

  - Acknowledgement by our professors that P-hacking (pruning datasets to get the desired results) was not just common, but rampant

  - One of our classes being thrown in limbo for several months after we found out that a bunch of foundational research underpinning it was entirely made up (See: Diederik Stapel).

  - Experiencing first-hand just how unreproducible most research in our faculty was (SPSS was the norm, R was the exception, Python was unused).

  - Learning that most psychology research is conducted on white psychology students in their early/mid-twenties in the EU and US. But the findings are broadly generalized across populations and cultures.

  - Learning that the DSM-IV classified homosexuality as a mental disorder. Though the DSM-V has since dropped this. 

Though I do generally hold psychologists in high regard (therapy is good), I'm not particularly impressed by psychology as a science. And in turn don't necessarily trust the DSM all that much.

We are more or less trying to solve this exact problem with Wasm Components [1]. If core WebAssembly is a portable instruction format, WebAssembly Components are a portable executable/linkable format.

Using them is unfortunately not yet quite as easy as using repr(wasm)/extern "wasm". But with wit-bindgen [2] and the wasm32-wasip2 target [3], it's not that hard either.

[1] https://youtu.be/tAACYA1Mwv4

[2] https://github.com/bytecodealliance/wit-bindgen

[3] https://doc.rust-lang.org/nightly/rustc/platform-support/was...

Hey all, today the Azure Core Upstream team has open sourced Wassette: a WebAssembly-based runtime that allows Wasm Components to connect to AI agents using the Model Context Protocol. Wassette’s main contribution to the MCP space is efficient sandboxing: because if you’re going to run untrusted third-party tools locally, it’s probably a good idea to proactively restrict which system resources it can access.

In this post we explain what Wassette is, how to set it up locally, and finally walk through an example that exercises Wassette’s capability system. What we don’t cover in the post is how to write Wasm Component-based tooling for Wassette, but we have some docs for that in the README [1].

Anyway, I hope this interesting to folks here! I’ll be around for a couple of hours here to answer questions folk might have. And if I don’t know the answer, I can probably find an engineer who does. Thanks!

[1] https://github.com/microsoft/wassette#building-for-wassette

`await-tree` seems to be able to output to JSON. As long as all keys are unique, it should be straightforward to convert it into the Collapsed Stack Format most flame graph tools natively ingest.

As a reference: I wrote a Dhat-JSON to Flamegraph conversion tool a while ago for fun. Adapting this to instead convert from the await-tree JSON format probably shouldn't take long:

https://github.com/yoshuawuyts/dhat-to-flamegraph/blob/main/...

A study published just yesterday [1] showed that just two airborne diseases [2] were responsible for approximately 85% of all sicks days in Greece during 2023-2024. Disregarding the common-sense argument that reducing collective suffering is a good thing overall - even by the cold hard logic of capital, being able to reduce company sick days by up to 85% is a huge opportunity.

Imo we're way overdue standards and controls for clean indoor air that are on par with standards for drinking water and food. Like this article shows, we have the tech to provide clean air today. All we're missing is policy to uniformly deploy it.

[1] https://www.sciencedirect.com/science/article/abs/pii/S01966...

[2]: SARS-CoV-19: ~75% of sick days, Influenza: ~10% of sick days

Though both share the ability so securely execute multi-tenant workloads, but they make very different tradeoffs when it comes to compatibility vs performance. To compare:

Firecracker is great if you want to securely execute an OS image. It has the benefit of compatibility with many existing programs, but that comes at the cost of some overhead.

Hyperlight is great if you want to securely execute program runtimes. This requires bespoke guest bindings, but it has the benefit of having less overhead.

There’s a place for both approaches, and I see both happily co-exist.