QNX has been "opened" twice before. Each time, there was a rug pull, and it went closed again.
Before the first rug pull, open source groups routinely added QNX to their target list. There was a Firefox for QNX. Eclipse had QNX as a target. GCC and most of the Gnu command line tools could be built for QNX.
There was a desktop environment, Photon. I used that as a primary desktop for three years when working on a DARPA Grand Challenge vehicle.
All of that went away after the Harman acquisition of QNX in 2004.
Then, in 2007, QNX went open source. You could even look at the microkernel. It wasn't openly licensed, but you could look inside and build it.
In 2010, RIM acquired QNX, and, with no warning, closed the source. All open source development related to QNX ceased, and QNX lost all credibility in the community. So QNX shot itself in the foot. Twice.
Note the contractual terms.[1] "TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party". QNX can pull the plug at any time. Since they've done so twice in the past, there's a good chance that will happen again.
Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.
That's the way to do it if you want more adoption of QNX. Take the Epic term sheet to your lawyers and management. And have them take a look at Unreal Engine's revenue growth vs. QNX.
As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.
If I use Linux I know I won't have to have a discussion about licensing, I know I won't get rug pulled, etc.
Also the ban on commercial use is heinous. I am going through this with Arangodb right now. I love the product, but I have no budget for a cloud instance they manage and I have no budget to talk with their sales people about a commercial license. I have several systems that use it (including one that's about 80% of a way to a "too big for free" database) and I don't know if their fate will be (a) open sourcing, (b) a product or (c) a system that makes money for me directly but for me the short path is to switch to postgres, not talk to people whose business model doesn't necessarily allow my business model.
> Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.
One option: Dual-license as GPLv3 (the 3 is important!) or commercial license. Hobbyists and FOSS projects will be quite happy to use a GPLv3 OS. The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.
(IANAL, this is not legal advice, interpret licenses yourself.)
Shitty dx is baked into RIM/Blackberry's institutional DNA.
I had a long conversation with their engineering people way back before BB10 came out. At the time you had to apply to get access to the full blackberry SDK, and IIRC you also had to sign an NDA. Meanwhile Android and iOS were in full swing and wouldn't you know it, the platforms that had better developer experience, that prioritized making it easy to write apps, were successful.
Blackberry is just institutionally incapable of handling this sort of relationship with the community. It's that legacy telco "us vs them" mindset at the top of the org, and it filters down whether implicitly or explicitly.
As someone who knows only that QNX is a RTOS and that "real time" is good in some vague hand-wavy way, I found this 2015 comment a very succinct, concrete and illuminating description of one aspect of QNX's architecture that makes it properly real-time.
Even getting the licensing right isn't sufficient. They could license it as MIT today, close source it again tomorrow, and within a few releases no one would be using the MIT version.
Unless someone is interested in maintaining a full fork. It's the same reason Google can do whatever they want with Chromium even though it's technically open source. No one else has the resources/will to maintain it so there's no credible threat of a fork.
(I am not your lawyer, this is not legal advice. This is not a comprehensive review, assessment, or summary of possible interpretations of that license. Seek professional counsel from a lawyer before acting on anything stated below.)
These terms open with a ‘user did not have an opportunity to review and agree before binding themselves, their business, and/or their institution’ clause that may well wholly invalidate the entire document in the US, so please review these with your lawyer before use, so that your usage is not put at risk due to legalese overreach.
Academics, only students and faculty of your institution qualify, and your usage under this license will be viewed by your legal team as you signing a binding agreement on behalf of your employer; make sure you’re not exposed to liability through open source contributors or at risk of being fired for misrepresenting yourself as a signing authority for your institution.
Cloud users, your license is restricted to AWS per their terms; use on GCP, Heroku, or any other server instance not under your personal contractual control may result in owing licensing fees.
Only OSI definitions of “Open Source” are permissible here; this disqualifies anyone licensing software under a restrictive non-commercial license from making use of the QNX non-commercial license, as per OSI, all such restrictions are not “open source”.
Social apps are excluded by the “high risk” clause, which prohibits any use under these terms to develop applications that could harm society. Take care not to create viral applications that violate this clause.
They collect and retain all serial numbers identifiable on all hardware you use in association with this product.
Your noncommercial license may be severed unconditionally at any time without recourse, regardless of whether you have faithfully complied with the terms; at which time you may be compelled under contract to provide an undefined ‘certification’ of indeterminate cost that you deleted all QNX code provided to you.
Don't hold me to timelines, but we're definitely headed in the direction of being more open and transparent. We're hearing that this is important to our customers and the community alike. Stay tuned!
QNX and BeOS were the only operating systems I tried in the early '00s that could make old single-core mid-90s Pentiums feel excellent and snappy to use. Far, far better than any Windows version, or Linux.
I assume it's mostly scheduler stuff and much better multimedia stacks, in both cases. I always hoped the operating systems of the future would feel more like that. Closest we've got is probably iOS and it cheats by killing processes all the time. The future is lame.
BeOS was “pervasively” multithreaded, which in non marketing speak means the kernel did not have a giant lock (since it was designed as a many core system from day #1). Its comtemporary OS’s at the time had a giant single lock. BeOS also had 750ms preemption interval (or was it 3ms, I dont remember) while Linux and Windows had 20ms, then later 10ms, so this is what you fealt. A couple of decades later and most OS’s matched the finer locking granuality in kernel space, minus the premption interval (argument being throughput vs latency, since scripted OS benchmarks measure overall throughput, not GUI responsiveness). A perfect example is media buffers that benefit from smaller buffers, at the cost of less throughput. Musicians notice better responsiveness in BeOS, hence the monicker “Media IS”.
Also, in GUI space, the BeOS/Haiku app server still offers a more distributed workload compared to other desktop environments. Every windows is assigned its own thread, the app gets its own thread, and the app and application server have 1 thread per app and window to ensure they are not blocked waiting for slow app message parsing. So minimum BeOS app with graphical “Hello World” window is 4 threads. So even if the app is busy, the rest of the system still feels responsive.
All this comes at a throughput cost, as well as anapp development complexity cost, especially for ported apps. Haiku needs to marshall Qt/Gtk/toolkit messages from many windows into a single message queue to prevent multithreaded bugs from popping up (since in their original environment, all app message loopers were not multithreaded). This marshalling needs additional lock/unlock calls in Haiky even when not needed (messages to same window).
Haiku native apps, on the other hand, as smooth as ice. See this screenshot of Mefo video editor where all windows are working in their own threads (https://raw.githubusercontent.com/smallstepforman/Medo/refs/...). On modern systems, this app is smooth as ice, which for a video editor is heresy. Disclaimer: I wrote the linked Haiku app.
I non-ironically dream for the day that a modern computer is as snappy booting as my old Commodore 128, as fast to reset, and as responsive to all keystrokes.
Although they’re cheating, I give them props for trying. I abandoned Android when even Samsung didn’t make an honest effort to make their phones responsive. It’s nice that Apple consistently values responsiveness because then Google, Samsung and Microsoft have some incentive to address their bloated products.
My previous company, which made high-availability (Active/Standby) routers for mobile networks, used QNX as the OS. I remain impressed by its capabilities.
My memory is rusty, but we ran QNX on the control-plane processors, and it natively allowed launching processes on remote processors over the internal network of the router. That is: their low-level IPC was IP-capable. QNX's IPC was essential for our HA failover functionality.
Also, device drivers as user-space processes that you could restart on crash was great (we were developing our network drivers, so this would occasionally happen). Also, better respect for devices actually showing up in the /dev/ tree, unlike Linux where network devices are a notable exception.
One funny story, I once spent days debugging an issue which turned out to be due to me accidentally marking const the return values of some IPC, which caused my process to crash in between QNX's IPC function and mine! Whatever level of debugger (C/userspace) I was using at the time could not catch the error ^^;
Please consider bringing back some legacy software.
When I was learning computers, we learned on QNX (poor kids younger than I started on Windows!) and there were some very interesting software packages that I think don't exist anymore.
For example, QPaint. What made it interesting, is that you could save your image in a few image formats, or as a C header for inclusion in a C program. It could also import/export Logo generated images.
There was also a software voice module. I assume it had different voices because when it was demoed to us, it was a robot guy voice, but later there was an educational graphical interface that looked like a girl's face, and it of course had a female voice when it spoke. It would be strange to have two things do exactly the same thing, so I suspect they were the same software for speech.
I think it was simply invoked with 'speak'. We used to prank other students by speak -something- /dev/tty.... where the tty pointed to other people's nodes on the server network. Fun times!
Kudos on your bold undertaking! I've been a side-lined QNX admirer for some time, though not a potential user in most cases. A good next step would be a series of blog posts where the author takes on common types of enthusiast projects and unpacks how QNX's strengths can be applied in those scenarios.
We need to start treating “non-commercial” as the ambivalent term that it is.
Eg: All “non-profit” and “personal” use likely isn’t necessarily “non-commercial”, but those two can be easily identified based on who it is that makes use of the software.
I’ve had a lot of experience in developing on QNX over the years, and with each successive year, the call to migrate to Linux got stronger. The day to day developer experience is great, you can very easily setup a CMake toolchain and bypass the need for QNX’s Momentics, which if you’re just developing for QNX is something you will want to do. But, in my experience the driver support simply isn’t there, and that became painful. A fair few major board manufacturers treat QNX integration as a complete afterthought, and at a point you start to feel that this is directly related to RIM’s decision to shutdown source access to QNX. I’ve since left that company, but I imagine there is still a call to use Linux.
I think we're at something like 235 millions cars on the road today with QNX inside. The volume blows my mind. We're also hiding inside lots of healthcare products, industrial control systems, etc.
There's lots of interesting key differences between something based on Linux, for example, and QNX. Worth digging into if you're interested in these things. My colleague wrote a short ebook and the intro has a good summary: https://gitlab.com/elahav/qnx-rpi-book/-/tree/master/pdf
> They are the brains of a ton of cars on the market, like all Ford cars. Used for complex calculations like automatic transmissions.
I would seriously doubt that QNX or anything like it resembling a "real OS" is running on the automatic transmission. If the transmission controller is running any OS at all it's likely a microcontroller running a much more specialized RTOS.
QNX is very common in automotive applications, but in things like digital instrument clusters and ADAS where the software is complex enough to benefit from a full networkable OS with support for a lot of different high speed buses but the use case still needs real-time guarantees and/or microkernel stability. I've specifically seen QNX's hypervisor marketed for digital clusters where the critical data display and interaction with the ECU could happen within a fully certified QNX environment that would be designed to be as stable and reliable as possible while allowing infotainment applications to run in a VM instance of Android, Linux, or even more QNX where software reliability was less critical. If it crashes, the important instruments are still working.
Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on QNX as well, though being just infotainment they didn't really care about the realtime aspect (though I'm sure stability was a big thing compared to their Windows CE based predecessors). They've moved to Android for their latest revision.
> Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on QNX as well, though being just infotainment they didn't really care about the realtime aspect (though I'm sure stability was a big thing compared to their Windows CE based predecessors).
I've got a Sync 2 car, and I can't say I've noticed instability. The UI toolkit is slow, but the story on that is someone's cousin did something some Macromedia stuff that barely worked and they shipped that. I've got some issues with GPS offset, but that's pretty stable. I had worse stability with the Chrysler UConnect in my 2017 Pacifica, and that was reportedly based on QNX; it would sometimes crash and restart, or the screen would not come on at all unless you knew the magic buttons to hold to force reboot.
@JohnAtQNX can you remove the "everybody needs an account" restriction from your website downloads, and also remove the license mechanism from qcc? That would go a long way towards encouraging hobbyists to try it out.
Your money comes from high-volume licensing deals, where you presumably get a per-unit license fee. That revenue stream is jeopardized by pissing off the CI/CD teams that have to support QNX product lines.
Hiya! We've discussed how to make that work. It's good to hear the same thing from an outside voice. I'll bring it back to the table to inch it along. Thanks!
In case you are wondering: QNX is a commercial Unix-like real-time operating system owned by BlackBerry, aimed primarily at the embedded systems market.
The "unix-like" characterisation seems it might be be from the Wikipedia QNX article and repeated by a lot of web content. But it doesn't seem really accurate to me and it's not used by their own web site or documentation. It seems quite opposite to Unix in a lot of ways even though it has some API compatibility.
I still remember being blown away by the single-floppy QNX demo that included a web browser. It was so fast.
I wish you guys the best. I can only imagine what a gordian knot it must be getting all the legal ducks in a row to actually open things up. Like others have mentioned, after two rug pulls, we're all wary, but there's so much to enjoy about QNX, I hope you manage to get traction with this.
With linux options in embedded space aplenty, who would want to move to a propriety os? QNX's big brother Vxworks has already been pushed out of most consumer embedded devices and is now limited to space probes and critical medical equipment. I just don't see a future for QNX anywhere.
Dealing with Linux can be a PITA. Once you get a base system up you still need to roll a bunch of our own stuff. Do you use System unit or systemd, etc. The driver api's are pretty unstable.
I make embedded linux device and I'm curious if QNX could make things easier, especially for long term stability.
This is very interesting and I'm happy to see this. It's probably not relevant but i'm remembering reaching out 20+ years ago for a license to use in a Darpa GC team and getting a quote for 16K which made it unavailable for our make shift team but I have a tremendous amount of respect for the company and their work to build QNX. I will probably be looking into this for something in the future.
@JohnAtQNX the way to put the rug-pulling concerns to bed is to license all the source code under the ISC License, BSD 2-clause License, or MIT License.
This would certainly have an impact once that was done. Of course I cannot speak to what that would do to your software business...
I hear it loud and clear. We're certainly in the early days of this initiative, but as things progress I'll make sure to bring up source code licensing as a community concern.
I recall running QNX on my iPAQ handheld, sometime in the late 2000s. It was pre-iPhone, so seeing a Unix-like O/S on a handheld device back then was quite a treat.
They then killed the self-hosted QNX entirely, no downloadable .ISOs after 6.5. No working toolchain, so porting software became difficult, pkgsrc abandoned.
They are completely noncommittal, nothing short of actually open-sourcing it, MIT/BSD, would convince me otherwise.
We have a couple of students working on bringing up the hardware in the Pimoroni Trilobot kit on QNX, but adding some ML to the camera for some kind of autonomous steering perhaps. It will be the perfect blend of intensive processing (camera+ML) with hardware control (short high-priority interrupts). (P.S. hope to open-source this when they are done, along with some blog posts or tutorials -- stay tuned.)
Separately, I think making a GPS-synced weather station would be a fun project. QNX is often used when tight timing is needed for telemetry, so using it to collect weather (and other) data, including from pulsing hardware like an anemometer, and then publishing it to an online service would be a lot of fun.
If software-only is more your style, there may or may not be someone in the office next to me porting some classic games right now! =)
I would like to explore it's IPC. I heard a lot of good about it. For example that it is has quite a nice API and is efficient.
Maybe I will tell it all wrong, but I remember that for example it could be easy to do RPC on the same machine for the isolation. A client calls the server and the scheduler would switch context immediately to the server process upon IPC.
Is there an eBPF equivalent for QNX?
Also, with the real-time linux patch (which has been mainlined now), I'm able to run C++ ROS2 control loops @ 1ms down to even 250us on commodity off the shelf i3 and i5 hardware with dedicated cores.
I've worked on vxWorks, QNX and Linux and I found the pace of development using Linux the fastest.
Wouldn't that not make sense for QNX? eBPF is for running code in kernel space but QNX is a microkernel. The microkernel approach would be to just run another userspace program like any other program.
It's a particularly cursed form of writing IPv4 addresses:
> A popular implementation of IP networking, originating in 4.2BSD, contains a function inet_aton() for converting IP addresses in character string representation to internal binary storage. In addition to the basic four-decimals format and 32-bit numbers, it also supported intermediate syntax forms of octet.24bits (e.g. 10.1234567; for Class A addresses) and octet.octet.16bits (e.g. 172.16.12345; for Class B addresses). It also allowed the numbers to be written in hexadecimal and octal representations, by prefixing them with 0x and 0, respectively. These features continue to be supported in some software, even though they are considered as non-standard.
I was also coming back in to edit my comment and write that my x -> 0.0.0.x was technically wrong and the same for the others. If you stick to only single-byte values then what I wrote was correct but if the values span multiple bytes they fill in the missing 0s appropriately, as in:
It's not really about eliding zeros, though. It's kind of a cursed thing:
x -> x3.x2.x1.x0
x.y -> x.y2.y1.y0
x.y.z -> x. y.z1.z0
x.y.z.w -> x. y. z. w
Where x0 is the 8 least significant bits of x, x1 is the next 8 higher bits, and so on.
The "zeros" happen when the last number is smaller than 256 (or 65536, etc.), but it doesn't have to be. For example 10.258 is a valid way to write an IPv4 address, it's the same as 10.0.1.2.
TIL the Blackberry brand still exists in this space. Similar to Nokia I suppose, the consumer side no longer exists but the enterprise side is still going.
I was excited to see "free", and even more excited to read "like things used to be", but after reading more closely I see it's merely free-as-in-gratis, as opposed to the more interesting definitions.
My experience looking at the page as someone who has never heard of QNX:
First there is so much text that wants to tell me how great this software/tooling/resources is, without telling me what exactly it is.
As I still wanted to know what it is, after reading your comment here†, I clicked on the front page https://blackberry.qnx.com/en which has a concise introduction
"Real-Time OS and Software for Embedded Systems
Launch your critical embedded systems faster with our commercial RTOS, hypervisor, development tools and services."
An RTOS for embedded system, aha! That would be valuable information on the QNX Everywhere page. (Real-Time OS / RTOS isn't mentioned once)
Then I found the resources section nearly at the bottom, which has quick start guide, where I can see what I will get when I sign up for a free license and that would be exactly what I (as someone who has no clue what to expect from QNX) would want to see at the top, after a short introduction to what it is and why I want to try it out.
Maybe this page is more intended for people who are already aware of QNX, but if you intend to "catch" new people I really would recommend you to reorder/simplify this page, by putting relevant information (like a short introduction, why I would want to try it and a quick start guide) at the top instead of a wall of marketing text.
† this comment was first under a comment from the author, which now got moved to the HN post text
QNX is a microkernel-based real time operating system. The kernel is tiny; it was about 60KB (not MB) twenty years ago. All the kernel does is message passing, timers, CPU dispatching, and memory allocation. Everything else is in user space, including file systems.
Everything is a message, rather than being a file. Messaging works like a function call - you send a block of data to another process, wait, and get a reply back. Processes which receive messages act like servers - they have a thread or threads waiting for incoming requests, and when a request comes in, it's handled and a reply is sent back. It's a microservices architecture.
Unlike Linux, it's a fast microservices architecture. Message passing and CPU dispatching are integrated. When a process sends a message to a service process, the sender blocks. (Timeouts are available.) If the service process isn't busy, control immediately transfers to the service process without a trip through the CPU dispatcher. When the service process replies, the reverse happens, and control goes back to the original sender. With most inter-process communication systems, there's queuing delay for this kind of operation. QNX got this right. This is the core insight behind QNX.
Yes, there is message passing copying overhead. In practice it's under 10%. I've sent video through the message system. Copying is less of a problem than you might expect, because, with today's large CPU caches, the data being copied is probably warm and in cache.
All this is real-time aware. Higher priority processes get their messages through first. If you call a service, it inherits the caller's priority until it replies. This prevents priority inversion, where a high priority process calls a low priority one and gets preempted by lower priority work. This works so well that I was able to do compiles and web browsing on a single-CPU machine that was also running a robot vehicle.
There's a tool for building boot images. You put in the kernel, a standard utility process called "proc", and whatever else you need available at startup. For deeply embedded systems, the application might go in the boot image. It's all read-only and can execute from ROM if needed, which is good for applications where you really, really want startup to always work.
Files and file systems are optional. For systems with files, there are file system and disk drivers to put in the boot image. They run in user space. There's a standard startup program set that creates a Unix-type environment at boot time. This is all done in user space. The file system is accessed by message passing.
System calls look like POSIX. Most of them are implemented in a library, not the kernel. Service processes do the work.
When an application calls POSIX "read", the library makes an interprocess function call to the file system or network service server. Program loading ("exec") is done in user space. The boot image can contain .so files. "Exec" is done by a .so file that loads the image. So the kernel doesn't have to worry about executable format, and program loading is done by untrusted code.
Because it uses POSIX, most command line UNIX and Linux programs will compile and run. That's QNX's big advantage over L4. L4 is a good microkernel, but it's so stripped down it's just a hypervisor. Typically, people run Linux on top of L4, so all the bloat comes back.
There is no paging at the OS level. That would kill real-time. There's a paging to disk library that can be used by programs such as compilers with big transient memory needs, but most programs don't use it. The effect is that responsiveness is very consistent.
I miss using QNX desktop. There's no lag.
That's awesome! It's decent, yes. The starter image comes with a graphical app launcher you can check out. I'll poke the team about releasing the source for that launcher soon (I think they wanted to clean it up so it's a good sample).
I wonder how much DBus (the Inter-Process-Communication (IPC) standard Linux desktops have been based around) is baked into QNX & instrumental to it! Maybe I can find out now?
That was such a time. It's sad that it was a security panic, to me, because there was incredible promise there... All of the cars infotainment, windows, interior lighting, HVAC, all these things are just DBus services hosted on QNX? And I can just connect to my car & modify them, in some cases even over the air? QNX & DBus could have been a huge selling point, could have been such an awesome way to debundle the car from its infotainment. If only.
Really interested to see if DBus really does underpin much of QNX, or whether this was just a time & place. Seeing how monolithic versus networked QNX is in general would be fascinating; is there one or two QNX hosts & lots of devices, or so the story more distributed that that?
In my opinion, any platform should be available for free for any non-commercial purpose. This is how people get started, and this is how the platform proliferates.
I might even suggest going a bit further: provide some limited support for non-commercial users, for example, make it super-easy to file a bug.
But otherwise, it's a win-win for both the free tier (students, hobbyists) and the corporate.
This is great feedback, thanks! I absolutely want to find ways to provide some support -- a bug portal is a fantastic idea. For now we're accepting issue reports though gitlab.com/qnx.
If only you could believe them.
QNX has been "opened" twice before. Each time, there was a rug pull, and it went closed again.
Before the first rug pull, open source groups routinely added QNX to their target list. There was a Firefox for QNX. Eclipse had QNX as a target. GCC and most of the Gnu command line tools could be built for QNX. There was a desktop environment, Photon. I used that as a primary desktop for three years when working on a DARPA Grand Challenge vehicle.
All of that went away after the Harman acquisition of QNX in 2004.
Then, in 2007, QNX went open source. You could even look at the microkernel. It wasn't openly licensed, but you could look inside and build it.
In 2010, RIM acquired QNX, and, with no warning, closed the source. All open source development related to QNX ceased, and QNX lost all credibility in the community. So QNX shot itself in the foot. Twice.
Note the contractual terms.[1] "TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party". QNX can pull the plug at any time. Since they've done so twice in the past, there's a good chance that will happen again.
Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.
That's the way to do it if you want more adoption of QNX. Take the Epic term sheet to your lawyers and management. And have them take a look at Unreal Engine's revenue growth vs. QNX.
As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.
[1] http://www.qnx.com/download/feature.html?programid=51624
[2] https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
Also I wonder how many applications really need more real time responsiveness than you can get out of Linux. We even have
https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...
If I use Linux I know I won't have to have a discussion about licensing, I know I won't get rug pulled, etc.
Also the ban on commercial use is heinous. I am going through this with Arangodb right now. I love the product, but I have no budget for a cloud instance they manage and I have no budget to talk with their sales people about a commercial license. I have several systems that use it (including one that's about 80% of a way to a "too big for free" database) and I don't know if their fate will be (a) open sourcing, (b) a product or (c) a system that makes money for me directly but for me the short path is to switch to postgres, not talk to people whose business model doesn't necessarily allow my business model.
rt linux is not appropriate for many hard realtime requirements
i have seen some try and fail in an effort to save $perceived_value
> Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.
One option: Dual-license as GPLv3 (the 3 is important!) or commercial license. Hobbyists and FOSS projects will be quite happy to use a GPLv3 OS. The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.
(IANAL, this is not legal advice, interpret licenses yourself.)
Shitty dx is baked into RIM/Blackberry's institutional DNA.
I had a long conversation with their engineering people way back before BB10 came out. At the time you had to apply to get access to the full blackberry SDK, and IIRC you also had to sign an NDA. Meanwhile Android and iOS were in full swing and wouldn't you know it, the platforms that had better developer experience, that prioritized making it easy to write apps, were successful.
Blackberry is just institutionally incapable of handling this sort of relationship with the community. It's that legacy telco "us vs them" mindset at the top of the org, and it filters down whether implicitly or explicitly.
For everyone else, your QNX comment from 2015: https://news.ycombinator.com/item?id=9872640
As someone who knows only that QNX is a RTOS and that "real time" is good in some vague hand-wavy way, I found this 2015 comment a very succinct, concrete and illuminating description of one aspect of QNX's architecture that makes it properly real-time.
So thank you very much for the link.
Even getting the licensing right isn't sufficient. They could license it as MIT today, close source it again tomorrow, and within a few releases no one would be using the MIT version.
Unless someone is interested in maintaining a full fork. It's the same reason Google can do whatever they want with Chromium even though it's technically open source. No one else has the resources/will to maintain it so there's no credible threat of a fork.
For QNX 8.0, here’s a saved-you-five-minutes direct link to the developer terms associated with noncommercial use:
https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
(I am not your lawyer, this is not legal advice. This is not a comprehensive review, assessment, or summary of possible interpretations of that license. Seek professional counsel from a lawyer before acting on anything stated below.)
These terms open with a ‘user did not have an opportunity to review and agree before binding themselves, their business, and/or their institution’ clause that may well wholly invalidate the entire document in the US, so please review these with your lawyer before use, so that your usage is not put at risk due to legalese overreach.
Academics, only students and faculty of your institution qualify, and your usage under this license will be viewed by your legal team as you signing a binding agreement on behalf of your employer; make sure you’re not exposed to liability through open source contributors or at risk of being fired for misrepresenting yourself as a signing authority for your institution.
Cloud users, your license is restricted to AWS per their terms; use on GCP, Heroku, or any other server instance not under your personal contractual control may result in owing licensing fees.
Only OSI definitions of “Open Source” are permissible here; this disqualifies anyone licensing software under a restrictive non-commercial license from making use of the QNX non-commercial license, as per OSI, all such restrictions are not “open source”.
Social apps are excluded by the “high risk” clause, which prohibits any use under these terms to develop applications that could harm society. Take care not to create viral applications that violate this clause.
They collect and retain all serial numbers identifiable on all hardware you use in association with this product.
Your noncommercial license may be severed unconditionally at any time without recourse, regardless of whether you have faithfully complied with the terms; at which time you may be compelled under contract to provide an undefined ‘certification’ of indeterminate cost that you deleted all QNX code provided to you.
Stay safe, folks.
To add some details - the source code for QNX was available from 2007 until the takeover by RIM/Blackberry in 2010.
So do you plan to offer access to QNX source code again in the future?
https://www.qnx.com/news/pr_2471_1.html
Don't hold me to timelines, but we're definitely headed in the direction of being more open and transparent. We're hearing that this is important to our customers and the community alike. Stay tuned!
The stock is almost dead. Please just opensource it instead of taking all that to the grave with you. Just do it.
I just looked. BB peaked around US$140 and is now around US$2. Financials are so bad it's amazing the doors are still open.[1]
QNX is a great technology, but nobody who acquired it knew what to do with it.
[1] https://www.bing.com/entitydetails?q=BB+stock&wt=FinanceGene...
So from what I gather, this is the third time you want to be open and transparent with your sources?
But then it will be clear that almost nothing was done in that time…
You are not John "patent troll" Chen right? Your ceo suck
QNX and BeOS were the only operating systems I tried in the early '00s that could make old single-core mid-90s Pentiums feel excellent and snappy to use. Far, far better than any Windows version, or Linux.
I assume it's mostly scheduler stuff and much better multimedia stacks, in both cases. I always hoped the operating systems of the future would feel more like that. Closest we've got is probably iOS and it cheats by killing processes all the time. The future is lame.
BeOS was “pervasively” multithreaded, which in non marketing speak means the kernel did not have a giant lock (since it was designed as a many core system from day #1). Its comtemporary OS’s at the time had a giant single lock. BeOS also had 750ms preemption interval (or was it 3ms, I dont remember) while Linux and Windows had 20ms, then later 10ms, so this is what you fealt. A couple of decades later and most OS’s matched the finer locking granuality in kernel space, minus the premption interval (argument being throughput vs latency, since scripted OS benchmarks measure overall throughput, not GUI responsiveness). A perfect example is media buffers that benefit from smaller buffers, at the cost of less throughput. Musicians notice better responsiveness in BeOS, hence the monicker “Media IS”.
Also, in GUI space, the BeOS/Haiku app server still offers a more distributed workload compared to other desktop environments. Every windows is assigned its own thread, the app gets its own thread, and the app and application server have 1 thread per app and window to ensure they are not blocked waiting for slow app message parsing. So minimum BeOS app with graphical “Hello World” window is 4 threads. So even if the app is busy, the rest of the system still feels responsive.
All this comes at a throughput cost, as well as anapp development complexity cost, especially for ported apps. Haiku needs to marshall Qt/Gtk/toolkit messages from many windows into a single message queue to prevent multithreaded bugs from popping up (since in their original environment, all app message loopers were not multithreaded). This marshalling needs additional lock/unlock calls in Haiky even when not needed (messages to same window).
Haiku native apps, on the other hand, as smooth as ice. See this screenshot of Mefo video editor where all windows are working in their own threads (https://raw.githubusercontent.com/smallstepforman/Medo/refs/...). On modern systems, this app is smooth as ice, which for a video editor is heresy. Disclaimer: I wrote the linked Haiku app.
I non-ironically dream for the day that a modern computer is as snappy booting as my old Commodore 128, as fast to reset, and as responsive to all keystrokes.
Although they’re cheating, I give them props for trying. I abandoned Android when even Samsung didn’t make an honest effort to make their phones responsive. It’s nice that Apple consistently values responsiveness because then Google, Samsung and Microsoft have some incentive to address their bloated products.
My previous company, which made high-availability (Active/Standby) routers for mobile networks, used QNX as the OS. I remain impressed by its capabilities.
My memory is rusty, but we ran QNX on the control-plane processors, and it natively allowed launching processes on remote processors over the internal network of the router. That is: their low-level IPC was IP-capable. QNX's IPC was essential for our HA failover functionality.
Also, device drivers as user-space processes that you could restart on crash was great (we were developing our network drivers, so this would occasionally happen). Also, better respect for devices actually showing up in the /dev/ tree, unlike Linux where network devices are a notable exception.
One funny story, I once spent days debugging an issue which turned out to be due to me accidentally marking const the return values of some IPC, which caused my process to crash in between QNX's IPC function and mine! Whatever level of debugger (C/userspace) I was using at the time could not catch the error ^^;
Please consider bringing back some legacy software.
When I was learning computers, we learned on QNX (poor kids younger than I started on Windows!) and there were some very interesting software packages that I think don't exist anymore.
For example, QPaint. What made it interesting, is that you could save your image in a few image formats, or as a C header for inclusion in a C program. It could also import/export Logo generated images.
There was also a software voice module. I assume it had different voices because when it was demoed to us, it was a robot guy voice, but later there was an educational graphical interface that looked like a girl's face, and it of course had a female voice when it spoke. It would be strange to have two things do exactly the same thing, so I suspect they were the same software for speech.
I think it was simply invoked with 'speak'. We used to prank other students by speak -something- /dev/tty.... where the tty pointed to other people's nodes on the server network. Fun times!
Kudos on your bold undertaking! I've been a side-lined QNX admirer for some time, though not a potential user in most cases. A good next step would be a series of blog posts where the author takes on common types of enthusiast projects and unpacks how QNX's strengths can be applied in those scenarios.
I’d love to see this. I’m curious about QNX but at a loss as to how it could benefit me as someone who tinkers with robotics at home.
I also work for a non-profit org which does coastal margin research. We have several people working on custom hardware. Could this benefit us?
Start with https://gitlab.com/elahav/qnx-rpi-book/-/blob/master/pdf/qnx... as an intro to tinkering at home.
We need to start treating “non-commercial” as the ambivalent term that it is.
Eg: All “non-profit” and “personal” use likely isn’t necessarily “non-commercial”, but those two can be easily identified based on who it is that makes use of the software.
So what is the definition of “non-commercial”? Nothing in itself. Eg. Creative Commons elaborates a lot on what it means in that context: https://wiki.creativecommons.org/wiki/NonCommercial_interpre...
I’ve had a lot of experience in developing on QNX over the years, and with each successive year, the call to migrate to Linux got stronger. The day to day developer experience is great, you can very easily setup a CMake toolchain and bypass the need for QNX’s Momentics, which if you’re just developing for QNX is something you will want to do. But, in my experience the driver support simply isn’t there, and that became painful. A fair few major board manufacturers treat QNX integration as a complete afterthought, and at a point you start to feel that this is directly related to RIM’s decision to shutdown source access to QNX. I’ve since left that company, but I imagine there is still a call to use Linux.
I use CMake for QNX all the time. It just works, out of the box.
For anyone who (like me) was confused at what this is, it's a Unix like OS for embedded systems.
https://en.m.wikipedia.org/wiki/QNX
They are the brains of a ton of cars on the market, like all Ford cars. Used for complex calculations like automatic transmissions.
I think we're at something like 235 millions cars on the road today with QNX inside. The volume blows my mind. We're also hiding inside lots of healthcare products, industrial control systems, etc.
There's lots of interesting key differences between something based on Linux, for example, and QNX. Worth digging into if you're interested in these things. My colleague wrote a short ebook and the intro has a good summary: https://gitlab.com/elahav/qnx-rpi-book/-/tree/master/pdf
> They are the brains of a ton of cars on the market, like all Ford cars. Used for complex calculations like automatic transmissions.
I would seriously doubt that QNX or anything like it resembling a "real OS" is running on the automatic transmission. If the transmission controller is running any OS at all it's likely a microcontroller running a much more specialized RTOS.
QNX is very common in automotive applications, but in things like digital instrument clusters and ADAS where the software is complex enough to benefit from a full networkable OS with support for a lot of different high speed buses but the use case still needs real-time guarantees and/or microkernel stability. I've specifically seen QNX's hypervisor marketed for digital clusters where the critical data display and interaction with the ECU could happen within a fully certified QNX environment that would be designed to be as stable and reliable as possible while allowing infotainment applications to run in a VM instance of Android, Linux, or even more QNX where software reliability was less critical. If it crashes, the important instruments are still working.
Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on QNX as well, though being just infotainment they didn't really care about the realtime aspect (though I'm sure stability was a big thing compared to their Windows CE based predecessors). They've moved to Android for their latest revision.
> Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on QNX as well, though being just infotainment they didn't really care about the realtime aspect (though I'm sure stability was a big thing compared to their Windows CE based predecessors).
I've got a Sync 2 car, and I can't say I've noticed instability. The UI toolkit is slow, but the story on that is someone's cousin did something some Macromedia stuff that barely worked and they shipped that. I've got some issues with GPS offset, but that's pretty stable. I had worse stability with the Chrysler UConnect in my 2017 Pacifica, and that was reportedly based on QNX; it would sometimes crash and restart, or the screen would not come on at all unless you knew the magic buttons to hold to force reboot.
QNX was the OS behind the ICON computer that was used in schools across Ontario in the mid-80’s. At the time, I thought they were pretty cool.
https://en.wikipedia.org/wiki/ICON_(microcomputer)
Wow. 80186. That's something you don't see every day.
Wow, I didn't know this! Thanks for sharing!
@JohnAtQNX can you remove the "everybody needs an account" restriction from your website downloads, and also remove the license mechanism from qcc? That would go a long way towards encouraging hobbyists to try it out.
Your money comes from high-volume licensing deals, where you presumably get a per-unit license fee. That revenue stream is jeopardized by pissing off the CI/CD teams that have to support QNX product lines.
Hiya! We've discussed how to make that work. It's good to hear the same thing from an outside voice. I'll bring it back to the table to inch it along. Thanks!
In case you are wondering: QNX is a commercial Unix-like real-time operating system owned by BlackBerry, aimed primarily at the embedded systems market.
From https://www.sealevel.com/2023/01/02/what-is-qnx
The "unix-like" characterisation seems it might be be from the Wikipedia QNX article and repeated by a lot of web content. But it doesn't seem really accurate to me and it's not used by their own web site or documentation. It seems quite opposite to Unix in a lot of ways even though it has some API compatibility.
How does it seem like the opposite? It's POSIX.
It's got a POSIX API layer, but it's about as "unix-like" as Haiku.
You should update the Wikipedia article in that case.
I still remember being blown away by the single-floppy QNX demo that included a web browser. It was so fast.
I wish you guys the best. I can only imagine what a gordian knot it must be getting all the legal ducks in a row to actually open things up. Like others have mentioned, after two rug pulls, we're all wary, but there's so much to enjoy about QNX, I hope you manage to get traction with this.
With linux options in embedded space aplenty, who would want to move to a propriety os? QNX's big brother Vxworks has already been pushed out of most consumer embedded devices and is now limited to space probes and critical medical equipment. I just don't see a future for QNX anywhere.
Dealing with Linux can be a PITA. Once you get a base system up you still need to roll a bunch of our own stuff. Do you use System unit or systemd, etc. The driver api's are pretty unstable.
I make embedded linux device and I'm curious if QNX could make things easier, especially for long term stability.
There's BSD too (e.g. Playstation, Apple Airport, Some POS devices and printers)
Not everything has to be linux. It's good to have options for avoiding monoculturalization.
It's not a real option (to Linux) though at it is still governed by a non-free license.
This is very interesting and I'm happy to see this. It's probably not relevant but i'm remembering reaching out 20+ years ago for a license to use in a Darpa GC team and getting a quote for 16K which made it unavailable for our make shift team but I have a tremendous amount of respect for the company and their work to build QNX. I will probably be looking into this for something in the future.
20 years too late but ok.
And about a month after the RT Linux patches were put in the kernel master.
Agreed, a walled garden is still a walled garden...
Even a $12 SoC is no longer resource constrained with a stripped minimal Linux kernel. QNX missed their launch window decades ago...
The just bought a cow and wanted to milk to death. RIM is just a slow company to react.
@JohnAtQNX the way to put the rug-pulling concerns to bed is to license all the source code under the ISC License, BSD 2-clause License, or MIT License.
This would certainly have an impact once that was done. Of course I cannot speak to what that would do to your software business...
I hear it loud and clear. We're certainly in the early days of this initiative, but as things progress I'll make sure to bring up source code licensing as a community concern.
Typical marketing euphemism: "Built-in Support for Open-Source Components"
Read: we take free things thankfully, but we don't live by the same standards.
> Develop open-source software (OSS) that is interoperable with QNX software, provided you make the resulting OSS publicly available at no charge.
Even the GPL doesn't have this restriction...
I recall running QNX on my iPAQ handheld, sometime in the late 2000s. It was pre-iPhone, so seeing a Unix-like O/S on a handheld device back then was quite a treat.
I don't want to create an account just to know if it'll work on a pi zero w, will it?
https://blackberry.qnx.com/en/developers/board-support-packa... - no need to create an account, BSPs listed here and you can filter by several fields.
Right now, in the Pi family, only the Pi 4 on the BCM2711.
I don't have great expectations for this, we've been rug pulled before.
https://www.osnews.com/story/23565/qnx6-is-closed-source-onc...
They then killed the self-hosted QNX entirely, no downloadable .ISOs after 6.5. No working toolchain, so porting software became difficult, pkgsrc abandoned.
They are completely noncommittal, nothing short of actually open-sourcing it, MIT/BSD, would convince me otherwise.
What would be a good hobbyist project to learn QNX?
We have a couple of students working on bringing up the hardware in the Pimoroni Trilobot kit on QNX, but adding some ML to the camera for some kind of autonomous steering perhaps. It will be the perfect blend of intensive processing (camera+ML) with hardware control (short high-priority interrupts). (P.S. hope to open-source this when they are done, along with some blog posts or tutorials -- stay tuned.)
Separately, I think making a GPS-synced weather station would be a fun project. QNX is often used when tight timing is needed for telemetry, so using it to collect weather (and other) data, including from pulsing hardware like an anemometer, and then publishing it to an online service would be a lot of fun.
If software-only is more your style, there may or may not be someone in the office next to me porting some classic games right now! =)
I would like to explore it's IPC. I heard a lot of good about it. For example that it is has quite a nice API and is efficient.
Maybe I will tell it all wrong, but I remember that for example it could be easy to do RPC on the same machine for the isolation. A client calls the server and the scheduler would switch context immediately to the server process upon IPC.
None, I guess. It is just a Posix OS, with not the brightest future.
Maybe not the brightest future, but it's more than just a POSIX OS.
Is there an eBPF equivalent for QNX? Also, with the real-time linux patch (which has been mainlined now), I'm able to run C++ ROS2 control loops @ 1ms down to even 250us on commodity off the shelf i3 and i5 hardware with dedicated cores.
I've worked on vxWorks, QNX and Linux and I found the pace of development using Linux the fastest.
Wouldn't that not make sense for QNX? eBPF is for running code in kernel space but QNX is a microkernel. The microkernel approach would be to just run another userspace program like any other program.
Does it come on a 1.44MB floppy (image)?
* http://toastytech.com/guis/qnxdemo.html
* https://winworldpc.com/product/qnx/144mb-demo
* https://crackberry.com/heres-how-qnx-looked-1999-running-144...
Not this time! =). But today's floppy equivalent is a micro-SD card.. Right? Right?
Wait, http://127.1/
In the browser in the crackberry video
what the....
It's a particularly cursed form of writing IPv4 addresses:
> A popular implementation of IP networking, originating in 4.2BSD, contains a function inet_aton() for converting IP addresses in character string representation to internal binary storage. In addition to the basic four-decimals format and 32-bit numbers, it also supported intermediate syntax forms of octet.24bits (e.g. 10.1234567; for Class A addresses) and octet.octet.16bits (e.g. 172.16.12345; for Class B addresses). It also allowed the numbers to be written in hexadecimal and octal representations, by prefixing them with 0x and 0, respectively. These features continue to be supported in some software, even though they are considered as non-standard.
(https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_addr...)
Never use this.
127.1 is the same as 127.0.0.1. 0 bytes are inserted based on the following:
But sometimes 127.1 means 127.1.0.0/16. For example in the output of `netstat -rn` on MacOS.
Good to know.
I was also coming back in to edit my comment and write that my x -> 0.0.0.x was technically wrong and the same for the others. If you stick to only single-byte values then what I wrote was correct but if the values span multiple bytes they fill in the missing 0s appropriately, as in:
Similar rules apply to ipv6 addresses as well.
IPv6 at least sensibly has a different delimiter for when you are eliding zeros.
It's not really about eliding zeros, though. It's kind of a cursed thing:
Where x0 is the 8 least significant bits of x, x1 is the next 8 higher bits, and so on.The "zeros" happen when the last number is smaller than 256 (or 65536, etc.), but it doesn't have to be. For example 10.258 is a valid way to write an IPv4 address, it's the same as 10.0.1.2.
little known fact: you can write shorthand for any ip address. It simply omits 0. Ie 127.0.0.1 (or 127.000.000.001). Try pinging it. `ping 127.1`
10.0.0.3 -> ping 10.3
what's the problem, there's a self hosted web server on it.
If you are talking about the short url, well ipv4 allows it and they needed to save space to fit on the floppy ;)
I found this a while back. Unsure if it's related https://github.com/vocho/openqnx
(I prefer 32-bit because most applications don't need more than 4GB RAM, but I guess 64-bit could be useful too)
TIL the Blackberry brand still exists in this space. Similar to Nokia I suppose, the consumer side no longer exists but the enterprise side is still going.
Oh cool, does this also include the unfortunately discontinued desktop version of QNX? I've always wanted to try out a real time OS
Why not real-time Linux? It's even been accepted into mainline now.
Is that a true RTOS though? I thought it was only a partial implementation
I was excited to see "free", and even more excited to read "like things used to be", but after reading more closely I see it's merely free-as-in-gratis, as opposed to the more interesting definitions.
> Many of you probably used or tinkered with (the very open) QNX back in the day.
Well I didn't and it was not easy to understand what it is from your website. Wikipedia came to my rescue. You may want to consider that.
My experience looking at the page as someone who has never heard of QNX:
First there is so much text that wants to tell me how great this software/tooling/resources is, without telling me what exactly it is.
As I still wanted to know what it is, after reading your comment here†, I clicked on the front page https://blackberry.qnx.com/en which has a concise introduction
"Real-Time OS and Software for Embedded Systems
Launch your critical embedded systems faster with our commercial RTOS, hypervisor, development tools and services."
An RTOS for embedded system, aha! That would be valuable information on the QNX Everywhere page. (Real-Time OS / RTOS isn't mentioned once)
Then I found the resources section nearly at the bottom, which has quick start guide, where I can see what I will get when I sign up for a free license and that would be exactly what I (as someone who has no clue what to expect from QNX) would want to see at the top, after a short introduction to what it is and why I want to try it out.
Maybe this page is more intended for people who are already aware of QNX, but if you intend to "catch" new people I really would recommend you to reorder/simplify this page, by putting relevant information (like a short introduction, why I would want to try it and a quick start guide) at the top instead of a wall of marketing text.
† this comment was first under a comment from the author, which now got moved to the HN post text
Bad product, bad company, bad marketing. Consistent.
You'd be one of the first people I've seen that doesn't like QNX itself. Normally people complain about the licensing or RIM. What issues do you have?
I need to know if it comes with Photon microGUI! Please, lord, let it happen...
Photon was dropped years ago. They use a completely new graphics architecture now.
Great. Long over due, maybe too late.
With all due respect, I’ve never spent so long clicking through a website trying to figure out what it actually was.
What is QNX haha
QNX is a microkernel-based real time operating system. The kernel is tiny; it was about 60KB (not MB) twenty years ago. All the kernel does is message passing, timers, CPU dispatching, and memory allocation. Everything else is in user space, including file systems.
Everything is a message, rather than being a file. Messaging works like a function call - you send a block of data to another process, wait, and get a reply back. Processes which receive messages act like servers - they have a thread or threads waiting for incoming requests, and when a request comes in, it's handled and a reply is sent back. It's a microservices architecture.
Unlike Linux, it's a fast microservices architecture. Message passing and CPU dispatching are integrated. When a process sends a message to a service process, the sender blocks. (Timeouts are available.) If the service process isn't busy, control immediately transfers to the service process without a trip through the CPU dispatcher. When the service process replies, the reverse happens, and control goes back to the original sender. With most inter-process communication systems, there's queuing delay for this kind of operation. QNX got this right. This is the core insight behind QNX.
Yes, there is message passing copying overhead. In practice it's under 10%. I've sent video through the message system. Copying is less of a problem than you might expect, because, with today's large CPU caches, the data being copied is probably warm and in cache.
All this is real-time aware. Higher priority processes get their messages through first. If you call a service, it inherits the caller's priority until it replies. This prevents priority inversion, where a high priority process calls a low priority one and gets preempted by lower priority work. This works so well that I was able to do compiles and web browsing on a single-CPU machine that was also running a robot vehicle.
There's a tool for building boot images. You put in the kernel, a standard utility process called "proc", and whatever else you need available at startup. For deeply embedded systems, the application might go in the boot image. It's all read-only and can execute from ROM if needed, which is good for applications where you really, really want startup to always work.
Files and file systems are optional. For systems with files, there are file system and disk drivers to put in the boot image. They run in user space. There's a standard startup program set that creates a Unix-type environment at boot time. This is all done in user space. The file system is accessed by message passing.
System calls look like POSIX. Most of them are implemented in a library, not the kernel. Service processes do the work. When an application calls POSIX "read", the library makes an interprocess function call to the file system or network service server. Program loading ("exec") is done in user space. The boot image can contain .so files. "Exec" is done by a .so file that loads the image. So the kernel doesn't have to worry about executable format, and program loading is done by untrusted code.
Because it uses POSIX, most command line UNIX and Linux programs will compile and run. That's QNX's big advantage over L4. L4 is a good microkernel, but it's so stripped down it's just a hypervisor. Typically, people run Linux on top of L4, so all the bloat comes back.
There is no paging at the OS level. That would kill real-time. There's a paging to disk library that can be used by programs such as compilers with big transient memory needs, but most programs don't use it. The effect is that responsiveness is very consistent. I miss using QNX desktop. There's no lag.
So that's an overview. Microkernel done right.
I mean, I figured it out from HN but still.
I'm interested in building a Unity game for Raspberry Pi 4. Does QNX have good graphics support for RPi currently?
That's awesome! It's decent, yes. The starter image comes with a graphical app launcher you can check out. I'll poke the team about releasing the source for that launcher soon (I think they wanted to clean it up so it's a good sample).
Will Photon be available as well ?
This isn't an OS meant for desktops.
There are many uses for graphical UIs outside general purpose desktops.
For attracting more developers can you compile a comarison table with the benefits of QNX versus competitors?
The existing information out there is of questionable reliability and probably out of date too...
This is a good blog post idea. I'll get it on our backlog.
I wonder how much DBus (the Inter-Process-Communication (IPC) standard Linux desktops have been based around) is baked into QNX & instrumental to it! Maybe I can find out now?
https://ioactive.com/pdfs/IOActive_Remote_Car_Hacking.pdf or https://insights.sei.cmu.edu/blog/vehicle-cybersecurity-the-...
That was such a time. It's sad that it was a security panic, to me, because there was incredible promise there... All of the cars infotainment, windows, interior lighting, HVAC, all these things are just DBus services hosted on QNX? And I can just connect to my car & modify them, in some cases even over the air? QNX & DBus could have been a huge selling point, could have been such an awesome way to debundle the car from its infotainment. If only.
Really interested to see if DBus really does underpin much of QNX, or whether this was just a time & place. Seeing how monolithic versus networked QNX is in general would be fascinating; is there one or two QNX hosts & lots of devices, or so the story more distributed that that?
This is a good move!
In my opinion, any platform should be available for free for any non-commercial purpose. This is how people get started, and this is how the platform proliferates.
I might even suggest going a bit further: provide some limited support for non-commercial users, for example, make it super-easy to file a bug.
But otherwise, it's a win-win for both the free tier (students, hobbyists) and the corporate.
Eg the Business Source License and the Functional Source License makes it always available for non-commercial use
This is great feedback, thanks! I absolutely want to find ways to provide some support -- a bug portal is a fantastic idea. For now we're accepting issue reports though gitlab.com/qnx.
Reinventing QNX will always be seen as cutting edge.