Linux real-time has existed for many years, but it's still Linux. That means that it's a big, underspecified project. RTEMS is designed for high reliability embedded environments, especially spaceflight. These systems are smaller and have very high standards for reliability and verification. Linux doesn't fit well in that niche, but RTEMS is very good.

About that:

- Real-time is about guaranteed response times

- What are the guarantees of real-time Linux?

I don't think I have ever read about the latter. Maybe because real-time Linux is barely used where real-time behavior has more important consequences than audio dropouts. And it's difficult on PC hardware with stuff like surprise system management mode intervention, various hardware probably hogging some bus sometimes...

In embedded systems with hard real-time requirements, there are several ways to schedule tasks. Once the number of tasks you need to execute grows long enough, scheduling becomes a challenge. An RTOS is one way to manage these tasks with guaranteed, deterministic timing.

A concrete example: if you're in a car (an embedded system doing many things at once) and press the brakes, you want the car to be as responsive as possible. A real-time operating system will sacrifice other features of a general purpose OS to guarantee that the brakes are applied within a specified time interval after you press them.

Also, there are responses to a similar comment from when this was previously posted: https://news.ycombinator.com/item?id=32329499

There are a lot of systems that rely on precise timing, for instance clock generation/recovery, or opening/changing/closing a control valve in some process. It has to be precise or you lose sync in the first case or legitimate catastrophes can happen in the second.

A realtime OS makes some guarantees about the timeliness of things like interrupt service routines, and that necessarily excludes unbounded and unknown workloads from getting in the way -- something that every general purpose or soft realtime OS struggles with as the lack of determinism can improve throughput and scalability.

It's important for manipulating dynamic physical objects. Things tied stronger to wall clock than CPU clock, like rockets flying through the atmosphere and EV motors rotating as car rolls downhill.

They don't care about cache hits and branch predictions, so whatever you do with pulsating fuel pressure or flowing back regen electricity better happen predictably on-time than just ASAP off quuees. RTOS offer you that stability in time direction.

One of main differences between a traditional multiprocessing operating system and a real time one is that in the latter each process gets a fixed time slot to run and the kernel provides a guarantee that the process will be preempted no matter what. This gives every process running under the supervision of a real-time kernel a chance to do something useful.

Whereas in non-RT systems, a process may «overstay the welcome», and the time slot it has been allotted may lengthen (e.g. due to a computationally intensive unit of work or a blocking I/O operation) at the expense of other processes waiting in the scheduler run queue.

So non-RT kernels operate on the best effort basis («I will try my best to ensure each time slot has the same duration») vs guaranteed preemption in RT kernels («I hereby underwrite a guarantee that each time slot has the same duration and pledge that offending squatters will be evicted»).

Other than an example with the car, real-time processing is important in the audio engineering or processing where an audio stream will stutter in a non-RT operating system. There are other similar scenarios as well.