Slashdot Mirror


QNX RtP 6.2 World Preview

Jason writes: "OSNews is running an exclusive preview of the brand new version 6.2 of the QNX realtime operating system. The article is going through the installation process, the Photon user interface (lots of screenshots included), the internals, and the advantages and disadvantages of the OS as a desktop system. QNX RtP 6.2 is expected to be released for free (for non commercial usage) before March."

59 of 209 comments (clear)

  1. Why would anyone use by wiredog · · Score: 2, Redundant
    A real time OS as a desktop system? I've worked with embedded/real time systems and performance in that world is different from performance in the desktop and server worlds. QNX has a nice looking GUI, but who would need it in an embedded or real time application?

    Real time OS's Have Issues with performance on the desktop, just as desktop/server OS's Have Issues in the real time space.

    1. Re:Why would anyone use by jayant_techguy · · Score: 2, Informative

      Ya that pretty true, but QNX as they say, was built for people who wish to know some more about real time os'. and it does that job pretty well :)

    2. Re:Why would anyone use by chrisatslashdot · · Score: 3, Informative

      From the article:
      QNX RtP is serving as the self hosted development platform for QNX-based internet appliances and other QNX embedded applications.

      --


      Simple people talk of people, better people talk of events, great people talk of ideas.
    3. Re:Why would anyone use by boris_the_hacker · · Score: 2, Interesting

      I think the point of the GUI is to allow for a self contained system in which to develop products using QNX. This is a nice idea as it allows you to compile, run, test, debug rather than compile, transfer, run, debug [remote/local]. Where the transfer stage adds yet another stepping stone in the development cycle (ok for large changes, but if you are tracking down a small bug it's a PITA).

      From the article it seems like the tools and apps that are for QNX RTP are there to make the developers life less painfull (eg. the media application) and it's not for a general purpose desktop - and why can't developers have a nice GUI?

      Just my 2 pence.

      Regards, Chris

      --
      chris at darkrock dot co dot uk
      http colon slash slash www dot darkrock dot co dot uk
    4. Re:Why would anyone use by corrosiv · · Score: 2, Interesting


      1 - self hosted development: it is generally intended to be the embedded developer's desktop system, not a general purpose desktop system

      2 - GUIs are frequently used in embedded/realtime systems. Factory control systems, health monitoring & analysis, PDAs.

      My $0.02 (Canadian)

    5. Re:Why would anyone use by Sloppy · · Score: 3, Funny

      Real time OS's Have Issues with performance on the desktop

      Yeah, but the main "issue" they have is that they are so damned fast that users think it must be a trick.

      What's good for RT, is good for everyone.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    6. Re:Why would anyone use by Arandir · · Score: 2

      QNX has a nice looking GUI, but who would need it in an embedded or real time application?

      Unix geeks demanding CLI-only interfaces aren't the only people that use embedded or real-time systems.

      Scenario A) An embedded device controllable by the enduser: Gas pumps, POS terminals, ATMs, PDAs.

      Scenario B) A realtime system with a non-realtime front end: medical scanning systems, manufacturing control systems.

      A million more scenarios exist. Embedded RTOS aren't only for unseen automobile smog sensors.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    7. Re:Why would anyone use by mangu · · Score: 2
      nothing is going to get CPU time when it's busy working its IDCT magic


      What you are describing is windows, not a true RT system. I once started developing a real-time data processing system in NT, and found I had to set the inner loop in my program to "real time priority" in order to keep up with the data coming in. The result was that I lost the mouse and keyboard. The only way out was to set the inner loop to yield to other processes when its calculation was done. This, effectively, amounts to rewriting the kernel low-level scheduler.

      In a true real-time system, I would be able to set the mouse and keyboard processes to run at given intervals, while still having my data-handling routine able to digest what came in.

      Fortunately, my story has a happy ending: I found out that Linux has a good enough scheduler to run my program without data loss, even if it's not a true real-time OS. But I toyed with the idea of using QNX for a while. Gave up when found out how much it costs.

  2. QNX goes back a *long* way by InterruptDescriptorT · · Score: 5, Interesting

    Do any Canadians (perhaps only Ontarians) remember the ICON computers they used to have in elementary and high schools? The ICON, also known as the 'Bionic Beaver', was a computer manufactured by CEMCorp (Canadian Educational Microprocessor, IIRC) that was meant to bring data processing and computer skills to thousands of high-school students.

    The design of the machine was interesting--intelligent nodes running an 80186 connected by ArcNet to a central server node--but they ran a version of QNX. I remember the slightly different set of commands than we are familiar with in UNIX: for example, to go up a directory, it was 'cd ^', files could be deleted with 'zap', and commands could be easily run on remote nodes by prefixing the command with [nodenum].

    It was on this machine and OS that I cut my teeth in C, 80x86 assembly and basic networking concepts (I wrote a small multi-node chat program using the virtual circuit calls in QNX), and as such I was always have very fond memories of it. Thanks for letting me reminisce. :-) (BTW, if anyone has one and is planning on getting rid of it, I'd gladly take it off your hands.)

    --
    Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
    1. Re:QNX goes back a *long* way by gbrandt · · Score: 2, Informative

      That would probably have been a derivitive of QNX 2.x. We used QNX 2.x exclusivley at a company I worked for. It was our desktop system from accounting to engineering. All running on ARCNet.

      Since then QNX has moved up in the world. QNX 4 has full posix compliance and is very much like a normal *NIX. 6.x is so much like *NIX on the command line, that you can barely tell the difference.

    2. Re:QNX goes back a *long* way by InterruptDescriptorT · · Score: 2

      Yup, that's the ICON. The trackballs were always in such bad shape, partially because my 'Hat Trick' clone was very trackball-intensive. :-)

      Anyway, the last year I remember them was about 1991--they were replaced with 'modern' 386s around that time.

      --
      Karma: Excellent Birds (mostly as a result of listening to Laurie Anderson)
    3. Re:QNX goes back a *long* way by SuiteSisterMary · · Score: 2

      Ahhh the Icon. With the built in trackball; I remember the movie maker app, and the 'choose your own adventure' real-life sim type thing. With Danny, I think his name was, the pot-head.

      --
      Vintage computer games and RPG books available. Email me if you're interested.
    4. Re:QNX goes back a *long* way by MatriXOracle · · Score: 2

      Ahhh the ICON's. Those things were great. There were several variations of the ICON. The ICON I's were huge things with a built in montitor/keyboard/trackball/cpu all in one unit. The ICON II's and III's had more in common with the original iMac's: CPU and monitor in one unit, and the keyboard/trackball a separate piece. Those things used 386 processors.

      I actually really liked the trackballs on those systems, it was really easy to move the ball around with your hand and press the Action button with your thumb.

      And anyone remember Offshore Fishing? That game was great.

    5. Re:QNX goes back a *long* way by B1 · · Score: 2, Interesting

      Our school had them (Oakville Trafalgar High School... class of 92).

      I fondly remember the 'ipaint' program on the ICONS--that program where you could create vector-based animation by drawing key frames. Also, there was that really cool chemistry lab program.

      Most of the kids at school grudgingly used them--I remember it had some sort of 'PC Compatibility' mode, and they tried to teach kids WordPerfect on them. Wordperfect under the DOS compatibility mode was brutally slow though--felt a bit like wading through a pool of bubblegum. I tried to stay away from them as much as possible.

      I had one friend that waded through the reference manuals for the ICON, and actually did quite a bit of development under them. That was like him though--always wanting to figure out what made things tick. While most of us were content with DOS, he was mastering UNIX, QNX, C, and this wierd thing called 'Usenet'. I can honestly say he knew more about the ICON than anybody else at the school, including the Comp. Sci teacher/sysadmin.

      There's no doubt there was some inner beauty to the ICON--certainly, it was a very interesting network architecture. Alas, this was all hidden behind horrific applications and a cumbersome user interface.

      I think the ICON is what you get when you let the government design computers. All the right features, on paper they should have been great...terrible execution though.

    6. Re:QNX goes back a *long* way by tzanger · · Score: 2, Informative

      Do any Canadians (perhaps only Ontarians) remember the ICON computers they used to have in elementary and high schools?

      Yup. Used 'em in Grade 7/8 IIRC at Stanley Park Senior Public in Kitchener, ON. (Grade 7 would have been '89?) -- I got booted out of the room after a while for dicking around at the command prompt they boot up with, trying to get in to something I had no idea about at the time.

      I've got one now (had two) -- they cut off the keyboard though, and I've got to figure out what pins go where (the connector's gone) but I'd love to boot it up again. You've got the specifications exactly right: 80186 (basically a controller version of the 8086, it includes the PIC, DMA, PIT and a few other of the 82xx-series of support chips in the processor package itself), I think about 640k of memory (weird staggered-SIPP package), arcnet, EGA or VGA display. Gray case that boots up blue and spends 99% of its time displaying blue background. :-)

      I bet you could get something like ELKS running on it without much trouble.

      Man... I remember the *sound* of the room they were in. the server(s) (I believe we had two, one for each double row of ICONs, about 20-24 ICONs per server) with physically ENORMOUS hard drives and fans and fans and fans... in a room with no sound suppression. It sounded like a large colo facility does today, I bet.

    7. Re:QNX goes back a *long* way by DrXym · · Score: 2
      I programmed QNX 2 for 3 years for use in medical diagnostics instruments and I have to say it was the worst, most nasty OS I have ever used. Yes it did multitasking, but the tools were diabolical, the compiler was a joke, it had an ugly OpenLook-like UI, it was proprietary and not in a good way and it cost a lot of money. I have no idea how it ended up inside mission critical software because it looked like a hobbiest OS gone bad. It didn't even have a decent editor and I had to port MicroEmacs to it. It's only saving grace was it was fast, realtime and had some natty messaging protocols.


      Quantum made a very wise and sensible decision with QNX 4 (what happened to 3?) to go Posix since it made the OS tolerable and almost Unix like. Still, by that time I was getting restless feet and I moved onto bigger and better things. I still wonder about the company I left - I bet there are poor souls working there who have to fix problems in QNX 2. May god have mercy on their souls.

    8. Re:QNX goes back a *long* way by irix · · Score: 2

      Indeed. I went to an Ontario high school and gradualted in 1993. By 1993 we had a lot of macs and PCs, but in the earlier grades we used them a lot.

      We did elemntary programming using logo and later Pascal using the ICONs. I never remember doing any C with them, but by the time I started learning C it was 1992, so I was on to PCs by then.

      --

      Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
  3. A microkernel that doesnt suck by Koim-Do · · Score: 2, Interesting

    I generally know that the Neutrino microkernel is faster than Mach, but have anyone ever made (and published the results of) performance comparision between Neutrino, Mach and L4 ?

    1. Re:A microkernel that doesnt suck by Animats · · Score: 2
  4. First Impressions by jaavaaguru · · Score: 3, Insightful
    As someone who's never used or seen QNX before but has seen many other OSs, I like the first impression this gives me (going by the eye candy). Some questions I need to know the answer to:
    • Does the calculator have a paste feature? This is something really lacking in KDE's one. And it bugs me when I can't be bothered adding two file sizes together (or typing the sizes into the calculator)
    • Will the interface always be as consistent as it is in the screenshots? - the Macs at school always had consistent user interfaces. With the advent of Microsoft Domination we witnesed horrible UIs that were exremely inconsistent. They can't even make their own apps have the same UI as their OS.
      These shots of QNX make is seem like they've missed out all the bad features of other OS's and included all the good ones. I like it.
    • Does the web browser perform as fast as the other ones that are currently in use? (IE, Konqueror, Mozilla, Opera) and can it render the majority of pages that Konqueror can?
    These are just some things that people notice.
    1. Re:First Impressions by ergo98 · · Score: 4, Informative

      You can always get Opera if you want.

    2. Re:First Impressions by kindbud · · Score: 2

      If you had read the review, you would have known that the Voyager web browser supports a pluggable HTML engine, for which Opera has made a plugin. So yes, it renders HTML at least as well as Opera 5. :)

      --
      Edith Keeler Must Die
    3. Re:First Impressions by Russ+Steffen · · Score: 2

      You are wrong about KDE's calculator not supporting cut and paste. If you right click on the calc's "display", the value is copied to the clip board. If you middle-click on the display, whatever is on the clipboard is pasted in.

  5. Who is this reviewer? by djweis · · Score: 2, Interesting

    Does he have any background in embedded systems? He seems about as qualified as me reviewing pacemakers. I think prettiness is overrated in a system like this.

    1. Re:Who is this reviewer? by dhuff · · Score: 5, Insightful

      "He" is a she - Eugenia Loli-Queru. Eugenia is Editor-in-Chief of OSNews.com. Before moving to the U.S. she was a web-designer in the U.K., ported more than 80 Linux/Posix/DOS applications to BeOS and founded the BeUnited BeOS Development Movement in April 2000.

      As for a background in embedded systems, I'm not sure - but she is certainly more qualified than you suggest, having experience with many OSes incl. BeOS, AtheOS and FreeBSD among others...

  6. QNX vs. Joel On Software by gbrandt · · Score: 2, Insightful

    Here is a banner example that sometimes rewriting software does make sense. Since 1985, QNX has rewitten thier OS three times, first QNX 2.x, then QNX 4.x and now RTP 6.x. All rewritten from scratch and all better than the last.

  7. A simple OS for mom by Pengo · · Score: 3, Interesting


    Maybe this is it. Show her how to dial up with the modem, use launch the email client and web client and find a version of AIM and there you go. I imagine that because it's UNIX(like), you should be able to run it non-priviliged without problems or fear of someone else messing it up.

    Has anyone tried running this on slow hardware? (Such as a P133 or something w/32 megs ram?) How does it fare?

    1. Re:A simple OS for mom by nhavar · · Score: 5, Interesting

      The slowest machine I've set this up on is a P75 w/32 megs of ram. It worked fine although with the video card I had it couldn't get to higher color depths. Amazingly I didn't have to do anything to configure the modem, sound card or NIC and everything ran fine. Really helped a novice get on the net quick and play a few games that they like to play. No need to spend $600 for a new PC just so someone can surf the net and get mail and play card games, dust off the old PC and slap QNX on easier than a Mandrake install.

      --
      "Do not be swept up in the momentum of mediocrity." - anon
    2. Re:A simple OS for mom by Ivan+Raikov · · Score: 3, Informative

      My understanding and one of the common grips about QNX for the desktop is that QNX is POSIX-like and not UNIX-like.

      QNX 6.something is now available for download from QNX's web site -- I installed it last weekend and played around with it a little bit. It appears that most of the user utilities are taken from NetBSD, and the configuration file tree is structured very closely after BSD. The system library claims POSIX compiance, and the kernel claims conformance to the realtime POSIX API.

  8. Hello Point... you've missed it. by MosesJones · · Score: 5, Insightful


    Its a real time operating system for embedded devices. The PC based platform is for development to help you rather than plugging directly into the RS232 port of your dev kit.

    The questions you ask are nothing to do with an RTOS but looking at it from the perspective of "Oh look a Windows competitor" this is NOT in the same market as even WindowsCE, although there is some overlap. The PC based platform is to aid development, it can be stripped down to a delivery box but this is not for Joe Sixpack PC user.

    The real question is "Can anything else run in a couple of Megs of RAM..... or less" and have guarenteed delivery times on tasks. The answer for Linux and MS-Windows is NOPE.

    THIS IS NOT A DESKTOP OS.

    Sorry for shouting but people should

    a) Read the article

    b) Understand that MS-Windows and bloatware are not the most interesting market in the world.

    c) Realise that cut and paste on a VCR is a silly idea.

    --
    An Eye for an Eye will make the whole world blind - Gandhi
    1. Re:Hello Point... you've missed it. by ergo98 · · Score: 5, Interesting

      You're totally wrong. QNX Neutrino is a bottom to top OS from tiny machines to clusters of high power hardware. QNX has pushed their OS on thin-cients, Internet Appliances, etc, it isn't just for embedded monitoring hardware. Indeed the big QNX push is "QNX on a floppy" that basically turns a PC into an IA.

    2. Re:Hello Point... you've missed it. by be-fan · · Score: 2

      Umm (RtP == RealTime Platform) *is* a desktop os.

      --
      A deep unwavering belief is a sure sign you're missing something...
  9. Re:Grammer Nazi by corrosiv · · Score: 2, Informative

    The original QNX OS was released as QNX2 in the early 1980s. I don't know the story on QNX 1 - perhaps it was the specialized product that inspired them to attempt a general purpose realtime OS. In the late 1980s/early 1990s it was rewritten as QNX4 to implement many new ideas (and improve on old ideas). This was labelled QNX4. QNX4 gave the world a better, more UNIX-like development platform and more UNIX-like behaviour via POSIX. Not long after QNX4 came Neutrino. This was to be a specialized kernel for deeply embedded applications while QNX4 was to be more general-purpose realtime. The entire QNX4 application base has now evolved to run on Neutrino, so now this is all packaged together like QNX4 was and is called QNX6 or RealTime Platform.

    Steve

  10. QNX: longtime (semi) embedded player by RatOmeter · · Score: 3, Interesting

    As has been pointed out in other post(s), QNX has been around a long time. In fact, they first called it Qunix, but AT&T (Bell Labs) slapped'm down on that long ago.

    I'm heard first-hand testimonials attesting to its bullet-proof operation which makes it a great choice for controlling machinery. You can also install, de-install just about any service/driver/app without needing to reboot.

    Where I work, we make large, expensive automated testing equipment (lotsa horsepower, moving parts, other dangerous shit). We wanted to eval QNX about 3 years ago, but they told me they only provide free eval copies to their $100K plus customers. We make about 7 to 12 machines per year; they slammed the door in my face.

    Now (and their previous free non-comm version) that the've got a pkg I can use to eval, it's too late. Even if we were still in a position to choose QNX, I doubt we'd easily forget our previous snubbing.

  11. Amiga by Snowfox · · Score: 4, Insightful
    A reminder that this was originally going to be the OS used for the new Amiga hardware, before Amiga up and went in a strange, new direction which didn't involve new hardware.

    I guess this is a peek at what the new Amiga could have been. It doesn't look as nice as 3.9, though the underlying technology is pretty neat.

  12. Some hangups. by be-fan · · Score: 5, Interesting

    QNX RtP has tons of potential, but there are lots of things holding it back as a desktop OS:

    1) Lack of unified VM/buffer-cache. The size of the disk cache is fixed rather than dynamically adjusted depending on need.

    2) Lack of proper swapping. Since swapping kills embedded apps, RtP lacks good swapping. Use of swap has to be explicitly coded into the app, and was implemented as sort of a hack to allow gcc to be self-hosted.

    3) Real-time scheduler. The hard-real time scheduler might be nice on an embedded system, but on a desktop system (where fairness takes a back seat to user-percieved responsiveness) it doesn't work well.

    4) Crappy disk subsystem. I don't know if this problem has been fixed in 6.2 (I doubt it) but RtP has a really slow disk system. The IDE drivers have issues and the filesystem is ancient.

    Some of the numbers that RtP shows aren't as impressive as they could be. 0.55us context switches sound great, but Linux can do switches on that order as well. Still, RtP is a great system. QNet, in particular, is very featureful, and Photon totally destroys X in every area except maybe 3D support. It has superlative network transparency, a good (fast) widget set, incredible fonts (courtesy of BitStream's FontFusion) and a nice, lean, architecture. If QSSL would port Photon to Linux (which wouldn't be that hard, given that both are mostly straight POSIX) I'd pay to run it.

    --
    A deep unwavering belief is a sure sign you're missing something...
    1. Re:Some hangups. by Sloppy · · Score: 3, Interesting

      Real-time scheduler. The hard-real time scheduler might be nice on an embedded system, but on a desktop system (where fairness takes a back seat to user-percieved responsiveness) it doesn't work well.

      Huh? Fairness is the enemy of responsiveness. There is no back-seat. On an RT system, if you have your UI run at a higher priority than your cpu-sucking apps, you get responsiveness that Windows/Linux users can only dream about.

      --
      As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
    2. Re:Some hangups. by be-fan · · Score: 2

      Traditional schedulers have several problems with GUI programs.

      QNX RtP's scheduler, a straight priority-driver round-robin affair, allows a high priority process to run whenever it becomes ready, even if it is preempting the foregroung GUI process. Its a very static scheduler, which means it doesn't take into account the myriad of issues that result in good UI response.

      Traditional UNIX schedulers try to be fair to each process, penalizing CPU-bound processes and giving better response to I/O bound processes. This, too, has flaws. A CPU-bound GUI process can get penalized when an I/O bound background process (such as a compiler) can get boosted. The scheduler doesn't take into account which process is in the foreground when making decisions.

      The two best schedulers I've seen for desktop systems are Windows NT's and BeOS's. Both treat GUI scheduling as an integral part of the system and take issues such as which is the foreground process into account when making decisions. This is not as "clean" as the UNIX way of doing things, but results in much better user-percieved responsiveness.

      --
      A deep unwavering belief is a sure sign you're missing something...
    3. Re:Some hangups. by be-fan · · Score: 3

      1) Actually, POSIX plays a huge role. The X server is nothing more than a big program that accesses the system through the standard kernel APIs (barring DRI, of course). Since both the QNX kernel and the Linux kernel offer similar functionality through a similar API, it shouldn't be any harder to port Photon than any other major app. The only hangup I can think of would be the differing messaging schemes, but that's a very narrow and concrete issue to solve.

      2) For all practical purposes, X is XFree86. We are talking desktop OSs here and there is only one X server that is of any consideration as a main GUI for an OS and that is XFree86. I don't care what SGI has made IRIX's version of X do, it doesn't run on Intel machines and is thus irrelevent. Isn't life great when you have 99% market share? That said, I challenge you to point out one thing that X does better than Photon, aside from 3D,

      --
      A deep unwavering belief is a sure sign you're missing something...
    4. Re:Some hangups. by be-fan · · Score: 2

      Obviously, somebody didn't read the docs. QNX RtP is designed to:

      "[scale] seamlessly from the leanest consumer device right up to the largest distributed SMP systems."

      --
      A deep unwavering belief is a sure sign you're missing something...
    5. Re:Some hangups. by Pseudonym · · Score: 3, Informative

      I disagree in part.

      1) Lack of unified VM/buffer-cache. The size of the disk cache is fixed rather than dynamically adjusted depending on need.

      I can see why you say this, but in practice I can't see this as a problem. The size of the disk cache is increased with the number of devices mounted. On the other hand, separate caches mean you can implement different buffer cache policies depending on the device. (You can imagine, for example, that flash memory could use a very different write-back policy than disk.)

      Separation of mechanism and policy is something that pervades QNX, and is arguably the key to the flexibility of modern operating systems (compared with the inflexibility of monolithic systems). Even the QNX kernel, Neutrino, is actually a microkernel built on top of a nanokernel. The nanokernel implements mechanism, and the microkernel implements policy.

      2) Lack of proper swapping. Since swapping kills embedded apps, RtP lacks good swapping. Use of swap has to be explicitly coded into the app, and was implemented as sort of a hack to allow gcc to be self-hosted.

      It's not a hack, but I do think it's unfortunate that it's not "officially" supported. It would make more sense to:

      • Determine at boot or configure time whether you want swapping or not.
      • Assuming that swapping is enabled, applications which are granted I/O privileges get all their memory non-swapped. This is non-negotiable. (Why? Because if you have I/O privileges, you can install an interrupt handler. Your interrupt handler had better not access swapped-out memory.)
      • Again assuming that swapping is enabled, any other applications may selectively lock all or part of their memory. (This may require other privileges.)
      3) Real-time scheduler. The hard-real time scheduler might be nice on an embedded system, but on a desktop system (where fairness takes a back seat to user-percieved responsiveness) it doesn't work well.

      You really need a hybrid (and I don't mean RTLinux). Desktop systems need real-time. BeOS users can testify to this. Also, there are new applications such as serving streaming media and ATM routing which really need real-time. Even burning CDs really needs real-time to do properly.

      Admittedly, you probably don't need to implement an ATM switch on your desktop machine, but you might on your server. Real-time scheduling might be a really good thing here.

      4) Crappy disk subsystem. I don't know if this problem has been fixed in 6.2 (I doubt it) but RtP has a really slow disk system. The IDE drivers have issues and the filesystem is ancient.

      That's true.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
    6. Re:Some hangups. by be-fan · · Score: 2

      I can see why you say this, but in practice I can't see this as a problem. The size of the disk cache is increased with the number of devices mounted. On the other hand, separate caches mean you can implement different buffer cache policies depending on the device. (You can imagine, for example, that flash memory could use a very different write-back policy than disk.)
      >>>>>>>>>
      Seperate caching policies can be implemented with a unified cache as well. The thing is, that on a desktop machine, the usage of disk cache can vary wildly. At one minute, the user might be running a disk-intensive program like a compiler, and the next moment they might be running a program that doesn't touch the disk, like a game or raytracer.

      You really need a hybrid (and I don't mean RTLinux). Desktop systems need real-time. BeOS users can testify to this. Also, there are new applications such as serving streaming media and ATM routing which really need real-time. Even burning CDs really needs real-time to do properly.
      >>>>>>>>>>
      I think you need soft-realtime, but you have to be flexible about it. Hard-realtime, with its viscious demands on timing, is really not appropriate for an environment where you might sometimes want to "break the rules" and give a process some extra time in order to make the desktop more responsive to the user.

      --
      A deep unwavering belief is a sure sign you're missing something...
    7. Re:Some hangups. by Pseudonym · · Score: 2
      Seperate caching policies can be implemented with a unified cache as well.

      True, but I wouldn't like to maintain or debug the code that does it.

      The thing is, that on a desktop machine, the usage of disk cache can vary wildly. At one minute, the user might be running a disk-intensive program like a compiler, and the next moment they might be running a program that doesn't touch the disk, like a game or raytracer.

      By "disk-intensive [...] like a compiler", I assume you're referring to VM performance. Correct me if I'm wrong (I may well be), but shouldn't pages written out to swap or read in from swap not hit the buffer cache at all? (They might if you're using a swap file rather than a dedicated swap device, of course.)

      Games and raytracers aren't disk intensive only because they do their own caching, not relying on the OS to get policy right. Games can be several CDs in size, and are only managable because they're easily partitioned into levels.

      Renderers (including raytracers) aren't so lucky. A Pixar-level scene may have up to 2Gb of gzipped geometric data and 10Gb of texture data, and you don't know in advance what's needed when. Needless to say, professional renderers spend a lot of lines of code managing cached data very carefully.

      --
      sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});
  13. Internet Appliance != Desktop by MosesJones · · Score: 4, Interesting


    And an internet appliance is a minimal spec box, possibly without a hard-disk that has a cheap screen (possibly touch screen). Again its not aimed at the Microsoft market so the original point still holds. The cluster stuff is for specific tasks and not the desktop. The point is quite simple. Not every OS out there is meant to run the same way as windows, there is a wonderful world out there of OSes that are aimed at different tasks, all too often Slashdot is concerned, and its readership only aware, of the MS style of market.

    OS/390, AS/400, EPOC, QNX etc etc etc... well cool OSes for paticular circumstances.

    --
    An Eye for an Eye will make the whole world blind - Gandhi
  14. Alas, QNX! by fm6 · · Score: 3, Interesting
    Never heard of these machines, but as you describe them, their design makes a lot of sense. At about that time, I was working for Convergent Technologies, which mostly made systems that ran CTOS. Like QNX, CTOS had a message-passing architecture, and was thus very well-suited to distributed computing. QNX has always struck me as more elegant than CTOS, though.

    When I left Convergent, I ended up working with 8086 and 80286 systems -- and found the limitations of MS-DOS really painful. QNX was then being marketed as a DOS alternative. They claimed to be able to do serious multitasking on 8 mhz systems. I actually found that claim credible, not to mention tantalizing. But I never got a chance to test it. The QNX license fees were just too high.

    It's a real pity QNX wasn't in the picture when IBM was shopping around for a PC OS. History would be very different!

  15. Moving away from desktop. by Xapp · · Score: 2, Insightful

    "However, I somewhat got the feeling from the new version that QSSL is moving even more far away from a "desktop QNX." " QNX as a company has no interest in the desktop market and all that it entails. (eg. tech. support, updates, etc.) It is mainly concerned with providing a realtime system for industry as well as providing a decent developement environment for the software that will go into those systems.

    --
    Eye, says I.
  16. 0.55us is very good by Anonymous Coward · · Score: 3, Informative

    This time is not the time between context switches. It is the time required to perform one context switch.

    Windows performs 50 switches per second, but appears to take on the order of 200us to perform a single context switch. That means that windows spends about 10 ms in context switches.

    QNX would spend 25us in context switches. This means that it can do a lot more, say a 1000, thats only 1.25ms spent in switches, and a much smoother communitcation between threads.

  17. GUI by SilentChris · · Score: 2

    I haven't seen this OS before, but I wasn't surprised to see it had a primarily Windows 9x-style GUI. Shouldn't we be up to something new? (Even XP, which I sorta like, uses the same old Start button motif).

  18. A Seriously cheap way to get 'net connected! by FyRE666 · · Score: 2, Interesting

    Since you can now pick up old Compaq Internet Appliances for as little as $39 dollars (233/266mhz, 32MB RAM, 32MB Flash, 800x600 TFT screen), I'm sure QNX could be hacked into one of these to make a very usable and cool looking little browser/terminal! I believe it was also used in the original iopener devices, which had similar specs.

    It's a pity Be crashed out of the embedded market really; their BeIA operating system was amazingly efficient. We were developing a system using the Compaq devices as shop terminals, (the versions we had included ethernet ports) and even when running telnetd, ftpd, the desktop (tracker) and the Opera browser, they were using like 18-20MB of their 32MB RAM! Pretty fast too, they could play Flash 4 animations at a decent speed even with pretty slow processors. An interesting thing about the Opera browser on the BeIA platform was that it gradually leaked memory, losing a little every time a new page was loaded. Once the device was over 90-92% memory usage, the browser was killed, and respawned. However, the user wouldn't notice this, as when the browser was killed, it left its image on the screen, then reloaded the last page visited so it was just a slight delay!

  19. All my hardware is supported. by rasactive · · Score: 2, Funny

    Maybe I'll make the move from linux to an OS with even LESS supported software. :)

    I have no authority on the matter, but it looks like a pretty cool OS.

  20. Desktop QNX by fm6 · · Score: 4, Insightful
    THIS IS NOT A DESKTOP OS.
    Actually, that's not true. QNX has always had a lot of desktop features, and was originally sold to that market.

    At one time QNX's realtime features worked in favor of its use on the desktop. That was 20 years ago, when processors were wimpy, and attempts to create GUIs based on DOS had pathetic results.

    Of course, QNX's window of opportunity to compete with NT, or even Linux, has long since closed, So the development efforts and the marketing noise emphasize embedded and realtime apps. That's why the Photon GUI is so dated, and the interactive apps are starting to clash with the desktop apps. These are things that could be fixed, but never will be. The reasons are economic, not technical

  21. I'm in love with RtP by MSBob · · Score: 4, Insightful
    I played with RtP for quite a while. I love it. I learned so much about OS design just by reading the RtP manuals and I think it has a hell of a potential especially on internet appliances and web tablets etc.

    The beauty of QNX and RtP is the microkernel design (let the flamewars begin). The OS is exteremly resilient because the core kernel just acts as a messaging bus for all other services that run in the user space. For example, should your filesystem crash you can just restart it like any other user space process!. Alternatively if you don't need multitasking capabilities but memory and hardware are at premium you simply don't run proc and don't have to put up with the overhead of a process scheduler. QNX is such a clean design it puts other microkernels to shame. Rock on QSSL.

    --
    Your pizza just the way you ought to have it.
  22. License Fee by Alsee · · Score: 3, Insightful

    Could you imagine the uproar if Microsoft tried to charge a license fee before you could release an application that ran on the operating system?

    -

    --
    - - You can't take something off the Internet! That's like trying to take pee out of a swimming pool.
    1. Re:License Fee by Arandir · · Score: 2

      The reason is simple: the "free" version of QNX is an *evaluation* version. Shareware in other words. In order to release a QNX application you must have the licensed version of QNX.

      This is in many ways the same situation that exists under Microsoft. If you release a Windows app created on a pirated copy of Windows, and Microsoft found out, you're in deep doodoo. QNX at least gives you an uncrippled evaluation copy to use.

      According to my QNX rep, you *can* release non-commercial software for QNX using the evaluation copy. Of course, he's not a lawyer, but a salesman, but I suspect he knows more about it than I.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    2. Re:License Fee by Animats · · Score: 2

      Yes. Try releasing an XBox game.

  23. Re:Would this help for my 486 lab? by Kris+Warkentin · · Score: 2

    I think you might find RTP would run reasonably well but don't take my word for it. Go to http://qnx.tucows.com/preview/201252.html to download an iso for burning to a CD. If you insert this into the cd drive on an windows box, it will let you make a boot floppy for boxes that won't boot to the CD. Good luck. BTW, you may want to turn of some of the eye candy on the gui (the pointer cam sucks back a few cycles that you can't spare) but I think it might not be too bad.

    --

    In Soviet Russia, hot grits put YOU down THEIR pants.
  24. And.. by mindstrm · · Score: 2

    from what I've seen, QNX is one of the more friendly embedded systems.

    Ever used VxWorks?

  25. Re:AAAAAAARGH!!! by SilentChris · · Score: 2
    "Played with an I-Opener?"

    No.

  26. Re:Boosting the foreground GUI application by be-fan · · Score: 2

    It wouldn't be too hard on UNIX. It would require that X run as setuid root, but X could manually renice applications on the fly. Actually, the last point you mention would be very helpful for GUI applications. Tannebaum mentions something similar in relation to lottery scheduling in his book "Modern Operating Systems."

    --
    A deep unwavering belief is a sure sign you're missing something...