But the RT patches have been available for 20 years... not sure why the fact that it is mainlined would suddenly expand its popularity? It might be easier to get started sure, but people doing RT were already going to such troubles anyway.

I'm curious about this. I've started playing with Reaper and getting into music recording and production. I'm very fresh on the scene and haven't used any DAWs on any other OS, except viewed protools on Mac. I can't quite get latency free playback, which may just be user error and configs.

Do you know if something like this will have default benefits out of the box, or will we need to somehow configure our apps and services to utilize these changes? I'm completely ignorant but am really intrigued.

Probably some use cases for "regular" users. Someone mentioned music production, though that's probably more professional than hobby.

To my understanding, you mostly need real time performance for specialty cases where timing is absolutely critical. So I guess if you were building custom drones or custom control boards for drones, you could use real time Linux for that now since the timing could be guaranteed.

Pretty specific use case. A normal OS handleds time slicing and core assignment for processes and uses it's judgement for that. So at any time your process can be suspended and you don't know when you get your next time slice.

Same with when you make wait calls. You might say wait 100ms but it may be much longer before your process gets to run again.

In a real time OS if you have real time priority the OS will suspend anything else including it self to give you the time you request. It also won't suspend you no matter how long you use the core.

So if you need to control a process with extreme precision like a chemical manufacturing process, medical device, or flying a rocket where being 10ms late means failure they are required.

However with great power comes great responsibility. You need to make sure your code calls sleep frequently enough that other tasks have time to run. Including things like file io or the gui.

My guess is not a whole lot to the average user, but it would allow for things to still respond when other things have bogged down resources. I am assuming real world applications would be industry like a machine safery stop should always have a quick turn around, and not be delayed by harddrive writes. But may like how they write special OS code for spacecraft where sending and receiving instructions on board has special states and if response isn't given in timely manner the system can recognize, so malfunctions are prevented. There was an artivle/podcast somewhere abouy how this all had to work in realtime and not be queued waiting

No, but you might notice programs get more responsive as time goes on, ofc if people use it wrong you might see more freezes and system crashes.

RedoxOS is trying to do that with Rust

Doesn't say, but I am curious. They said their workarounds broke other workarounds which caused a lot of implementation delay, but I'm not sure what the actual compromise was to address all that.

Answer probably lies somewhere in the kernel maintainer's mailing list, I'd imagine. Just not equipped to search for it right at the moment.

I'm not an expert, but have used a real time kernel for scientific research, using rtxi. My understanding is that the real time threads allows the computations to occur in a deterministic amount of time. This is necessary if you want to quickly respond to changes in personal membrane voltage with injections of current, and don't want it to sometimes take longer to calculate how much current to inject.

RT systems are all about responsibility.

When you're driving a vehicle, the vehicle has a lot of CPUs inside that help the steering.

When these CPUs pause - for even 0.4 seconds - something bad can happen. Somebody can get seriously injured, or even killed. So it is very important that these systems never freeze or pause for any reason. That is what RT is all about.