https://github.com/bazelbuild/starlark

This claim is situationally true, but not universally so like many people seem to believe. For example, Brightline rail service in Florida has been operating since 2017 and averages (by my math) 29.8 deaths / 100M passenger-miles, while the road system in Florida averages 0.89 deaths / 100M passenger-miles. Those deaths are mostly not suicides, and imo we should treat pedestrian deaths from trains as substantially more morally weighty than passenger deaths, since it's a victim that didn't opt-in to the risk.

For what it's worth, the unusual spike in Spain train crashes this year seems to have pushed them barely over the fatality numbers of Spanish cars (0.91 deaths/100M pax-mi vs 0.73 for cars) but that's pretty clearly an outlier.

If you measure per vehicle-mile rather than per passenger-mile I'm pretty sure trains are always way more dangerous, although that's a less fair comparison.

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