Controversy is swirling around coincidental real-time Linux releases from Novell and Red Hat, but despite the back and forth, there appear to be some significant differences in what the companies are offering. Novell released its SUSE Linux Enterprise Real-Time 10 (SLERT10) last week, aiming primarily at financial services organizations with a low-latency, predictable version of its OS. Red Hat, on the other hand, has rolled the real-time capabilities in with messaging and grid technology for its Red Hat Enterprise MRG, made available in beta this week and expected for release in early 2008. Red Hat seems to be aiming at a much wider set of customers, including those not as interested in real-time as they are in the messaging or grid components.

Red Hat’s bundling of the different technologies may be the company’s way of differentiating its real-time Linux and confronting the eventual commodification of real-time capabilities in the open source OS. That strategy makes sense, but you would never know it when we hear more about Red Hat’s contentions that it is the real or only force behind real-time Linux. The fact of the matter is there are a number of companies, Novell included, as well as Linux kernel developers pushing real-time in Linux. How is Novell countering the real-time commodification conundrum? Ironically, the company says its employment of kernel developers, as well as some proprietary features such as ZENworks Orchestrator integration, differentiate its real-time Linux.

There are other more technical differences between the Novell and Red Hat offerings, including the actual code provided to users. This is reminiscent of Novell’s inclusion of the Xen hypervisor in SLES 10 a year and a half ago. That’s when Red Hat held off on Xen in its enterprise Linux distribution, saying the virtualization technology was too new and too untested to incorporate in an enterprise production OS. Now, Novell is incorporating the latest Linux kernel 2.6.22 in SLERT10, while Red Hat, citing lack of stability in the CFS scheduler, has opted for 2.6.21 with some backports from 2.6.22. Red Hat is correct that these real-time Linux users cannot afford instability.

Still, Novell may help itself with a Xen-like approach whereby it is first to put the latest real-time Linux capabilities in the hands of financial and other customers willing to pay for it. As Matt Asay correctly points out, Novell is a big boy and knows about releasing code to other big boys. That doesn’t mean Red Hat can’t legitimately claim stability concerns, but the case of Xen, which Red Hat subsequently incorporated heavily in RHEL5, illustrates there are benefits to being first.