4 ms·

Aw. I've always liked QNX. But a modern implementation, not a revival of a 30 year old abandoned project, would be more useful. We really need something for sma

Aw. I've always liked QNX. But a modern implementation, not a revival of a 30 year old abandoned project, would be more useful. We really need something for small IoT boxes that has less attack surface than Linux. The problem people run into trying to build something like QNX is that, while the kernel is tiny, it won't even do Hello World until you have the necessary user-space drivers running. Initial debugging is hard.

bregma 1y ago
If you're looking for something like QNX you could use... QNX. It's still around and free for hobbyists [0]. You can use it knowing you're using the same OS as your car, or train, or medical device, or spacecraft. [0] https://www.qnx.com/products/everywhere/ https://www.qnx.com/products/everywhere/
- Chris2048 1y ago
  You still have to register with them, I'm not sure that is common among NC licenses. I assume this also means its not really open-source (or compatible with open collaboration) if they are gatekeeping (via licences) the free dev licence. Also consider this - If you got a licence would this "taint" you if you ever wanted to work on a project like OPs? As in, the registration is proof you could access the proprietary QNX code, forming the basis of a lawsuit.
  - jacquesm 1y ago
    Quantum has muddied the waters considerably here by at some point releasing the code under a fully open license. They tried hard to reverse that decision but I'm sure there are still copies of that version floating around.
    - cxr 1y ago
      In contrast to Minix 3.0+, no version of QNX has ever been fully open. At its most permissive, it was made available (behind a form submission) under a look-but-don't-touch All Rights Reserved sourceware license.
- p_l 1y ago
  After previous rugpull, why anyone would want to jump through the hoops?
  - Animats 1y ago
    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.
    - jacquesm 1y ago
      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 1y ago
        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 1y ago
        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-tools/ 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.
naasking 1y ago
> We really need something for small IoT boxes that has less attack surface than Linux. seL4 exists.
- Animats 1y ago
  People mostly use seL4 as a hypervisor, running Linux on top of it. QNX has a POSIX API, so you don't need another layer.
  - naasking 1y ago
    QNX is allegedly a microkernel. Either the QNX POSIX API is itself another layer over the microkernel, or QNX cannot be a microkernel (hint: it's the former [1]). People run L4 as a hypervisor only because they want access to the full Linux API. That's not really what you're talking about though, and there's nothing stopping a thin QNX-style POSIX compatibility layer as a user-space server or library as with QNX. The point being, the mature, widely deployed, robust and widely tested microkernel you're looking for already exists, so you just need to focus on the POSIX layer. [1] https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/intro_embeddable.html https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino...
    - Animats 1y ago
      Actually, most of the POSIX compatibility stuff is in QNX's equivalent of "libc". When you call Unix "write", the library does a MsgSend to the appropriate service. MsgSend is in the kernel, but whatever performs the write is in some other process. Some other functions, such as program loading, are in user space .so files. When you spawn a new process (in QNX, spawn is the usual function, and fork/exec are emulated for backwards compatibility), the library in your program attaches to the .so file that contains the program loader. The user process requests memory and decodes the executable image, and sets up the new process environment. If something in executable file decode does something wrong, the process faults in the usual user space way. There's no privileged emulation layer. At boot, the .so files for this sort of thing are part of the boot image and are loaded into memory, so they are available even before there's a file system. As are the userspace programs needed during startup. You can build your own boot image, with whatever programs you want. You might, for example, include the "dashboard driver" for a car, and omit terminal support. There's no assumption in QNX that there's a console, because, often, there isn't.
glonq 1y ago
Back when I did embedded development full-time I always lusted after QNX, but the costs and royalties were higher than what our low-volume product could justify. Or maybe we were just cheapskates.
- jacquesm 1y ago
  No, you are right, in volume QNX is expensive. We spent a ton of money ($1600 / license iirc) on licenses for a system that we built, and even so it felt like Quantum never took us serious because we only needed 10's of them rather than the 100's of thousands they were used to selling to their bigger automotive customers. But it is still an OS that will for me always embody the 'road not taken' and I still strongly believe that it was a better road, based on my experience with IRIX, Windows, DOS, VMS, Linux, VAX Unix, OS/9, Plan 9 and QNX. It felt like that only one that always ran and that always stayed responsive, no matter what we threw at it. Across many years and 10's of machines running various versions of QNX I have not seen a single production crash of the OS that was not an indication that the underlying hardware had died. But it was perfectly possible to anticipate even that and have an Erlang like supervisor system in place to deal with that.
jacquesm 1y ago
QnX is expensive. And in a way that is exactly what I'm hoping for with this release: that someone will pick it up, see how simple a robust OS can be and to use it as a base to build on (for instance, by porting Rust and rewriting the core in that, which would give a very quick path to a self hosting OS), or maybe just as a source of inspiration. Here you have all of the scaffolding in place already so now you can focus on those other parts one at the time while having the luxury of good tooling and a nice debugging environment, no need to bring it up from scratch. Another great thing would be to make an ARM or other CPU port. And that's not all that hard: there is only one process that is CPU specific and there are a very limited number of pieces that you need (essentially just a COM port driver) to be able to make it self hosting.

bregma 1y ago

If you're looking for something like QNX you could use... QNX. It's still around and free for hobbyists [0]. You can use it knowing you're using the same OS as your car, or train, or medical device, or spacecraft. [0] https://www.qnx.com/products/everywhere/ https://www.qnx.com/products/everywhere/

Chris2048 1y ago
You still have to register with them, I'm not sure that is common among NC licenses. I assume this also means its not really open-source (or compatible with open collaboration) if they are gatekeeping (via licences) the free dev licence. Also consider this - If you got a licence would this "taint" you if you ever wanted to work on a project like OPs? As in, the registration is proof you could access the proprietary QNX code, forming the basis of a lawsuit.
- jacquesm 1y ago
  Quantum has muddied the waters considerably here by at some point releasing the code under a fully open license. They tried hard to reverse that decision but I'm sure there are still copies of that version floating around.
  - cxr 1y ago
    In contrast to Minix 3.0+, no version of QNX has ever been fully open. At its most permissive, it was made available (behind a form submission) under a look-but-don't-touch All Rights Reserved sourceware license.
p_l 1y ago
After previous rugpull, why anyone would want to jump through the hoops?
- Animats 1y ago
  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.
  - jacquesm 1y ago
    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 1y ago
      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 1y ago
        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-tools/ 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.

naasking 1y ago

> We really need something for small IoT boxes that has less attack surface than Linux. seL4 exists.

Animats 1y ago
People mostly use seL4 as a hypervisor, running Linux on top of it. QNX has a POSIX API, so you don't need another layer.
- naasking 1y ago
  QNX is allegedly a microkernel. Either the QNX POSIX API is itself another layer over the microkernel, or QNX cannot be a microkernel (hint: it's the former [1]). People run L4 as a hypervisor only because they want access to the full Linux API. That's not really what you're talking about though, and there's nothing stopping a thin QNX-style POSIX compatibility layer as a user-space server or library as with QNX. The point being, the mature, widely deployed, robust and widely tested microkernel you're looking for already exists, so you just need to focus on the POSIX layer. [1] https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino.sys_arch/topic/intro_embeddable.html https://www.qnx.com/developers/docs/8.0/com.qnx.doc.neutrino...
  - Animats 1y ago
    Actually, most of the POSIX compatibility stuff is in QNX's equivalent of "libc". When you call Unix "write", the library does a MsgSend to the appropriate service. MsgSend is in the kernel, but whatever performs the write is in some other process. Some other functions, such as program loading, are in user space .so files. When you spawn a new process (in QNX, spawn is the usual function, and fork/exec are emulated for backwards compatibility), the library in your program attaches to the .so file that contains the program loader. The user process requests memory and decodes the executable image, and sets up the new process environment. If something in executable file decode does something wrong, the process faults in the usual user space way. There's no privileged emulation layer. At boot, the .so files for this sort of thing are part of the boot image and are loaded into memory, so they are available even before there's a file system. As are the userspace programs needed during startup. You can build your own boot image, with whatever programs you want. You might, for example, include the "dashboard driver" for a car, and omit terminal support. There's no assumption in QNX that there's a console, because, often, there isn't.

glonq 1y ago

Back when I did embedded development full-time I always lusted after QNX, but the costs and royalties were higher than what our low-volume product could justify. Or maybe we were just cheapskates.

jacquesm 1y ago
No, you are right, in volume QNX is expensive. We spent a ton of money ($1600 / license iirc) on licenses for a system that we built, and even so it felt like Quantum never took us serious because we only needed 10's of them rather than the 100's of thousands they were used to selling to their bigger automotive customers. But it is still an OS that will for me always embody the 'road not taken' and I still strongly believe that it was a better road, based on my experience with IRIX, Windows, DOS, VMS, Linux, VAX Unix, OS/9, Plan 9 and QNX. It felt like that only one that always ran and that always stayed responsive, no matter what we threw at it. Across many years and 10's of machines running various versions of QNX I have not seen a single production crash of the OS that was not an indication that the underlying hardware had died. But it was perfectly possible to anticipate even that and have an Erlang like supervisor system in place to deal with that.

jacquesm 1y ago

QnX is expensive. And in a way that is exactly what I'm hoping for with this release: that someone will pick it up, see how simple a robust OS can be and to use it as a base to build on (for instance, by porting Rust and rewriting the core in that, which would give a very quick path to a self hosting OS), or maybe just as a source of inspiration. Here you have all of the scaffolding in place already so now you can focus on those other parts one at the time while having the luxury of good tooling and a nice debugging environment, no need to bring it up from scratch. Another great thing would be to make an ARM or other CPU port. And that's not all that hard: there is only one process that is CPU specific and there are a very limited number of pieces that you need (essentially just a COM port driver) to be able to make it self hosting.