Posted by transpute 12/27/2025
[1] https://www.qnx.com/developers/docs/6.5.0SP1.update/com.qnx....
[2] https://www.mikecramer.com/qnx/momentics_nc_docs/photon/prog...
At the end, I had really beautiful (to my eyes, back then) and very functional desktop, but something went wrong when I made backup before installing SuSE Linux 7.0, so months of vigorous customizing were lost. :-(
But it was fun while it lasted. There were a number of alternative desktop shells in the Windows 95/98 era.
I have ever seen.
The arrows of time branch and spiral, so it's possible that "later" could require some properties of "earlier".
If Photon could not be open-sourced, it could be licensed to a third party for custodian maintenance. If QNX is abandoning Photon forever, would Blackberry object to Photon being cloned for Linux or FreeBSD? That could preserve a future option for QNX to use it again, like XFCE.
Enthusiasts still use Blackberry keyboards on handheld devices in 2025, which sell out in minutes. In a parallel universe, Blackberry.com offers embedded SBC developers self-service purchase and global delivery of the legendary Blackberry keyboard, with Bluetooth for convenience or USB-c for security.
They also mailed a manual along with the demo disk, and I was amazed that QNX had built-in network bonding, amongst lots of other neat features. At the the time I was using Slackware & the linux kernel version was still 1.x, I don't think bonding came to linux until 2.x?
I'd be honest and say that qnx demo disk had more usability overall than my disk, but one could easily have a usable text only linux bootable disk. Busybox and uclibc already existed back then.
https://www.cs.columbia.edu/~spotter/floppy.bin (won't be that useful today due to the ethernet drivers, but it was a 1.44mb floppy)
I wasn’t claiming Linux couldn’t achieve this, merely stating why QNX was mind blowing: because it was way ahead of what was available, not what was possible.
Congrats on your live floppy project, I guess.
my conceptual floppy was less to demonstrate it fitting on a floppy (that was just the carrot), the idea was to show how one could dynamically "rewrite" shared libs to only include the symbols one needed to run the apps and have them work.
argument being, static linking a single binary is smaller than dynamically linking it and including the shared library, but as one adds binaries, the duplicated code will eliminate that size advantage. But shared libraries (especially something like glibc) are large and apps dont always use vast sections of them), so what if one could iterate over all the dynamically linked apps one wanted to include and only include the sections of the shared libs that were needed.
So the project was demonstrating that. In practice, uclibc was smaller than the sliced up glibc (and at least for this project, worked just fine)
I’m sure it’s better now, it wasn’t so when QNX had come out.
The kernel processes are actual processes so each of the drivers is fully sandboxed, an error in one bit of code can not cause any other processes to be affected unless you explicitly declare that it should be so (shared memory, for instance) and of course you don't do that.
The reduction of scope alone is worth at least 30 IQ points.
Absolutely rock solid. I built some specialized network devices using QnX and those things ran for a decade+ after first installation. Not a single reboot.
[0] https://www.cvedetails.com/vulnerability-list/vendor_id-436/...
The reduction in scope is really gold, it makes it so much easier just to have a small defined interface per program. It is a bit like Erlang/OTP but with C as the core language, the IPC is so lightweight that it becomes the driver behind all library level isolation. So what in a macrokernel would be a massive monolith with all manner of stuff in the same execution ring turns into a miniscule kernel that just does IPC and scheduling and everything else is a user process, including all of the luxuries that you normally associate with user processes: dumps, debuggers, consoles.
BARTLET
By the way, the words you are looking for are, "Oh, good grief!"Photon or not, I hated the period where they sort of moved to canned BSP deployment only, where in 6.5 I could just develop on a live system. This is nice.
"This environment runs as a virtual machine, using QEMU on Ubuntu. To try the image, you'll need: Ubuntu 22.04 or 24.04." So it doesn't boot on bare metal?
Maybe they're trying to get away from needing Windows. The previous recommended development environment was cross-compilation from Windows.
The big news here is that they have a reasonable non-commercial license again.[1] The trouble is, QNX did that twice before, then took it away.[2] Big mistake. They lost their developer base. Support of open source tools on QNX stopped. As I once told a QNX sales rep, "Stop worrying about being pirated and worry about being ignored". They'll need to commit contractually to not yanking the non-commercial license to get much interest.
QNX should be licensed like Unreal Engine. If you ship enough products using it, it gets noticed and they contact you about payments, and if you're not shipping much product, Unreal doesn't care. This has created a big pool of Unreal developers, which, in turn, induces game studios to use Unreal. Unreal's threshold is US$1 million in sales.
Apparently they opened things up a bit last year, but nobody noticed.
Usefully, there is a QNX Board Support Package for the Raspberry PI, so you can target that. QNX would be good for IOT things on Raspberry PI machines, where you don't want the bloat and attack surface of a full Linux installation.
[1] https://qnx.software/en/developers/get-started/getting-start...
I am a little confused about it both being a virtual image running on QEMU and requiring a very specific Ubuntu version as the base OS.
Shouldn't anything that can run QEMU work?
I used to do software development back on 386 with the OS on a floppy disk and really loved it. In fact, I ported my Objective-C compiler and runtime to QNX back then. Would love to play around with it on my Mac.
Thanks!
That sounds quite a bit harder to enforce for an OS designed to run inside, often not internet-connected, devices.
Right. These days it's better to invest into Redox OS[1] as a potential substitute for it (if work on real time capability). And with real time patches merged into Linux mainline[2] QNX doesn't stand much chance today too.
[1] https://doc.redox-os.org/book/microkernels.html
[2] https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...
Correct me if I'm wrong but these and other Linux patches were always about soft real time and Linux never had hard real time capability because of its architecture.
In case you're not aware: CDE is still around, open source, and runs on modern unix-likes.
> that doesn't require long time abandoned C code
https://github.com/NsCDE/NsCDE
Not so Common Desktop Environment (NsCDE) 2.3 Latest
on Jun 16, 2023
https://sourceforge.net/projects/cdesktopenv/files/
src 2025-11-25
CDE is still in active development. NsCDE is effectively abandoned.
Oh I'm aware :) also this beauty from SGI is now around again:
Some comments mentioning QNX can run Swift code makes me think of it could also run iPhone apps.
While Blackberry exited the phone market, I’m surprised to know QNX is still the most popular os for cars. With 275 million devices running it atm.
Not at all. That is like saying because it can run C, it can run windows apps. To run iPhone apps you would need all the libraries and runtimes ported, including the whole GUI. Just not happening.
It's great that Apple are pushing Swift out there a bit, but honestly if they want the World to catch fire with it, they need to give away the Crown Jewels and get SwiftUI out there as well.
Meanwhile, it's great that QNX is supporting modern languages. I can imagine having a bit of fun with this developer desktop and seeing how modern tooling plays nicely with it.
Initially the actual implementation didn't match the conceptual framework, but by version 1.2 they had really cleaned things up.
I think it's a real shame Blackberry didn't manage to etch a third (or fourth - I also loved Palm's WebOS) niche for their QNX-based phones. Blackbberry 10 was an amazing mobile OS.
100% this. I had a Passport and it was one of the single lovelist phones I've ever had.
Compared to my Nokia 7710, the last device with the original Psion UI... that was an elegant touchscreen, plus physical buttons, and a replaceable battery, but that was about it.
Compared to my Nokia E90 Communicator...
The keyboard was even better; it charged off a standard MicroUSB port, and had a standard headphone jack; it had way more apps, because it ran Android ones pretty well.
Compared to any Android phone... Vastly unrecognisably better messaging app, with one inbox for all messages and notifications. Square screen so no fighting portrait vs. landscape. Physical keyboard for much more accurate typing -- and scrolling. Google-free.
I would still love one, but I don't think I could move it to my own Blackberry account at this point in time.
275M cars with QNX, https://roboticsandautomationnews.com/2025/12/19/blackberry-...
AI/robotics, https://qnx.software/en/industries/robotics