9 ms·

Building a QNX 7 Desktop

208 points by desiderantes 9y ago

Theodores 9y ago
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 9y ago
  Isn't QNX's realtime features the reason why it's been integrated into a lot of automative systems?
  - Animats 9y ago
    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 9y ago
      It always seemed to me that QNX and the rise of smart cars was one of the things that's keeping Blackberry afloat.
  - Theodores 9y ago
    @Animat gets it right - they slipped away from being accessible to developers and being a 'weapon in the toolchest' for tasks where a normal operating system would not cut it, even things like SGI IRIX that was tied into realtime things such as framerates. There was a time when you used QNX as tool of choice when you had a time critical task and a few 'perl scripts' to do the job. The I/O was easy to do and much like how you can put something together with a Raspberry Pi today with minimal domain expertise, back in the day you could with a QNX box. As noted, this is now just not so accessible.
saosebastiao 9y ago
> 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?
- detaro 9y ago
  Does QNX really have a license that interferes with software running on it? Just being not-open/free isn't a problem for running GNU stuff.
- mcpherrinm 9y ago
  I can run GCC on Windows, another proprietary OS....
  - saosebastiao 9y ago
    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 9y ago
      And what license problem do you see with distributing it?
      - saosebastiao 9y ago
        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 9y ago
        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)
slobotron 9y ago
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
- userbinator 9y ago
  Very unusual that it apparently has an HTML3.2 browser... with JavaScript! Another very small yet very full-featured OS is MenuetOS: http://menuetos.net/ http://menuetos.net/
- josh64 9y ago
  I loved BB10 and the Hub. It was my favourite smartphone OS by far. That being said, I hated momentics!
  - protomyth 9y ago
    The Passport's keyboard was a poor layout but BB10 usage of it was amazing for editing. https://www.youtube.com/watch?v=QNVT95S6_eE https://www.youtube.com/watch?v=QNVT95S6_eE
- digi_owl 9y ago
  When not even MS could muscle their way back in after burning their PocketPC bridge, BB didn't stand much of a chance.
CyberShadow 9y ago
> 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
Animats 9y ago
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 9y ago
  > It's what home routers and similar devices ought to be running instead of Linux. The bummer is that it's not FOSS.
  - throwaway91111 9y ago
    Well, one day gnu/hurd will be the FOSS system we all deserve.
  - notalaser 9y ago
    The bummer for the companies doing the home routers is really just that it costs money. The only people who give a flying fsck about the F part are hobbyists, sadly. Source: worked in this industry.
    - bluejekyll 9y ago
      Not having a hobbyist option, means there are fewer people trying to use it for new and interesting things.
  - Frenchgeek 9y ago
filereaper 9y ago
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?
hoodoof 9y ago
Is QNX available for download and install?
nickpsecurity 9y ago
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#c_bpjfb3 https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop...
i336_ 9y ago
> 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).
rcarmo 9y ago
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 9y ago
  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 9y ago
    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.
icc97 9y ago
I suggest adding 'Blackberry' to the title, will save all the people clicking through who don't know what QNX is
- RandomBK 9y ago
  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.
- jacquesm 9y ago
  QNX was around long before BB.
pavlov 9y ago
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
manyoso 9y ago
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.
protomyth 9y ago
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.
digi_owl 9y ago
Refreshing myself on QNX I find myself thinking that recent developments in the Linux world ends up being a half-assed QNX clone.
jacquesm 9y ago
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_ 9y ago
  > 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#c_bpjfb3 https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop..., 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-review/3 http://www.anandtech.com/show/4266/blackberry-playbook-revie... 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)#Compatibility_with_BeOS https://en.wikipedia.org/wiki/Haiku_(operating_system)#Compa...) 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.
sgt 9y ago
"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.

208 points by desiderantes 9y ago

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 9y ago
Isn't QNX's realtime features the reason why it's been integrated into a lot of automative systems?
- Animats 9y ago
  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 9y ago
    It always seemed to me that QNX and the rise of smart cars was one of the things that's keeping Blackberry afloat.
- Theodores 9y ago
  @Animat gets it right - they slipped away from being accessible to developers and being a 'weapon in the toolchest' for tasks where a normal operating system would not cut it, even things like SGI IRIX that was tied into realtime things such as framerates. There was a time when you used QNX as tool of choice when you had a time critical task and a few 'perl scripts' to do the job. The I/O was easy to do and much like how you can put something together with a Raspberry Pi today with minimal domain expertise, back in the day you could with a QNX box. As noted, this is now just not so accessible.

saosebastiao 9y ago

> 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?

detaro 9y ago
Does QNX really have a license that interferes with software running on it? Just being not-open/free isn't a problem for running GNU stuff.
mcpherrinm 9y ago
I can run GCC on Windows, another proprietary OS....
- saosebastiao 9y ago
  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 9y ago
    And what license problem do you see with distributing it?
    - saosebastiao 9y ago
      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 9y ago
        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)

slobotron 9y ago

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

userbinator 9y ago
Very unusual that it apparently has an HTML3.2 browser... with JavaScript! Another very small yet very full-featured OS is MenuetOS: http://menuetos.net/ http://menuetos.net/
josh64 9y ago
I loved BB10 and the Hub. It was my favourite smartphone OS by far. That being said, I hated momentics!
- protomyth 9y ago
  The Passport's keyboard was a poor layout but BB10 usage of it was amazing for editing. https://www.youtube.com/watch?v=QNVT95S6_eE https://www.youtube.com/watch?v=QNVT95S6_eE
digi_owl 9y ago
When not even MS could muscle their way back in after burning their PocketPC bridge, BB didn't stand much of a chance.

CyberShadow 9y ago

> 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

Animats 9y ago

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 9y ago
> It's what home routers and similar devices ought to be running instead of Linux. The bummer is that it's not FOSS.
- throwaway91111 9y ago
  Well, one day gnu/hurd will be the FOSS system we all deserve.
- notalaser 9y ago
  The bummer for the companies doing the home routers is really just that it costs money. The only people who give a flying fsck about the F part are hobbyists, sadly. Source: worked in this industry.
  - bluejekyll 9y ago
    Not having a hobbyist option, means there are fewer people trying to use it for new and interesting things.
- Frenchgeek 9y ago

filereaper 9y ago

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?

hoodoof 9y ago

Is QNX available for download and install?

nickpsecurity 9y ago

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#c_bpjfb3 https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop...

i336_ 9y ago

> 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).

rcarmo 9y ago

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 9y ago
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 9y ago
  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.

icc97 9y ago

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

RandomBK 9y ago
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.
jacquesm 9y ago
QNX was around long before BB.

pavlov 9y ago

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

manyoso 9y ago

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.

protomyth 9y ago

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.

digi_owl 9y ago

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

jacquesm 9y ago

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_ 9y ago
> 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#c_bpjfb3 https://lobste.rs/s/ensbd6/building_blackberry_qnx_7_desktop..., 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-review/3 http://www.anandtech.com/show/4266/blackberry-playbook-revie... 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)#Compatibility_with_BeOS https://en.wikipedia.org/wiki/Haiku_(operating_system)#Compa...) 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.

sgt 9y ago

"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.