That ends up being a really powerful primitive for library authors to get users off of deprecated functions, as long as the old semantics are concisely expressible with the new features. It can even be used (and I'm hoping someone makes tooling to encourage this) to auto-migrate users to new semver-incompatible versions of widely used libraries by releasing a 1.x version that's implemented entirely in terms of thin wrappers around 2.x functions and go fix will automatically upgrade users when they run it.

I'm not aware of any statistics for how often children come into contact with human-driven cars.

- The game obviously needs to run as root, at least until large amounts of this stuff gets upstreamed into the kernel.

- We're going to be leaving the kernel and boot as untrusted, but injecting a hypervisor underneath the running kernel that is responsible for protecting most pages of game memory. This allows users to still run whatever kernel they want.

- The hypervisor sets up two sets of page tables, one that's only active when the game's thread is running and in userspace, one that hides protected pages and is active when the kernel or other threads are running. Note that game code itself needs to get decrypted into protected ram.

- The TPM of the system gets involved when we jump into the hypervisor to attest that the hypervisor is actually running, and the hypervisor then provides attestations to userspace that certain memory regions are protected from kernel or other thread access.

- Any syscalls will fail if they require the kernel to read or write pages that are protected. The game needs to allocate data that should be shared with the kernel into non-protected pages.

- When the game is closed, we can remove the hypervisor and Linux will be back to bare metal operation. This should be unobservable to the rest of the system.

This architecture preserves the ability of users to run arbitrary kernel modules, but does mean a hypothetical attacker can observe data that passes through the kernel (like draw calls/pixels). It's likely that a more complete implementation would also want some way for the hypervisor to attest to the accuracy of keyboard/mouse input and interface with iommu configuration like Windows KAC does.

To answer your question, the limit on motor power exists as a proxy for limiting the weight, speed, and acceleration of ebikes within safe limits, since having an ebike charging uphill at 20mph with 500lbs of payload would present actual safety risks. Trying to regulate payload/speed/slope combinations directly has practical problems (police officers don't really want to stop delivery drivers to weight their cargo), while regulating motor power is much simpler.

https://kunimune.blog/2023/12/29/introducing-the-elastic-pro...

https://www.astralcodexten.com/p/your-review-alpha-school

https://github.com/groupcache/groupcache-go

https://github.com/Skydio/revup

We’re building novel robots for case picking in warehouses, a huge unsolved automation opportunity for a very labor-intensive, critically important and sh*tty human job in the thin-margin industry of logistics. Our software is all Rust/Pytorch, embedded dev through research-frontier applied algorithms and an integrated development iteration time measured on a watch, not a calendar.

There’s more than enough fun problems to go around, and we’re looking to grow the team with a couple more great-to-work-with folks, including generalists or job descriptions we haven’t realized we should be hiring for. We’re also specifically looking for a summer applied ML intern for robotic perception and controls. There’s a lot more cool stuff we can’t share publicly just yet. To apply, email a resume to @autopallet.bot, and include the role you’re looking for in the subject line, and we’ll take it from there. Bonus points if you include a link or photo of something cool you’ve made.

If you had a spinning duct, you'd presumably need a stationary shaft in the middle for mounting the vanes, and would have similar tolerance issues between the tips of the stationary vanes and the rotating duct. There's reasons that it might be easier to solve (the duct can be lower temperature) and reasons it's harder (bearings for a giant spinning duct). Not sure if anyone has tried such a design.

In the process of investigating this, I also realized that there's a ton of other unique-per-thread pointers accessible from that structure, most notably including the value of %fs itself (which is unfortunately unobservable afaict), the address of the TCB or TLS structures, the stack guard value, etc. Since the goal is just to have a quickly-readable unique-per-thread value, any of those should work.

Windows looks similar, but I haven't investigated as deeply.

[0] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...

[1] https://github.com/andikleen/glibc/blob/b0399147730d478ae451...