Trying to emulate Mach, which was a dud as a microkernel, didn't help.
QNX is one of the few microkernels to get it right. L4 got stripped down so far that it's just a hypervisor, on which people usually load Linux. L4 took out arbitrary-length message passing in favor of interrupt-like events and shared memory between sender and receiver. This simplifies the kernel, but now it's easier for one side of a sender/receiver to mess up the other, since they share a communications area. The QNX primitive set (MsgSend, MsgReceive, and MsgReply) work well enough in practice to allow full POSIX functionality. Applications can talk to file system servers, network servers, etc. through those primitives. All QNX I/O works that way. You take maybe a 20% performance hit for the extra copying, but you get robustness in exchange.
Most important thing for performance in a microkernel: the CPU dispatcher and the message passing have to be tightly coordinated. You must be able to call another process and get a reply back without trips through the scheduler or a switch to a different CPU. QNX gets this right, because MsgSend is blocking. The sender blocks and the receiver starts without having to schedule. The data being sent is right there in the cache of the CPU, ready for use by the receiver. Good test for a microkernel - put some CPU-intensive jobs in a loop, while also running something that makes short request/reply calls to another process. If the request/reply process stalls out, the microkernel is doing it wrong. If the CPU-bound processes stall out, the microkernel is doing it wrong. Message passing should schedule as smoothly as a subroutine call. If it doesn't, performance under load will suck.
Roar.
QNX was cautiously courting the open source concept and venturing in the direction of shared source (with some code already available), when BlackBerry bought them and threw all of that out the window.
Biggest yanked opportunity. D:
Now QNX is all-commercial again, with source only available under a license. And Photon is gone, too: no more self-hosting.
I wish BB would(/could?) do the webOS thing with QNX. That would be amazing. The community would absolutely get Photon up and running again, it would be an alternative to Linux and BSD.
data:text/html;base64,SSBmaWd1cmVkIG91dCBob3cgdG8gZ2V0IFFOWCA0IGxpY2Vuc2VkIGEgd2 hpbGUgYmFjay4gSWYgeW91IGdldCBzdHVjayBteSBlbWFpbCBpcyBpbiBteSBwcm9maWxlLiBJZiB hbnlvbmUga25vd3MgaG93IHRvIGxpY2Vuc2UgNi54IEkgZG93bmxvYWRlZCB0aGF0IHRvby4=
Photon, the GUI, probably had the sanest internals of any major GUI system.
Dan Dodge, who designed much of QNX, was CEO of QNX, and he retired from QNX/Blackberry to go work for Apple. Apple might end up doing something in this direction. But if they do, they'll never let the internals out.
I assume you were using QNX for the GC vehicle compo because of its RTOS qualities? In any case, that's awesome.
I thought Photon was pretty cool too, at least from a "oh hey these screenshots look awesome" perspective. I vaguely recall running it in a VM, once, so long ago I only hazily remember poking around the sidebar. Sadly it'll be somewhat challenging to do further academic research on that subject now, I wish the educational/noncommercial free options still existed there.
Also, I found (and bookmarked) this HN thread from some time ago that's got some QNX gems in it: https://news.ycombinator.com/item?id=4834334 (very curious about the modem)
And you're very sadly right about Apple, they're very unlikely to release the truly interesting bits of any projects like this.
That course features implementation of microkernels based on QNX from scratch to drive trains around a track, should be straightforward to implement on a Raspberri Pi or a Pandaboard/Beagleboard. The course uses a TS7200 which is an older ARM chip.
[1] http://www.cgl.uwaterloo.ca/wmcowan/teaching/cs452/w16/notes...
I know there's L4 which is pretty mainstream on coprocessors.
Minix 3. The rise of platforms like Raspberry Pi are good for alt-os projects because they give a well-fenced compatibility target.