Also I wonder how many applications really need more real time responsiveness than you can get out of Linux. We even have

https://arstechnica.com/gadgets/2024/09/real-time-linux-is-o...

If I use Linux I know I won't have to have a discussion about licensing, I know I won't get rug pulled, etc.

Also the ban on commercial use is heinous. I am going through this with Arangodb right now. I love the product, but I have no budget for a cloud instance they manage and I have no budget to talk with their sales people about a commercial license. I have several systems that use it (including one that's about 80% of a way to a "too big for free" database) and I don't know if their fate will be (a) open sourcing, (b) a product or (c) a system that makes money for me directly but for me the short path is to switch to postgres, not talk to people whose business model doesn't necessarily allow my business model.

rt linux is not appropriate for many hard realtime requirements

i have seen some try and fail in an effort to save $perceived_value

Is there a good libre real-time OS you would recommend over it?

RTEMS is one and there is also eCOS. RTEMS has flown in space a few times so it is proven.

Forgot to mention: the neat part of RTEMS is it allows one to sort of turn a Unix program into a bare metal program.

Why do RTEMS and eCOS trump, say, Linux? Linux on a RPi has also famously flown (really!) in space.

It's all very well asserting something but a bit more chat would be nice.

I'm not sure what "turn a Unix program into a bare metal program." means.

Say all your program does is read some sensors via gpio, save those readings in ram, do a bit of math on that state, then set some other gpio pins, and that's all the entire system does. when it turns on, it should jump right into doing that and nothing else.

It may be easier to write that on a full sized Linux system, but come time to deploy it, all that Linux code that isn't being used is a liability for bugs and unexpected behavior to crop up. One approach is to slim down Linux to avoid that (eg removing systemd, esp for systems that don't have enough ram to run it), but another approach would be to just use something less complicated than Linux. It would suck to get to space only to find that something had messed up permissions on the gpio pins again so your satellite didn't deploy and now you've wasted a launch. If there's no permissions system to mess up, that can't go wrong.

As far as bare metal, I presume it means to port a Unix program which has all sorts of assumptions about running on a Unix operating system, to an OS that's not one, with simplified models for a lot of things, and for the system to reliably run that program on boot and not do anything unecessary. Like run cups.

For some tasks you don't need even need an OS and that competes with QNX. For instance I do hobby experiments with persistence of vision displays on AVR-8 and assembly language on the bare metal is so simple but it is simple hardware and simple software, bigger jobs need something more.

As it has been already said, with RTEMS and other similar real-time operating systems it is easy to predict the worst case time for the handling of any event. This is absolutely necessary when controlling many kinds of hardware devices.

This is completely impossible with standard Linux. Real-time Linux might offer some guarantees, but I am pretty sure that they are rather soft.

Linux is already too big to be easy to understand and audit in order to be certain that you really know which will be the worst case.

With a simple OS like RTEMS, a competent programmer can become an expert in its internals in a month or so, and then it is easy to understand what exactly will happen in any circumstance.

I have used in the past some commercial real-time operating systems, like pSOS and VxWorks, but the free RTEMS has been much better than those, especially because being open-source it allows a much deeper customization than any proprietary solution.

chibios is great, but I haven't followed their culture or licensing in a few years now.

my experiences then would lead me to recommend it, though.

ChibiOS doesn't really compete in the same space as QNX. It's a single address space executive that's more like FreeRTOS than QNX.

I believe seL4 is formally verified.

Verified worst case execution time analysis. So instead of just hanging on it until it achieves the desired responsiveness (like QNX and rt Linux) Sel4 can actually back up its claim.

In that case, you’re just hanging on the specs, prover, compiler, and other dependencies. Things most developers can’t even begin to verify. That also assumes the hardware works which isn’t safe if talking about cosmic rays.

Empirical testing of “verified” software often found errors, too. High-assurance, security certification used to require formal methods, thorough testing of code, review of anrtifacts, and pen testing by independent team. We should do that today.

In this case, you’d do white box and black box testing of the WCETS of seL4.

Agree but I have seen more people wrongly think they need hard real time than people incorrectly picking their kernel.

I don’t doubt this but it’s worth noting that I believe spacex uses Linux as their RTOS.

SpaceX can afford that by their _very_ resilient design and accepting, even anticipating failure.

If your design is resilient to missing deadlines, you don't need a RTOS and the question becomes moot.

talk nerdy to me, which ones ?

RT Linux is not the only alternative. There are now plenty of options for achieving hard real-time performance without relying on proprietary RTOS solutions:

  Dedicated Real-Time Cores: Many SoCs include dedicated cores specifically for hard real-time tasks.
  Microcontroller Companions: Pairing a microcontroller running a lightweight RTOS with a larger, general-purpose processor as a supervisor (You can use normal Linux).
  FPGAs: Custom FPGA implementations can deliver deterministic timing where ultra-low latency or specialized processing is needed.

And ofc, RT Linux, that in my experience is suitable for over 80% of hard real-time applications (an estimation, based on experience as a former user—your mileage may vary).

Out of curiosity, to what extent can modern x86 / Arm systems support hard-realtime guarantees?

I'm wondering about things that could cause unexpected delays, like PCIe bus contention / error correction, high interrupt traffic, etc.

(I don't know much about this topic, so apologies if my question is ill-conceived.)

If by "modern" you mean a desktop/server CPU, the problem is the complexity that exists because of optimization for average throughput. Do you really know how long you will wait, worst-case, if three different cores flush the same cache line back to DRAM? Or maybe some niche hardware you use has some funky behaviour that stalls some hardware bus, or waits in the kernel for a millisecond, twice a month or whatever.

On the other hand, on FPGAs, deterministic timing is so very simple. Your output will not be a single clock cycle late even if something else goes wrong in logic running on the same FPGA (except through a connection that you control).

If you really want to know, OSADL has a QA Farm that monitors worst-case interrupt and scheduling latency for various CPUs and Linux versions.

Real time is about worst case time, not average.

The classic test for a real time OS is simple. You write a program that waits from an interrupt from an input pin. When the input is raised, there's an interrupt. That activates a user process. The user process turns on an output pin.

You hook this up to a signal generator and a scope. Feed in a square wave. See the delay between input and output. If there are outliers, delays much larger than the normal delay, the system is doing real time properly at all.

If it passes that test, run some other program at a lower priority than the one that's monitoring the input pin. The results should not change. The other program should reliably be preempted.

QNX could pass that test, at least when I last used it.

Note that this requirement conflicts with many modern CPU and OS features, such as sleep modes, power-saving under light load, and paging. Classically, you didn't care, because the control CPU used far less power than whatever large piece of equipment it was controlling. But for things that run on batteries, it's a problem.

Something that's given trouble: "system management mode". Some industrial computers used code running in system management mode to help out with some peripherals, such as making flash memory look like a hard drive. This time-stealing shows up in the interrupt latency test. QNX techs used to quietly have a blacklist of embedded computers to avoid.

> If there are outliers, delays much larger than the normal delay, the system is doing real time properly at all.

Just to clarify for anyone reading, I think you meant:

> If there are outliers, delays much larger than the normal delay, the system is not doing real time properly at all.

That has to be the correct reading.

> Now, if QNX is serious about this, the way to go is to use the licensing model Epic uses for Unreal Engine. Unreal Engine is behind most AAA game titles. The basic terms are that you can download the source and use it for anything you want, and there's no charge until you get the first $1 million in revenue from your product. Then Epic takes a 5% royalty.[2] This has been extremely successful for Epic. There's not much of a piracy problem, because if your game gets enough revenue to matter, it has enough visibility that their licensing people will notice. Meanwhile, there's a large pool of people using Unreal Engine.

One option: Dual-license as GPLv3 (the 3 is important!) or commercial license. Hobbyists and FOSS projects will be quite happy to use a GPLv3 OS. The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.

(IANAL, this is not legal advice, interpret licenses yourself.)

Even more critically, dual-license commercial and AGPLv3 to avoid the AWS loophole (hosted services or source modifications without licensing it commercial.)

AGPLv3 is perfect for kernel and userspace tools because, while it doesn't guarantee licensing revenues, as soon as they do anything to modify it they have to release those changes to ANY users of the system, whether downstream distributors or simply users of the network services they provide. Since they have to provide any IP/patents they used to do it under copyleft terms, QNX would get publicly visible benefits, albeit with changes that might not be useful under the commercial license without negotiating a CLA with the modifying party, but under the commercial license you could negotiate terms/a discount to trade their new code for a reduction in their cost of licensing. It's a win/win from either an open source PR or a behind the scenes commercial negotiation point. Obviously your lawyers, bean counters, and C-suite have to get onboard, but if you are serious about growing QNX's marketshare now that Linux is gaining real-time kernel support in mainline, you had better point out to your bosses they need to make the decision quick and stick to it, or there won't be a next time.

Edit: Adjustments made to clarify my position and suggestion.

My honest opinion is that the prevalence of licenses like GPLv3 and AGPLv3 end up indirectly leading to people recreating the wheel, rather than using the wheel that exists already.

Working as intended. If they don't want to share, then they can't benefit.

It's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that.

It applies to both sides of the argument, with organizations keeping things to themselves or others avoiding codebases for the inverse reason.

> It's not so much that as there is the net-negative side effect of having people redo the same work over and over again at their day job or whatever. It horrifies me when I think about the number of hours of people's lives wasted on things like that.

Given that this issue applies to all proprietary/non-opensource software, which is the overwhelming majority of software out there, you can hardly blame GPL3 for this fact of life.

But who cares if someone chooses to redo work they didn't have to? I don't care about that at all. Self inflicted wound.

They presumably can salve that horrible wound with all the money they get (not make or earn, just get) from their chosen modus operundi.

I would argue that in many ways (that vary from project to project) the duplicated efforts are a good thing overall. Now, instead of having one single group or person working on a particular topic, there are many and the knowledge, learning, experience, and expertise that comes from that isn't locked up with only a select few. That can be applied in more areas, used for more things, or carried into other endeavors. It also hedges against all that expertise being lost if the few experts of the original project abandon it for whatever reason.

I don't see all the efforts that go into *BSD, Windows, macOS, etc... as being wasted just because Linux is available, nor would I consider the effort to try something completely new in os/kernel design that starts from a clean slate a waste, even if it doesn't end up becoming wildly popular. Not everyone who has the capacity to work on a duplicate effort would be able to contribute to the original, and the original will never be able to perfectly meet the goals/needs of everyone.

Absolutely. LLVM exists because GCC is GPL; that's a feature not a bug.

LLVM exists because its original developers wanted to do research, not because of GPL and at the time there wasn't even a C compiler for it, not to mention that GCC wasn't designed at all to do what LLVM did.

The license angle with Apple did happen because of GCC's switch to GPLv3 but that came years later - and GCC still wasn't (and AFAIK still isn't) designed to be used like LLVM or (later) Clang, like using it as a backend for IDEs, analyzers, language servers, etc. The two projects aren't interchangeable with only the license being the thing that differentiates them.

They could have very well used lots or reusable parts of GCC. It was possible, and were many projects trying to change GCC.

gcc was specifically designed to not have many reusable parts to avoid people ripping them out. modularity only happened after LLVM and clang specifically started eating its lunch.

> LLVM and clang specifically started eating its lunch

I don't know how you can eat GCC's lunch. I feel like in this analogy GCC eats from a communal trough and is very happy to share. A company that sells licenses can lose customers, the GNU project just wants the world to benefit. GCC is still ubiquitous and has plenty of developers and mindshare, what more could they want?

Basically most of the embedded folks that used GCC forks are now on clang, and if in the old days they were breaching GPL, nowadays they are fully compilant, so not upstreaming is not even a legal issue any longer.

Fair enough. I guess you're talking about microcontrollers rather than lightweight CPUs, at least in my experience it's still standard to use GCC on the sort of dinky ARM-based devices my company produces.

I'll note that GPL never says anything about upstreaming. It can certainly make life easier if you want to keep your patches up to date and hand off maintenance responsibility, but it suffices to make a written offer of source code under the same license (on a conventional medium) to your customers to comply with any GPL version. You're never obliged to upstream or even publish your code.

Sure, but they didn't even do that most of the time, with MIT that isn't even part of the conversation.

Most certainly not. The modularity was not great, but BIG chunks of code could be copied. I did that myself.

I don't even understand how you can point to LLVM as an example of this failing. GCC is still alive and well, and perfectly suited for the task it was always intended to fill. People that wanted a commercial C compiler always had the option to purchase one at-cost, GCC was intended as an alternative to that process, not the alternative. It may be hard to remember, but less than 50 years ago squabbles over compiler licensing was what most developers had to deal with.

Respectively, LLVM fills it's own gap nicely. It has the classical BSD-like issue where hundreds of unique and disperate forks exist with no roadmap to bring them together, but that's also technically a "feature" of each license and not a bug. If GCC developers felt their job was obsoleted by Lattner, there wouldn't be a reason to update and maintain it. The end result has been healthy competition, accountability for either team, and better optimizations for everyone using either compiler.

Also after LLVM came to be, GCC gained on its official collection Go, D, and Modula-2 frontends.

And, hopefully, Rust soon as well[1][2][3].

[1] https://rust-gcc.github.io/

[2] https://github.com/Rust-GCC/gccrs

[3] https://blog.rust-lang.org/2024/11/07/gccrs-an-alternative-c...

I think wheel-reinvention is the perfect punishment for people that want to be stingy with their wheel development. Copyleft infringement deserves no more empathy than copyright infringement.

> AGPLv3 is perfect for kernel and userspace tools because, while it doesn't guarantee licensing revenues, as soon as they do anything to modify it they have to release those changes to ANY users of the system, whether downstream distributors or simply users of the network services they provide.

This is actually fairly ambiguous in the text. It says "if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version". This is fairly straightforward when applied to a database—if you modify an AGPL database and offer it as a hosted version then your users are obviously interacting with it over the network—but much less straightforward when talking about an AGPL program that doesn't intentionally build in network connectivity.

The GPL FAQ addresses this provision [0] and it seems to support a more conservative reading. My understanding from the FAQ is that a Program that is not "expressly designed to accept user requests and send responses over a network" derives no benefit from being AGPL vs GPL, even if a web app interacts with that AGPL code over IPC or similar.

[0] https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...

Yep, I think the agplv3 behaves like the gplv3 for programs that are not network services.

With the twist that if your non networked, agplv3 program happens to contain code that's interesting to build a network service, this code can only be used under the agplv3 :-)

> this code can only be used under the agplv3 :-)

This code can only be used to make a derived work under the AGPLv3. What constitutes a derived work is still... complicated.

I wouldn't risk this in a production setting for a real business just out of caution, but my reading of the license would suggest that you'd be perfectly fine to wrap AGPLv3 code in a web service and then have your own code interact with that web service. Release the wrapper service as AGPL, but then the rest can be proprietary.

The main protection that AGPL gives isn't legal, it's that you scare most legal departments away just because it's such a weird license with no established precedent.

> I wouldn't risk this

This seems like a technical workaround for a legal requirement. Indeed, that seems risky xD

> The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.

Yes. And it is even more than that.

Blackberry could have a general QNX verison under AGPLv3 and keep the "safety certified" version proprietary and they would not loose a single customer.

What the automotive world, robotic world and others are paying for... is not the Operating System, it is the safety critical certification of the Operating System.

Making an RTOS is easy. Making an RTOS plus a compiler ISO26262 ASIL-D certified is a freaking nightmare. This is precisely what companies are willing to pay for.

Opening the QNX source code under GPL would widen significantly the number of software ported on QNX and the adoption.

Unfortunately, Blackberry is way too stupid to do it and it is unlikely to happen.

> One option: Dual-license as GPLv3 (the 3 is important!) or commercial license. Hobbyists and FOSS projects will be quite happy to use a GPLv3 OS. The big commercial users - traditionally cars and other embedded uses - will not want to be legally obligated to give users the ability to install custom firmware (which GPLv3 basically requires), so they'll still pay for it. Everyone wins.

GPLv3's protection against locked systems isn't as strong as people often think it is.

In the case of cars at some point the makers are going to realize that instead of including firmware with all the features the car can support they can switch to shipping the car with a more basic firmware that just has built in support for basic car features and has an app store.

They can then put all the other features in apps that you have to buy (or subscribe to).

If that basic firmware is locked down so it can't be replaced by the user then they do indeed after avoid using GPLv3 for any code in that firmware.

The GPLv3 provisions about locking thing down do not apply to apps downloaded from an app store. They designed those previsions to stop what Tivo was doing, which was ship with a locked down operating system, and they wrote fairly narrow terms that don't cover much outside that case.

In particular, they apply when you convey object code of a GPLv3 work in, with, or specifically for use in a "User Product" and that conveyance is part of a transaction "in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term".

I.e., sell (or rent or lease etc) hardware that includes GPLv3 code and you have to provide a way to replace that code with modified versions. Sell (or rent etc) GPLv3 programs separately from hardware and then GPLv3 is neutral on locking it down.

Even better, GPLv1+TiVO clause AND commercial (i.e. you don't choose, but both terms simultaneously apply).

Shitty dx is baked into RIM/Blackberry's institutional DNA.

I had a long conversation with their engineering people way back before BB10 came out. At the time you had to apply to get access to the full blackberry SDK, and IIRC you also had to sign an NDA. Meanwhile Android and iOS were in full swing and wouldn't you know it, the platforms that had better developer experience, that prioritized making it easy to write apps, were successful.

Blackberry is just institutionally incapable of handling this sort of relationship with the community. It's that legacy telco "us vs them" mindset at the top of the org, and it filters down whether implicitly or explicitly.

It was worse than an NDA! You also had to start your application with a trip to a notary to get your ID confirmed.

And if their signing servers were down…You couldn’t load had just compiled onto your own dev / test device.

I loved using my blackberry but I hated developing against it. Bb10 was its own little adventure but had similar draconian dx

One of the dirty secrets of the mobile industry, particularly before Apple showed up and spoiled all the fun, was how many execs and chunks of the ethos were airlifted out of Ma Bell. The kind of moat-building we're seeing take over the internet over the last couple decades is something that mobile carriers already had in heaps.

It was also common for carriers to extort very high fees from anyone selling apps on their platforms. People bitch and moan about Apple taking 30% (which is more like 15% now) but I saw mobile app execs complaining about only grossing 30% after the carrier fees, and so you could only either make blockbusters and pay for R&D on volume, or set your VC money on fire to fatten up the carriers and get nothing, except more powerful carriers, for your efforts.

I'm not at all surprised to hear that RIM was only slightly less evil.

I remember getting some LG phone in maybe 2007 and being excited because I read you could write 3rd party apps and games for it. Then I tried reading the BREW developer docs and trying the emulator, which were both abysmal. Then I read that just to try an app on my phone I would need to pay hundreds of dollars (IIRC it was $400) to get it signed.

That totally killed my desire to develop for my flip phone.

It's crazy to think that that's an ecosystem where paying a dollar or more for a ringtone had been normalized.

If you look up the music industy revenue source breakdowns by year, there was a time when ringtone revenue represented 10%.

https://www.visualcapitalist.com/music-industry-revenues-by-...

Was this North America specific. I remember using sdk/dev tools for Symbian. I don't remember timelines, so maybe they changed after iPhone release.

If I recall correctly the Symbian SDK was freely available more or less from the Psion start. Not sure about it's different "editions" though.

> Bb10 was its own little adventure but had similar draconian dx

I did some development for it but the bureaucracy killed my will to do more.

It was a great phone OS though. The real time nature makes even modest hardware responsive.

The BB10-powered Passport was my favorite device

I still want one. Can’t find any.

I still have mine but it's useless because it isn't receiving updates and can't run third party OSes due to the locked down boot chain.

Still runs the base BB 10 apps. My Q-10 still works as a phone. And can read e-mail.

> The BB10-powered Passport was my favorite device

I loved mine.

My favourite device was my Nokia E90 Communicator. Hardware-formfactor-wise that's the best smartphone I ever owned.

Closed, it's a one-hand T9-driven smart candybar phone. Open, it has a usable QWERTY keyboard, a letterbox screen that can display a slice of an A4 or Legal PDF at readable size. I never watched films on it, but you could do in principle.

Even worst! When everything was signed, you would get no support at all! Worst experience ever!

From the people I know who worked there, same crap in internal culture, too.

For everyone else, your QNX comment from 2015: https://news.ycombinator.com/item?id=9872640

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

Even getting the licensing right isn't sufficient. They could license it as MIT today, close source it again tomorrow, and within a few releases no one would be using the MIT version.

Unless someone is interested in maintaining a full fork. It's the same reason Google can do whatever they want with Chromium even though it's technically open source. No one else has the resources/will to maintain it so there's no credible threat of a fork.

That's not a great example. Maintaining a full fork of QNX would not be terribly complex compared to maintaining a full fork of Chromium. The latter targets standards which are moving and evolving. Nobody cares which version of POSIX QNX is compatible with. (Also, Chromium is much bigger)

I think a fork could have some maintainers. I'd be more worried about people wanting to put new features in than anything else.

Between Microsoft on one hand and all the other browser companies (Opera, Brave etc) on the other, I wouldn't be so sure.

Following Google's lead is massively cheaper than having a custom fork or engine, but it's not impossible. If Google does something wild and unpalatable to all these companies, I wouldn't be surprised if we see a Linux Foundation version of Chromium, with custom skins on top.

That could even get Mozilla to jump on the bandwagon, especially if they lose 9x percent of their revenue due to Google's antitrust remedies, which is not that unlikely.

Back before 2004, QNX could have still been relevant as there was still a lot of OS experimentation from the user/developer themsevels. They could have attracted enough people to carve a niche even in the desktop space at that time.

After beos failed, I played/developed with QNX until they pulled the rug. I was on it full time on my main dev machine. I loved it.

When they closed it I got severely burned to the point that I will not touch a any closed development platform. I see from the license they didn't change a bit.

Not that it matters anymore.. they're largely irrelevant today except for whatever existing markets they already have. It would be fooling to choose QNX today: we now have good alternatives, and all of them with open licenses.

I remember being really excited about QNX for a few months after BeOS closed up. It had a cool desktop environment and was mostly posix so it was more or less familiar coming from Be or Linux.

>QNX went open source.

Not open source. Those words have a specific definition[0], which QNX never met.

0. https://opensource.org/osd

Things don't become true just from being written down on the Internet. Open source means that the source code is open for the public to see, and that's it.

This misunderstanding continues to crop up on Hacker News. [0]

> Things don't become true just from being written down on the Internet

That's not what they were saying.

People who care about open source software use the OSI's definition. You can't reason about the open source movement if you use a fundamentally nonstandard understanding of the term, such as the one you are proposing. You wouldn't be able to make sense of a blog post like this, for instance. [1][2]

> Open source means that the source code is open for the public to see, and that's it.

The open source movement disagrees. Are we expected to accept your definition just because it's written down on the Internet?

[0] https://news.ycombinator.com/item?id=31203209

[1] https://drewdevault.com/2024/07/16/2024-07-16-So-you-want-to...

[2] https://news.ycombinator.com/item?id=40993787

So it's not just me. I asked for a license to do pkgsrc package building on QNX, got rejected, and couldn't even get a human to respond to my messages with anything that didn't resemble a copied-and-pasted form response.

They gave the impression at the time that they really couldn't be bothered with open source. This just happened to be not long after 2010.

> As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.

Microsoft realized that a long time ago. That's why you could always get Windows for free if you knew where to look.

QNX will lose even more since linux merged the RT patches. There is almost no reason to use QNX on an embedded system where linux is also available.

It is sad. With GNU it could have been something interesting.

I worked for a startup in Germany that was acquired by RIM/Blackberry in 2011. The company tried to get all the employees to sign new contracts for their existing roles and pay. The new contracts put severe IP limitations on everyone. All open source was forbidden. Many of us were very active in open source at the time. (I had worked for the Eclipse Foundation). A friend who wrote fiction was told he’d need written permission for each story he wanted to post or publish. They insisted that German engineers sign contracts where the binding language was English even though it was provided with a German translation. Many of us just left instead. My favorite line from the transition team sent from Canada was about how lucky we were going to be that they’d let us keep our awesome office in Munich because everyone at RIM worked in dark concrete dungeons. Yeah, how lucky we were that we could keep what we had.

Open anything is just completely foreign to that company’s DNA. I would not trust them an inch.

Ubitexx?

Unreal engine has certainly had its licensing issues.

https://www.theverge.com/2023/10/5/23905082/epic-unreal-engi...