Hard real-time Linux has been around for ages, or it may never appear. It all depends on who you talk to. It also depends on your requirements. A two-second interrupt latency may be acceptable for some applications, and even many Linux implementations can easily handle interrupts within tens of milliseconds.
Part of the problem is that several solutions have existed for many years, like FSMLabs RTLinux and MontaVista Linux. Both take a different approach to improving the base Linux core interrupt performance. RTLinux drops in a microkernel, RTCore, underneath standard Linux. Developers write hard real-time applications for the RTCore, while regular applications remain in user space. This works well when interrupt latencies must be under 1 ms. Of course, the processor's speed and its hardware interrupt support will affect interrupt response time.
Monta Vista and other companies like Timesys have gone a different route by improving the real-time performance of the Linux kernel. This is done by tracking down the various routines that limit interrupt response time and recoding them more efficiently from an interrupt standpoint. It's possible to push interrupt response time under 5 ms.
Many of these features start out as open-source enhancements that eventually move into the main Linux kernel source tree. As we all know, good real-time response isn't a feature that should be restricted to embedded applications. To get the the best interrupt response performance from Linux, you must go outside the main source tree.
Lurking in the corner, though, is a third alternative. Take an existing hard real-time operating system (RTOS) and make it run Linux applications. This is the approach taken with LynuxWorks' LynxOS. LynxOS is a hard RTOS that even comes in a DO-178B-certifiable version. LynxOS uses the same binary format as LynuxWorks BlueCat Linux. Only device drivers are not directly transportable between the two platforms.
But interrupt latency is just one aspect of a real-time system. Scheduling is another. Here again, there are options with Linux, because the default scheduler isn't always an optimal solution. This is especially true in an embedded environment where periodic services are more common.
Plenty of alternatives prevail for developers of real-time systems when it comes to Linux. The trick is to establish the requirements and find the operating system to match. It's really no different or more difficult than trying to find a non-Linux solution. Linux offers many benefits in addition to being a good RTOS, making it worth investigating.