Oh good luck, I really feel your pain :) Consider using an emulator until you're really ready to go to hardware that might save you a lot of time and headache, it also makes observability a lot better. Nothing beats having access to memory from a debugger.

No, but I had used it extensively and written a fairly large amount of code for it so it was mostly re-implementing how I thought things must work under the hood. The hardest part was to bridge some of the posix like functionality to this rather strange set of primitives, especially 'fork' and the '/dev/' parts required some pretty hacky solutions. But they work and they ended up being quite reliable.

As for it being lightyears ahead of Minix: Minix was built from the ground up as a platform to demonstrate how Unix works without being Unix. QnX and by extension my version on that theme was built from day one to be low latency and to have the smallest possible kernel footprint that you could have. The lack of a root file system and the Plan-9 like network transparency are all as a result of that and allow extremely fine grained control over what goes into the final package. It is far more suitable for low level control while at the same time having high level tooling than Minix. What I loved about Minix is the way the source code is organized and how - and this is obviously no accident - it reads as a textbook, I learned a lot from looking at the code and ended up adopting the file system as a stand-alone piece of code (which allowed me to pass files in and out of the OS early on by writing them under one OS and then rebooting so I had access on the other side).

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.

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.

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/

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

seL4 exists.

I should definitely make that picture. Yes, it as VM. Message passing all runs through the kernel. Task isolation is strictly memory based, whether a task acts on or responds to a message is something the tasks will have to negotiate between themselves. You could whitelist, use a token scheme or any other method for authentication that you wish to put in place, but out of the box there is none, if you know a tasks ID you can send it a message. Obviously there are ownership of resource constraints and the kernel will always ensure that the receiving task knows who the sending task is to ensure that parties are not stealing each others descriptors and such.

Pull the source and ask Claude to explain it to you...

Thank you. One download so far :) Mega success!

It's interesting how you can release an OS + source code and hardly anybody will bat an eye. But nonsense attached to an LLM will draw a crowd ;)

Anyway, I'm happy that I got it to work and I hope at least someone will find it useful.

That's a good question and one that I've been wondering about myself. For me it is the very clean abstraction layers. There is zero side-to-side communication it is all broader foundations to narrower verticals plugged in to those. For instance, the networking stack has a process for every layer. That keeps that whole thing manageable and it means that problems can never escape the scope of the process they are in, unlike a 'large' kernel where a botched device driver can bring down the whole system. You can pretty much tear this down to the task scheduler and the loader and rebuild it up without taking the system down. And I had a good idea on how you could replace the scheduler with another one while the system is running.

I'm really curious what - if anything - people will do with it, I think that the fact that an OS like this one powered the BlackBerry (which people loved) should work in its favor, other places where you find this kind of OS is in industrial control and in vehicles. Usually there is some kind of hardware component involved but that's entirely optional, you could use it as a general purpose OS as well.

It's a running OS snapshot as a drive image, not a source tree, the sources are on the drive image.

As for GitHub itself: I am not going to further Microsoft's grip on the world of software development.