Novell to Launch Quick-Response Linux 69
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."
Re: (Score:1)
from the that's-awful-fast dept. (Score:5, Insightful)
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. (Score:4, Interesting)
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
You might want to take a couple of computer classes before you
Re: (Score:2)
Re: (Score:2)
Re: (Score:1, Insightful)
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 pathal
Re: (Score:3, Insightful)
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 cert
Re: (Score:2)
RTOS overhead... (Score:4, Informative)
Of course, your point is correct too, a requisite step with respect to this particular aspect of a RTOS is generally considered to be doing whatever it takes to make the context switch as fast as possible. In a server or desktop OS historically context switches aren't nearly as optimized as the solution can be for most applications to lengthen the timeslice. Server platforms particularly tend to have long timeslices as their activity isn't highly interactive, and the percentage of the time the system can do useful work is more important than each application being able to do their thing in a timely manner. On a desktop OS, timeslices being shorter is helpful (fairly recently a lot of debate and configurability happened in linux with respect to this), as multiple applications are more directly interacting with users. With a handful of processes it isn't really noticeable but as it scales up the delays get into perceptible fractions of a second. Having a smooth interface is a bit more along the lines of a design point of RTOS, so it makes sense. Anyway, there is a penalty paid, but the timeslices for satisfying human interaction requirements may still be orders of magnitutde higher than those required for RTOS applications, depending on what's going on.
Re: (Score:1)
Re: (Score:2)
Re: (Score:1)
Guaranteed-max-response-time is the real issue (Score:2)
Re: (Score:3, Interesting)
Newer isn't always better.
Re:from the that's-awful-fast dept. (Score:5, Informative)
This is not about the response time after you click on your Office document - and in fact, the (huge) added complexity of a RTOS is nor needed nor desired in most desktop and even enterprise uses.
Re: (Score:2)
Re: (Score:1)
Quick-Response linux (Score:1)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Indeed. There's a reason why half of this thread is people who misunderstand the nature of an RTOS, and the other half is people helpfully explaining it to the first half, and it's because someone chose to use the phrase "Quick-Response". Shameful.
Is this rtlinux? (Score:1)
Re: (Score:3, Insightful)
not rtlinux (Score:2)
Reminds me of Homer as Max Power (Score:3, Funny)
Bart: Isn't that the wrong way?
Max Power: Yeah, but faster!
Real time.. (Score:1)
Re: (Score:1)
Re: (Score:1)
Amen. Even on my 64-bit machine, it took minutes to respond. And this was on a fresh install.
Overall I really like SuSE, but between that and the lack of mpeg support on 64-bit (yeah, I could kludge it - whatever) it was enough for me to keep on keeping on.
Anyone know why yast is such a pig?
Launch Date! (Score:1)
Quick Response and Real-Time (Score:2, Informative)
Re: (Score:1)
Sounds like it might be (Score:2)
Re: (Score:2)
Re: (Score:3, Informative)
Ingo Molnar and Andrew Morton's original 2.4 patches for better soft-real-time performance were prompted by complaints from those of us in the linux audio (pro-audio/music) software community. Systems like JACK [jackaudio.org] and applications like Ardour [ardour.org] were written around this kind of functionality.
Ingo has picked up the ball and run with it for 2.6 to the point where a kernel patched with his most recent patches is basically hard-time except for cases where a badly written device driver screws it up. And increasing
Re: (Score:1)
ATTN Novell CIO (Score:5, Funny)
Re: (Score:1)
Marketting towards aircraft radar? (Score:3, Insightful)
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: (Score:3, Insightful)
Re: (Score:1, Interesting)
Real Time? (Score:1)
I'd be happy if they could just help me work out my IPv6 woes between Suse 10.0 and my ISP...
I too wonder what market they may be going after here...
Also, I wonder if this will be the usual "jack up Linux and slip a real-time kernel in underneath" approach. Then Linux actually runs as a low(er) priority task on the R-T kernel...
nope, not the usual (Score:2)
There are some crazy hacks here. Unpatched Linux will run various kernel-related housekeeping tasks on any CPU. With this, no. Other CPUs take care of the one dedicated to real-time.
Bravo, Slashdot commenters (Score:1)
Now, whether or not it's a good business decision for Novell to go down this road is another question.
*shudder* (Score:1, Troll)
Linux is good and all, but would you really trust it for critical safety systems? Why not use something that's actually designed for that purpose?
Re: (Score:2)
Re: (Score:2)
Hard realtime and safety-critical are two completely different things, althougth the latter may require the former.
Nope (Score:2)
Sorry to break it to you, but the OS world is made up of far more than Unix/BSD/Linux and Windows.
"Like a purpose written linux/bsd etc kernel?"
No, not at all. If one were to successfully convert a non-realtime OS like Linux into a real-time one, it would essentially be a completely different OS. The same goes for Windows, BSD, UNIX, VMS, etc.
Example uses.. (Score:1, Informative)
The Passur system basically p
Real-time isn't about absolute time frames (Score:2)
That's not really what real-time is about. Real-time is about consistent timing, not absolute timing. Thus a 100MHZ system can be more real-time than 1GHZ system.
Re: (Score:2)
please explain (Score:1)
selling ? support or what ?