Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Novell to Launch Quick-Response Linux 69

Posted by Zonk from the that's-awful-fast dept.
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."
This discussion has been archived. No new comments can be posted.

Novell to Launch Quick-Response Linux More

Novell to Launch Quick-Response Linux

Comments Filter:

  • from the that's-awful-fast dept. (Score:5, Insightful)

    by Anonymous Coward on Thursday September 21, 2006 @05:42PM (#16157163)
    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. (Score:4, Interesting)

      by packeteer ( 566398 ) <packeteer@sub d i m e n s i o n . com> on Thursday September 21, 2006 @05:45PM (#16157183)
      But those fixed time intervals are almost always faster than the lag time you run into from non-realtime OS'es. Windows is of course the clunker we think of first but my linux machine is sometimes not completely responsive and snappy when i clink something.

      • Re: (Score:2, Insightful)

        by random coward ( 527722 )
        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: (Score:3, Informative)

          by Doctor Memory ( 6336 )
          WTF? "real-timeness adds overhead"? The whole point of RTOSes is to remove the overhead and turn almost everything over to the application. Lots of RTOSes have only basic memory management and I/O is largely limited to device discovery and initialization -- everything else is left to the application, because only the application can define how long an operation may take. Some telephone switches can even be rebooted while the applications run!

          You might want to take a couple of computer classes before you

          • Re: (Score:2)

            by yarbo ( 626329 )
            Yeah, figuring out those deadlines is pretty much free, right?
            • 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.

              • Re: (Score:1, Insightful)

                by Jherek Carnelian ( 831679 )
                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 pathal

                • Re: (Score:3, Insightful)

                  by Doctor Memory ( 6336 )

                  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 cert

          • RTOS are very much over kill for most RT embedded applications. A good ol' main with an idle loop and interrupts will cover a big chunk of the reeal world. I miss the 6502 - nice hard and clean deterministic interrupts (Thanks Chuck Peddle). OK, there was that issue with http://en.wikipedia.org/wiki/MOS_Technology_6502#D ubious_features [wikipedia.org] simultaneous IRQ and NMI...

          • RTOS overhead... (Score:4, Informative)

            by Junta ( 36770 ) on Thursday September 21, 2006 @08:10PM (#16158039)
            A characteristic common of multi-tasking RTOSs is that timeslices are very small, and context switches extremely frequent, to help assure that apps will be able to do something in the required timeline, which is not necessarily a small amount of time, but in many applications it is a short time. There are more complexities, but the bulk of the 'overhead' mentioned in the GP is probably the high percentage of time spent doing context switches rather than useful work. The key word here is multi-tasking RTOSs, you describe cases in which the OS is largely a base for a single application that does everything itself. This is very common in the RTOS world, but their do exist areas where pre-emptive multi-tasking RTOSes fulfill a need....

            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.
          • That's not the point, much less the whole point, of RTOSs. You appear to be confusing RTOSs with microkernels and other minimal kernels. And quite the contrary, real-time UNIXs (for example) have more, not less, overhead in the sense that full preemptability (required for minimizing interrupt response times) requires locks which historically have added about 10% extra overhead from the standpoint of throughput. I'm going to save a lot of screen space here by referring you to my web site http://www.real-tim [www.real-time.org]
            • Well, yeah, if you're going to take a general-purpose OS like UNIX and try to make it real-time, you're going to have to deal with the fact that you can't analyze every code path and predict your response time, so you've got to introduce mechanisms to compensate for that. In that case, sure, you've probably got more overhead. The post I was responding to, however, was asserting that a real-time OS would almost always be slower than a general-purpose one. I've worked on a couple of real-time projects, and
              • Given the semantics of "quicker" being interrupt response time and the like, my experience is the same as yours: real-time OS's are generally quicker than non-real-time OSs -- I cannot think of a counter-example. Moreover, almost all real-time OSs go to some considerable effort to make "quicker" also be more predictable than interrupt and service call latencies of non-real-time OSs, by which they usually mean least upper bounded (they often thoughtlessly omit the "least" and leave themselves open to upper b
          • There are lots of RTOS kinds of applications that go for light-weight because they need speed and that's sometimes faster on average and sometimes more reliable. But that's not the critical feature for real-time-ness - it's guaranteed maximum response time, not average speed, usually because the RTOS application is controlling some real-world equipment that needs it. "Going Real Fast" often helps, which is *why* many of the systems are lightweight, but it's not always necessary. Canonical applications in

      • Re: (Score:3, Interesting)

        by LiquidCoooled ( 634315 )
        Actually, I find windows apps on a stable clean machine to be very responsive, however move to a .net application and they become noticably painful, every action is like a webpage refresh.
        Newer isn't always better.

      • Re:from the that's-awful-fast dept. (Score:5, Informative)

        by Lisandro ( 799651 ) on Thursday September 21, 2006 @06:44PM (#16157550)
        It's actually not a matter of speed. A realtime OS [wikipedia.org] guarantees that a given external event will trigger a response in no more than x milliseconds. This might be slower (or faster) than a non-realtime OS, but it's not the point. There are a lot of applications where things must be attended within a given timeframe (radars, as mentioned, industrial automation, nuclear plant safety devices, etc.). Achieving this this is not a trivial excersice.

        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.
      • It isnt' always faster. A real-time system that uses polling based IO where each application gets, say, a 10ms timeslice every 100ms, might be a bit slower than a non-real time system that uses interrupt-driven IO when the system is under a light load. (interrupt IO is a bit trickier in a real-time OS, since one input can basically spam out every other application).
    • Personally, I want my OS to respond in realtime and compute in such a manner. Fixed time intervals? Ok. I get that, but put this way: Would you rather have a figher jet running a realtime OS or die via BSOD? Yeah, that last letter really means Death in this case. realtime computing [wikipedia.org]
  • Quick-Response linux ... Whatever happened to accurate headlines
    • If you want fast headlines, quality is going have to take a hit. Which is why I'm looking forward to a Quick-Response linux.
      • Well it will be neat to have a commercial real-time linux available - a lot of devices have some crappy hacked-up OS inside them. Hopefully that will change now.

    • 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 from FSMLabs repacked?

    • Re: (Score:3, Insightful)

      by stirfry714 ( 410701 )
      Hint: If you actually read the article, it will answer your question.
    • It's a hack that reserves one CPU for real-time tasks. Even the regular kernel stuff gets kicked off that CPU to make room for the real-time.

  • Reminds me of Homer as Max Power (Score:3, Funny)

    by Anonymous Coward on Thursday September 21, 2006 @06:15PM (#16157392)
    Max Power: Kids, there's three ways to do things. The right way, the wrong way, and the Max Power way!
    Bart: Isn't that the wrong way?
    Max Power: Yeah, but faster!
  • With the experience they'll gather from real-time linux, may be they can fix yast which takes forever..
    • Heh.
    • With the experience they'll gather from real-time linux, may be they can fix yast which takes forever..

      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?
  • Novell plans to announce this product at the Gartner Symposium/ITxpo on Oct. 9
  • ...are not related. Real-time operating systems have shadulers that sort tasks per various priorities. Which mean that task admitted with low priority isn't going to have quick response.
    • you got the point. imho the headline is misleading. real-time is like iso-certification. it just says that things / time stay the same, but it has no qualitative meaning weather it's good / fast or not ;)
  • aimed at military, aeronautics, etc. But it sounds perfect for audio and video production.
    • Funny, that was the first thing to cross my mind... Audio capture, and multitrack recording controllers, etc. would a good use of such a beast. :)

    • Re: (Score:3, Informative)

      by paulbd ( 118132 )

      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

  • ATTN Novell CIO (Score:5, Funny)

    by njchick ( 611256 ) on Thursday September 21, 2006 @06:33PM (#16157483) Journal
    Real-time operating systems can respond to external events within a guaranteed time frame
    Shouldn't Novell's financial department use it? NASDAQ and Wells Fargo will surely appreciate it :)

  • Marketting towards aircraft radar? (Score:3, Insightful)

    by CounterZer0 ( 199086 ) on Thursday September 21, 2006 @06:54PM (#16157621) Homepage
    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: (Score:3, Insightful)

      by Burz ( 138833 )
      Novell needs to diversify, and this looks like a good way to do it.

    • Re: (Score:1, Interesting)

      by Anonymous Coward
      I work for an aeronautics company that is purchasing this for the real-time capability and the idemnification. I'm sure there are others looking at it as well. Marketing seems to be fine.

  • 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...

    • It's instead "reserve one CPU exclusively for real-time". There is no secondary kernel.

      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.
  • I am happy to see that the majority of people commenting to this article actually are correct when they clarify what Real Time means. This gives me new hope fot Slashdot. Thank you.

    Now, whether or not it's a good business decision for Novell to go down this road is another question.
  • ... such as aircraft radar

    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?

    • Ingo Molnar (and others) have been designing Linux to be real-time for many years now. And Novell has elaborated on that work, to provide a packaged system with a large supporting enterprise, which system is specifically designed to be capable of hard real-time operation. What's not to like? Portable code, familiar tools, free as in free... Would you rather trust a closed-source product with 10 engineers reviewing the code, or an open-source one with 10,000 engineers reviewing the code, among them, qui

      • Ingo Molnar (and others) have been designing Linux to be real-time for many years now. And Novell has elaborated on that work, to provide a packaged system with a large supporting enterprise, which system is specifically designed to be capable of hard real-time operation.

        Hard realtime and safety-critical are two completely different things, althougth the latter may require the former.

        Would you rather trust a closed-source product with 10 engineers reviewing the code, or an open-source one with 10,000 en

  • Example uses.. (Score:1, Informative)

    by Anonymous Coward
    Passur [passur.com] makes a system system uses Linux with RT patches on the back end for the processing of radar data. About 6 years ago, I helped install and perform low level maintenance for some of the Passur subsystems at IAD for a major carrier there. I also met with and worked with the Passur engineering team near Islip airport in NY and got a day or two of technical training from them. Disclaimer: I have not worked there in over 5 years so my information may be a little out dated.

    The Passur system basically p
  • "Real-time operating systems can respond to external events within a guaranteed time frame"

    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.
  • please explain : "Novell plans to begin selling the real-time variant of the open-source operating system next month."

    selling ? support or what ?

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close