The most obvious answer is gaming. Hard 60/144Hz deadlines is RT. But there are lots of changes that got into the kernel from the RT group, starting with getting rid of the BKL, which helped everyone.

People who wanted GPS were also already using it by buying TomToms or other GPS devices…

The average desktop user already benefits from the changes the RT folks have slowly been getting into the baseline.

“Very fast” is relative. 1200mm/s is very fast for 3D printing, no argument. But it’s 1.2mm/millisecond, and we’re talking about time scales in the microsecond range. I suspect you’re going to run into materials issues far before real time performance becomes a limiting factor in print speed and quality.

It’s like saying GPS was available for decades before, why would putting it in everyone’s phone expand its popularity.

For myself, I’m hoping the nerds and hackers that otherwise found it not worth the effort will start creating tools to manage real time better and start building them into the applications they write. That way you don’t need to pay an arm and a leg to RedHawk for the privilege of dynamically isolating CPUs or have to reboot the computer to modify kernel arguments a la RedHat MRG.

What’s preventing that from working now? If it’s indeterminate latency, then yeah, absolutely. Theoretically this will give you the ability to have a very deterministic loop around the accelerometer data, but 3d printers don’t move all that fast to begin with so having unbounded latency might not matter. The determinism we’re talking about here is on the order of tens of microseconds or less.

Could be that both texts are provided to the phone, which would then pick the appropriate version. Seems more reasonable than trying to keep track or query millions of phones of different make and manufacturer for a language setting.

They probably aren’t insured at all. These aren’t billion dollar satellites, so they’re probably just launched at risk.

systemd-boot baby