Hiya folks! I’m John from the Developer Relations team at QNX. I just wanted to let you know that, through our QNX Everywhere program, we’re opening the doors to QNX like things used to be.
I see a lot of folks here still work on products as far back as QNX 2! That’s amazing! It’s a testament to what the platform can be if it’s open to the community for feedback and contributions. We’re getting there, starting with the availability of free non-commercial licenses to use the newest QNX. You can go today to get a free license to QNX 8.0 with just a few clicks: Free Access to QNX SDP 8.0 for Non-Commercial Use
We’ve also just released some sample apps and a ready-to-go QNX 8.0 quick start target image for Raspberry Pi 4. All you have to do is download and flash the image, and you’ve got a running QNX 8.0 target that connects to Momentics or VSCode and all of the QNX tooling for development and debugging. It even has a little graphical demo launcher the team whipped up!
I know some of you must be intrigued by this and are anxious to take a peak at the multi-core processing and throughput improvements in QNX 8.0! Your feedback about QNX 8.0 and about our QNX Everywhere initiative are invaluable, and I’ll be paying extra special attention to the group here when bringing feedback to the QNX leaders for consideration. Please let me know what you think and what we can do to open the gates even more. It’s only just the beginning! You can find me here, on StackOverflow for technical questions, and on some other social platforms.
I notice that no-one has responded to your notice about the QNX8 non-commercial licences. So I will!
I was approved to obtain it and after building up a new Ubuntu Linux box managed to download and install the SDP last Monday (my time). I now have it running (able to build at least) and managed to build the Raspberry Pi4 BSP without any real problems (other than me not setting up the environment properly)! I hope to try the new QNX8 RPi4 image later today to see how it goes. It is quite different to the 7.1 RPi4 build but so far nothing untoward.
I notice a few traditional QNX utilities have been removed. Probably the loss of qtalk hits me the most as I used it extensively - since for the last 29 years I have been working with QNX serial drivers. I guess I will have to write my own terminal program but I’d be interested to know why qtalk was removed from the lineup. I realise that the utilities are mainly out of the Toolbox but some useful QNX specific utilities could have been retained. QCP also gone but that (for me at least) is not a big deal. I used to use textto a lot but for what I intend using this QNX8 for (my own interest basically) it’s not a big deal either.
I do like the fact that telnet and FTP have been removed from the BSP images in favour of SSH/SCP! I had already done that with my QNX 7.1 images/systems. Not sure about PAM however…
Like a couple of others who frequent this forum I have been a QNX user for a long time. 37 years - back to the QNX2/3 days - and have used it exclusively through the QNX4, QNX6, and QNX7 eras, to this day (well, last February anyway). A lot has been lost in recent years - things that made QNX unique. First (QNX6.6) we lost Photon ( a great GUI) and a self-hosted development system (for x86). The latter didn’t really affect me but losing Photon with 6.5 stopped me in my tracks with a product I had developed back then. Now, with QNX8 we have lost QNET, and the ability to share IRQ’s within one thread (InterruptAttach()). I expect to find a few more lost features as I move forward but these are the two that stick out. In both cases, if I were to come out of retirement and get serious again, a major system design would be required as I would never have thought (and didn’t) that core QNX features would simply be removed (for whatever reasons - and I am aware of some of them).
Presumably the Send/Receive/Reply IPC and resource manager architecture is not under threat!
Anyway, it is good that Blackberry has seen fit to offer these non-commercial licences as forking out 5-digit amounts of dollars to start learning about QNX and how to use it was a tall order! Now, hopefully, there is an easy pathway for Linux developers (especially disgruntled Linux developers - and I know a few of them)! will take the opportunity to learn about an alternative approach to such things as hardware driver implementations (resource managers), event driven system design, etc. I know, way back in my day (pre-Linux) I saw the advantages of QNX and have stayed with it ever since. But it is now time for a new generation of QNX developers and hopefully they take this up. I, for one, will and do encourage it. As for me, well, I no longer work [much] for a living (being “retired”) but that doesn’t mean I’ve lost interest in what sustained me and my family for close to 40 years!
Thanks John,
I’m one of those guys that still can help with QNX 2. I think this is a good step for Blackberry.
Geoff,
While I like your optimistic view of bringing over disgruntled Linux programmers, it’s not clear if this will be productive. I have almost 40 years of experience building message passing based systems and as you know, it takes a bit of time to get the hang of it. In the last 10-15 years I’ve been called in on projects where the programmers have buildt their applications as if they were in a monolithic kernel environment. That is to say they build the entire system as one process with different components running in separate threads. I’ve found them resistant to learning anything new. That of course is a shame as building small robust protected and restartable units with QNX is one of its shining features. I’ve also noticed that when QNX removes a feature, they are resistant to making the source available to anyone who might require it. I’ve observed that attitude lose them more than one customer including the US Postal Service.
Thank you both for your replies! I don’t have much to add in response, but I do really appreciate hearing your perspectives as QNX veterans. Knowing you’re watching these changes and evaluating them for new generations of QNX developers is a great motivator to me and the team to make sure we’re taking the right steps in this program. Cheers!
I have written a rather lengthy document that might take a lot of the pain associated with getting started with a working Raspberry Pi4 system. It is intended for people interested in getting to the point where they can write a program, transfer it to the RPi4 target, and run it. I imagine these will include people who have no QNX or even Linux experience, or no knowledge of the Raspberry Pi4 hardware.
I start with how to download the SDK from the QNX website using the QNX Software Centre (also downloaded), install the SDK on a suitable Linux box, then download the Raspberry Pi4 BSP (also using the QSC), build the RPi4 Image File System (IFS) file, and get it onto an SD card from which the Rpi4 will boot.
While the provided RPi4 IFS will work, it is read-only which for this purpose is not (in my opinion) terribly helpful. So I explain how I implement my QNX systems so that I also have a writable native QNX6 file system on the SD card to use.
I am not sure if this sort of thing is explained elsewhere.
Please indicate on this thread or even better PM me if there is any interest. If there is I think I can post it without getting into trouble with anyone. I’m making the effort in order to assist people who might find themselves up against a brick wall getting started and might otherwise lose interest and give up.
I have decided to make available on my own website the four documents I have written so far. They deal mainly with how to extract and build the rpi4.build file provided in the BSP, and then how I go about modifying it to do what I want with it. In my case, I generally want a writeable file system (the default IFS is read-only) so I go into how I deal with that.
It’s been a while since I posted here. I saw this post two weeks ago and took some time to come up with a more measured response. Thanks, but no thanks.
I’m now happily developing on Linux, for Linux, and I wish I had switched from QNX6 sooner.
I work for a company that was left hanging by QNX/BlackBerry’s business decisions. When we transitioned from QNX4 to QNX6, we created a code layer that encapsulated all QNX-specific functionality, allowing our code to compile and run on both QNX4 and QNX6. When we switched from QNX6 to Linux, we extended that same code layer to implement S/R/R across both network and local environments, global name services, pulses, and more.
Fortunately, we never relied on the resource manager framework, which simplified things. We also didn’t have to write any drivers since all hardware products we use come with Linux drivers.
Messaging is implemented using TCP and UNIX sockets.
Pulse is built on top of mqueue, with a dedicated thread handling remote pulses.
The entire system runs in user space.
Messages and pulses do not affect priority; we didn’t implement this because it wasn’t necessary.
One requirement for cross-network messaging is that each machine mounts a common nfs drive. I had planned to eliminate this dependency, but in practice, it hasn’t been a significant issue.
Initially, we used auto.nfs and a configuration files to provide a /net/... mount, but we no longer rely on that.
Although we use a real-time kernel, I don’t believe it’s necessary for our use case. Initially I was really nervous about real-timeness and performances but turned out linux is so much better then QNX6.5 to squeeze performance out of the harware that it was a no issue.
When we migrated from QNX 6.5 to Ubuntu 18, our software’s processing time dropped from 1 second to 0.65 seconds on the same hardware. Our software runs on servers with many cores—20 at the time, not including hyperthreading. Even before switching to Linux, we found the QNX kernel inefficient under heavy loads. It took too long to migrate waiting threads between cores and lacked awareness of hyperthreading and NUMA architectures. It introduced lots of latency compare to Linux.
Initially, our software was 32-bit, but we transitioned to 64-bit. At the time, QNX 7 did not support 32-bit applications.
We also experienced issues with the e1000 driver and io-pkt-v4 under heavy loads and with multiple network cards. The system would hang, and after sending our (standard) hardware to QNX and spending $50,000 on support, they were still unable to resolve the issue. Since switching to Linux six years ago, we haven’t encountered a single problem.
None of us should be surprised in the least. QNX 6.5 was released around 2012-2015 frame. That’s 10+ years ago. Based on Moores law CPU power has increased roughly 16x or more since then (especially when considering how many more cores there are now). Over time pure hardware advances have rendered obsolete most of QNXs speed advantages over non-RTOS systems.
Like your company, we’ve always wrapped all the O/S calls in wrapper classes so that the code was portable to Linux/Windows etc on a moments notice. We’ve begun experimenting with running everything in C# over the last year or so and so the results in >98% of our code say there is no appreciable difference between QNX and C# because by the time the physical hardware actually responds on large vehicles the difference between a few milliseconds is meaningless.
I would imagine once we’ve got more proven time on the systems running C# that we’ll move away entirely into C#.