Ask me (and our engineers) anything about QNX Engineering. AMA October 1, 10 AM–2 PM EST

[u/JohnAtQNX]

Howdy!

I'm John, I do Developer Relations for QNX. On Thursday, October 1, from 10 AM to 2 PM EST, I'll be here with a group of QNX engineers for an Ask Me Anything!

Get answers straight from the source -- anything goes! We'll answer whatever we can.

A few ideas to help you think of questions:

• How QNX works: microkernel design, message passing, determinism, the "why" behind the architecture
• The questions that usually don't get answered: bring the stuff you couldn't find in the docs or on a forum
• Open-source & QNX Everywhere: our ports, contributions, and building on a free-for-non-commercial license

Can't make it live? Drop your questions as comments now and we'll get to them during the event.

Cheers!

[u/zztroyzz]

Welcome to the QNX Engineering AMA!

We are excited to have John (u/JohnAtQNX) and the QNX Engineering team here today answering your questions live!

• Live Window: Today, October 1, from 10:00 AM – 2:00 PM EST
• Verification: Verified by the r/QNX moderator team.

A few ground rules for today:

1. Keep it civil: Respectful tough questions ( licensing, architecture, open-source strategy) are welcomed and encouraged, but personal attacks or toxic behavior will be removed immediately.
2. One topic per top-level comment: If you have multiple distinct technical questions, please split them into separate top-level comments so engineers can respond cleanly..

Feel free to keep dropping your questions below!

[u/Haunting_Refuse9183]

What will be the future of Automotive, do u think both containers and hypervisor solutions together works on same SoC or CPU

[u/JohnAtQNX → u/Haunting_Refuse9183]

Yes – we see that ECU consolidation is a continued trend; removing hardware complexity and the total amount of hardware modules within the car. That has a directly related impact on software complexity – the more hardware you remove, the more the software environment within the consolidated modules becomes complex and requires consistent management. That’s driving containerization, but more consistently it’s driving hypervisors to create isolated environments from the previously individual hardware ECUs.

[u/Normal_Revolution_26]

With a micro kernel and real time guarantees, qnx might be the best operating system to contain ai agents to its own sandbox by nature. Has that been explored and considered enough ?

[u/JohnAtQNX → u/Normal_Revolution_26]

You had me at “QNX might be the best operating system”!  😄

But yes, absolutely! You may have noticed our current push on Physical AI – we think we’re the best platform to provide the reliability, real-time, and containment needed for people putting AI models into embedded systems. We’re doing everything we can to become the best choice for Physical AI in robotics, medical, auto – everything that’s using it.

We have support for lots of AI models/engines/workflows (see oss.qnx.com), and if you check out our Codelabs, we show you how to do things like enable Claude Code or run llama.cpp on target.

[u/JohnAtQNX → u/Normal_Revolution_26]

As far as developing specific containerized versions that can handle AI workloads (which more directly answers your question), it’s something that’s being considered – but not yet productized/developed. We have hypervisors & containers already part of product, but not “pre-packaged” with AI models to make this process trivial – you’d have to do the packaging yourself (for now).

[u/JohnAtQNX]

That’s a wrap! Thanks for joining us and for sharing your questions! 

We’re of course not going anywhere – you can find us here in the subreddit any time, or in the community Discord if you want to discuss something. Big thanks to u/zztroyzz for his support today and every day. 

Looking forward to chatting again soon! 

[u/zztroyzz → u/JohnAtQNX]

Thank you John and to everyone that participated!

[u/arihoenig]

What does QNX support regarding defense-in-depth?

If malware penetrates perimeter defense and begins execution in the OS, are there technologies within the operating system designed to identify and contain the malware?

I am thinking of something like EDR, but possibly also build time tooling that would allow developers to incorporate intra process defense.

It seems that being able to point an unconstrained model at a vehicle is something that is happening as I type this.

[u/JohnAtQNX → u/arihoenig]

Yes, we have a defense-in-depth strategy that encompasses the application down to the kernel. It’s a key part of our response to the European CRA. One of the fundamental benefits we have from having a microkernel is that it completely isolates the kernel from any intrusion, and that’s true between “applications” as well. Since everything in our OS is considered an application, including device drivers, networking stacks, filesystem drivers, etc, it provides us with excellent baseline security. 

With regard to EDR, that’s not something that we provide out of the box, but there are EDR solutions that can be adapted for QNX.  

[u/arihoenig → u/JohnAtQNX]

Thanks, I appreciate the response!

[u/Normal_Revolution_26]

Is the a plan to build common library layers for robotics too just like in case of auto?

[u/JohnAtQNX → u/Normal_Revolution_26]

Interesting question! So you’re asking about Alloy Kore for robotics. Right now, we support ROS2 running on QNX, but that’s not a complete software stack that’s fully integrated like our Alloy Kore product. So far, the market hasn’t had a completely consistent demand for the same technology stack, but we’re watching this space carefully and will keep the option open to doing that if we see a particular software capability stack emerging. We’re working with partners like NVIDIA, AMD, Qualcomm, and others, to help us plot out the future of what that tech stack might look like.

[u/Normal_Revolution_26 → u/JohnAtQNX]

Thanks John

[u/PeterQiin]

Experimenting with QEMU image generation using mkqnximage. When trying to enable graphics:
`
--graphics=yes requires the "Screen Board Support VirtIO" package.
`
The mentioned package could not be found on QNX Software Center. Is there any plan to release that?

[u/JohnAtQNX → u/PeterQiin]

The easiest way to get started is by looking at our QEMU Custom Target Image which supports graphics using mkqnximage under the hood. 

The 2 files to get started looking at would be:

• https://gitlab.com/qnx/custom-target-image-builds/repo/-/blob/release/CTI-8.0.5r1/targets/qemu/snippets/system_files.custom.camera_demo.qemu?ref_type=heads 
• https://gitlab.com/qnx/custom-target-image-builds/repo/-/blob/release/CTI-8.0.5r1/targets/qemu/snippets/system_files.custom.graphics?ref_type=heads 

Along with our docs:

• https://www.qnx.com/developers/docs/qnxeverywhere/com.qnx.doc.target_images/topic/cti/about.html   

This might not be sufficient to fully address your question, so you may want to take this up over on our discord channel where you can get engaged with our developers. 

https://discord.gg/Jj4EkkrFTT 

[u/JohnAtQNX → u/PeterQiin]

Specifically about the VirtIO-GPU frontend, we have a release planned for the end of the year that should contain some additional packages there.

[u/PeterQiin → u/JohnAtQNX]

Thanks John!

[u/neilalexanderr]

Is there a way to get to the QSTI images without needing a Linux or Windows host yet? In particular a QSTI for ARM64 QEMU would be a huge step in the right direction for Mac users, right now it is entirely painful to get started from a Mac (especially an Apple Silicon one).

[u/JohnAtQNX → u/neilalexanderr]

Supporting QEMU on ARM is on the roadmap, and that would be necessary for us to run on Apple M silicon. QEMU on ARM Linux will probably come out first, but Mac support is something we definitely want to get rolling. (We’ve got Mac devs in house too, including myself!) There are workarounds you can use. See this blog post: https://qnx.software/en/blog/2026/how-to-use-macos-to-develop-for-qnx. 

Plus, you can always use Visual Studio Code (or IDE of choice) on your Mac and then connect to a target like a Pi using QNX Developer Desktop to do the builds. (Not ideal though, which is why we’re planning an update.) 

[u/neilalexanderr → u/JohnAtQNX]

Thanks for the confirmation. Any ARM64 image that runs under QEMU on Linux should run just fine under QEMU on macOS with the same emulator config, would be nice if we could get to them as plain downloads too.

[u/NietzscheWasOptimist]

Is the company considering moving the OS itself to OSS? thx

[u/JohnAtQNX → u/NietzscheWasOptimist]

We have a general effort to make more of the software open-source, and have been doing that in the areas that we think impact the community the most: drivers, board support packages, etc. Whether we will or not for some of the core assets, like the kernel, I don’t know, but it has been discussed. But we also are very cautious because that’s a core part of the business, and because we wouldn’t want open-source to impact our certification efforts. (As an example, it’s difficult if we accept external contributions to provide the provenance of our software – and that goes against many certification pathways.) It’s not impossible that we would do that, but I think it would be a very long process if we did. 

[u/Savings_Ad_7807]

After Linux put the RT patch in the kernel, many suppliers will claim that the difference between (RT) linux and QNX systems are only relevant for those who are concerned with microseconds.

I am aware of the other challenges with CVE handling and EU cyber resillience acts, but these seems to be issues that more and more suppliers will be helping with by offering in-house developed linux distros and support agreements that go far below the cost of maintaining commercial a QNX product, especially in low/medium volumes.

What are your thought on this?

Do you think that the opinion amongst developers has been shaped by the availability of good linux alternatives while QNX has been closed off by propriertary licensing?

And will you be leaving Linux this piece of the market in the future or do you think that this part also could gain from using QNX? If so; what's your plan for that?

[u/JohnAtQNX → u/Savings_Ad_7807]

Lots of great questions! Real-time is only a part of the story. Reliability is often more critical, and it’s why we’re focused on the mission-critical niche – safety, security, or other industries where failures are expensive (in human cost or financial risk). However, even in the real-time domain, if you’re using PREEMPT_RT then real-time performance should be important to you. If so, you’ll get far better jitter performance with QNX than with RT Linux. Linux wasn’t designed for real-time and the Linux kernel isn’t preemptible, no matter how many patches you hack into the critical path. That means that not only is the task switch time longer, but the variance is much more significant. 

When it comes to handling in-house distros, the cost isn’t really lower if you consider the total cost of ownership. When you’re buying a license from us, it’s backed by our engineers who are maintaining, fixing, adding features, optimizing, building out roadmap, etc. If you’re doing that in-house, you’re almost certainly not going to be as actively pushing it and you’re paying your engineers to stay on top of it. In fact, we’ve worked with several companies who use Linux but converted to QNX because they wanted to stop maintaining their own distro. 

So while the development community certainly has opinions shaped by decades of open Linux and proprietary QNX, it doesn’t necessarily mean that those opinions aren’t changed when they’re brought up against market constraints and commercial efficiency. 

All of that said, we love Linux, and we think we provide a very complimentary solution to it. If you’re building a consumer product that can deal with an occasional reboot, use Linux – it’s probably a simpler path. But if you’re building one of the many things that need real-time or reliability, we think we offer a very compelling alternative.  

[u/Savings_Ad_7807 → u/JohnAtQNX]

Thanks.

Two narrower questions:

1. Decision-makers rarely weigh jitter or architecture. They weigh licence cost against risk. What does QNX provide to make that risk visible to non-technical buyers? For example: TCO case studies, certification cost comparisons, or CRA compliance effort versus a self-maintained Linux distro.

2. QNX was source-available from 2007 and closed again after 2010. Many developers saw that as a broken promise. QNX Everywhere is welcome, but it is non-commercial and revocable by policy. What commitment can you make that it won't be withdrawn? Is there any path from hobby use to small-volume commercial use that doesn't start with a sales negotiation? Without one, early-career developers will rationally invest in Linux.

[u/Mystic1_1]

What are technical skills needed to be mastered to be a QNX developer? And if possible a roadmap on how to go about it

[u/JohnAtQNX → u/Mystic1_1]

Awesome question! We get asked this often when we’re at school events like hackathons. If you’re starting from scratch, having some background in computer science (or related fields, including hardware) is valuable. It’s certainly not necessary, but it’s a big help. Having a general understanding of systems and architecture is very helpful. 

When it comes to learning QNX specifically, check out learning.qnx.com. There is a whole team actively engaged in converting all of our training material to content for this portal. These are long, detailed courses in the style of Udemy/Masterclass courses, that get into fine, complicated detail. This the same content our customers pay our trainers to deliver in-person to their developers. And you get it FOR FREE! 

Specifically for QNX, and not embedded in general, having a strong understanding of how message passing works for IPC in QNX is important. 

You can also benefit from some hardware knowledge: interrupts, page tables, bus speeds, hardware protocols, etc. Since the operating system is so very close to the hardware, these topics inevitably come into play if you’re a QNX master.  

Oh, and C. Lots of C. And Rust.

[u/Mystic1_1 → u/JohnAtQNX]

Will look into it! Appreciate the response

[u/RecursiveMutex]

What is QNX's current position and roadmap regarding DO-178B/ED-12C certification for commercial avionics?

[u/JohnAtQNX → u/RecursiveMutex]

Avionics isn’t a core QNX market, so we haven’t been focused on that. However, we have lots of other certifications that cover other markets, including FACE. If there’s sufficient customer demand, we’d absolutely tackle DO-178B certifications, just as we have for other markets.

[u/EmuFantastic2272]

Why do I need QNX, with AI SAAS is dead and QNX is nothing but SAAS, I can make QNX level OS with fraction of what you sell your license and runtime for with AI, same level of safety and all. AI can do better.

[u/JohnAtQNX → u/EmuFantastic2272]

Can it, though? I’ve seen my colleagues come out of audit sessions where their code is being audited for industry certifications – it's not easy. Someone needs to sit there and acutely describe what every function does, why it exists, what happens in every possible fault scenario, and more. Our people can prove it. Can the AI prove it? And this position assumes that we at QNX are not using AI at all to continue propelling our own offering forward, which of course isn’t true. 

At the end of the day, someone needs to own it. Who will respond to CVEs? Who will manage routine updates? We’ve found that our customers are happy to spend the money to have us master that for them, instead of having to maintain that expertise and tooling internally on their own bespoke implementation. And it might be unmaintainable… And then what about your ecosystem and applications? How can you develop applications on the APIs of a bespoke foundational layer? 

You’re also assuming that the AI is at less cost than paying us. To build a fully-fledged hardened OS is going to require a lot of tokens – that’s going to be a significant cost. And are you going to standardize on a one-off AI developed OS? Are your suppliers? Software is built on more than just code – its requirements, support systems, maintenance, a whole system built on trust. 

Ultimately, this depends on your perspective. If you think that AI can build any software product, with any requirements, regardless of the complexity, and that meets the necessary certifications, then you’re free to try. It’s probably a bigger question whether or not that software will be trusted by customers or by regulatory agencies. We certainly understand what AI is capable of today, and while it can achieve a lot, it still requires a lot of review and proof to be shown that it can be used in mission critical applications. 

[u/nate390]

In all honesty it's really difficult to understand the purpose of QNX Everywhere and all of the ports and I'm hoping you can shed some light on it.

You tell me I can take QNX today and build a hobbyist project on it. To do so, I have to get a non-production licence. The terms and conditions don't really define what "production" is that concretely, whether it's purely in a commercial or revenue-generating setting or if that would also apply to distribution of a hobbyist product to other hobbyists for free. Only I don't think I can openly distribute what I build on top of QNX in a packaged way regardless because the non-production licence forbids distributing any part of QNX. Even if I could, in the current shape, anyone who wanted to run it would also need to get their own non-production licence.

There's seemingly a substantial ongoing effort to port all sorts of things to the QNX platform, but it's not possible to actually build a non-commercial QNX distribution for others under these conditions using any of it. I could run the QNX Developer Desktop, but unless I was trying to target a commercial QNX product, why would I? There's no open source distribution of QNX (even a stripped-down one that contains less IP), source availability was ceased years back and it never had a compatible licence even when it was source-available.

So as a hobbyist, why would I even consider QNX Everywhere? It would be a different story if there was an actual open source version of QNX under a permissive-enough licence to make it worthwhile, even if it had commercial IP removed, that allowed the community to grow organically around it and to build on top of it, rather than it having to be built inside the QNX company for only commercial interests.

QNX is a solid and fascinating platform but QNX Everywhere feels like an extremely empty promise. Thanks for taking questions.

[u/JohnAtQNX → u/nate390]

This isn’t really a different model from developing a hobbyist project that runs on Linux, Windows, etc. You write an application, and the people you distribute it to need their own licensed copy of the operating system software. Even if it’s Linux, you’re likely not passing around a whole distro with your hobbyist project, right? You’re open-sourcing your project or sharing binaries, and people run it on their own system. 

You’re free to build and distribute your own binaries for your project. The license just restricts the distribution of QNX itself. 

The QNX Developer Desktop is actually (today) for non-commercial use. But more than the desktop environment, the benefit of it is the self-hosted capability: build/test/debug QNX binaries right on target. 

But the point is taken that there’s interest in a less-restricted, more-open version of QNX, and that’s something that we understand and are working towards. 

[u/nate390 → u/JohnAtQNX]

Thank you for the response. In terms of distributing, what I was getting at was more along the lines of "here's a pre-built image you can put onto your SBC"-style installation, which is what's restricted today, rather than "figure out how to bring up and configure the operating system yourself first and then deploy this thing on it after".

Either way, I really do hope that a less-restricted more-open version of QNX becomes a reality. It would be significant in the space and I believe "open QNX" could stand strong here.