Hacker News Reader

Comment by gosub100 | Hacker News Reader

You would use it if you wanted to get a job doing RTOS dev and wanted to show you had some skin in the game.

Maybe you would have used QNX as an engineer flex in 2012, but as an embedded firmware dev myself, I'd laugh if someone suggested we use QNX for anything. Besides the licensing issues... just why? It confers no imaginable benefit versus any one of dozens of alternatives. It's like if someone suggested I run Haiku on my work laptop.

ISO 26262 ASIL D safety certification, mature tooling and ecosystem, easy to hire experienced devs, “it worked for the last 5 projects”, etc.

There's a few vendors that sell FreeRTOS forks that have that cert. SAFERTOS is a very common one

> mature tooling and ecosystem

Amazon has been working on freertos for a long time

> easy to hire experienced devs

tbh if you've used one rtos, you've used them all. the learning curve is in the concepts, not the api. any good vendor will have engineering support that helps you where appropriate

> “it worked for the last 5 projects”

inertia only takes you so far

lmao "skin in the game". what a useless cliche.

that's such a lame excuse, and if for some stupid reason, i chose the rtos first, i would simply choose one of the many competitors that have positive mindshare and increasing install base. freertos, rt linux, hell even vxworks.

the simple fact is that rtos are more commodity than ever. if im going to start a project, im going to do it based on the requirements, find a soc and bsp that has excellent support for those requirements, and then follow up writing a task for whatever rtos it uses.

for example, im not using freertos because its "cute" and has a neat little floppy disk demo. im currently using amazon's freertos beceause that's what the espxx family supports. im using the esp32 because it has the power profile i need for my sensor project.

in today's market, it's absolutely asinine to choose the rtos first. i honestly have no idea what qnx is a first class citizen on anymore. I actually feel bad for anyone who's spent their whole career in QNX-land - that train might be coming to a stop and there's probably a lot of people who would rather not retrain.

actually, there's a nugget of wisdom in there for the qnx team: i should be able to buy a $20 board that runs qnx, and fits into the power, performance, and hardware profile of something like the esp32. integrate it heavily with platform.io. let me use qnx without having to specifically go and seek it out and hack on it a bunch.

any commercial rtos shop where QNX may be appropriate is either using 1. some wacky expensive proprietary rtos that you've never heard of, 2. freertos or 3. real-time linux depending on what they need. asking what makes QNX a compelling rtos when freertos exists, is widely supported and used, and has an MIT license is a very valid question.

further, no one in embedded actually cares what RTOS you used. they are all similar enough that you won't get stuck if it's a brand new RTOS

QNX is heavily used in industries where functional safety or particular high assurance models are required.

Sure FreeRTOS has a SafeRTOS mode, but its not sufficiently functional for a modern ADAS stack or complex robotics systems. QNX is used in all major automotive companies around the world for a reason, and a crucial part of NVIDIA's DriveOS stack.

QNX is in a space with few competitors. FreeRTOS or ThreadX are designed to provide microcontrollers with scheduling and memory management functionality. They don't depend on fancy things like MMUs or provide frameworks for networking or file systems out for the box. The flipside is that you can compile them down to maybe 30kB of machine code.

QNX is designed for more powerful and featureful hardware to drive a software stack with true process isolation and generally provide the bells and whistles of general purpose OS on top of a hard realtime core. It can run complex GUIs without sacrificing its real time capabilities. Not many competitors live in that particular space.

> and a crucial part of NVIDIA's DriveOS stack

fwiw they have been working hard to support linux as a second option, and have been major contributors to Real Time Linux

sooooooo

Are there any automakers out there that use real-time Linux for anything at or above ASIL-B?

I know there are a few hypervisor vendors that do heartbeats for C and D. You can use whatever solution you like as long as there's a fallback task.

> no one in embedded actually cares what RTOS you used. they are all similar enough that you won't get stuck if it's a brand new RTOS

Out of curiosity (as an outsider), how does the availability of device drivers factor in?

I assume they still need to be ported to each combination of OS and device.

I don't think that "skin in the game" means what you think it means.

I meant it as a job-seeker proving they spent time doing a sample project on a real OS, such as QNX, instead of studying leet-code trivia and thinking they're ready for a job. As an interviewer, I would always choose the one who has skin in the game.

Reply on news.ycombinator.com