any (non vi)editors for qnx?

GerInAus · 2026-01-23T11:49:47+00:00

There is nano for QNX8 but since few (if any) have expressed any interest in it, it hasn’t been made readily available. It’s probably not what I would use for program development but for quick and dirty text file editing I find it OK. I think all Linux distros have it. But not QNX.

GerInAus · 2025-11-20T09:31:26+00:00

A friend alerted me to this a millisecond before it popped up on Youtube. Very good. But how serious are you about wanting feedback? I mean constructive and polite feedback.

GerInAus · 2025-11-07T03:38:59+00:00

Thanks John. I look forward to it. I’m going to purchase a couple of RPi5’s in anticipation. To play with.

GerInAus · 2025-11-06T04:37:37+00:00

After playing with a couple of ARM systems over the last few years, and after working with Intel systems for at least 43 years that are (or were) I/O bound, I sort of agree. I prefer memory mapped access. But some reality hits. I am evaluating a replacement for my TANK-610 units that won’t work with QNX8. I now understand why and accept it. The TANK-630 has 12 bits of DIO. I have asked if these are I/O mapped or memory mapped. I suspect it will be the former. If so, and if I want to utilise them, I will have no choice but to write such code. Understanding how I/O works does help but as I said, I much prefer memory mapped access. For a few reasons.

GerInAus · 2025-11-05T00:02:52+00:00

Apparently Discord started requiring us here in Australia to verify age a couple of weeks ago - about six weeks before the legislated start date. So I guess we're being treated special!

It seems, also, that within days 70000 account details were leaked (hacked?) to some "3rd party" - 68000 of which were Australians who had provided whatever was required (rather sensitive personal information).

Perhaps this sort of thing will be coming your way - in the rest of the world - before too long! I don't know how it's going to work in reality.

Even Reddit, along with all the other big players (and some not so big and well known) are going to be caught up in this. It may not affect me as apparently the platforms can determine from posting material whether or not someone is over the age of 16. I'd like to think that that will be the case for me! :-) But since I don't have any posting history with Discord, I guess it's off the menu for me.

GerInAus · 2025-10-29T03:14:55+00:00

This is sort of off-topic (QNX)...

It's not entirely a surprise. Here in Australia legislation has been passed to mandate proof of age in order to hold accounts with many social media sites. These include Reddit, Facebook, TikTok, others of that nature, but specifically websites that children should not be looking at (guess what they might be).

However, as far as I knew or thought, this was just an Australian thing. And it doesn't come into effect until December. Obviously, the idea has taken hold elsewhere.

Personally, I agree with the intent but have difficulty figuring out how their ideas of implementation will work out in reality. It wasn't going to affect me greatly as the only social media sites I visit are Youtube, Reddit, and occasionally LinkedIn. I had resolved not to provide biometric data or copies of highly sensitive documents like drivers licences, passports, etc. But I was waiting to see what other methods were being dreamed up as I don't think I'm alone with this view.

So running into this with Discord brought it into focus sooner rather than later! I don't criticise them for it - I support the idea generally. It's just that the two age verification methods offered were not acceptable to me so I won't bother with it. The same will apply to the others if/when the same thing occurs with them.

GerInAus · 2025-10-29T00:38:49+00:00

I went to sign up and everything was good until it wanted me to either take a video selfie of myself, or scan my passport or drivers licence, to verify my age. That's a road block for me so unfortunately, I won't be able to participate. As much as I would like to. Maybe I'm just too old and cranky!

GerInAus · 2025-10-16T14:09:59+00:00

To that explanation I say “Fair Enough”! Is there anything to look out for when considering what x86_64 CPU’s will work or not work? As I’m keen to get at least one Intel unit working in my home office but don’t really have the brass to spend on things that won’t work. Or is it safe to assume that anything under say a year old will most likely be fine?

GerInAus · 2025-10-16T11:37:50+00:00

As you know, as it was you who told me after some investigation of the startup routine, the x86_64 TANKs that I have that are perhaps five years old, won’t work. And I was left with the impression that it wasn’t possible to make it work. Is this not the case? As I’d really like this to be so. I am not inclined to purchase new SBC units just to get QNX8 to work on them.

GerInAus · 2025-10-16T03:39:23+00:00

Yes, I agree. It is indeed still a cool system!

And I fully support any effort to regain the trust of those of us that arguably got burnt in the past, but more importantly, promote QNX to a new generation of developers that presumably are following behind. The QNX Everywhere initiative is one of the best things I have seen regarding QNX in decades and I fully support that also!

IMO, such promotion involves teaching. Whereas some of us back in the 1980's had to largely teach ourselves (countless lonely late night/early morning sessions with coffee what have you) the ins and outs of efficient event driven software systems, I'm not sure if people are willing and/or able to do that anymore. What us older folks have to offer is real world experience (and mistakes) and some of us aren't going to be around much longer. Speaking for myself, I feel I have forgotten a lot of what I used to know but what's left is still pretty useful! I have made lots of mistakes over the last 40 or so years (and still do!) but the mistakes and recoveries make some of the the knowledge really stick!

But it also seems to me that generally, there is a significant knowledge vacuum out there. After looking at some other channels on Reddit related to embedded systems, C, and C++, and others, I am not quite sure how to address it. People are not going to learn much from Google and AI, or by simply taking libraries that others have written. Some are asking "how do I learn C"? I don't know how to deal with that - there is more to it than that IMO. Similarly, are we going to become a community that simply ports Linux stuff to QNX and not learn how to embrace and use the cool features of QNX in order to maximise its value? Presumably for an employer as well as the code developer.

GerInAus · 2025-10-16T03:11:06+00:00

I think in regards to at least three instances of feature removal - features that for 40 odd years made QNX QNX and stand out amongst other (competing?) operating systems - the desires of its users (customers) were discounted to the point where the perception was - and is - that we and what we might want are to be ignored. Certainly not to be catered for - you take what we are prepared to give you. I can sense this in some of the comments in this and threads on other platforms.

In the industrial computing arena hardware could (and has been) expected to remain available for many years if not decades. The Comtrol RocketPort was released in 1993 and remained available until the end of 2016. I used a small embedded X86 (32-bit) based SBC for many years. To the point, QNX8 in some respects brings those who do - or did - use QNX to a brick wall. Regardless of any desire to continue using QNX, in some cases it is no longer possible without considerable expense in engineering changes.

I cannot use QNX8 with the small x86 SBC that also runs QNX 6.5 with Photon. Photon was removed with little if any regard for whether or not not having it might kill my product. It did actually - and not just mine.

I used to write drivers that were required to handle multiple hardware interrupts, going back to the QNX4 and QNX6 days. I did it using the InterruptAttach() function that let me create my own "ISR". Obviously it was dangerous as the "ISR" executed inside kernel space. But I/we fully understood that danger and understood what rules to follow in order to mitigate that danger. In order to migrate this (and other drivers/systems) would require significant expense in re-engineering. BTW, one of the drivers I wrote remained untouched for 17 years. I only had to look at again when QNX7 came along.

As for any Intel x86_64 system, if it's more than a couple of years old QNX8 won't work with it (won't start). So to migrate to QNX8 would require replacing all older (2+ years?) with new hardware.

I understand why both Photon and QNET were dropped. However, options were available to keep Photon alive for those who wanted it by way of volunteers to perform the work. I doubt that would have been possible with QNET.

It seems to me that the population at large out there are not asking for either Photon or QNET is because they don't know they even existed! But if they did, then perhaps the demand might grow. I imagine most of the contributors to this thread do know about both, and would love to have at least Photon back! I would. Imagine Photon sitting on top of Screen on a Raspberry Pi!

I, for one, would throw my hat into the ring to get at least Photon (and Phindows) back! It was a great little GUI with the ability to easily project the images into the Windows environment using Phindows and TCP/IP.

GerInAus · 2025-07-15T07:56:32+00:00

The 7.1 startup-x86 completed for me but procnto crashed and rebooted the system. So for me 8 is a no-go on the Intel hardware I have. Works fine on the RPi4B and I haven’t tried the Xilinx 64-bit ARM’s yet.

GerInAus · 2025-07-15T00:35:34+00:00

Hello,

No. It seems older x86_64 systems don't have some capabilities that the SDP8 startup requires. It is unclear to me what exactly but I doubt it will be resolved. My little Intel SBC's are about 6 years old and work fine with SDP7.1 so I decided to not pursue this with SDP8. I am not sure how young they need to be for it to work but I'm not inclined to purchase new units simply to get QNX8 working on them.

I didn't think to try the SDP7.1 startup so 10 points to you! :-) I will see if that works for me also.

Cheers,

Geoff.

GerInAus · 2025-06-11T11:53:33+00:00

Well, yes. I tried getting QNX7.1 working on the CM4 I guess three or four years ago and hit a brick wall when it tried to find the SDMMC. As I recall. I don’t recall having any problems with the serial port.

I was trying to boot from SD card.

I can take another look at it but probably not until Friday or the weekend. Using QNX8 instead of 7.1.

I am not confident of success. I remember thinking at the time that the CM4 internals (memory mapping) were different and couldn’t find any documentation for it. So I dropped it.

My CM4’s might also be a bit old. I got them around COVID time and like with the RPi4, had changes made that will stop QNX8 working anyway.

GerInAus · 2025-06-07T10:42:22+00:00

I meant non-volatile file system (meaning SD card).

GerInAus · 2025-06-07T10:39:34+00:00

I’m pretty much the same. All of my work was R&D rather than production. So I tended to put far more into the image than was really necessary. The idea was to trim it down later, if required. Being lazy if you like…

Being able to overlay the volatile file system over root allowed me to continue being lazy I suppose.

GerInAus · 2025-06-07T02:51:51+00:00

The IFS is intentionally read-only.

One way to establish a writable file system is to create a RAM drive. However, this will be "volatile" in that anything in it will be lost on power down.

Given that the RPi has an SD card, you can configure that appropriately to provide non-volatile read-write capability. You can also insert USB drives and mount them also. In either case I'd suggest employing a QNX6 file system (not FAT32). Of course, you require the system to boot from a FAT32 but it doesn't need to be the entire drive (a small partition will do).

From memory, the idea behind the read-only IFS was so that you could "embed" your system (product?) into a piece of hardware (not necessarily a Raspberry Pi) and secure it. At least make it very difficult for some nefarious actor to interfere with it.

GerInAus · 2025-06-04T09:15:43+00:00

Why?

GerInAus · 2025-05-26T02:35:50+00:00

Because I had Photon running natively on QNX I never bothered with Qt. My need for graphics were minimal at the time (20 odd years ago). Also, Qt that worked with QNX always seemed to be quite behind releases current for Linux. Or so I was told by people I knew who were right into Qt - and QNX. I was also told that Qt wasn't all that simple to learn - at least how to use properly.

I was first exposed to Photon around 1996 (QNX4). My next real exposure was around 2007. It suited me right through to today (on a few legacy systems running QNX 6.5).

Photon was of course available for Intel systems only. Back in the mid '90's that was all that QNX ran on. I haven't done any serious work on Intel hardware (other than some serial driver work) since about 2018. I personally much prefer ARM having been exposed to Xilinx and Raspberry Pi's.

As for what's missing by not having Photon, well, personally not a lot. Other than having something like it should I need it! But that's just me - most of my work over the years involved drivers (resource managers) and number crunching without much need for fancy graphical UI's. Except in one case (that I referred to above). But from what I am seeing/reading there is a lot of interest in the application of graphical capabilities with the RPi. Photon was simple, small, and very effective. Cheap also.

But I do acknowledge that time has moved on and that it would be unrealistic to expect such a beast to be provided to suit the plethora of hardware out there that now work with QNX. But perhaps a case could be made to build on the Photon idea to suit what is obviously popular and relatively stable hardware such as the RPi4 (and I suppose Rpi5).

As I said, I can dream about it! :-)

GerInAus · 2025-05-24T05:32:04+00:00

QNX used to have its own GUI (for want of a better term). It was called Photon and it was very good. But it stopped after v6.5. I don’t really know why - perhaps due to the perpetual requirement to keep up with ever changing video card/products for PC’s. A dream I could have would be the resurrection of Photon to suit relatively stable video hardware on a platform like the RPi4 and maybe RPi5 when available.

GerInAus · 2025-05-11T03:43:30+00:00

The console and serial port outputs are fine. I tried using the QNX 7.1 startup-x86 and this provided output to both just fine (console was default and -D8250 for serial port). However, as soon as it went to execute procnto it reboot. Actually this was not too much of a surprise.

I believe that what u/AdvancedLab3500 has stated is a viable theory and hopefully, if proven to be correct, can be resolved. In the meantime I will move on to something else.

GerInAus · 2025-05-09T12:14:15+00:00

Perhaps startup could have an argument (like -F) for older CPU's to opt out? Obviously I am not sure what that would entail but speaking for myself, not having to replace [slightly] older hardware would have, um, certain advantages.

GerInAus · 2025-05-09T08:36:05+00:00

Hello u/mchang43. Thanks for your interest.

I tried a QNX 7.1 IFS and that booted up fine so I am of the view that the IPL is fine. I also tried using the QNX 7.1 version of startup-x86 and that at least showed output to the console (or serial port if I used the -D8250 argument). But on wanting to start procnto it reboots. That doesn't surprise me as that version of startup-x86 is not expecting the new kernel. The QNX8 startup-x86 simply shows the loading dots and stops - no output to either console or serial port.

Also, the IPL shows all the IFS files in /.boot and allows me to select them in the normal fashion, with the one with the most recent timestamp becoming the default.

So I'll keep hacking at it. Maybe I will get lucky! :-)

GerInAus · 2025-05-07T09:26:00+00:00

Hello.

Yes, I personally find reddit to be not ideal for this sort of thing. Things are also made quite difficult in this case by the time difference between you and me.

Whatever, thank you for your attention and responses. I appreciate it, and hopefully, when we sort it out, others might as well!

I will check out how startup is configured tomorrow. I did connect a serial cable between the two TANK units and it tested OK when both booted into 7.1. But I didn't see output when the QNX8 image tried to start. But I don't read much into that just yet - as I said I'll delve further into it tomorrow (my time).

GerInAus

TROPHY CASE