It's much simpler. In the EU, truckers have to do mandatory 45 min breaks after 4 1/2 hours of driving. With the latest truck generation, this is enough time to recharge to get through the rest of the shift. 400 kW charging is sufficient in this scenario. No wasteful expensive H2 or fancy battery swapping technology required.
IQ tests are a bit absurd if one looks at the changing definitions of intelligence over the past century.
Someone in the 1920s/30s would call the ability to solve equations or play chess well as signs of high intelligence. Not so long ago, translation of natural languages was considered a task requiring a good level of intelligence.
Each progress in AI changes the definition of intelligence as we realize that a machine finally able to do task X is not really as intelligent as we thought it had to be.
And today the AI/robotics industry struggles to build a machine that can perform the job of a room cleaner. Beating grand masters at chess was far easier.
I did once fly as a guest with a winch start, and yes it is something. The ascend is pretty steep and the acceleration is powerful. The pilot did not find good lift and we had to land shortly after. My stomach did not like his curving around looking for lift, so I wasn't too unhappy about the short flight.
My late father was a maintenance technician for those things. He hated it when programmers did smart instruction placement to optimize drum timing. When the drum speed was a little off, they called him to calibrate it so their programs would run fast again.
I don't understand the difference to TCP here. If the path is not congested but the receiving endpoint is, the receiver can control the bandwidth by reducing the window size. Ultimately, it is always the sender that has to react to congestion by reducing the amount of traffic sent.
RPC is something of a red flag as well. RPCs will never behave like local procedure calls, so the abstraction will always leak (the pendulum of popularity keeps swinging back and forth between RPC and special purpose protocols every few years, though).
AFAIK, an ebpf function can only access memory it got handed as an argument or as result from a very limited number of kernel functions. Your function will not load if you don't have boundary checks. Fighting the ebpf validator is a bit like fighting Rust's borrow checker; annoying, at times it's too conservative and rejects perfectly correct code, but it will protect you from panics. Loops will only be accepted if the validator can prove they'll end in time; this means it can be a pain to make the validator to accept a loop. Also, ebpf is a processor-independent byte code, so vectorizing code is not possible (unless the byte code interpreter itself does it).
Given all its restrictions, I doubt something complex like a graphics driver would be possible. But then, I know nothing about graphics driver programming.
> Fighting the ebpf validator is a bit like fighting Rust's borrow checker
I think this undersells how annoying it is. There's a bit of an impedance mismatch. Typically you write code in C and compile it with clang to eBPF bytecode, which is then checked by the kernel's eBPF verifier. But in some cases clang is smart enough to optimize away bounds checks, but the eBPF verifier isn't smart enough to realize the bound checks aren't needed. This requires manual hacking to trick clang into not optimizing things in a way that will confuse the verifier, and sometimes you just can't get the C code to work and need to write things in eBPF bytecode by hand using inline assembly. All of these problems are massively compounded if you need to support several different kernel versions. At least with the Rust borrow checker there is a clearly defined set of rules you can follow.
reply