Rust does not rely on syscalls or libraries on embedded targets, which is what the #![no_std] marker at the top of the project indicates. On some platforms, like ESP32, Rust can make calls into the RTOS and don't need that marker, but other embedded targets don't provide access to the std crate and you need to interact with peripherals from Rust or by interfacing with C or assembly.
This has stayed the case with the transition to Wayland: pressing Ctrl + Alt + F1 shows me the login screen, and Ctrl + Alt + F2 takes me back to the desktop.
Software vulnerabilities are often not placed maliciously, and are present in the original source. If you don't patch them if discovered later, you'll be vulnerable to them.
With the exploits published as-is, you'll only get root inside the container: there's no explicit namespace break, and calling setuid() in a container just gives you root in the container.
However, it can be used to modify files that are passed into the container (e.g. Docker run -v), or files that are shared with other containers (e.g. other Docker containers sharing the same layers). kube-proxy with Kubernetes happens to share a trusted binary with containers by default, which is how it can be exploited: https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kuber...
I would love a world where I could put all my API keys in the TPM so malware couldn't gain persistent access to services after wiping my computer. This would be so easy if more providers used asymmetric keys, like through SSH or mTLS. Unfortunately, many don't, which means that stealing a single bearer token gives full access to services.
There's also the TPM speed issue. My computer takes ~500ms to sign with an ECC256 key with the TPM, which starts to become an issue when running scripts that use git operations in serial. This is a recurring problem that people tend to blame on export controls: https://stiankri.substack.com/p/tpm-performance
> The computer that you are trying to wake up also needs to be connect with an ethernet cable as it is not possible to send a magic packet over wifi.
While WiFi adapters may not support waking up the computer from a WiFi signal, you absolutely can send magic packets over WiFi as they're normally just UDP broadcast frames. Convenient for waking up a desktop from a laptop!
Yep. While the Terminal is not an option from the 4 apps listed in the initial screen, it's available from Utilities → Terminal at the top. They even provide a convenient way to access the hard drive from another computer: https://support.apple.com/guide/mac-help/macos-recovery-a-ma...
Nice! There's also zstd's flush ability that I've used for streaming robotics data. You can write data and flush it over the network for realtime updates, but the compression stream stays open so it can still reference past messages. This means messages get smaller over time so you don't need to share a dictionary ahead of time. I'm not aware of other compression algorithms that have flushing capability like this.
> binary data to connected clients in tiny messages, each saying “field 5 on object X is now 123”
I wonder how Meta's newer, format-understanding OpenZL would do. I imagine its schemas could be auto-generated from protobuf.
Linux by default allows all users to read CLI arguments of running processes. While it looks like your bwrap invocation prevents the sandbox from looking at this process (--unshare-pid), any other process running on your system can read the secret.
Firefox's WebRender is truly a great creation. While Chrome is faster at most things especially involving JS, Firefox puts so much of its rendering on the GPU so moving elements around is incredibly fast.
Rust's only requirement is that memcpy, memmove, memset, memcmp, bcmp, and strlen are available, and it can provide them if needed: https://github.com/rust-lang/compiler-builtins