I read through the link. The other pilot and the captain are complicit by the virtue of being there. Autopilot disengages at 2:10 and they crash at 2:14. Terrible.
My other immediate thought -- Tesla's autopilot. I've never used it so I'm not sure I'm fully correct here, but apparently it requires you to be vigilant and take over in certain situations? Wonder how well that works out in practice.
In practice, there's a camera in the Tesla that looks at the driver to make sure they're paying attention. If they're not, perhaps fiddling with their phone or looking at something in the passenger's seat, then the system gives a warning and then a strike. Get five strikes and you can't use FSD for the next week or two. So drivers are directly incentivized to keep their eyes on the road because if they don't, they can't actually use the system which would suck for a long road trip.
Well, maybe. It's projection, because I certainly don't make simple processes myself a lot of the time, but I do try to optimize them afterwards. I have a few decades of seeing people implement processes than I've had to use, and then had to simplify as I moved into more senior roles. I've had people push back quite forcefully when I've pointed out they do things like writing reports that no one reads or gathering data that teams ignore. People often fight for added complexity because their perception is that it's important, and that means they must be important because they're the one in control of it.
There is an element of projection because there is in most things people talk about; I'm speaking about this through my filters and biases after all. But it's grounded in a fair chunk of experience.
Maybe you are saying the same thing, but couldn't that be explained better by those people being afraid to be made obsolete? Or at least, afraid if having to retrain?
I pretty much always read the first sentence of an article, then the last paragraph, and then the full first paragraph, then the beginning sentences of middle paragraphs, until finally reading an entire piece. Often times, along this process I'll abandon the piece.
I appreciate when an article can so clearly tell my mind to stop so soon. Anyways, I clicked on this article, saw that line you linked, clicked the comments and was pleased somehow to see someone else point that line out.
Humans going around the moon will be amazing every single time for the next 10,000 years it happens for anyone who isn't already a miserable person. Going for a swim in the ocean is an amazing experience every single time and I can do it every day. It's still a great feeling. Going to the moon is so much more extraordinary in the literal sense of the word. The fact that any collection of creatures is able to do it is remarkable.
Both. Whatever works for you I'd say. I targeted the Raspberry Pi (Cross-Linux From Scratch variant), and a fake root (via chroot) and qemu. This was circa 2014 though.
These days the ARM64 processor on the Raspberry Pi 5 is probably fast enough to just build natively on it, no cross-compilation necessary. Cross-compiling adds a metric ton of complexity.
Having done this way back when on both: go with a VM first.
Targeting a known set of virtual devices makes a lot of things much easier when building LFS. Dev ux is also much nicer:, you get faster restarts, a socket and optional snapshots to go back to a known less broken state.
In my opinion having it on a separate computer is easier,
but you can also run this in one or three KDE konsole tabs,
for instance, on an external hdd/sdd.
We could also talk about lb•AU (pound Astronomical Units), but generally it's best to stick to what's standard so readers don't need to do conversions. Watt hours is great.
It's not terrible... The iPhone 17 has a battery capacity of 63 nano lb·AU. Around 16 million would equal 1 lb·AU.
Another fun one would be milli hundredweight leauge (mcwt·lg). Both hundredweight and league have multiple accepted definitions to make it more "fun". But the range maps quite nicely to everyday things:
