Comment by Animats

As a casual outside observer, it seems to me that dropping self-hosted support was a very sensible move. They probably didn't want to spend resources on PC hardware support, particularly for laptops. And of course, a developer's PC doesn't just run development tools; it also has to handle things like connecting to VPNs and being manageable by company IT departments. Some people need accessibility accommodations (e.g. screen readers, magnifiers, or alternative input methods), and there's no reason to assume that this group doesn't (or couldn't) include some developers of niche embedded systems. The list goes on and on. Even desktop Linux doesn't do a great job on all these things, never mind a niche OS like QNX. So doing cross-development from Windows or macOS makes a lot of sense.

Edit to add: Just had a scary thought. What if Red Hat and whoever else is actually spending money on desktop Linux development applied the same logic to desktop Linux itself that I retroactively applied to self-hosted QNX? After all, non-developers don't use Linux, right? (I'm speculating that they'd make that assumption, not saying it's actually true.) And developers can work with Linux by connecting to a remote machine or running a VM on a "normal" (i.e. Windows or Mac) computer. Is there enough economic incentive to keep maintaining and improving desktop Linux that this won't happen? The death of desktop Linux wouldn't actually hurt me, as I mainly use Windows, but I'd still be sad.

QNX was a true microkernel architecture that worked, and worked well. The basic building block was called IIRC Send/Receive/Reply: Every "system" call looked like a regular function call, but would "Send" a message to a different process, and (usually) suspend the caller; The other process would "Receive", do whatever was requested, and "Reply", at which point control went back (with the response) to the calling process. IIRC it was also possibly to do async calls, but in that case the other process would call ("Send") the response back, rather than "Reply". I might be confusing this with another system though.

device drivers weren't privileged - they were just another process you called into, and could be restarted in the case of a fault (rather than kernel panic or blue screen).

A system that doesn't provide this is not an alternative to QNX; It's just another operating system (which are all, in some ways, alternative to each other and thus QNX, but ...)

1. Nothing. Someone was writing a QNX-type kernel in Rust. What happened to that? There's L4, but it's too low-level. It's more of a hypervisor. People usually run another OS, usually a stripped-down Linux, on top of L4. QNX offers a POSIX API, so you can run applications directly.

2. C++. Here's the source code. [1]

3. No.

[1] https://github.com/John-Nagle/Overbot/

>What's the FOSS alternative that is as good as QNX nowadays? FreeRTOS, NuttX, Zephyr etc are used for MCUs not general purpose computation AFAIK

SeL4 with CAmkES, or Genode.

In automotive infotainment systems, where QNX was used a lot in the past, it mostly had been replaced with combinations of Linux or Android on the non-realtime critical systems, and smaller microcontrollers which run realtime OS (OSEK and autosar derivates). The latter are usually not open source.

Dunno if it’s an alternative but Linux had RT_PREEMPT and you can build a kernel that’s fully preemptable.

Minix 3 is closest to "as good as" minus the realtime support.

FWIW, Windows is not a true RTOS, but it does get pretty darn close.

The true hallmarks of an RTOS kernel is hard-realtime scheduling usually with round-robin priorities, and support for priority inversion, which is when a low priority process blocks a high priority one, it inherits the high priority temporarily to meet the deadline.

Windows is threads have a priority, with the highest priority thread occupying the CPU - however there's a series of 'hacks' that allow it to emulate real time behavior.

Threads can get a priority boost in some cases, such as the aforementioned priority inversion case, when the user interacts with the program associated with the thread, when the thread hasn't run for a long time etc.

Additionally there's a set of 'real-time' priorities that can preempt all non-realtime priorities and you need admin or kernel access to set this prio level, as these threads will lock up your system because they can't be preempted.

While I wouldn't trust Windows to control an ICBM, but it's good enough at giving resources to user processes so the your UI feels responsive.

> There is no current desktop RTOS at all afaik.

Plan 9 has deadline scheduling out-of-the-box for real-time. It runs on x86-64, 386, Arm v7 and AArch64 (And more): http://doc.cat-v.org/plan_9/real_time/ (mostly obsolete but describes the motivation and implementation)

See proc(3) man page for deadline scheduling (towards the bottom real-time i described): http://man.9front.org/3/proc (I always recommend the actively maintained 9front fork)

The best part is you don't need special patches or libraries. You simply configure the process/group by writing messages to the procs ctl file using the command line, a script, or from within your program.

Linux with a kernel built with RT_PREEMPT ?