4 ms·

I've only ever used QNX in the form of Blackberry products (mostly the Playbook), so I am afraid I don't what the advantages of it would be compared to Linux or

by tombert 10mo ago

I've only ever used QNX in the form of Blackberry products (mostly the Playbook), so I am afraid I don't what the advantages of it would be compared to Linux or something. I know it's a microkernel which is inherently cool to me, but I don't know what else it buys you. Can anyone here give me a high-level overview of why QNX is cool?

cyberax 10mo ago
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.
- jacquesm 10mo ago
  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.
  - cyberax 10mo ago
    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.
    - jacquesm 10mo ago
      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.
jacquesm 10mo ago
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.
- m132 10mo ago
  >IPC including network transparency Sadly not anymore, Qnet was removed in 8.0
  - jacquesm 10mo ago
    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.
    - JohnAtQNX 10mo ago
      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.
      - jacquesm 10mo ago
        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.
      - m132 10mo ago
        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.

by tombert 10mo ago

cyberax 10mo ago

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.

jacquesm 10mo ago
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.
- cyberax 10mo ago
  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.
  - jacquesm 10mo ago
    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.

jacquesm 10mo ago

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.

m132 10mo ago
>IPC including network transparency Sadly not anymore, Qnet was removed in 8.0
- jacquesm 10mo ago
  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.
  - JohnAtQNX 10mo ago
    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.
    - jacquesm 10mo ago
      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.
    - m132 10mo ago
      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.