"At this point, an intermezzo with some QNX history is in order. A bit more than a decade ago, the QNX source code was available to the public. Back then, QNX had a vibrant open source community. People would experiment with the kernel, write various useful utilities and help each other in forums. QNX even had a fully featured Desktop GUI, ran Firefox and was self-hosting, so you could develop for QNX right on QNX itself with full IDE and compiler support. It was beautiful."
"Then QNX was bought, source code access was revoked and the community largely withered away. Questions were increasingly asked via private support tickets directly to QNX, locked away from the public. QNX know-how becomes harder and harder to acquire, open source software for modern QNX releases is essentially non-existent and the driver situation is a catastrophe. The QNX kernel is the most beautiful and interesting kernel I have ever had the pleasure of working with, but it lies in the shackles of corporate ownership."
It's sad.
QNX was originally an independent company. During that period, anyone could get a free copy of QNX for personal use. It wasn't open source, but it was available. It's POSIX-compatible, so it was a supported target for Gnu, Firefox, and Eclipse. We used QNX for our DARPA Grand Challenge vehicle in 2003-2005, and all that code was developed on desktop QNX.
Then QNX was acquired by Harmon, the successor to Harmon-Kardon, which once made home audio components and pivoted to car audio. They were thinking car infotainment. Harmon didn't really know what to do with an operating system, especially since the big market was systems for industrial control and point of sale. So eventually they opened the source.
Then QNX was acquired by Blackberry, the early smartphone company. They closed the source, very suddenly. They even killed off the free version for personal and educational use. So all third party open source development stopped. Blackberry eventually shipped a phone that ran QNX, but they were not powerful enough as a company to keep a third phone standard going. So Blackberry went to Android.
Blackberry killed off the self-hosted desktop environment, and users now had to cross-compile from Windows.
> but they were not powerful enough as a company to keep a third phone standard going.
They absolutely were, which is the tragedy of the whole thing, people absolutely loved their products and strongly preferred them to everything else on the market.
Instead of recognizing the game changer that the iPhone was they slept on the market and didn't do much to bring big touch screens and rich internet applications to their platform.
They may have been powerful enough in size and monetary resources, but not in process, structure, or vision. RIM (later BlackBerry) was a tech company that wasn't really run like a tech company - it was run like an insurance company, with a full fledged bureaucracy governed by their legal department. And as a result, when competition from Apple and Google came, they couldn't pivot to compete beyond a snail's pace and faded into the sunset very quickly.
> They absolutely were, which is the tragedy of the whole thing, people absolutely loved their products and strongly preferred them to everything else on the market.
Concur. I had a Passport and it was a deal-changing sort of device.
The universal inbox was amazing technology, which totally reworked how a pocket comms device worked. Sadly as companies gradually dropped BB10 support, although you could run Android messaging clients, those didn't integrate with the BB10 inbox, so gradually the phone got less and less useful.
This should have been a reason to demand open comms protocols and legally require all comms-tools vendors to support 3rd party clients.
Today, I use Ferdium to connect almost all my comms apps into one client app, but it's just a bloated Electron thing that forcibly unifies dissimilar web apps. It's clever but it's not really a solution. It's a herd of elephants on a seesaw in order to crack a peanut.
Never mind laws about cookie banners, it should be a procurement requirement for all government agencies in the free world that all vendors must support a documented protocol so that native client apps can connect.
To Slack, Whatsapp, Signal, Telegram, Google $ChatAppOfTheMonth, MS Skype|Teams|Whatever.
No web apps, no Javascript, just mandatory lowest-common-denominator local rich clients, so that tools like BB10 could talk to everything.
Frankly I don't care if it doesn't support sound or video. I will go quite far to avoid that anyway. But text, basic formatting, smilies, maybe embedded static image files and attachments.
I've always thought QNX 4.24 w/ Photon microGUI should've been fully open sourced, even a decade later. It would've been competitive with linux in the desktop OS arena.
I'm very surprised that there aren't any projects based on the last available open-source version. This sort of thing usually happens when the company behind an open-source project that has a large community does something stupid to the project. Mapbox is one such example.
It was never actually open-source: it was only source-available. So when they stopped making it available there was no legal basis for continuing. (this is why the definition of open source matters!)
It was, for a while. Blackberry did revoke QNX source code access. The original poster had a copy around from the open source era, and thus was able to fix "ps".
I once told a QNX sales rep that their problem was not being pirated. It was being ignored. Today, I'd say "forgotten".
I actually ran across this issue myself, SIGQUIT'd the process, loaded it into a debugger and found the exact same problem. I can confirm the problem still exists on QNX 7.1. Fortunately we were moving off it, so I didn't think much more about it, but glad someone wrote it up.
QNX really needs to modernize if they want to survive. Their tooling ecosystem is stuck in 2008, and their kernel's performance is pretty low. IIRC, the kernel itself is also single-threaded, and can't take advantage of multiple CPUs (even if tasks can be SMP scheduled).
Their moat is supposedly their ASIL certification, but I see that value shrinking more and more over time for the following reasons:
1. If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.
2. I'm not convinced that the QNX kernel is less buggy than the Linux kernel. Also, most failures don't tend to be kernel related.
There is NO market where “ASIL” is required.
Of course if something happens you better have a safety case as described in the ISO26262, or a good excuse.
That being said, that a system has a safety case according to ISO26262 ASIL D, does bot mean at all that all pieces must be certified.
Currently working in a project where ASIL D is reached by having an independent microcontroller, whatching out the whole QM mess.
There is a very large installed base of machines running on QNX, including medical equipment, radio communications, railway switches, automotive modules, etc. Most manufacturers are upgrading in small steps and absolutely do not want to start from scratch with their software layer.
Most manufacturers are upgrading in small steps and have no desire to start from scratch with their software layer. At best, they will add a touch screen, an arm processor and an Android system, but only for the interface. The critical parts will remain under QNX.
The same is true for VxWorks, a large proportion of industrial PLCs, electrical networks, water and sewage systems depend on VxWorks.
QNX and VxWorks are omnipresent but invisible systems.
I recall trying to debug a crash in QNX during the mid-90's. I was impressed by the svelte OS that could load from a 3.5" floppy. The failure scenario was coincident with one of my first tasks as a BIOS engineer and it entailed adding some custom error logging in System Management Mode (SMM). Luckily for me it turned out that I had forgotten to save/restore certain general purpose registers around my SMM logic. Fun times.
SMM is pretty good at 'breaking' operating systems :)
Every developer I know (myself included) that has worked with QNX has a story about some insane bug that took significant effort to uncover. At this point, I would say the only reason one should look at QNX is for cost since it is pretty cheap. The low jitter on context-switching to the highest priority thread is a nice thing but the dev process is absolute garbage.
yep. it's really trash. used it 20-25 years ago when they were just introducing "neutrino" vs. the classic QNX4. the former had a good rep with auto and medical usage.
- very bad port of GCC was buggy and generated bad code. it was the result of some idiot blindly haphazardly applying a ton random incoherent patches to try to get it to build instead of porting it properly. (to be clear mainline GCC at that time was fine; we re-ported it ourselves instead)
- and, of course, they used their own faulty compiler to build their libraries and services ;) causing unknown carnage waiting to be discovered.
- malloc broken (heavy use under multiple threads causes heap corruption). replaced with dlmalloc.
- serial port driver broken. rewrote a new one.
- intel network card driver crashes. replaced hardware with 3com to survive.
- certain math library functions broken (iirc, fmod). replaced.
and so on and on.
it doesn't matter what certification your RTOS (or whatever) has. if you cannot examine the source, rebuild it, etc. (oss or private source available) - it cannot be trusted. this was one of the worse examples, but it's always like this with "proprietary" OS/toolkits.
What I like about seL4 (although not a complete embedded dev platform) is formally-verification. QNX might have EAL4 in some configurations, but like most every other operating system on the planet, they haven't bothered to up their game by formally verifying it for correctness. This is a shame and entirely preventable with greater attention to testing and verification.
what sel4 shows is that it's entirely preventable with a rewrite from scratch by a team of formal-methods ph.d.s over many years, if they invent a design that allows the kernel to only be a few thousand lines of code so that the titanic effort of formal verification becomes feasible, barely. it's not something you can do with a codebase of millions of lines of code or a codebase that wasn't written from scratch with formal verification in mind. yet, anyway
Readit News
"Then QNX was bought, source code access was revoked and the community largely withered away. Questions were increasingly asked via private support tickets directly to QNX, locked away from the public. QNX know-how becomes harder and harder to acquire, open source software for modern QNX releases is essentially non-existent and the driver situation is a catastrophe. The QNX kernel is the most beautiful and interesting kernel I have ever had the pleasure of working with, but it lies in the shackles of corporate ownership."
It's sad.
QNX was originally an independent company. During that period, anyone could get a free copy of QNX for personal use. It wasn't open source, but it was available. It's POSIX-compatible, so it was a supported target for Gnu, Firefox, and Eclipse. We used QNX for our DARPA Grand Challenge vehicle in 2003-2005, and all that code was developed on desktop QNX.
Then QNX was acquired by Harmon, the successor to Harmon-Kardon, which once made home audio components and pivoted to car audio. They were thinking car infotainment. Harmon didn't really know what to do with an operating system, especially since the big market was systems for industrial control and point of sale. So eventually they opened the source.
Then QNX was acquired by Blackberry, the early smartphone company. They closed the source, very suddenly. They even killed off the free version for personal and educational use. So all third party open source development stopped. Blackberry eventually shipped a phone that ran QNX, but they were not powerful enough as a company to keep a third phone standard going. So Blackberry went to Android.
Blackberry killed off the self-hosted desktop environment, and users now had to cross-compile from Windows.
And QNX became more of a niche product than ever.
They absolutely were, which is the tragedy of the whole thing, people absolutely loved their products and strongly preferred them to everything else on the market.
Instead of recognizing the game changer that the iPhone was they slept on the market and didn't do much to bring big touch screens and rich internet applications to their platform.
It was a slow and agonizing death.
But they made that error long before buying QNX. By the time they bought QNX they had probably lost too much ground to turn it around.
Concur. I had a Passport and it was a deal-changing sort of device.
The universal inbox was amazing technology, which totally reworked how a pocket comms device worked. Sadly as companies gradually dropped BB10 support, although you could run Android messaging clients, those didn't integrate with the BB10 inbox, so gradually the phone got less and less useful.
This should have been a reason to demand open comms protocols and legally require all comms-tools vendors to support 3rd party clients.
Today, I use Ferdium to connect almost all my comms apps into one client app, but it's just a bloated Electron thing that forcibly unifies dissimilar web apps. It's clever but it's not really a solution. It's a herd of elephants on a seesaw in order to crack a peanut.
Never mind laws about cookie banners, it should be a procurement requirement for all government agencies in the free world that all vendors must support a documented protocol so that native client apps can connect.
To Slack, Whatsapp, Signal, Telegram, Google $ChatAppOfTheMonth, MS Skype|Teams|Whatever.
No web apps, no Javascript, just mandatory lowest-common-denominator local rich clients, so that tools like BB10 could talk to everything.
Frankly I don't care if it doesn't support sound or video. I will go quite far to avoid that anyway. But text, basic formatting, smilies, maybe embedded static image files and attachments.
Nobody would lose from this.
Deleted Comment
I'm very surprised that there aren't any projects based on the last available open-source version. This sort of thing usually happens when the company behind an open-source project that has a large community does something stupid to the project. Mapbox is one such example.
I once told a QNX sales rep that their problem was not being pirated. It was being ignored. Today, I'd say "forgotten".
Their moat is supposedly their ASIL certification, but I see that value shrinking more and more over time for the following reasons:
1. If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.
2. I'm not convinced that the QNX kernel is less buggy than the Linux kernel. Also, most failures don't tend to be kernel related.
If you're in a market where a ASIL certification is needed, the customers ONLY care about this certifications. I keeps them out of jail.
Currently working in a project where ASIL D is reached by having an independent microcontroller, whatching out the whole QM mess.
At least SDP 8.0 overhauled the kernel to not be locked to a single thread anymore, which is nice IMO
Can you elaborate on this? How is it "low"
Other than that, the blog post was very interesting, I learned a bit of history of QNX, and concluded that I should avoid it.
- very bad port of GCC was buggy and generated bad code. it was the result of some idiot blindly haphazardly applying a ton random incoherent patches to try to get it to build instead of porting it properly. (to be clear mainline GCC at that time was fine; we re-ported it ourselves instead) - and, of course, they used their own faulty compiler to build their libraries and services ;) causing unknown carnage waiting to be discovered.
- malloc broken (heavy use under multiple threads causes heap corruption). replaced with dlmalloc.
- serial port driver broken. rewrote a new one.
- intel network card driver crashes. replaced hardware with 3com to survive.
- certain math library functions broken (iirc, fmod). replaced.
and so on and on.
it doesn't matter what certification your RTOS (or whatever) has. if you cannot examine the source, rebuild it, etc. (oss or private source available) - it cannot be trusted. this was one of the worse examples, but it's always like this with "proprietary" OS/toolkits.