QNX is hard realtime. At one point, its kernel had O(1) guarantees for message passing and process switching. It could have been rewritten without any loops. I'm not sure if that's still true.

It's also really compact. This used to be a great selling point for underpowered car infotainment systems. Some cars had around 1Mb of RAM for their infotainment, yet they were able to run fairly complex media systems.

QNX is also used for non-UI components, just as a good realtime OS.

I think it is mostly used for non-UI stuff. I could be wrong but outside of car infotainment I've never seen it used for UI stuff. Mostly it just sits headless quietly running some branch of industry that we all depend on. The joke used to be that if QnX had a y2k bug that had been missed civilization would end and never mind windows because you won't have any water, food, energy or transportation anymore.

Yep. QNX was better than anything else around 2000. VxWorks was technically slimmer and more reliable, but QNX had a real mostly-POSIX-compatible environment. You could develop/debug the code on QNX itself and deploy it on the devices.

They were also early adopters of Eclipse, which was the "default IDE" before the advent of VS Code.

I've used VxWorks as well, yes, it was slimmer (a lot slimmer, actually), but I would disagree that it was more reliable. QnX supported a ton of hardware out of the box and if there ever was unreliability as far as I've seen it it was always comms layer related, never the core OS or any other bits that you could put next to VxWorks and compare on a functional level. You just required a much bigger SBC to run it, and that's why we used VxWorks in the first place. But I would have been much happier with QnX. I'm imagining the modern day equivalent of QnX running on a Raspberry Pi Pico or one of the larger Arduino's or a Teensy. That would be an absolute game-changer.

Hard real time (so latency guarantees), microkernel (and they actually mean it, so your device drivers can't hose your system), standardized networked IPC including network transparency for all services, ISRs at the application level.

>IPC including network transparency

Sadly not anymore, Qnet was removed in 8.0

Oh! I only worked with it commercially prior to that so I never got the memo. What an insanely stupid move. That was one of their USPs.

In general QnX was commercially mismanaged and technically excellent. I'm imagining a world where they clued in early on that an open source real time OS would have run circles around the rest of the offerings and they'd have cleaned up on commercial licensing. Since the 80's they've steadily lost mind and marketshare though I suspect they'll always be around in some form.

There's been talk about this on Reddit too, where our chief architect of QNX 8 broke down the decision. He mentioned it was ultimately a tough decision, but that in the end the cons outweighed the pros.

Such decisions should always involve the customers. A chief architect that knocks one of the foundation stones out from under a building isn't doing the bureau they work for any favors.

Hey, could you please post a link to the thread you're referring to? I'm guessing it had to do with the io-pkt to io-sock transition, but I couldn't find any information about that.

I've also noticed that all of the message passing system calls still accept the node ID. Are there plans to open up this interface to allow for implementation of custom network managers, maybe? I'd be very interested in exploring that.