
Building a QNX 7 Desktop - desiderantes
https://membarrier.wordpress.com/2017/04/12/qnx-7-desktop/
======
Animats
That's nice, but sad. Until QNX 6.5, there was a full windowed desktop
environment, with the Photon window manager.

I used QNX on the desktop when developing a DARPA Grand Challenge vehicle from
2003-2005. Back then, at QNX 6.21, you had the window manager, the Eclipse
development environment, Firebird (Firefox before the name change), and
Thunderbird. Then QNX marketing cut off the free version, and all the free
software projects stopped making builds for QNX. Desktop usability went
downhill from there.

The desktop environment had very consistent performance, because QNX doesn't
swap. (It's a real time system, after all.) I could run the real-time vehicle
control system and simulator at a higher priority than the desktop and not
have it miss a timeout while doing compiles and web browsing at a non real
time priority.

I miss QNX. It's much simpler and saner than Windows or Linux. Yet all of
POSIX is available. It's what home routers and similar devices ought to be
running instead of Linux.

~~~
shmerl
_> It's what home routers and similar devices ought to be running instead of
Linux._

The bummer is that it's not FOSS.

~~~
Frenchgeek
Funny there doesn't seem to be an OSS attempt of something like it... ( Or my
google-fu is weak )

~~~
frik
Google Fuchsia is a capability-based, real-time operating system (RTOS) being
developed by Google.

[https://en.wikipedia.org/wiki/Google_Fuchsia](https://en.wikipedia.org/wiki/Google_Fuchsia)

15 years ago I waited for GNU Hurd, but now I am very interested how Google
Fuchsia turns out. What I read it shapes up nicely, and I can imagine we all
will use it in near future instead of Windows and other binary blob legacy
operating systems; it might also replace Linux as Android kernel - but that is
still just speculation.

~~~
Animats
That's going to be interesting. Some of the people at Google working on it are
ex-QNX people.

~~~
bitmapbrother
I know some are ex BeOS people, but I haven't heard of anyone from QNX on the
project. Apple did hire the founder of QNX not too long ago, though.

------
jacquesm
Nice to see QNX getting some love on HN.

QNX is one of the most ground breaking OSs that I've seen in real life and had
the pleasure to work with for a good five years as my 'day job'. It was so
good that everything else felt (and still feels) both sluggish and cumbersome
by comparison. Imagine an OS that _never_ freezes, one that allows you to
restart device drivers and upgrade them on running systems. Use remote
resources as if they are local. Control hardware in real time from the same
machine that runs your desktop. What held it back is that the company that
sold it (Quantum Software in Montreal, Canada) wanted to charge for every bit
that left their premises and for a long time it looked as if that strategy was
going to win them the race.

Then FREEBSD86 happened and suddenly a lot of router vendors had an
alternative, then came Minix and finally Linux. Now none of those three are as
good at what QNX does best: hard real time, message passing, clustering. So
the fit for these other OS's to occupy QNX's niche was never a good one. And
so Quantum stayed alive a little longer. I petitioned them for a 32 bit
version when they were still fully behind their 16 bit OS and refused to even
consider making a 32 bit version because their old product was selling well
and because backwards compatibility must have been a hard nut to crack for
them.

So, in about 2 years I wrote a kernel that lifted the userland mostly from
minix and linux. Added a network stack and if not for some unfortunate affairs
it would have been released as open source.

In a way I'm happy that never happened because I would have been the slave of
the rest of the world maintaining that. It's one thing to push an application
into the world, those things have a life-span. But an operating system will
easily outlive its creators. The fact that Quantum was super aggressive when
it came to IP also didn't help the chances of a release.

Every day your life is touched by 100's if not 1000's of instances of QNX
still quietly chugging away somewhere in the belly of the systems that keep
our infrastructure working.

I'd love to see a 64 bit open sourced version of QNX take over, there is
really no substitute for an OS with a sense of time. But I'm afraid it will
have to stay a dream, the stewards of QNX have never really dared to commit to
open sourcing it for real, I've been asking them for long enough now that I
feel that will simply not happen.

~~~
i336_
> _Imagine an OS that never freezes, one that allows you to restart device
> drivers and upgrade them on running systems._

I'm curious how much of this depends on the driver behaving sanely at load and
unload time, cleaning up after itself, gracefully handling unexpected
initialization-time state, etc.

Graphics drivers on Linux are a particularly sad example of what I mean - for
example while tinkering with an old PC with I-don't-remember-exactly-what
onboard graphics chipset a little while ago, I noted how the framebuffer
driver boasted that upon unload it would switch back to 80x25 (which it did!
:D).

At the other end of the spectrum, while doing some KMS/DRM debugging on my old
ThinkPad X61 at one point, unloading the driver would result in a frozen
display - but not a frozen system, so my test cycle became "make; rmmod ...;
cp .....; insmod ...". It worked absolutely perfectly (with just a ~250ms
screen freeze), but it's kind of sad that this inelegance is the current state
of affairs.

> _Use remote resources as if they are local._

I am particularly frustrated by Linux's lack of IPC in practice. The fact that
I can CONFIG_SYSVIPC=y - that that option exists - means nothing: _nothing I
know uses it, and I have no idea_ how _to use it._ OS-level IPC is not common
knowledge. It's maddening.

It's sad the best option here is Erlang: that results in "yay message-passing"
being restricted to large monolithic systems. I have wanted a message-
passing/IPC-based command shell since forever. That's the one thing I wish I
knew how to build.

> _Control hardware in real time from the same machine that runs your
> desktop._

:) you know what this reminds me of? The real-world version of Symbolics Lisp
machines. With those you could do anything you wanted, literally - they had no
MMU, and I think (I might be guessing...) the memory map was static. Not quite
Commodore-64, but the same ideas were there.

> _So, in about 2 years I wrote a kernel that lifted the userland mostly from
> minix and linux. Added a network stack and if not for some unfortunate
> affairs it would have been released as open source._

Very very nice. Hopefully my question is answerable if I phrase it like this:
is your code still in use out there, and if so, what sorts of things would I
be doing (banking, using electricity, etc etc) if I were indirectly using it?

More directly, if you can actually provide more info about this kernel, I'm
very curious.

> _In a way I 'm happy that never happened because I would have been the slave
> of the rest of the world maintaining that. It's one thing to push an
> application into the world, those things have a life-span. But an operating
> system will easily outlive its creators. (...)_

I think I should mention AtheOS here - this was a little hobby x86 OS one guy
did in his spare time. Everything, kernel up, all the way to a desktop with
applications. Sound, video, I/O... file system... SMP... C++ GUI... POSIX...
threads. Took 6 years (1994-2000).
[https://en.wikipedia.org/wiki/AtheOS](https://en.wikipedia.org/wiki/AtheOS)

Eventually the project was abandoned, but in 2002 a small group of
enterprising developers took AtheOS' GPL'd codebase (\o/) and built Syllable
from it:
[https://en.wikipedia.org/wiki/Syllable_Desktop](https://en.wikipedia.org/wiki/Syllable_Desktop),
[https://syllable.org](https://syllable.org). They tidied up the UI a bit,
added USB support and other things, and make slow progress forward.

Now, Syllable is certainly not QNX. But I wanted to say this: the person (or
group) who does the sprint and gets to the point of "ok, it's out there now"
doesn't have to be the same group that eventually maintains everything. It's
an interesting idea to weigh up, because it instantly puts an upper bound on
total development time. That time might be years, but 5-6 years is not eg 20
years. (Methinks it'll be interesting to hear Linus reflect on kernel
development after he's retired and can say what he really wants to, and can
step back far enough to consider all of his ~40+ years of involvement.)

Now, sure, with a "sprint then step back" approach it's impossible that there
won't be disappointment and frustration with the way some things end up being
done by the new gatekeepers, but if the implementation is sketched out
sufficiently well and the time is taken to get the fundamentals (and the
thousands of little things) correct, that could well mitigate the worst of
that problem.

The reason I say all this is because I noticed
[https://news.ycombinator.com/item?id=14230456](https://news.ycombinator.com/item?id=14230456)
which pointed to
[https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop...](https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop#c_bpjfb3),
which said at the bottom:

> _I’m with Animats that it’s surprising that nobody is cloning QNX in these
> microkernel projects given it’s architecture is open. Past any patent
> protection, too, if they had any._

Such an approach would bring many benefits.

Being able to pick the license is the clear winner, of course. It would be an
interesting nut to crack, because license changes (at least after public
releases) are inelegant, and always run the risk of compromising confidence.
This would take some interesting discussion: I personally hate the GPLv3, for
example, but "GPLv3 or contact us" might be attractive to interests that need
to draft a license from scratch (at least ideologically - of course a
commercial license template would be filed away).

Another very attractive benefit I see is that everyone would be able to debate
the finer points of QNX's existing design as implemented, and debate what
parts of the design are worth copying and what should be reconsidered.
Benchmarking different workload types as well as collecting anecdotes could be
useful here.

I won't deny that QNX as a whole is huge, and that while building rebuilding
the kernel in 4350 LOC
([https://news.ycombinator.com/item?id=9477947](https://news.ycombinator.com/item?id=9477947))
might be fairly trivial, building everything else
([http://www.anandtech.com/show/4266/blackberry-playbook-
revie...](http://www.anandtech.com/show/4266/blackberry-playbook-review/3)
says the kernel is 100K LOC, I presume this probably includes all the drivers
and possibly some of userspace) is going to take, well, a while.

Haiku ([https://www.haiku-os.org/](https://www.haiku-os.org/)) has been in
slow development since 2001, and only got to R1 in 2012. So, 11 years - for a
small team of enthusiasts.

I guess the next question would be, is an open reimplementation of QNX a sane
idea?

QNX is associated with a bunch of different ideas. When you say "open-source
reimplementation of QNX that does X, Y and Z," you get to run with the
existing context. So, rebuilding QNX could be sane in that regard.

But... Haiku's binary compatibility _almost_ feels like a committee meeting
for the sake of meeting now. Haiku is locked to GCC 2.95 (and had to backport
a bunch of critical fixes in order for that to be viable), doesn't support
BeOS R5 on PPC aka the BeBox (which is understandable, but notable), a bunch
of private APIs aren't going to be implemented, and _for all that_ , only a
handful of applications work.
([https://en.wikipedia.org/wiki/Haiku_(operating_system)#Compa...](https://en.wikipedia.org/wiki/Haiku_\(operating_system\)#Compatibility_with_BeOS))

The question is, how set-in-stone are QNX's various APIs - ie, how much of a
_non_ -moving target are they, how well-documented is _everything_ , how well-
known are the bugs?

Obviously binary compatibility itself would be a good idea for an open-source
reimplementation of QNX, there are quite a few more apps for QNX than BeOS.
But the kind of apps running on QNX are the kind that you generally want to be
able to leave running for a few years knowing there won't be a scheduling
glitch anytime soon - the margins with QNX are _a lot_ tigher than BeOS ever
was.

:v

I need to go out now and I want to post this now instead of when I get back in
a few hours, so I'll leave it there.

I can envisage that redoing QNX might be a "...dude. No. Too much work. Don't
go there." in terms of the investment/reward, _with all the details taken into
account_ , but I don't know what all the details are, and with the little I do
know it sounds like it could be well worth it.

~~~
jacquesm
Wow, that's quite the comment :)

Ok, from the top:

> I'm curious how much of this depends on the driver behaving sanely at load
> and unload time, cleaning up after itself, gracefully handling unexpected
> initialization-time state, etc.

Well, drivers are just processes. So as long as they don't leave the hardware
in a totally borked state a re-start of that process should re-initialize the
driver and as long as that works I see no reason why the driver would not be
able to restart and function.

> It's sad the best option here is Erlang: that results in "yay message-
> passing" being restricted to large monolithic systems.

And Erlang is soft real-time as opposed to QNX's hard real-time. For non-
interactive backend stuff it doesn't matter that much but for front-end or
hardware control it matters a lot.

> is your code still in use out there, and if so, what sorts of things would I
> be doing (banking, using electricity, etc etc) if I were indirectly using
> it?

I never released other than some very fancy routers where it was used under
the hood without anybody being the wiser, but just about every industrial
plant runs QNX somewhere, and quite possibly still the 16 bit version on
ancient Compaqs.

> I guess the next question would be, is an open reimplementation of QNX a
> sane idea?

You're asking the guy whose front page post reads 'how to sort 2 tons of
lego'? :)

I'm not always the best in making decisions when it comes to what makes
economic sense. But I think the world of computing would be a much better
place if we went microkernel. Stability and reliability and real time in my
book easily trump performance.

> how set-in-stone are QNX's various APIs - ie, how much of a non-moving
> target are they, how well-documented is everything, how well-known are the
> bugs?

QNX is incredibly simple at the core. The hard part was to get the interrupt
handlers work right, after that it was a walk in the park. But I do recall
having a footswitch connected to the reset button because I got tired of
diving under the table to reset the machine. No VMs back then...

> Obviously binary compatibility itself would be a good idea for an open-
> source reimplementation of QNX, there are quite a few more apps for QNX than
> BeOS.

I would not care about that at all, but I'm sure you could do a ABI layer if
you really wanted to.

> "...dude. No. Too much work. Don't go there." in terms of the
> investment/reward, with all the details taken into account,

Fortunately when I started that trick I didn't know just how hard it was. And
eventually QNX did come out with a 32 bit version (2 years later or so).

But an open source version of it would make big inroads into all kinds of
embedded systems. But good luck getting the likes of NVIDIA to make a driver.

~~~
i336_
>> I'm curious how much of this depends on the driver behaving sanely at load
and unload time, cleaning up after itself, gracefully handling unexpected
initialization-time state, etc.

> _Well, drivers are just processes. So as long as they don 't leave the
> hardware in a totally borked state a re-start of that process should re-
> initialize the driver and as long as that works I see no reason why the
> driver would not be able to restart and function._

Yeah. Fair point. I think I was conflating OS architecture with buggy drivers
there.

>> It's sad the best option here is Erlang: that results in "yay message-
passing" being restricted to large monolithic systems.

> _And Erlang is soft real-time as opposed to QNX 's hard real-time. For non-
> interactive backend stuff it doesn't matter that much but for front-end or
> hardware control it matters a lot._

Ooooh. Good point. Now I think about it, hard real-time _and_ message-passing
is... I can see why people like it :) those two things together are something
I've been trying to figure out for a very long time.

>> is your code still in use out there, and if so, what sorts of things would
I be doing (banking, using electricity, etc etc) if I were indirectly using
it?

> _I never released other than some very fancy routers where it was used under
> the hood without anybody being the wiser, but just about every industrial
> plant runs QNX somewhere, and quite possibly still the 16 bit version on
> ancient Compaqs._

Nice. Very nice :)

(I noticed from a comment elsewhere that it was a 32-bit reimplementation when
QNX was 16-bit, and that you dropped it in without anybody realizing. That is
both insane and awesome.)

>> I guess the next question would be, is an open reimplementation of QNX a
sane idea?

> _You 're asking the guy whose front page post reads 'how to sort 2 tons of
> lego'? :)_

Oooh! That was _you_! That was a really impressive design. I found the "jet of
compressed air" so reminiscent of "use a desk fan to blow the box off the
conveyor" in that apocryphal "$2m consultant" story :)

> _I 'm not always the best in making decisions when it comes to what makes
> economic sense._

Sometimes economic sense isn't the best driver of things that become
revolutionary ideas. Linux isn't overall a bastion of best practices nowadays
(sadly) but it was started as "just another hobby project" that happened to go
viral (in the 90s, no less).

But even before that, UNIX itself was purely academic and its designers
retained the "information wants to be free" mentality, continuing to quietly
release updates via tape even after the licensing wars began.

But besides all of that, sitting around all day and figuring things out
without commercial focus (at least initially) - basically just having fun
being creative - can be the most educational. Oh, and fun. :D (I've only just
recently figured this out...)

> _But I think the world of computing would be a much better place if we went
> microkernel. Stability and reliability and real time in my book easily trump
> performance._

I don't fully understand why Linus thinks that a monolithic kernel approach is
honestly more efficient. I can't help but wonder if it was a case of "it was
easier for me to do it that way, shhhhhh", or what. QNX is a microkernel that
also offers hard real-time guarantees. I find it difficult to believe that
microkernels do not offer practical performance in the face of such
capability. But then again, I'm admittedly not an OS expert. (Although
[https://en.wikipedia.org/wiki/Talk%3ANanokernel](https://en.wikipedia.org/wiki/Talk%3ANanokernel)
\- thanks Google for showing me the talk page instead of the article! haha -
cleared things up nicely.)

I can very easily understand microkernels being more stable and reliable.
(Does QNX have anything like Minix's reincarnation server?)

Regarding realtime, I've personally been particularly interested in UI design
for as long as I can remember, and one of the things I've been trying to crack
for ages is how to get rock. solid. animation. - with consistent fps
regardless of what else is going on - and I've finally concluded that there
are no alternatives to doing this from the kernel up.

iOS got fluid animation on a 412MHz CPU, 137MHz LPDDR and 60MHz GPU
([http://blakespot.com/ios_device_specifications_grid.html](http://blakespot.com/ios_device_specifications_grid.html))
by doing screen updates with hard realtime, AFAIK. What more needs to be said?
:P

Also - being able to do realtime hardware I/O from hacked-together Perl sounds
like... yes please!

>> how set-in-stone are QNX's various APIs - ie, how much of a non-moving
target are they, how well-documented is everything, how well-known are the
bugs?

> _QNX is incredibly simple at the core._

That's promising!

> _The hard part was to get the interrupt handlers work right, after that it
> was a walk in the park. But I do recall having a footswitch connected to the
> reset button because I got tired of diving under the table to reset the
> machine. No VMs back then..._

Wow, hah. (Hopefully this was on an embedded box with no/a skippable BIOS? :P)

Nowadays a decent i7 (a _decent_ one) can get 200MHz emulated performance in
Bochs, AFAIK.

And there are tons of other emulation and simulation options out there: on my
way to relocating [http://www.marss86.org/](http://www.marss86.org/) I turned
up [https://github.com/cap-lab/tqsim](https://github.com/cap-lab/tqsim) and
[http://www.unicorn-engine.org/](http://www.unicorn-engine.org/). And those
were just what I unintentionally stumbled on, not what I was deliberately
looking for.

FWIW, MARSSx86 is a fork of QEMU 0.14 with a 200kHz cycle-accurate
simulator/instruction logger that kicks in either when you run a command in
QEMU's console or in QEMU's launch parameters. So when it's off QEMU runs at
full (emulated, non-virtualized) speed.
[https://github.com/avadhpatel/marss/graphs/contributors](https://github.com/avadhpatel/marss/graphs/contributors)
shows that development wound down ~halfway through 2012, with very minor
updates since. But it's not dead.

Obviously these tools are not perfect, but seem like they might make
"serious"/in-depth OS development a tiny bit more fun and accessible. And
besides these there's also DOSBox's built-in (and eminiently-hackable)
debugger that you can enable at compile time (IIRC).

I also remember stumbling on a little assembler-emulator for DOS that could
"play" the assembly backwards, which I've always thought was quite cute. It's
easiest to link to the last time I mentioned it (you'll see why):
[https://news.ycombinator.com/item?id=13807599](https://news.ycombinator.com/item?id=13807599)

>> Obviously binary compatibility itself would be a good idea for an open-
source reimplementation of QNX, there are quite a few more apps for QNX than
BeOS.

> _I would not care about that at all, but I 'm sure you could do a ABI layer
> if you really wanted to._

Oh, okay. Hm.... could this ABI layer itself be a server to the microkernel?
:D :D

>> "...dude. No. Too much work. Don't go there." in terms of the
investment/reward, with all the details taken into account,

> _Fortunately when I started that trick I didn 't know just how hard it was.
> And eventually QNX did come out with a 32 bit version (2 years later or
> so)._

Heh.

This is very very interesting, then. Depending on how long ago you did this
(sounds like it was a while ago - not sure when QNX went 32-bit) you might
remember quite a bit if you tried to do it again.

And if you did, you've already done the "re-do QNX, fixing all the less-than-
ideal bits that couldn't be identified as such at design time" thing - so
you'd be going over it _a second time_ , with potentially even more refined
results.

> _But an open source version of it would make big inroads into all kinds of
> embedded systems. But good luck getting the likes of NVIDIA to make a
> driver._

Eheheheh. The situation is not nearly that negative now! :D

First, you target Intel. This is simply tedious: there are real specifications
floating around, along with a full GPLv2'd implementation in Linux that "just"
needs normalizing (basically, distilling KMS and DRM out of the picture). As
you go along, you may be able to get some assistance - Intel recently said
hello to FreeBSD:
[https://news.ycombinator.com/item?id=13848258](https://news.ycombinator.com/item?id=13848258),
and I think you could describe QNX to be sort of on the same spectrum/track as
an OS ecosystem in some ways, so that might translate to not-entirely-closed-
doors where/when it would count. HD Graphics is a huge win to have available;
many embedded systems (:D :D) don't have discrete GPUs, and the on-chip GPU
specifies two video heads (IIRC), can handle 1080p+, and generally from the
standpoint of "reimplement QNX" provides an overkill level of hardware
capacity/capability. It would be more than enough to get in the door of making
a serious MVP (that's actually usable), if you will.

With some kind of established thing going on with Intel, work would begin to
try and target AMD, specifically the APUs. This is likely where the NDAs would
start, but it would be viable to do so because a) AMD would be able to see the
Intel-only situation and want to compete and b) I expect there would be some
sort of commercial thing with the OS happening at this point (eg, the MVP
attracting some bites, either from VCs or industry) helping things along.

From there, it'd be a matter of going "hey NVIDIA...?" and either waiting 2E14
years^W ^W for a port or getting specs to help out.

I realize I've naïvely just described a very high-level timeline involving
tens of man-decades of development, a noteworthily large team, and probably a
7 figure budget. Sounds like a ridiculous amount of fun :)

I'll also admit that my experience with C is not quite where I'd like it to
be, and I've never written about an OS before so I'd have no idea where to
start.

But I'm game if you ever feel like doing this at some point. I was thinking of
maybe making a website (hmm, what to call it - I have no idea) so people could
have a hub/point of reference to point to and figure out what to work on and
stuff.

That being said, no rush; this sounds like a fun idea, best to keep it that
way. So TL;DR get in touch if you ever want to pursue this :P

(To clarify - I'm not saying you have to email to reply to this comment, just
that my email's in my profile if you want to get in touch in future.)

------
slobotron
Nice work! Very tempted to try it out on a spare machine. Sure brings back
memories of the fully functional QNX desktop that fit on a single 1.44MB
floppy! [0]

Tangent: It's a shame that Blackberry hasn't captured more of mobile phone
market with the QNX based BB OS10 - I got myself a BlackBerry Passport couple
months ago and find it is a great daily driver for my needs. Square screen
(1400x1400) and physical keyboard ftw.

It's got a rather enjoyable development experience too. Momentics IDE let's
you write QML/JavaScript apps that automatically refresh running instance on
phone after every save, much like one would expect nowadays with React. Wrote
a simple DI.fm Radio Streaming app[1] over a course of few nights - I haven't
had that much fun scratching-own-itch and learning new platforms since playing
with Delphi almost two decades ago...

[0]
[http://toastytech.com/guis/qnxdemo.html](http://toastytech.com/guis/qnxdemo.html)

[1] [https://github.com/slobo/BlackBerry-10-Digitally-
Imported](https://github.com/slobo/BlackBerry-10-Digitally-Imported)

~~~
digi_owl
When not even MS could muscle their way back in after burning their PocketPC
bridge, BB didn't stand much of a chance.

~~~
bluejekyll
Blackberry owned the market though. They were the corporate smart phone. They
lost it all...

Has anyone written about what blackberry actually tried to do to prevent
losing to Apple? My memory is that they basically were convinced there was no
way they could lose their marketshare, so effectively just watched as they
lost everything.

~~~
protomyth
"Losing the Signal: The Untold Story Behind the Extraordinary Rise and
Spectacular Fall of BlackBerry" by Jacquie McNish & Sean Silcoff

Scandal distracting them, playing by the old bandwidth rules too long, and
Verizon wanting an iPhone killer (which is different from RIM/Blackberry's
focus) were the lessons I read. Remember, they hit their max market cap a year
after the iPhone.

------
Theodores
I used QNX as part of the day job in the 1990's, the reason for using it was
real time scheduling and doing stuff for analog broadcast. We had a full 19"
rack of 4 Compaq servers, each of them a very large box for a 75 Mhz CPU, with
redundancy built in everywhere.

Back then QNX was definitely targeted at real time/embedded but you could also
just use it like any other UNIX. Ease of installation to a functional X
Windows desktop on PCs was minimal effort (one floppy?).

Somewhere along the way QNX lost this reason to exist - realtime interrupt
handling etc. - and it being the easy, accessible tool for quickly putting
together real time things, e.g. for broadcast, where the only coding
requirement is simple scripts with the OS making it all work realtime
reliably. In those days you couldn't just use a normal operating system for
such things, it had to be your own EEPROM or something done higher level in
QNX - a quick and dirty solution to some extent, in a good way.

Having read the article it now seems that getting started or up to speed on a
QNX project is no longer something that can be done in an afternoon, it is all
a whole lot less accessible.

~~~
Apocryphon
Isn't QNX's realtime features the reason why it's been integrated into a lot
of automative systems?

~~~
Animats
Yes. It's also used by Boston Dynamics' robots.

Over the last decade, QNX management managed to piss off everybody needed to
support their ecosystem - open source developers, point-of-sale systems
people, robotics people, hobbyists, and even industrial real-time developers.
All the money is is selling to high volume markets, and that meant automotive
and Blackberry devices. But that focus cost them brand awareness and a pool of
people familiar with the thing.

I hope it gets open sourced when Blackberry goes bust.

~~~
Apocryphon
It always seemed to me that QNX and the rise of smart cars was one of the
things that's keeping Blackberry afloat.

------
pavlov
There was a time 20 years ago when QNX was to be the foundation of the next-
generation Amiga.

Gateway, a PC clone vendor, had acquired the rights to the Amiga brand and
technology in early 1997. The company wanted to expand outside the Wintel
space, and Amiga still had major brand recognition in Europe. The new Amiga
would be a PowerPC-based consumer computer built by Gateway and equipped with
the QNX operating system.

It didn't work out, of course -- such was the curse of the Amiga. Here's an
account with some more details of what happened:

[http://www.trollaxor.com/2005/06/how-qnx-failed-
amiga.html](http://www.trollaxor.com/2005/06/how-qnx-failed-amiga.html)

------
rcarmo
Transparent IPC over the network was the reason I set up QNX a long time ago
(back when it was freely available for a bit).

I can't help but wonder how a Raspberry Pi Port would fare - the thing would
be tremendously efficient, and it would certainly increase their popularity.

Edit: well, apparently someone ported QNX 6, but licensing requirements seem
to curtail its use for hobbyists - [https://github.com/varghes/Raspberry-
QNX](https://github.com/varghes/Raspberry-QNX)

~~~
jacquesm
They'll never get it. They could really own the space and be a serious
competitor to RedHat. Especially with all the self-driving car research and
other real time tasks QNX would rock if it were open source.

~~~
asdfghbvcxz
Yup. Completely agree. I worked on a project that moved off of qnx because
dealing with cost and maintainability issues was too much of a pain.

I don't mean maintainability as in the system itself didn't work. I mean the
pain of updating, upgrading, and adding to our system. Maybe the shop I was at
just didn't have things set up well, but as a result we were trapped on a
specific version of neutrino while trying to interface with modern networked
and front end systems. When we can easily upgrade a Linux kernel,
apt/yum/pacman install a package, and have more modern versions of our
toolchains, it was easy to justify the switch. Not to mention not having to
port 3rd party packages we decide to use, which is out of the question for the
closed source ones and frankly just a lot of work for the open source ones.

It honestly felt like we were always stepping back 10-15 years in time trying
to do something on QNX. And unless there is some hidden community I never
discovered in my short stint as a qnx oriented dev, anytime I would stumble
upon a forum for qnx stuff it seemed like the last post was from 2008 or so.
And don't get me started on their online docs. "Oh this web documentation for
<thing> is deprecated. Click this link (that dumps you on the front page of
multi-page, hard to search HTML docs) to go to the up to date documentation."

It really is a shame too, because their IPC setup was insanely powerful. And I
don't think I ever actually experienced an OS crash. The whole OS boiled down
to its IPC concept, and that's what made it so cool and so useful: \- Kernel
module? IPCs under the hood to 'plug in' to the system. \- POSIX? Thin wrapper
over the IPC stuff. \- Need to talk between your processes? Sure you could use
sockets or shared memory like Linux, but those QNX IPCs work fine (and I'd
argue they were way easier to use, too). \- Networked processes? Just use that
same IPC setup. \- Networked/distributed OS stuff? The OS is built on those
IPCs you just networked in the previous bullet.

~~~
mycall
Sounds like the OP would have been the guy to help you.

------
CyberShadow
> However, Emacs required Gtk+.

I think you can configure with --with-x-toolkit=no to avoid the GTK
dependency.

It doesn't look too terrible, either:
[https://www.emacswiki.org/emacs/NoToolkit](https://www.emacswiki.org/emacs/NoToolkit)

------
filereaper
I wanted to pull down QNX and contrast it to what little thing I had built
from CS452 course from UW, compare whatever I had build to the full blown
production variant. Also attempt to add SMP on mine and throw it on a
PandaBoard.

QNX was prohibited from giving source out once it was acquired by Blackberry
:(

I'm not sure how anyone can try out what OP has posted, is there any source we
can hack on?

------
protomyth
QNX had some amazing demos back in the day. Doom playing with half a screen on
one machine and half on another. The ability to restart drivers was pretty
sweet for debugging. I wish BB10 had done better, the Passport's keyboard was
on to something.

------
i336_
> _QNX was cautiously courting the open source concept and venturing in the
> direction of shared source (with some code already available), when
> BlackBerry bought them and threw all of that out the window. Biggest yanked
> opportunity. D:_

I said that ^ last time QNX got brought up:
[https://news.ycombinator.com/item?id=12777520](https://news.ycombinator.com/item?id=12777520)

Quick UNix (QUnix, which became QNX "after a brief infestation of AT&T
lawyers" \-
[https://news.ycombinator.com/item?id=4834334](https://news.ycombinator.com/item?id=4834334))
seems to be one of the cooler UNIX designs (and OS designs) out there. (As an
aside, does anyone know anything about Dan Dodge's "hand-made modem"
referenced in that thread? There are no citations I can follow, I've been
curious for months.)

Sure, it probably has its fair share of little insanities (which are not
common knowledge due to it being closed source) but it seems the things QNX
gets right more than make up for them.

I have three very pointed questions. I'd love answers, suggestions or critique
to any or all of them.

1\. Does anyone know someone who knows someone [...] who might be able to
unearth "the right person to talk to" at BlackBerry about QNX? While I'd
probably want to defer the actual conversation to a person (or small group)
more familiar with QNX from real-world experience in industry, my motivation
behind adding this point is the hope that there may still be some glimmer of
interest in a shared-source model, and that - and I really hope this - the
source-access shutdown was simply due to insufficient time to refine the
contracts (because the buyout was executed at a particularly fast-moving
instant in time). My thinking is that BlackBerry doesn't realize the QNX
enthusiast community exists _because they were shut down_ , and that if
BlackBerry could be made aware of the fact that there are still big fans out
there, it might be a simple matter of adding a couple clauses to some super-
high-level document to eg re-allow academic access. (Yes, this point has a lot
of naïveté in it, but one can dream, right?)

1a. As a continuation of the above question, if I had a question/notation for
BlackBerry/QNX, it would be this: a) QNX had a shared-source release, and
seemed to be making good progress with that (in short, people weren't running
off with the code); b) the automotive industry and other large interests sound
like fairly stable considerations for QNX; could this affect (a) in the future
in any way? If this _were_ possible, would it be possible for Photon to be
included (perhaps with no warranty or code updates)?

2\. Can anyone who still has an old copy of the shared-source releases from
before the BlackBerry buyout dig out the license files? I'm very very curious
to see if there are any loopholes I could edge through sideways...?...

3\. There is terribly little easily-findable documentation on the Internet
helpful to OS enthusiasts who have _ahem_ stumbled on certain TTHs and want to
explore what they have found solely for personal research. While I had success
with QNX 4 some time ago (note what I am saying), I'm quite stumped about what
to do for any version beyond that. I'm very interested to learn whatever I can
here, perhaps via email (where I can share notes too).

~~~
jacquesm
I've gone that road, even had financing lined up for a 'ransomware' style buy-
out. Nobody even wanted to talk.

Very frustrating.

I completely share your sentiment and your vision.

~~~
i336_
Wow. That's quite something. For the whole OS?! :D

It seems that BB bought QNX for $200M:
[http://blog.vdcresearch.com/embedded_sw/2010/04/update-2-rim...](http://blog.vdcresearch.com/embedded_sw/2010/04/update-2-rim-
to-acquire-qnx-terms-of-the-deal.html)

If I may ask, I'm very curious (and I suspect others may also be interested in
this datapoint) - what sort of ballpark......? And what were you requesting?

Also, I have to admit that I'm unsure what you mean by "'randomware' style
buy-out" \- the only definition of ransomware I'm finding on Google (searching
for "randomware buyout", heheh) throws back info about malware. I'm not as
well-versed in business to be able to intuit what you're getting at there :)

You've probably noticed that I also replied to your top-level comment.

~~~
jacquesm
> If I may ask, I'm very curious (and I suspect others may also be interested
> in this datapoint) - what sort of ballpark......?

Well, you already supplied a number. I figured since they had not done QNX any
favors they should be happy with a bit of a discount, especially because I did
not care for the branding.

> And what were you requesting?

Open source the complete OS as it was available at that time, without the
brand. Perpetual license (they'd already done a release-and-retract once
before). Other deal parameters to be negotiated.

Anyway, as it is I strongly suspect that QNX will go under with BB at some
point, or that it will get sold to the highest bidder in some kind of
bankruptcy proceedings. Which likely will be quite a bit cheaper :)

I already wrote one QNX clone for 32 bits, it should not be too hard to make
another for 64 bit mode and it would be a lot cheaper too so maybe that's a
better way to go about it. It really isn't all that difficult, the fact that
it starts off with an extremely simple kernel makes the whole problem far more
tractable than it would be for a comparable macro kernel, the scope that needs
inspecting to home in on a bug is a very small fraction of what you get with a
macro kernel and if a device driver crashes you can simply inspect the core
dump of that device driver.

And with VMs as a test bed that job got so much easier.

------
sgt
"Some of us get very excited at the sight of a C program being compiled and
linked into an executable. The masses, however, need their entertainment."

Kind of reminds me how I had completely different priorities than other kids
in school when I was growing up.

------
manyoso
A better way to go is port ubuntu-Linux subsystem to QNX 7 like Microsoft did
for windows 10. Should be much easier too since QNX is posix compliant.

And then QNX Screen <-> wayland integration and you'd have a full fledged
desktop full stop.

------
digi_owl
Refreshing myself on QNX I find myself thinking that recent developments in
the Linux world ends up being a half-assed QNX clone.

------
saosebastiao
> As was mentioned earlier, BlackBerry QNX is not your typical embedded
> system, and our tools team provided me with the GNU tool chain (compiler,
> linker, debugger) built to run on an SDP 7 system.

Doesn't this imply some licensing troubles with the proprietary QNX license?

~~~
mcpherrinm
I can run GCC on Windows, another proprietary OS....

~~~
saosebastiao
Running software is different than distributing it, and this is from a QNX
engineer so I'm assuming this is being distributed by QNX.

~~~
detaro
And what license problem do you see with distributing it?

~~~
saosebastiao
I don't know, I have trouble understanding the implications of the nuances of
the GPL. This doesn't sound any different to me from the various violations of
the GPL that were pursued by the SFLC on behalf of the busybox creators, but
maybe it is different in some way that I'm not seeing.

~~~
detaro
It would be an issue if they didn't share the source code with him or other
users of the software (assuming there are modifications to it, but that's very
likely the case). From the blog post I see no reason to believe they wouldn't
provide it (especially in this case, where the "user" is one of their own
developers)

------
nickpsecurity
I linked to some architectural info, videos, and so on below to illustrate why
QNX is really impressive:

[https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop...](https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop#c_bpjfb3)

------
hoodoof
Is QNX available for download and install?

------
icc97
I suggest adding 'Blackberry' to the title, will save all the people clicking
through who don't know what QNX is

~~~
RandomBK
QNX had a vibrant life and strong name recognition in its field pre-
acquisition, and the BB acquision hasn't really changed that. It still
operates under its own name. Those in the target industry (real-time OS) would
know who QNX is without tying in Blackberry.

