Slashdot Mirror
QNX: When an OS Really, Really Has to Work
An anonymous reader writes "Fortune has this article about how QNX's OS has found a niche and is doing well. Especially after 1996 when Microsoft executives said they would crush them in 2 years. When your software absolutely positively needs to work!"
It isn't the operating system controlling the grinding of lenses or correcting the tilt of the TGV. It is a function of the hardware to do these things. That they report back to some software (which could frankly be run on any embedded OS) which then tells them what to do next is almost irrelevant.
Ummm...it is the operating system that matters -- the O.S. is the software that controls the hardware. Just like software on a PC can make the hardware do things it ought not do, software can make a precision laser be off by 1/100 of a millimeter, destroying someone's retina in the process.
Don't become a regular here, you will become retarded. -- Yoda the Retard
I question the validity of blindly praising microkernels.
A lot of the decision depends on the architecture involved. I hope someone more knowledgable than myself will comment on this, but as far as I know, the reason BeOS started to implement networking into the main kernel instead of making it a microkernel "server" was because the x86 architecture is much slower in switching between sub-functions than the PowerPC was (I've read 10 times slower but can't remember the source).
The two monolithic operating systems you criticize are both i386-centric, so a true microkernel probably wouldn't be such a hot idea.
QNX's design is great for certain applications but not all. I looked into it for an intel based SMP homebrewed but critical (as in the systems behind it cost over $1 million) firewall and decided a more traditional i386 operating system would be better.
I know you're not a culprit here, but being a fanboy for one design approach or another is just bad engineering sense. It's something I see all the time and I'd wish they'd teach a lot more critical thinking skills at the high school level because of it.
I agree with you that address translation is a problem, however, this is mostly a problem with the x86 architecture. The x86 flushes the TLB on every address space switch. If we had a decent tagged TLB, this wouldn't be a problem. Indeed, it isn't a problem on most architectures that QNX is asked to run on. Repeat until enlightened: Context switching is only expensive on the x86 architecture.
The "additional costs" for IPC are mostly an illusion, since we're talking about IPC which is tightly integrated with the kernel, not SysV IPC. Yes, it costs to copy memory, but the cost is there in Linux too; it's just a user space -> kernel space copy rather than a user space -> user space copy.
Having said that, it may be possible to write an OS for which the context switching is much cheaper. L4 uses a neat scheme where a small part of everyone's address space is allocated to other small processes, so context switching only requires a change of segment, rather than a change of address space mapping. IPC is very fast under L4 if you're doing it with a small address space task.
I've wondered that myself. I can only conclude that these projects are either experiments which accidentally escaped the lab, or the hackers who wrote them have no sense of sound software engineering principles.
sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});