The weirdest QNX bug I've encountered (2021)
mental-reverb.com
mental-reverb.com
"Then QNX was bought, source code access was revoked and the community largely withered away. Questions were increasingly asked via private support tickets directly to QNX, locked away from the public. QNX know-how becomes harder and harder to acquire, open source software for modern QNX releases is essentially non-existent and the driver situation is a catastrophe. The QNX kernel is the most beautiful and interesting kernel I have ever had the pleasure of working with, but it lies in the shackles of corporate ownership."
It's sad.
QNX was originally an independent company. During that period, anyone could get a free copy of QNX for personal use. It wasn't open source, but it was available. It's POSIX-compatible, so it was a supported target for Gnu, Firefox, and Eclipse. We used QNX for our DARPA Grand Challenge vehicle in 2003-2005, and all that code was developed on desktop QNX.
Then QNX was acquired by Harmon, the successor to Harmon-Kardon, which once made home audio components and pivoted to car audio. They were thinking car infotainment. Harmon didn't really know what to do with an operating system, especially since the big market was systems for industrial control and point of sale. So eventually they opened the source.
Then QNX was acquired by Blackberry, the early smartphone company. They closed the source, very suddenly. They even killed off the free version for personal and educational use. So all third party open source development stopped. Blackberry eventually shipped a phone that ran QNX, but they were not powerful enough as a company to keep a third phone standard going. So Blackberry went to Android.
Blackberry killed off the self-hosted desktop environment, and users now had to cross-compile from Windows.
And QNX became more of a niche product than ever.
They absolutely were, which is the tragedy of the whole thing, people absolutely loved their products and strongly preferred them to everything else on the market.
Instead of recognizing the game changer that the iPhone was they slept on the market and didn't do much to bring big touch screens and rich internet applications to their platform.
It was a slow and agonizing death.
But they made that error long before buying QNX. By the time they bought QNX they had probably lost too much ground to turn it around.
There were other issues that were much smaller in the bigger picture like android app support on BB10 coming a little late as well as the devices in general had a somewhat underpowered SoC. All of these contributed to slow adoption, but the fact they were promoting new models of the Bold while their warehouses were full of the Z10 was really what did them in.
That's kind of exactly what I meant, though.
Nokia made an almost identical mistake, before the Microsoft acquisition, by not doing a timely migration path from Symbian to Meego. The old business was a cash cow so they kept it going, not taking the new thing seriously.
Not familiar with BB lineage I checked the Wiki for the release dates and ... wow.
Not quite an offtopic: people bash me when I point out what Burning Platform is the result of the previous Nokia shenanigans, so blaming it all on Elop is like blaming the fire for charring your steak you forgot on the BBQ.
Concur. I had a Passport and it was a deal-changing sort of device.
The universal inbox was amazing technology, which totally reworked how a pocket comms device worked. Sadly as companies gradually dropped BB10 support, although you could run Android messaging clients, those didn't integrate with the BB10 inbox, so gradually the phone got less and less useful.
This should have been a reason to demand open comms protocols and legally require all comms-tools vendors to support 3rd party clients.
Today, I use Ferdium to connect almost all my comms apps into one client app, but it's just a bloated Electron thing that forcibly unifies dissimilar web apps. It's clever but it's not really a solution. It's a herd of elephants on a seesaw in order to crack a peanut.
Never mind laws about cookie banners, it should be a procurement requirement for all government agencies in the free world that all vendors must support a documented protocol so that native client apps can connect.
To Slack, Whatsapp, Signal, Telegram, Google $ChatAppOfTheMonth, MS Skype|Teams|Whatever.
No web apps, no Javascript, just mandatory lowest-common-denominator local rich clients, so that tools like BB10 could talk to everything.
Frankly I don't care if it doesn't support sound or video. I will go quite far to avoid that anyway. But text, basic formatting, smilies, maybe embedded static image files and attachments.
Nobody would lose from this.
Android is open source, leading there to be several Android-based distros like postmarketOS and popOS. they are able to take advantage of the android software ecosystem and so are able to have apps you'd actually want to run on them
https://en.wikipedia.org/wiki/List_of_custom_Android_distrib...
Pop!_OS is based on Ubuntu.
There are lots of AOSP-based mobile OSes, including LineageOS, Graphene, Amazon's Fire OS, CalyxOS and /e/ OS.
https://en.wikipedia.org/wiki/List_of_custom_Android_distrib...
But neither of yours are.
I once told a QNX sales rep that their problem was not being pirated. It was being ignored. Today, I'd say "forgotten".
https://github.com/vocho/openqnx/blob/master/trunk/lib/c/1/o... quotes the license as follows
> You must obtain a written license from and pay applicable license fees to QNX Software Systems before you may reproduce, modify or distribute this software, or any work that includes all or part of this software. Free development licenses are available for evaluation and non-commercial purposes. For more information visit http://licensing.qnx.com or email licensing@qnx.com.
Re-implementing the QNX 6 kernel in Rust would have been a nice project. It's only about 60 kilobytes of code.
All the kernel does is pass messages around, dispatch the CPU, and run timers. All device drivers are in user space. You can build a boot image with whatever processes you want running at startup, so you can have device drivers at boot.
For smaller embedded applications, everything might be loaded at boot. You don't have to have a disk or file systems. There are embedded real-time applications where having zero persistent state is desirable.
I'm very surprised that there aren't any projects based on the last available open-source version. This sort of thing usually happens when the company behind an open-source project that has a large community does something stupid to the project. Mapbox is one such example.
Their moat is supposedly their ASIL certification, but I see that value shrinking more and more over time for the following reasons:
1. If your product has a software-related failure, customers won't care about all of your certifications. Only the end product.
2. I'm not convinced that the QNX kernel is less buggy than the Linux kernel. Also, most failures don't tend to be kernel related.
If you're in a market where a ASIL certification is needed, the customers ONLY care about this certifications. I keeps them out of jail.
Edit: I wrote a rather highly rated HN comment about why Red Hat makes money last year: https://news.ycombinator.com/item?id=35588297
Currently working in a project where ASIL D is reached by having an independent microcontroller, whatching out the whole QM mess.
Define “required”. If every single legal department at every single major automotive company says “we must obtain ASIL-B certification for our gauge cluster software or we can’t sell cars”, does it matter if regulators don’t overtly mandate it? The legal environments of all of the major automotive markets make it a de facto requirement.
(someone else might come along and certify it themselves, effectively acting as a middleman, but then they're going to get most of the money)
At least SDP 8.0 overhauled the kernel to not be locked to a single thread anymore, which is nice IMO
Can you elaborate on this? How is it "low"
Other than that, the blog post was very interesting, I learned a bit of history of QNX, and concluded that I should avoid it.
- very bad port of GCC was buggy and generated bad code. it was the result of some idiot blindly haphazardly applying a ton random incoherent patches to try to get it to build instead of porting it properly. (to be clear mainline GCC at that time was fine; we re-ported it ourselves instead) - and, of course, they used their own faulty compiler to build their libraries and services ;) causing unknown carnage waiting to be discovered.
- malloc broken (heavy use under multiple threads causes heap corruption). replaced with dlmalloc.
- serial port driver broken. rewrote a new one.
- intel network card driver crashes. replaced hardware with 3com to survive.
- certain math library functions broken (iirc, fmod). replaced.
and so on and on.
it doesn't matter what certification your RTOS (or whatever) has. if you cannot examine the source, rebuild it, etc. (oss or private source available) - it cannot be trusted. this was one of the worse examples, but it's always like this with "proprietary" OS/toolkits.
It's really interesting to see the current "state of the art" in terms of the types of bots that get past the particular CAPTCHA implementation this site uses.
It's a very rudimentary type of CAPTCHA, the kind that anything developed within the past 5 years would probably get past with at least 30% accuracy (logarithmically skyrocketing to >90% within the past ~2 years).
So the post quality is somewhat distributed across a spectrum - on one end, dumb CAPTCHA OCR/processing <=> "slightly better than Markov chain model replication", and at the other end, clearly more sophisticated systems that more easily pass the CAPTCHA and generate more interesting posts.
What's curious is that 90% of the comments are rudimentary. There are very few interesting spam posts. I'm trying to figure out what to make of this.
I'm picturing some majority of utterly outdated spambot infra, still out there, scanning the Web for WordPress/XSS-level stuff, and finding success on blogs like these... and that these old bots are the only systems of their kind out there, because all the spammers collectively gave up with reCAPTCHA and CloudFlare protecting almost all meaningful concerns, with moderation following not too far behind.
Kind of makes sense.
But it's really depressing to compare these old clunky bots that are kind of cute (in a way) to the upgraded versions - the current-era tech, that get past moderation... and effectively pass the Turing test :'(
If it was truly AI-generated, I'd expect a random seed as part of its input, and unless there was very little entropy, I'm not sure it would chance upon the same exact formulations over and over. Maybe they hadn't tested the randomness aspect well in the training and it'd learned not to attach much weight to that beyond the first word or two.
They mostly make positive comments about the website/article/author to have less chances of being deleting. The end goal being linking their website to improve SEO.
Unless you are the kernel, and you can demonstrate that your loop is "safe" via some set of static analysis.
For example in an embedded system: a watchdog timer that you don't service during the execution of some context. If you fail to complete your task within the time, the kernel or entire system is rebooted.
For example in a VM-like system, you give the code some amount of "fuel" or "budget", if it exceeds that budget, the process/tasklet/whatever is terminated by the VM.
It's not a general solution to the halting problem, but a practical one.
Neither are pleasant, but they don't compromise system integrity and as such are not substantially different from other kinds of crash bugs.
Categorically that's the exception, not the norm.
For always-on systems, "by themselves" is pretty critical, as they can result in DOS style bugs/attacks as illustrated in the parent article. The infinite loop is most useful e.g. for the scheduler or other event loop code, which by definition this style of code does a lot more than "only" spin the CPU.
For systems capable of long-term power saving operation - the system can go dormant (either no power draw or very little). An infinite loop can be the difference between weeks of power off a battery, or days/hours.
edit: added parenthetical