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."
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 :)
Computer Help
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.
You can always get Opera if you want.
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.
QNX is a good project for throwing on that old machine or for use as an embedded system (it's currently the operating system of my cable modem).
I'm waiting before I install on my main machine, however. I've been following the progress of QNX for quite a few years now and I'd like to say it's coming along quite nicely, just give it more time.
Oh and don't praise it or knock over it's desktop appearance. Desktop is about the last thing I look for in an OS (if it's that bad I can always create a better way myself.. hrmf).
I live under the bridge, in a pile of feces.
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
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.
A context switch occurs when the CPU is interrupted and exchanges the running address space (the 'context') for another, eg: one process for another or a process to the kernel. Most OSses have the kernel space partially visible above the end of the user space (in the top 1GB, usually) so this doesn't require a context switch. There are several reasons for a cx, the most common is quantum expiry (the program has used too much time and another will be given a chance to run).
In a process-process cx (such as expiry) the kernel saves the running processes context (its registers, IP and in some cases the TLBs) and loads the next one. This memory transfer takes more CPU cycles and contributes to the delay. The rest is the expensive (on x86, anyway) re-loading of the page table and caches. Obviously the new process shouldn't be able to read the old processes memory, so the caches and TLBs must be cleared. They then get re-loaded by the next processes page faults.
That's the main time sink in a context switch.
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.
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
I disagree in part.
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.
It's not a hack, but I do think it's unfortunate that it's not "officially" supported. It would make more sense to:
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.
That's true.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});