Novell to Launch Quick-Response Linux

Krishna Dagli writes to mention a C|Net article about Novell's upcoming real-time Suse Linux Enterprise product. From the article: "Real-time operating systems can respond to external events within a guaranteed time frame, a feature that mainstream business computing doesn't generally require but that's necessary for some areas, such as aircraft radar. But in a move that indicates the flexibility of Linux, Novell plans to begin selling the real-time variant of the open-source operating system next month."

Comments

from the that's-awful-fast dept.

[Anonymous Coward]

from the that's-awful-fast dept.

It could take me a week to respond. As long as I respond within that week and a week is all that's needed, I'm realtime.

Realtime is not about speed, it's about fixed time intervals.

Re:from the that's-awful-fast dept.

[random coward]

This isn't true. Those fixed times are almost always slower than the average response time on a non realtime os. The real-timeness adds overhead, thus slower execution and less throughput than a gpos. The only place a real-time system is faster than a general purpose is in the worst case wich is bounded in on the real time os but can be quite large and is usually unknown on a gpos.

Re:from the that's-awful-fast dept.

[Jherek Carnelian]

Figuring out the deadlines is the programmer's job. Code path analysis and worst-case execution time determination are a big part of it. It's all done before the system even boots, so yeah, it's free as far as performance goes.

Hardly free at all.

When you have to reinvent the wheel, who do you think is going to produce better average case performance? The guys who have had years to tinker with a variety of implementations of a variety of algorithms and have the flexibility to trade off the occasional pathalogical blip in exchange for improved average case performance, or the guy who has to come up with something in a few months and can't afford a timeline blip even once?

On one hand you have the design goal of "As fast as possible for as often as possible" and on the other you have a design goal of, "No slower than X, ever." No one has unlimited resources, so of course the results are going to mirror the goals.

Re:from the that's-awful-fast dept.

[Doctor Memory]

When you have to reinvent the wheel, who do you think is going to produce better average case performance?

So you're asserting that guys who have worked on a given system for years will produce better average-case performance than some guy on a tight deadline? Well, duh, give the straw man a cigar!

OTOH, if you're not "reinventing the wheel" but "cranking out a new and improved wheel", and you're the one who has had "years to tinker with a veriety of implementations" (on a variety of projects), then you certainly can produce better average-case performance than some guys whose goal isn't performance but maybe portability, or ease of maintenance, or backwards compatability. Sure, everybody wants their code to run fast, but if your end goal isn't primarily performance, then you won't wind up with the fastest code. Not to mention that real-time work often affords certain conveniences that general-purpose systems don't have. E.g., you can specify that your code will only work with a given CPU / chipset / whatever, so you don't have to go through some generic driver layer that takes your read request and just turns around and passes it through to a driver that may not be fully optimized because it's constrained to support the generic driver interface. There's a lot of abstraction in most GPOSes today, which is unavoidable if you want to be truly "general purpose", but it's anathema to best possible performance.

Dunno, my first RT experience was a call data collection system running on duplex hardware hooked directly to a phone switch. Each call record represented a "cha-ching!", so we *could* *not* *lose* *any* *data*. We made the hardware as well as the software, and we sweated the details. That's what "real-time" means to me, so maybe it colors my perceptions.

Re:Is this rtlinux?

[stirfry714]

Hint: If you actually read the article, it will answer your question.

Marketting towards aircraft radar?

[CounterZer0]

Give me a break here. Novell is (Barely) known as an enterprise back office company. They make awesome management products, have a decent linux distribution, and a load of magic glue to hold all that together.
Where in the world does aircraft radar and embedded manufacturing fit into that business model? Is Novell hiring it's competitors to do marketing for it? Eesh!

Re:Marketting towards aircraft radar?

[Burz]

Novell needs to diversify, and this looks like a good way to do it.