Building a QNX 7 Desktop

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

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://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 which pointed to 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) might be fairly trivial, building everything else (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/) 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...)

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.

nice combination!

So true. This is why Genode OS is grabbing my interest these days.

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.