[dripton]

You can divide realtime applications into safety-critical and non-safety-critical ones. For safety-critical apps, you're totally right. For non-critical apps, if it's late and therefore buggy once in a while, that sucks but nobody dies.

Examples of the latter include audio and video playback and video games. Nobody wants pauses or glitches, but if you get one once in a while, nobody dies. So people deliver these on non-RT operating systems for cost reasons.

[lll-o-lll]

> You can divide realtime applications into safety-critical and non-safety-critical ones.

No. This is a common misconception. The distinction between a hard realtime system and a soft realtime system is simply whether missing a timing deadline leads to a) failure of the system or b) degradation of the system (but the system continues to operate). Safety is not part of it.

Interacting with the real physical world often imposes “hard realtime” constraints (think signal processing). Whether this has safety implications simply depends on the application.

[jancsika]

Your division puts audio performance applications in a grey area.

On the one hand they aren't safety critical.

On the other, I can imagine someone getting chewed out or even fired for a pause or a glitch in a professional performance.

Probably the same with live commercial video compositing.

[eschneider]

Audio is definitely hard realtime. The slightest delays are VERY noticeable.

[jancsika]

I mean, it should be.

But there are plenty of performers who apparently rely on Linux boxes and gumption.

[binary132]

This kind of makes the same point I made though -- apps without hard realtime requirements aren't "really realtime" applications

[tremon]

No -- soft realtime applications are things like video conferencing, where you care mostly about low latency in the audio/video stream but it's ok to drop the occasional frame. These are still realtime requirements, different from what your typical browser does (for example): who cares if a webpage is rendered in 100ms or 2s? Hard realtime is more like professional audio/video recording where you want hard guarantees that each captured frame is stored and processed within the alotted time.

[atq2119]

> who cares if a webpage is rendered in 100ms or 2s?

Do you really stand by the statement of this rhetorical question? Because if yes: this attitude is a big reason for why web apps are so unpleasant to work with compared to locally running applications. Depending on the application, even 16ms vs 32ms can make a big difference.

[tremon]

Yes I do, because I don't think the attitude is the reason, the choice of technology is the reason. If you want to control for UI latency, you don't use a generic kitchen-sink layout engine, you write a custom interface. You can't eat your cake and have it too, even though most web developers want to disagree.

[duped]

The traditional language is "hard" vs "soft" realtime

[binary132]

RTOS means hard realtime.

[pluto_modadic]

I sense that people will insist on their requirements being hard unnecessarily... and that the bug is the fault of it being on a near-realtime system instead of it being faulty even on a realtime one.