nixpkgs already has infrastructure to compile to wasi the same way you compile to other platforms like arm, darwin (macOS), musl, etc.

nix-build -A pkgsCross.wasi32.$pkg

i haven’t found any $pkg there that actually builds though. coreutils depends on posix stuff, busybox tries to include a non-existent netdb.h file. even hello barfs inside i think some autotools-generated wrapper around fcntl.

i don’t understand enough about wasm to know if it really is reasonable to think of it as a “system” the same was x86_64-linux or aarch64-multiplatform is a “system”, but if so i’d love the equivalent of this blog post showing how to use (or fix) the wasi32 system!

i switched all my devices to UTC about a year ago when a surprise DST transition caught me in a pissy mood.

it’s fairly internalized by now. i don’t think it’s that much harder than developing an intuition for both Celcuis and Fahreinheit temperatures. sometimes i’ll glance at the clock while at a friend’s house and it says 09:00 and i do a double-take because “how is it already going-to-bed time?” before i realize it meant 9PM local time, not 09:00 UTC (1AM local).

but it’s the things you don’t think about that make it difficult. set your phone to UTC and 24hr time. first thing you’ll notice is that every weather app blissfully ignores your settings, because they’re showing you weather for a specific place, and assume you care about the time local to that place. second thing you’ll notice is that half your IM apps are going to actually be using AM/PM still. they’ll even mix AM/PM with 24hr within the same app. you read “message received 11:20” and it could mean like 3 different things.

not to mention all the physical stuff: car clocks, oven/microwave clocks, … a lot of these in the US don’t even give an option for 24hr time, and “11:20 PM UTC” is just so cursed.

well that settles it: Cascadia is the land of weebs.