I turned BSD 4.3 unix into RT on a VAX 780 by using an external KW-11P clock on highest priority interrupt, have the RT code run in the kernel, and otherwise, timesharing was still going while we were running the robot -- although it was pretty sloooow. There was a big memory pool in kernel space that stored robot variables, so when the robot fell over, we would press a button which would 'freeze' the circular buffer, and then the user-space code would do an ioctl() to receive a copy of that memory pool (it was too hard to share the same pool between kernel / user space -- or maybe I was too lazy, and the solution found was 'good enough' ;-) )
You can see this in action here: https://youtu.be/mG_ZKXo6Rlg?t=34 yes, I'm sitting 'driving' the bot.
it is available from the mirrors. Currently also available from CentOS.
last time i checked, it would not load the NVIDIA driver. YMMV.
if you are in the < 120hz range, then it will probably work fine for most non safety critical times.
Soft realtime, yes. It does keep scheduling latency under control, enabling e.g. pro audio with low latency (very small buffer). This is unlike without PREEMPT_RT, where with buffers under 20ms XRUNs happen frequently.
Hard realtime, no. It can't guarantee a thing, as the kernel is complicated (has millions of lines of code) and thus unpredictable.
Look at seL4 instead if your deadlines are hard. It has been designed for realtime, and comes with formal proofs of worst case execution time.
When you have a hammer (Linux) in your hand, every problem looks like a nail.
seL4 can do hard realtime, with formal proofs of worst case.
Linux can't, and won't ever be able to, due to its complexity (Millions of LoCs).