This is exactly what the Starlark language was developed to solve, initially for Bazel but also used other places. It's a "full scripting language" but intentionally doesn't (in default configuration) support recursion or unbounded loops, so is deterministic and bounded execution time. I really wish more projects would reach for it as a configuration language.
I have such mixed feelings about Starlark and Bazel macros. When I write Bazel macros, they're great, the perfect tool for the job. When I encounter macros written by someone else, they are awful, a mistake and the bane of my existence.
> Not to mention that trains are far safer than automobiles too.
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.
In the context of this thread, it's worth pointing out that "trying to deceive regulators" is quite normal behavior for individual human drivers involved in car incidents, and iirc the Cruise collision itself also involved a human driver performing a hit-and-run who didn't afaict ever get prosecuted or come forward to police.
Tangentially related, but there's a bunch of extremely high-resolution panorama images from the Apollo landings available at this site, for anyone who enjoys this sort of thing. https://www.lpi.usra.edu/resources/apollopanoramas/
They successfully built local privilege escalation exploits (from several bugs each), and found other remotely-accessible bugs, but were not able chain their remote bugs to make remotely-accessible exploits.
Not even mentioned in the article, my favorite capability is the new `//go:fix inline` directive, which can be applied to a one-line function to make go fix inline it's contents into the caller.
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.
Do we even know that the child was injured? All I've seen anyone officially claim is that the Waymo made contact, the kid fell over, then stood up and walked to the side of the road. Assuming the Waymo was still braking hard, 6mph means it was about 1/4s and about 30cm from reaching a full stop, so it could be a very minor incident we're talking about here.
I'm not aware of any statistics for how often children come into contact with human-driven cars.
Your expectation is wrong in this case for almost all languages. The design of Pylance (as is sorta forced by Python itself) chooses to execute Python to discover things like the Python version, and the Python startup process can run arbitrary code through mechanisms like sitecustomize.py or having a Python interpreter checked into the repo itself. To my knowledge, Go is one of the few ecosystems that treats it as a security failure to execute user-supplied code during analysis tasks, many languages have macros or dynamic features that basically require executing some amount of the code being analyzed.
I did a pretty deep dive into this recently, although haven't yet started any implementation work. As far as I can tell, the best strategy that preserves Linux's open-source and user-empowering ideals as much as possible:
- 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.
Doing some quick math, if your bike is using 3kw to climb a reasonably steep (15% grade) hill at 8mph, we can calculate the weight it must be carrying, which ends up being about 1,200lbs
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://github.com/bazelbuild/starlark
reply