The QNX Neutrino Microkernel (2007) | Hacker News Reader

The QNX Neutrino Microkernel (2007)

qnx.com

61 pointsm0th8726 comments

Open articleView on HN

My biggest dream is for some version of QNX along with the Photon GUI to be fully open sourced. Even if it was QNX 4.

It would be a game changer.

It seems to me to be ideal for automation, yet most seem to be using Linux.

This is probably due to the Open Source status I suspect.

Photon GUI alone to replace X windows would be amazing.

I used it as my main desktop system for three years while working on a self-driving vehicle, in 2003-2005. There were versions of Firefox, Thunderbird, and Open Office, so you had all the essentials.

It's OK, but would feel dated to most users. The really great feature is that there is no lag. The consistency of QNX is impressive. This is a real-time system, not a warmed-over time sharing system. No swapping or paging. Proper CPU scheduling. So little "why did it do that?"

Tesla is using Linux and Qt UI which seems to work pretty well.

It was amazing to be able to restart the GUI without even impacting the apps that were running.

>... No swapping or paging. ...

That's more of a function of your hardware resources and workload than the OS architecture you're running. E.g. a lightweight Linux desktop installed on present-day hardware will literally run with zero swap use - in fact, it will cache most disk access. (Unless you open something that hogs RAM, of course.) That may not be literally a soft-RT system, but from the user's POV it's just as snappy as one.

You must have been throwing a lot of CPU power at it, or perhaps I've just been extremely unlucky:

I've used multiple QNX based user interfaces and the one thing they all had in common was their lagginess and unresponsiveness.

What version did you try? When I tried QNX 4.24 on my desktop computer, I think it might've been on a 125 mhz pentium? Or a 486. The Photon GUI was snappy.

6.71, on a Pentium III.

If you’re talking about automation like in factories or appliances or robots, “most” are actually using either VxWorks, Integrity, or ThreadX.

(IoT devices certainly use Linux, but mostly for the same reason they do everything else: to decrease their BOM while still seeming “feature-rich.”)

Also where the momentum is at is using Linux. More are moving from proprietary solutions to using Linux. Suspect that will continue to happen.

Tridium/Niagara AX is the leading supplier-agnostic integration software for building automation. It's huge and it's QNX.

Air-handlers, fluid-coolers, chillers, etc., are now frequently powered by a JACE (an embedded controller running the Niagara platform on the QNX Neutrino microkernel). JACEs are used to handle integrating BACnet equipment and coordination across sites.

It's quietly becoming the standard way to do things if you're not just going to hand Honeywell or Trane a million dollars and hope things turn out ok.

It was at one point. unfortunately RIM got their dirty hands on it...

If someone has the source code from back when it was publicly available I would really appreciate it being posted on Github. (Assuming that the license allows it).

I have looked for a copy many times over the years but am always amazed that somehow no copy appears to have survived.

I was so mad that I hadn't downloaded the sources before it was too late. So was everybody developing for QNX. All open source development for QNX stopped on that date.

On that date, RIM stock was worth $69.97 per share. Today, $7.60.

> I was so mad that I hadn't downloaded the sources before it was too late. So was everybody developing for QNX. All open source development for QNX stopped on that date.

> On that date, RIM stock was worth $69.97 per share. Today, $7.60.

Correlation does not imply causation.

It is suggestive of competence though.

It wasn't really open source anyway.

"Access to QNX source code is free, but commercial deployments of QNX Neutrino runtime components still require royalties, and commercial developers will continue to pay for QNX Momentics® development seats"

http://www.qnx.com/news/pr_2471_1.html

You can still probably find it on torrent trackers (i just checked and there’s 6.5.0 with like 10 seeds)

BSPs were never opened tho (except generic x86, i think) but it’s simple enough that one could probably botch it together in couple of weekends.

Did no one try to make an open source QNX clone? Because the kernel at least is rather minimal I would have thought this was very achievable, probably easier than the initial version of Linux for example.

Why when there's FreeRTOS and a Realtime patchset for the Linux Kernel? Not sure what else the QNX ecology covers.

FreeRTOS isn't a desktop class operating system (which QNX was fine at), it's a kernel for microcontroller class devices. QNX was a real desktop, not just a kernel. RT-Linux is an external patchset that still only gives you Linux, with some extra guarantees, but does not fundamentally change any other design decisions. QNX is real time from the ground up (for example, even disk I/O was bound by these policies, which I don't think RT Linux guarantees). QNX had a message passing microkernel architecture, that transparently extended to multi-node computing -- you could reboot/restart device drivers, message passing was transparent across single/multi-node programs. File access was transparently multi node, too. This means you could do things like run QNX as your desktop and cross compile your application on that desktop (for ARM, MIPS, whatever) and "run" it and it would magically run on some remote embedded control system in your office, provided they were networked together. All of this would be bound by real-time policies (so your browser audio would not, for example, stutter because you were compiling something and I/O scheduling anomalies caused a latency spike to hit the audio buffer.)

This was true all the way up to the window manager -- you could network two completely separate systems and even mirror/split windows between them, AFAIK. It was also a POSIX compliant system. In a sense it seems like a blend of what was later Plan 9 and something like Minix.

Everyone here posts about K8S all the time, but QNX was the original microservice-based distributed operating system, IMO. :)

Honestly, I really wish a capability-based QNX successor would hit the scene. seL4 would be an excellent basis for this. Fuschia seems like the best contender right now (but doesn't use seL4), but it's unclear where it will go and I'm wary of such a project being tied to Google in the long run (for fear of similar problems that have plagued Android as a platform.)

> RT-Linux is an external patchset that still only gives you Linux, with some extra guarantees ...

Most importantly, RTLinux is very much not the same thing as PREEMPT_RT - the patchset that is actually expected to be mainlined in the future, and that some distros are shipping as the "-rt" kernel. Yes, I know it's confusing. That's why clarity is very important here!

I appreciate you taking the time to explain this.

Essentially the same trick as in L4. Minimal messaging with MMU protection, all syscalls (messages) are blocking, no mailbox per receiver, unlike Mach/Hurd. Their biggest problem.

QNX has much better POSIX support than L4 though. But L4 is open source.

Reply on news.ycombinator.com