| Yes. The history is awful. Closed source, partially open source with free version, closed source, fully open source with free version (but not for commercial use), and then, suddenly one day, closed source. Twenty years ago, many of the Gnu tools built for QNX by default. That stopped. You can get a "personal use license" now, but you can't distribute anything that has parts of QNX code in it. |
| |
| ▲ | p_l 3 hours ago | parent | next [-] | | From what people reported around the rugpull, BB pretty much nuked all customer relationships with various groups that had commercial licenses too, not just with people who looked into open source or free-as-in-beer options. Greatly accelerated AGL with D-Bus (yuck) as patchwork replacement for QNX IPC | | |
| ▲ | jacquesm 3 hours ago | parent [-] | | Yes, this happened to us as well. It basically killed more than a decade of development. I did write a send/receive/reply/name_attach/name_locate library for Linux, which worked well enough that we could at least rescue the project. But BB killed QnX for large scale software development projects outside of the embedded space, and quite possibly for a lot of those as well (but I had no contact with such groups). There was a point in time where QnX ran a very large fraction of all of the world's infrastructure and BB showed the dangers of relying on a company that never fully committed to their long-term strategy. | | |
| ▲ | p_l 2 hours ago | parent [-] | | Some of the older autonomous challenges involving flight I remember a lot of contestants had QNX on board vs. let's say VxWorks or others. I also guess QNX having more point-to-point IPC/RPC fits some stuff better without having to plop in (possibly expensive) middleware like CORBA-RT | | |
| ▲ | jacquesm 34 minutes ago | parent [-] | | The way that IPC/RPC worked across the network was the real power of QNX and a very much under appreciated aspect of it. SUN microsystems had this slogan: "The Network Is The Computer". But they never really delivered on that QNX and Plan9 actually did. |
|
|
| |
| ▲ | jacquesm 4 hours ago | parent | prev [-] | | All of the acquisitions and license issues did QnX no favors. We built a very large installation on top of it and always felt that Quantum didn't really know what they wanted to be. The BB acquisition was the final nail in the coffin, though, as a platform it was a pretty good illustration of how powerful that whole mechanism is. | | |
| ▲ | Animats an hour ago | parent [-] | | Yes. The ownership by Harmon (an audio company) was clueless, and Blackberry was, strangely, no better. I once told one of their marketing guys "Quit worrying about being pirated and worry more about being ignored." I wonder if a business model like Epic's would have worked. Unreal Engine is free until you hit US$1 million in revenue, and then they want a cut of revenue.
This works in games because any game with significant revenue is publicly visible.
Less so in operating systems. You could have QNX inside a million traffic lights without anybody knowing. | | |
| ▲ | jacquesm 25 minutes ago | parent [-] | | The problem with operating systems is that if they work well they're all but invisible. They only attract attention when they malfunction. QNX allowed us to focus on the problems we were solving, rather than that it drew a lot of attention to itself. I walked into a project that was already years underway and started working on core application components within a few weeks of reading the QNX manual (which I thought was excellent, by the way, not unlike the documentation that came with Mark Williams C). The OS was facilitating what you wanted to do rather than that you were fighting it every step of the way. The main application we wrote (and of which I rewrote significant chunks) processed a record number of messages on every Monday morning, week after week, year after year. It was a massive cash cow for the company that had commissioned it (KVSA, https://www.kvsa.nl/en/data-and-intelligence/bts-broker-tool... , it is still alive but it no longer runs on QNX) and if not for QNX I doubt it would have gotten as far as it did. Especially in those first few years when it was mostly my old boss and one or two helpers building it. The OS pretty much enforced clean abstraction layers by showing at the OS level itself how this was done. Extending that was a natural path and I suspect that many QNX shops did this simply because it felt right and made it easy. They likely did not realize they were building what we would call a 'service oriented architecture' many years later and in a completely different context. This experience still leaves me looking at many of the systems we use today as unnecessarily bloated and frankly, quite ugly. QNX was light weight, but not a lightweight. The only other eco-systems that give me that same feeling are Plan9 and Erlang. |
|
|
|