Notices by yosh (yosh@toot.yosh.is)

Reminder: the term “annexation” is used instead of “invasion” to make the threat of war sound less hostile and more palatable.

You are always free to reject framing of this kind. It’s not a “special operation” or “proposed annexation” — it’s a ground invasion. A threat of war. Call it what it is.

Cladding terms like these in euphemisms is no accident. Even a child can tell you that war is a bad thing.

But if you don’t call things what they are, and make them sound academic or legal — well then all of a sudden it seems like it must be something elaborate and maybe even complicated.

No no, we’re not invading another country. We are re-evaluating the legality of historical territorial boundaries. Or something like that.

Nazi Germany had a knack for making up all sorts of legal terms and processes to justify their menagerie of horrors.

People feel safe in process. Euphemism is comfortable. And it absolutely works. Because it’s not state-sanctioned murder, it’s “capital punishment”. It’s not torture, it’s “enhanced interrogation.” It’s not genocide, it’s “protecting national security interests”. And so on.

In today’s “terminology matters”:

❌ Return To Office policy: middle-management language that assumes “office” is a neutral position, we’re somehow “returning to”. This term has been carefully crafted by corporate strategists to sound as palatable as possible.

✅ Mandatory Commute policy: centers the outcome for workers - spending hours each day on an unpaid commute to and from the office just so we can be on video calls all day.

We don’t just have to accept hostile framing.

Regular reminder that effective, cheap, mass sterilization technology for just about every known and unknown airborne pathogen exists — we just choose not to deploy it.

HEPA-grade air filters are cheap, easy to install, effective, and severely underused. Unprecedented flu outbreak? SARS pandemic? N5H1? It can scrub the air of all of the above quickly, efficiently, and economically.

There’s a lot I disagree with Drew DeVault on, but I respect this a lot:

https://drewdevault.com/2025/01/16/2025-01-16-No-Billionares-at-FOSDEM-please.html

Heh, I didn't consciously realize that the way Rust determines whether an associated function is a method or not is based on whether the identifier is called `self`. That means that this is a method:

fn meow(&mut self) { .. }

And so is this:

fn meow(self: &mut Self) { .. }

But this is not:

fn meow(Self { a, b }: &mut Self) { .. }

Instead the latter is parsed as a static method that takes an instance of `Self`. Despite it operating on the same type as the other variants.

Sorry, what kind of values?

Hear me out: Noctua bathroom fans

Found out about Wirth’s law the other day. It’s… not wrong.

(Software gets slower at a faster rate than hardware advances can speed things up)

https://en.wikipedia.org/wiki/Wirth%27s_law

Wasmtime being a universal language runtime also means there is an opportunity to write universal developer tooling.

New blog post: What are Temporal and Spatial Memory Safety?

https://blog.yoshuawuyts.com/temporal-spatial-memory-safety/

A good thing I did this week: deleted both YouTube and instagram off of my phone and iPad. Feeling a lot calmer already.

I’m keeping Mastodon tho; I can’t really keep scrolling on here, and I think that’s a good thing.

the existence of bisexual sitting implies the existence of bisexual sciatica

@xgranade

Hah, I thought USB was the USB of home theatre :P

For people looking for more context on why C++ Profiles are not going to work, here is a good analysis:

https://www.circle-lang.org/draft-profiles.html#c-is-under-specified

C++ profiles, as designed, cannot achieve memory safety. The only way I see it “succeed” is if they try and move the goalposts by attempting to redefine the term “memory safety” to fit what they can deliver.

From my perspective that’s a dead-end. The only realistic mid/long-term solution is replacing C++. The only realistic short/mid-term solution is sandboxing C++.

The cool thing about this approach is that it can be designed and implemented without any input from the C++ committee.

The way to think about “memory-safe systems languages” is that they provide *static* memory safety, which provide optimal performance.

But if the language chooses not to statically mitigate defects, then yeah sure, as practitioners we can just choose to employ security measures to guard against them at runtime.

Don’t just take my word for it; the Chromium project makes this pretty clear with their “rule of 2”. Pick no more than two of:

- code which processes untrustworthy inputs
- code written in an unsafe language
- code which runs with no sandbox

The inputs and outputs to programs are typically fixed to the domain and cannot be changed. Meaning: if C++ code cannot be replaced with a memory-safe language, and cannot be rewritten to be memory-safe, the only remaining option is to sandbox it.

“But Yosh, how would we sandbox C++ code at scale?”

While not a perfect solution — Firefox’s RLBox toolkit (https://rlbox.dev/) provides the template for that. It compiles a C program to Wasm, puts it inside a Wasm sandbox, and provides the same API on the outside of the sandbox.

Now if the sandboxes library exhibits UB, it can no longer be used to exploit the rest of the program. Here’s a full writeup of how this works:

https://hacks.mozilla.org/2020/02/securing-firefox-with-webassembly/

Re: the C++ committee voting down the adoption of a memory-safe subset.

IMO the choice was not between “memory-safe C++ subset” and “C++ profiles”. It was between “memory-safe C++ subset” and “C++ code must always be isolated in a sandbox” — AKA “C++ goes to jail now”.