Hacker News Reader

The final fate of self-hosted QNX was super unfortunate, and poor decision making on the part of RIM/Blackberry. QNX completely dropped support for self-hosted QNX Neutrino development after 6.5 [0], and stopped distributing installation media ISOs with 6.6/7.0. Instead you needed to develop everything on macOS/Windows/Linux hosts, make custom specialized images using their published BSPs (Build Support Packages).

So no neutrino hosted compiler toolchain, no desktop. Oh yeah, they also completely killed off their full GUI desktop, the Photon microGUI in QNX 6.6. There was even a working port of Mozilla Firefox to it at some point. You could use all this freely with a hobbyist/non-commercial license in the early 2000s.

[0] http://www.qnx.com/developers/docs/7.0.0/index.html#com.qnx....

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.

> dropping self-hosted support was a very sensible move. They probably didn't want to spend resources on PC hardware support, particularly for laptops.

Self-hosting support doesn’t require PC hardware support. You totally can run your toolchain in a VM (every developer using WSL on Windows is doing it). In the past, I’ve put development environments in Docker containers - it makes it easier for people to get started, and on Windows or macOS that’s a VM too.

Making a system self-hosting is exposing it to a broader range of use cases which can help shake out bugs, limitations and performance issues which other use cases don’t. Even if you don’t strictly need it, I still think it is a good idea to maintain that support (even use it in your CI) unless doing so becomes unjustifiably expensive.

I was using it at that time as my main desktop OS. I ported and wrote several tools of it. The gui itself was simple, nice to use and to program for.

Driver support wasn't extensive, but the available drivers were working fine. With qnxstart.com at the time and all the oss tooling I didn't have anything missing.

I was in love in a way that only beos gave me before.

This was the last commercial/closed-source OS I ever used in no small part due to the license change.

1- 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

2- What tech stack (language) you used for those challenges?

3- Your idea on Lisp (for these applications)?

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 ...)

Sounds like Erlang !

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/

>People usually run another OS, usually a stripped-down Linux, on top of L4.

Look into Genode.

> 3. No.

Why? No hope for real RT? (Or otherwise more generally due to the GC?)

>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.

How about WindRiver Linux? https://www.windriver.com/products/linux

Excluded, because it's Linux, with all its issues.

Huge TCB being the main one.

tcb... thread control block, aka task_struct?

Trusted Computing Base.

i.e. The code that needs to be trusted. For Linux, it includes the whole kernel, and it is huge.

i see, thanks for the clarification!

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.

QNX is NVidia's deployment target OS with DRIVE OS for critical systems, with Linux used for development.

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

It's good, but ... there's "fully preemptable" and there's "fully preemptable". QNX is one of those, RT_PREEMPT kernels are the other.

I just remembered that I've been running my desktop machine with `preempt=full` for a while now. I wonder why it's not the default for consumer distros yet.

RT_PREEMT has nothing to do with "real" realtime. You never know WHEN the preemtion is gonna happen. Might be in 20ms, might be in 200.

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

this demo cd is my benchmark of how a computer is supposed to feel like. if UI interactions are in any way slower than what this provides (on, say, 2008-era hardware), it's basically poop

It is a shame yes. There is no current desktop RTOS at all afaik.

I know an RTOS does not guarantee smooth desktop performance but I just would love to try it out to compare.

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.

Lots of unixes have real time scheduling classes (Linux too), comes with the POSIX RT APIs. Is there information somewhere about the real-timeness performance of Plan 9 that could be compared with current general purpose operating systems?

Interesting. Is that a desktop OS though? I'll have a play with it soon. Thanks for the heads-up.

It is a distributed OS that can run as a standalone workstation or desktop/laptop. Although it looks like Unix, it is not (same creators though).

Linux with a kernel built with RT_PREEMPT ?

"Folks, we're just waiting on word back from the tower while our instrument panel blocks to render a thumbnail of the airport. We should be touching down in 30 to INT_MAX minutes or so. In the meantime if you want to sit back and watch a movie on your entertainment panel we ask that you refrain from apt installing the non-free Nvidia drivers which can sometimes cause our landing gear to stick..."

"Folks, we're going to go ahead and uninstall Gnome and see if we can't get on the ground a little earlier. Should be anywhere from 30 to INT_MAX minutes. In the meantime a flight attendant will be coming around with wired keyboards if you'd like to play a free game of Snake on your Entertainment terminals..."

"ok let's run this terminal snake game they are talking about...aaaannd

  libc.so.6: version `GLIBC_2.28' not found (required by /usr/bin/snek)"

funny, but really far from on point.

Indeed. I've seen Preempt RT patched Linux control space ships.

And the space shuttle (via dSpace)

Is the latest version of the open source code available online?

edit: poking around https://archive.org/details/software?query=qnx

> As I once told one of their sales execs, "quit worrying about people pirating your system and worry about people ignoring it".

That's a very frequent comment about tech companies with underperforming sales.

This is how ARM leapfrogged MIPS around 2010. Their licensing was basicaly "you are buying a USB stick". MIPS on other hand was "pre-pay us $100k just to have our attorney to take a look on if we can sell to you"

In those "deep" tech companies, it's absolutely not unusual to have sales staffed by people with zero background knowledge, but nevertheless star sales professionals.