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.

"Real time" is only good if you need guaranteed responsiveness within certain time limits. It can actually be suboptimal and slow you down if you don't need it and want to optimize other things like throughput.

Though in practice, the act of designing your code for realtime tends to produce better performance than the status quo of doing nothing. Most uses of this warning seem intended to promote the latter rather than to get people thinking about their actual requirements.

Who needs throughput? Server software, but Linux is already dominant there and everyone's happy. For everything else, including desktop and mobile operating systems realtime sounds like a good idea.

That's waaaay too broad a grouping. You're thinking of PC's, basically, in one form or another (or their modern replacement, mobile devices).

Industrial automation and hard real-time embedded devices like those that control surfaces in Fly-By-Wire systems are out there and with those it's not a matter of "throughput" but a matter of timeliness.

I did a major project with QNX about a decade ago where the maximum allowed latency between any device on the (fiber-optic) network being asked a question by the master controller and the reply - then the processing of the reply - was less than 1 millisecond, full stop.

Come in late and most of the time the sky doesn't fall in. But on the occasions that it does, you potentially have a 4 meter wide ribbon of red-hot steel flying out of the stands at 50mph. Or you blow one of the transistors that controls the 10-20 megawatt DC motors in each stand. (These "transistors" were boxes about 7' tall, filled with oil, and cost northwards of $200k).

Sometimes it just doesn't pay to be late.

What a terrifying and cool project!

Can you say what kind of shop / machine it was for?

It was a hot-strip mill; this video shows the general gist of it: <https://www.youtube.com/watch?v=13dUL9OQFvw&t=15s> (tho the ones I worked with were all made by GE).

Absolutely deterministic latency isn't a requirement for the desktop like it is for industrial control.

If 99% of the time performance is faster, and the remaining 1% of the time isn't that bad, most people will take the trade of higher average performance. If it's running the antilock braking in your car, that's pretty bad.

> For everything else, including desktop and mobile operating systems realtime sounds like a good idea.

Why on earth would you need real time on desktop? Every time the topic is discussed on internet bunch of confused people chime in with this sentiment that doesn't make much sense. "RTOS" is not some magic that somehow makes everything on your desktop fast. All it would do in reality is make everything slower for 99% of your interaction but guarantee that "slowness" is uniform and you don't have any weird latency spikes in other 1%. Note that for cases that are not "nuclear reactor control system that requires Very Certified OS with audited and provable reaction times" RTLinux is already available, but distros are not inclined to leverage it on desktop for reason described above.

I've read many opinions of those who used QNX on desktop in the past, that it felt much more "snappy" compared to other systems.

Desktop definitely has real time tasks. Any animation is real time task. When I'm listening to music, it's real time task. macOS sound interrupts for a short time, when something hardware-related happens, so it's not pleasant experience. You might argue that user can tolerate those interruptions, but for me those are just bugs.

Indeed. There are people who have a fair point that desktops for users (as opposed to servers) should have a focus on being responsive and useful. Like how writing on a piece of paper produces meaningful markings in real time, user interfaces should be able to perform tasks with analogous interactivity. See comments about BeOS elsewhere in this thread. I don't know about the extreme, but the overall sentiment is valuable.

When recording live audio performances, some guarantees that the thread that records the signal will always get some attention for the scheduler, would be nice. Otherwise the recording program will miss on the signal, and the recording will have cracks.

We sidestep this problem because our CPUs are insanely fast for this task, so as long as you don't game, compile and record audio at the same time, you should be fine. But we don't have any guarantees.

> Who needs throughput? Server software, but Linux is already dominant there and everyone's happy. For everything else, including desktop and mobile operating systems realtime sounds like a good idea.

No, not at all. The actual question is who needs realtime.

Desktop is a typical place where you absolutely don't need realtime. You just want latency to be under the user perception threshold but that's easily achievable with a standard kernel. Plus the consequence of failing is basically nil. Why bother with the complexity introduced by a RT kernel?

The latency in modern desktop is not a consequence of unpredictable scheduling. It's just poorly optimised applications. A RT kernel is not a magical solution to that.

> Desktop is a typical place where you absolutely don't need realtime.

On a desktop, you want at least soft real-time when playing any sort of multimedia (audio, video, or interactive applications like video games). Otherwise, you get things like glitched audio or dropped frames.

Yes, I agree especially for audio which is a typical exemple of a latency sensitive application (video games are generally purposefully design to be as latency insensitive as possible and will drop frames with no impact on actual gameplay). But a performent application and proper scheduler priorities will bring you there without a RT kernel.

Desktop use at its lowest latency is typically 17ms and up to 33ms when using a 60Hz screen with one frame in the buffer and whether you have to wait for the one after that. But most operating systems and games default to more than one buffered frame. Still, even that lowest case scenario is a pretty big budget of time. The microsecond precision of a RTOS is not necessary then. If you want to increase responsiveness or reduce latency for interactive use of desktops or phones there are different avenues to approach to shave off milliseconds at a time.

> Somebody really should write a microkernel like this in Rust.

I wonder how far Redox's microkernel design is from what that comment describes.

A friend of mine is working on this OS:

https://gitlab.com/uxrt

I see this was submitted to HN a couple times over the last few years and has not received any comments. Can you describe the goals and status of this project? Does it fit into any larger ecosystem? Is it a research project or intended for eventual mainstream adoption?

I'll start by saying that micro-kernel OS development is a bit beyond my skill set but I can tell you that the goal is more or less to make an open source QNX with features from Plan 9 that is suitable for desktop use and higher level embedded platforms.

I'm not sure what you mean by larger ecosystem but a compatibility layer with Linux binaries is on the feature list. You can read the extremely detailed architecture notes document here[0]

It is absolutely intended for mainstream adoption and the project has recently received interest and funding from a very large OEM. I don't want to say who it is because I am not certain if they want it publicized yet. It's probably okay for me to say but I'm erring on the side of caution.

If you or anyone you know is interested in contributing to the project let me know or reach out to Andrew Warkentin on gitlab.[1]

[0] https://gitlab.com/uxrt/uxrt-toplevel/-/blob/master/architec... [1] https://gitlab.com/andreww591

Basically I'm trying to write a better Linux than Linux and a better QNX than QNX, at least for certain use cases that is. At least initially, my primary focus is on workstation/enthusiast desktops and higher-end embedded systems (some types of servers, especially ones where high security is important, are also a focus as well but maybe not quite as much for now). Pure consumer desktops aren't really much of a priority; the goal is to make something that's approachable but definitely not dumbed down. Almost every day I see people complaining about mainstream OSes and I think there's an opportunity for an OS that's cleaner and more integrated than Linux and has various advanced features not found in Linux, but still tries to maintain a high degree of compatibility with it. I'm not really trying to clone QNX or Linux 1:1, but I am trying to maintain similar enough semantics to allow easy implementation of compatibility layers for both systems.

At the moment I have a working microkernel and an incomplete process server with a partially-implemented VFS but no support for running regular user processes. Currently I am working on some of the first special filesystems built into the process server (specifically an early log/console device at the moment).

The kernel is a hard fork of seL4 (the biggest addition at the moment is a preliminary implementation of QNX-style arbitrary-length arbitrary-address message copying); I've forked it because seL4 is focused on lower-end static embedded systems, and full verification of just the kernel isn't really particularly useful for a dynamic OS when all of the servers are unverified. The process server is written in Rust, and it's likely most of the other low-level servers will be as well, although I'm not really writing a "Rust OS" as such. Many of the basic utilities will most likely be BSD-derived, and some of the higher-level desktop-related stuff may be written in various other languages (haven't completely decided there).

Interesting, but sounds like much more than a lifetime achievement. As far as I understand, it is written in Rust; this raises the question of whether there are significant differences to Redox OS, which seems to share most of the goals. But sel4 on the other hand is written in C; are you going to migrate sel4 to Rust?

Like I said, it's not meant to be a "Rust OS" and will incorporate a lot of C code still (and various other languages as well). I doubt that the kernel will ever get completely rewritten in Rust, although eventually some Rust code might get added (once I break up the giant kernel lock I am thinking I'll use the same locking library I'm using in the process server, so that would add some Rust code to the kernel). I don't see a lot of point to rewriting the kernel since it's probably not going to see lots of new code being added all the time and is generally pretty limited as to what it includes (I'm not quite as reluctant to add stuff to the kernel as the seL4 developers are, but I still am going to try avoiding it unless there's no other good way to do something).

Redox has several of what I consider to be questionable design/implementation decisions. I explained a couple of them in a previous comment (the limited filesystem namespace and IPC models and the lack of real-time support). Some other things include the weak implementation of locking (it uses pure spinlocks instead of something like the adaptive queue-based locking that I'm using in the process server), a rather limited heap allocator that doesn't support growing/shrinking the heap or custom object sizes for slabs (the heap allocator I'm using is a derivative of the same one that Redox uses but it's been heavily enhanced with support for shrinking/growing the heap and custom slab sizes), and the rather boilerplatey implementation of some of the libraries (for example fork() is implemented as a library function that copies process context through a filesystem-based API, but rather than having object-oriented wrappers on top of the filesystem for the various state objects that it's manipulating, the fork() implementation directly invokes open(), read(), and write() a lot).

That's interesting, thanks for the explanations. Which of the many OS text books do you think covers the topics you are confronted with in this projectk best (especially how to implement an efficient microkernel and integrated ipc)?

Redox's IPC is a fair bit weaker of a design than that of QNX or my seL4-derived kernel. It works sort of like that of QNX in that it has direct copying of messages between address spaces and RPC-like semantics with direct context switch from sender to receiver and back, but it is more limited and implemented in a slower way. Also, there seems to be no consideration for real-time performance at all.

Outside the core IPC model, the namespace model is also more limited than that of QNX; QNX allows multiple servers of a given type mounted anywhere within a namespace, whereas Redox's scheme-based namespace model only allows a single server of a given type per namespace, mounted on a fixed top-level prefix.

I think elaborate IPC designs are too much trouble, and I favor seL4's "context switch with benefits" approach of delegating larger messages to shared memory. It avoids performance and security hiccups with copying or kernel-mediated shared memory, like in EROS. To be fair, I'm less focused on efficiency and more on simplicity/robustness of the kernel, similar to seL4. Could you elaborate on your thoughts in the IPC space?

Thank you for adding that link. What I find particularly remarkable is that the author of that comment is John Nagle himself (of Nagle’s Algorithm fame https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm).