QNX is now free for anything non-commercial, plus there's an RPi image (blackberry.qnx.com)
I'm John from the Developer Relations team at QNX. I'm a loooong time lurker of this forum and excited to make my first post.
I just wanted to let you know that we've kicked off a new program to start opening the doors to QNX like things used to be. Many of you probably used or tinkered with (the very open) QNX back in the day. You can now easily get a free non-commercial license to use the newest QNX. We've also just released some sample apps and a ready-to-go QNX 8.0 quick start target image for Raspberry Pi. So you can get QNX and the development tools for free now to learn, experiment, and build.
It's been a long time in the making, so I'm really excited to get to post about this first phase of the QNX Everywhere initiative. My team and management have open ears, so please share feedback about what more we can do to open things up, be more transparent, and get you what you need to create an awesome embedded QNX project.
Cheers!
379 comments
[ 3.4 ms ] story [ 269 ms ] threadSo do you plan to offer access to QNX source code again in the future?
https://www.qnx.com/news/pr_2471_1.html
QNX is a great technology, but nobody who acquired it knew what to do with it.
[1] https://www.bing.com/entitydetails?q=BB+stock&wt=FinanceGene...
with BB's stock performance : maybe?
In my opinion, any platform should be available for free for any non-commercial purpose. This is how people get started, and this is how the platform proliferates.
I might even suggest going a bit further: provide some limited support for non-commercial users, for example, make it super-easy to file a bug.
But otherwise, it's a win-win for both the free tier (students, hobbyists) and the corporate.
I also work for a non-profit org which does coastal margin research. We have several people working on custom hardware. Could this benefit us?
* http://toastytech.com/guis/qnxdemo.html
* https://winworldpc.com/product/qnx/144mb-demo
* https://crackberry.com/heres-how-qnx-looked-1999-running-144...
In the browser in the crackberry video
what the....
I was also coming back in to edit my comment and write that my x -> 0.0.0.x was technically wrong and the same for the others. If you stick to only single-byte values then what I wrote was correct but if the values span multiple bytes they fill in the missing 0s appropriately, as in:
The "zeros" happen when the last number is smaller than 256 (or 65536, etc.), but it doesn't have to be. For example 10.258 is a valid way to write an IPv4 address, it's the same as 10.0.1.2.
10.0.0.3 -> ping 10.3
If you are talking about the short url, well ipv4 allows it and they needed to save space to fit on the floppy ;)
> A popular implementation of IP networking, originating in 4.2BSD, contains a function inet_aton() for converting IP addresses in character string representation to internal binary storage. In addition to the basic four-decimals format and 32-bit numbers, it also supported intermediate syntax forms of octet.24bits (e.g. 10.1234567; for Class A addresses) and octet.octet.16bits (e.g. 172.16.12345; for Class B addresses). It also allowed the numbers to be written in hexadecimal and octal representations, by prefixing them with 0x and 0, respectively. These features continue to be supported in some software, even though they are considered as non-standard.
(https://en.wikipedia.org/wiki/Dot-decimal_notation#IPv4_addr...)
Never use this.
https://support7.qnx.com/download/download/51624/BB_QNX_Deve...
(I am not your lawyer, this is not legal advice. This is not a comprehensive review, assessment, or summary of possible interpretations of that license. Seek professional counsel from a lawyer before acting on anything stated below.)
These terms open with a ‘user did not have an opportunity to review and agree before binding themselves, their business, and/or their institution’ clause that may well wholly invalidate the entire document in the US, so please review these with your lawyer before use, so that your usage is not put at risk due to legalese overreach.
Academics, only students and faculty of your institution qualify, and your usage under this license will be viewed by your legal team as you signing a binding agreement on behalf of your employer; make sure you’re not exposed to liability through open source contributors or at risk of being fired for misrepresenting yourself as a signing authority for your institution.
Cloud users, your license is restricted to AWS per their terms; use on GCP, Heroku, or any other server instance not under your personal contractual control may result in owing licensing fees.
Only OSI definitions of “Open Source” are permissible here; this disqualifies anyone licensing software under a restrictive non-commercial license from making use of the QNX non-commercial license, as per OSI, all such restrictions are not “open source”.
Social apps are excluded by the “high risk” clause, which prohibits any use under these terms to develop applications that could harm society. Take care not to create viral applications that violate this clause.
They collect and retain all serial numbers identifiable on all hardware you use in association with this product.
Your noncommercial license may be severed unconditionally at any time without recourse, regardless of whether you have faithfully complied with the terms; at which time you may be compelled under contract to provide an undefined ‘certification’ of indeterminate cost that you deleted all QNX code provided to you.
Stay safe, folks.
any product, device, component, or system which if it fails or is interrupted, may result in loss of life, or other serious or catastrophic personal injury and/or substantial financial or commercial or societal loss.
So its not just safety-critical applications, it also includes "societal loss". What does that mean I have no idea. Does losing Twitter client leads to "societal loss"? You can argue both ways
I cannot possibly imagine what motivated them to put in a “no edgy apps” clause and then post it on a bleeding edge site like HN. A job’s a job, I suppose.
- graphics card drivers years behind (actually what made me switch to linux)
- A lot of linux graphic environment tied itself to systemd and it's friends
- Specifically, firefox lacks some features that available on Linux, Windows and macOS (related to memory consumptions and overall snappiness)
- Many things depend on FreeBSD specific patches to work and if you aren't a seasoned porter, good luck porting it yourself[1]
[1]: this one obviously depends on what kind of software you require. For it me it's a miss.
Even a $12 SoC is no longer resource constrained with a stripped minimal Linux kernel. QNX missed their launch window decades ago...
https://en.m.wikipedia.org/wiki/QNX
There's lots of interesting key differences between something based on Linux, for example, and QNX. Worth digging into if you're interested in these things. My colleague wrote a short ebook and the intro has a good summary: https://gitlab.com/elahav/qnx-rpi-book/-/tree/master/pdf
https://ethw.org/Milestones:TRON_Real-time_Operating_System_...
which was demoed running on an 80186 with _multiple_ windows running videos w/o dropping a frame.
Described as "The most installed operating system in the world":
https://www.linuxinsider.com/story/the-most-popular-operatin...
Unfortunately, the U.S. State Department viewed the Japanese plan to place it on all computers in their educational system as anti-competitive.
Really wish it was available for the Raspberry Pi.
Can you recommend books or papers on how the kernel works, and what makes it better than e.g. L4/sel4 or Mach?
https://en.wikipedia.org/wiki/ICON_(microcomputer)
These machines didn't work at all without a server to network boot from, aka the LEXICON machine, so it's not likely some teacher squirreled all that across the border.
They were not commercially available.
I would seriously doubt that QNX or anything like it resembling a "real OS" is running on the automatic transmission. If the transmission controller is running any OS at all it's likely a microcontroller running a much more specialized RTOS.
QNX is very common in automotive applications, but in things like digital instrument clusters and ADAS where the software is complex enough to benefit from a full networkable OS with support for a lot of different high speed buses but the use case still needs real-time guarantees and/or microkernel stability. I've specifically seen QNX's hypervisor marketed for digital clusters where the critical data display and interaction with the ECU could happen within a fully certified QNX environment that would be designed to be as stable and reliable as possible while allowing infotainment applications to run in a VM instance of Android, Linux, or even more QNX where software reliability was less critical. If it crashes, the important instruments are still working.
Ford's "Sync 3" and "Sync 4/4A" infotainment systems run on QNX as well, though being just infotainment they didn't really care about the realtime aspect (though I'm sure stability was a big thing compared to their Windows CE based predecessors). They've moved to Android for their latest revision.
I've got a Sync 2 car, and I can't say I've noticed instability. The UI toolkit is slow, but the story on that is someone's cousin did something some Macromedia stuff that barely worked and they shipped that. I've got some issues with GPS offset, but that's pretty stable. I had worse stability with the Chrysler UConnect in my 2017 Pacifica, and that was reportedly based on QNX; it would sometimes crash and restart, or the screen would not come on at all unless you knew the magic buttons to hold to force reboot.
Whatever version of MFT my car shipped with was pretty bad, hitting the category button in the satellite radio controls was about a 1/5 chance of a crash. It also wasn't great at handling my USB drive full of MP3s. A few months later an update came out that was actually never officially released for my car, but if you put the right files on the USB drive it installed just fine. After that update those crashes were gone. All that was left, and it happened until I upgraded the system, was maybe once every 2-3 months the Bluetooth stack crashed and took the entire media UI with it, I'd have to use the physical Source button to switch to AM/FM and then switch back to regain control though whatever was playing would keep working.
I upgraded to Sync 3 and haven't crashed it since. Sometimes it gets in a fight with my wireless android auto adapter, but it's never had an issue in wired mode which is all it officially supports so I'm not going to fault it there.
Drivers are in user-land and can be restarted at runtime. Probably more, but it's been awhile since I used it. A lot of it comes from QNX having a micro-kernel.
> RT can also linux.
PREEMPT_RT was merged in september of this year[1]. I terms of "hard real-time" with PREEMPT_RT scheduler still not completely deterministic like in QNX.
[1]: Note that you could have turned linux in "somewhat" hard real-time with or without PREEMPT_RT patches for user-land application.
I do not know what you mean. IPC over IP is at least 50 years old, and today can be done with ANY POSIX system, as it is part of the Standard!
>> Drivers are in user-land and can be restarted at runtime. Probably more, but it's been awhile since I used it. A lot of it comes from QNX having a micro-kernel. And QNX is as microkernel as MacOs
Honesty at this point I don’t know if you are trolling or being sarcastic or you really never used linux. You absolutely can work with drivers in userspace in Linux (that is standard practice for driver development in linux) and has absolutely nothing, not even remotely, to do with the kernel architecture.
>> still not completely deterministic like in QNX.
First we have to admit that RT term is loosy, is used lousy and is full of it. Specially when somebody says “completely deterministic” there is just not a complete deterministic thing in a computer. Bottom line (a) RT Linux is more than enough for anything in the real world. (b) I haven't used QNX lately, but as I did, the only thing deterministic was the “yeah… this box has to be rebooted once a week, or QNX will just hang”
Separately, I think making a GPS-synced weather station would be a fun project. QNX is often used when tight timing is needed for telemetry, so using it to collect weather (and other) data, including from pulsing hardware like an anemometer, and then publishing it to an online service would be a lot of fun.
If software-only is more your style, there may or may not be someone in the office next to me porting some classic games right now! =)
Maybe I will tell it all wrong, but I remember that for example it could be easy to do RPC on the same machine for the isolation. A client calls the server and the scheduler would switch context immediately to the server process upon IPC.
You already have to add things to microkernel-based systems to make them useful. You have to add even more to those based on separation kernels.
What would be QNX specific would be making sure the main app is always responsive to user input. That the network, DB, or other things don’t slow it down. That might be done by scheduling dedicated time for both input and the main loop. Non-blocking I/O so main loop can check the progress of other things. Maybe a monitor in there watching for freezes.
If any component freezes, have it restart and get new/updated state. If that works, next version is a two-board, highly-available system with QNX’s networked IPC.
My memory is rusty, but we ran QNX on the control-plane processors, and it natively allowed launching processes on remote processors over the internal network of the router. That is: their low-level IPC was IP-capable. QNX's IPC was essential for our HA failover functionality.
Also, device drivers as user-space processes that you could restart on crash was great (we were developing our network drivers, so this would occasionally happen). Also, better respect for devices actually showing up in the /dev/ tree, unlike Linux where network devices are a notable exception.
One funny story, I once spent days debugging an issue which turned out to be due to me accidentally marking const the return values of some IPC, which caused my process to crash in between QNX's IPC function and mine! Whatever level of debugger (C/userspace) I was using at the time could not catch the error ^^;
This was already possible in CP/NET (https://en.wikipedia.org/wiki/MP/M#CP/NET) or CP/J with JUNET [https://pl.wikipedia.org/wiki/JUNET_(CP/J)].
The existing information out there is of questionable reliability and probably out of date too...
That's convenient, as I have a lot more of those sitting around than I do Pis at the moment.
First there is so much text that wants to tell me how great this software/tooling/resources is, without telling me what exactly it is.
As I still wanted to know what it is, after reading your comment here†, I clicked on the front page https://blackberry.qnx.com/en which has a concise introduction
"Real-Time OS and Software for Embedded Systems
Launch your critical embedded systems faster with our commercial RTOS, hypervisor, development tools and services."
An RTOS for embedded system, aha! That would be valuable information on the QNX Everywhere page. (Real-Time OS / RTOS isn't mentioned once)
Then I found the resources section nearly at the bottom, which has quick start guide, where I can see what I will get when I sign up for a free license and that would be exactly what I (as someone who has no clue what to expect from QNX) would want to see at the top, after a short introduction to what it is and why I want to try it out.
Maybe this page is more intended for people who are already aware of QNX, but if you intend to "catch" new people I really would recommend you to reorder/simplify this page, by putting relevant information (like a short introduction, why I would want to try it and a quick start guide) at the top instead of a wall of marketing text.
† this comment was first under a comment from the author, which now got moved to the HN post text
Apple doesn't have to explain on their homepage what they do. QNX, in some sectors, has been a very well-known brand for a few decades, which is probably why their marketing material is stuck in that mode.
The obvious fact though, as your comment demonstrates, they're now just another nobody.
I make embedded linux device and I'm curious if QNX could make things easier, especially for long term stability.
I disagree. Linux merged the real time stuff (https://news.ycombinator.com/item?id=41594862) not so long ago so it's now a real-time capable kernel, and hence it should be held comparable to other real time kernels.
The only serious user of rt-linux which uses it to build a hard-RT system that I know is SpaceX. Look up the Reddit AMA post from them on how rt-linux is used. They are staying on a specific kernel version, had to do kernel patches (other than applying rt-linux), they use a very specific model of an old Xeon for low latency interrupts, incorrect programming of one process can disrupt the RT behaviour of another process, and most importantly, they have a secondary board, a truly real time one (PowerPC based, IIRC) to communicate with the real hardware.
If the redundant hardware and some ground rules they have in place have made the onboarding of developers better and faster, than perhaps it should be recognized that they seem to be prioritizing the DX - especially since plenty of applications in RT will also use redundant hardware and confine their hardware selection similarly to prioritize the performance targets of their application, SpaceX just added developers to the feature matrix.
Well I didn't and it was not easy to understand what it is from your website. Wikipedia came to my rescue. You may want to consider that.
QNX has been "opened" twice before. Each time, there was a rug pull, and it went closed again.
Before the first rug pull, open source groups routinely added QNX to their target list. There was a Firefox for QNX. Eclipse had QNX as a target. GCC and most of the Gnu command line tools could be built for QNX. There was a desktop environment, Photon. I used that as a primary desktop for three years when working on a DARPA Grand Challenge vehicle.
All of that went away after the Harman acquisition of QNX in 2004.
Then, in 2007, QNX went open source. You could even look at the microkernel. It wasn't openly licensed, but you could look inside and build it.
In 2010, RIM acquired QNX, and, with no warning, closed the source. All open source development related to QNX ceased, and QNX lost all credibility in the community. So QNX shot itself in the foot. Twice.
Note the contractual terms.[1] "TERMINATION. This Agreement and licenses granted hereunder may be terminated by either Party upon written notice to the other Party". QNX can pull the plug at any time. Since they've done so twice in the past, there's a good chance that will happen again.
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.
That's the way to do it if you want more adoption of QNX. Take the Epic term sheet to your lawyers and management. And have them take a look at Unreal Engine's revenue growth vs. QNX.
As I once told a QNX sales rep, your problem isn't that you're being pirated. It's that you're being ignored.
[1] http://www.qnx.com/download/feature.html?programid=51624
[2] https://cdn2.unrealengine.com/UnrealEngine/faq/UnrealEngineE...
So thank you very much for the link.
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.
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.
Can you say what kind of shop / machine it was for?
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.
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.
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.
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.
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.
I wonder how far Redox's microkernel design is from what that comment describes.
https://gitlab.com/uxrt
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
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).
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).
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 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.
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
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.
That totally killed my desire to develop for my flip phone.
https://www.visualcapitalist.com/music-industry-revenues-by-...
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.
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.
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.)
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.
It applies to both sides of the argument, with organizations keeping things to themselves or others avoiding codebases for the inverse reason.
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.
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 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.
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.
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?
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.
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.
[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...
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...
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 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.
This seems like a technical workaround for a legal requirement. Indeed, that seems risky xD
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 standalone QNX... it is the safety-critical certified version of QNX.
It is easy to understand: Making an RTOS is easy. Making an RTOS (and a compiler) ASIL-D ISO-26262 certified is a freaking nightmare. And this is why companies are paying for QNX.
Opening the QNX source code under GPL would increase significantly the number of software ported on QNX and consequently the adoption of QNX.
Unfortunately, Blackberry is way too stupid to do it: It is not in their culture. That is very unlikely to happen.
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.
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.
I think a fork could have some maintainers. I'd be more worried about people wanting to put new features in than anything else.
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.
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.
i have seen some try and fail in an effort to save $perceived_value
my experiences then would lead me to recommend it, though.
Forgot to mention: the neat part of RTEMS is it allows one to sort of turn a Unix program into a bare metal program.
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.
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.
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.
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.
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.)
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.
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.
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.
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.
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
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
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.
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.
Open anything is just completely foreign to that company’s DNA. I would not trust them an inch.
https://www.theverge.com/2023/10/5/23905082/epic-unreal-engi...
What is QNX haha
Everything is a message, rather than being a file. Messaging works like a function call - you send a block of data to another process, wait, and get a reply back. Processes which receive messages act like servers - they have a thread or threads waiting for incoming requests, and when a request comes in, it's handled and a reply is sent back. It's a microservices architecture.
Unlike Linux, it's a fast microservices architecture. Message passing and CPU dispatching are integrated. When a process sends a message to a service process, the sender blocks. (Timeouts are available.) If the service process isn't busy, control immediately transfers to the service process without a trip through the CPU dispatcher. When the service process replies, the reverse happens, and control goes back to the original sender. With most inter-process communication systems, there's queuing delay for this kind of operation. QNX got this right. This is the core insight behind QNX.
Yes, there is message passing copying overhead. In practice it's under 10%. I've sent video through the message system. Copying is less of a problem than you might expect, because, with today's large CPU caches, the data being copied is probably warm and in cache.
All this is real-time aware. Higher priority processes get their messages through first. If you call a service, it inherits the caller's priority until it replies. This prevents priority inversion, where a high priority process calls a low priority one and gets preempted by lower priority work. This works so well that I was able to do compiles and web browsing on a single-CPU machine that was also running a robot vehicle.
There's a tool for building boot images. You put in the kernel, a standard utility process called "proc", and whatever else you need available at startup. For deeply embedded systems, the application might go in the boot image. It's all read-only and can execute from ROM if needed, which is good for applications where you really, really want startup to always work.
Files and file systems are optional. For systems with files, there are file system and disk drivers to put in the boot image. They run in user space. There's a standard startup program set that creates a Unix-type environment at boot time. This is all done in user space. The file system is accessed by message passing.
System calls look like POSIX. Most of them are implemented in a library, not the kernel. Service processes do the work. When an application calls POSIX "read", the library makes an interprocess function call to the file system or network service server. Program loading ("exec") is done in user space. The boot image can contain .so files. "Exec" is done by a .so file that loads the image. So the kernel doesn't have to worry about executable format, and program loading is done by untrusted code.
Because it uses POSIX, most command line UNIX and Linux programs will compile and run. That's QNX's big advantage over L4. L4 is a good microkernel, but it's so stripped down it's just a hypervisor. Typically, people run Linux on top of L4, so all the bloat comes back.
There is no paging at the OS level. That would kill real-time. There's a paging to disk library that can be used by programs such as compilers with big transient memory needs, but most programs don't use it. The effect is that responsiveness is very consistent. I miss using QNX desktop. There's no lag.
So that's an overview. Microkernel done right.
That'd be seL4.
Whereas, seL4 is a separation kernel. It does almost nothing but with high security. To do anything, you have to add software to it that can undermine its security or performance claims at a system level. These are also unproven additions most people know nothing about. That overall deal might be fine if one component being ultra-secure is your highest goal.
QNX is usually better than seL4 for most needs. Even security people because they’ll want useful functionality which they’d have to secure on seL4 anyway.