*lots* of terminology.
Let's try unscrambling some of it
*Millennium bug". Failure cased by incorrect processing of change from 1999 to 2000. The article shows *no* evidence for this class of bugs being the cause of the problem.
Business critical. System fails company goes down pan. That *would* have described any major *offline* accounts app EG LEO (Lyons electronic Office). More recently would be the code that did calculations for a medical radiation source to decide, given various factors how much to dose them with. Not real time at all (except in the loosest sense) but *absolutely* critical to delivering the machines function. The code had bugs and several patients got 10x the dose they should have had.
Latency tolerant soft real time. Describes lots of stuff on *any* GUI. You clicked on "My Documents" and it showed you the folder. It opened fast *enough* that you're not bothered. If it takes a *bit* more (or less) time to act you're *still* not bothered. The cursor followed you mouse *well* enough to keep you feeling in control.
Latency intolerant soft real time. Here the *consistency* of the response is the important thing but I can't think of a situation where this applies.
After this things get *tough*. Typically the computer system is connected to "stuff" and if the computer can't work out the *right* response in a *guaranteed* amount of time *every* time *very* bad things happen. The "stuff" might be another computer on the network (Skype's latency and *consistency* of that latency are both pretty important for it to work well). If the system is an airliner, jet engine or Uranium enrichment centrifuge things can go badly wrong very quickly.
*nix's were never designed to support *hard* real time constraints but various upgrades to standard functions and the *long* background in building architectures that run such tasks have built up a *lot* of expertise in what to do and how to do it.
Armadillo Aerospace runs such a box to to fly the lunar lander which won the NASA challenge prize.
Some of the usual features for the work include a high resolution clock for the scheduler, software modules locked in main memory (no writing to disk) and either locking module scheduling priorities *permanently* or only allowing them to be changed under *very* carefully controlled criteria.
The developer and admin mindset is important here. While it looks to the apps and the dev tools like a normal *nix box it is not *run* like one.
Of course while the knowledge is out there and developers *with* the knowledge are out there as well it's not clear if *these* developers have it.
BTW Be *very* careful of the phrase "real time." Real time relative to *what*? A human can't control an unstable aircraft without computer assistance (watch the control surfaces of an F16 if you ever see one but *can* respond fast enough to simulate an ABS (c5 brake presses a second IIRC). OTOH a chemical plant with a time constant of 1 hour can be controlled by a human with a chemistry set, some graph paper and a calculator in "real time."
That's my pedantry done.