Slashdot Mirror

← Back to Stories (view on slashdot.org)

QNX RtP 6.2 World Preview

Posted by timothy on from the cuteness dept.

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

5 of 209 comments (clear)

  1. Re:First Impressions by ergo98 · · Score: 4, Informative

    You can always get Opera if you want.

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

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

    --
    Bush Lies Watch
  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});