Show HN: The Unite real time operating system
jacquesmattheij.comGreat to see you resurrect this project and publish it.
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.
Sorry I misspelled your name originally!
I wonder what the ideal demo of this that makes its approach visually legible would be
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.
As for GitHub itself: I am not going to further Microsoft's grip on the world of software development.
For taking a stand against Microsofts "social network", "ai training data", greed and proprietary tooling.
I think sharing the source code as you do now is a perfect choice is it is what you are most comfortable with.
I have had many ideas for such kernels over the years, but not the patience yet to implement any of them. I wonder if Claude could help me with generating a kernel in less than a day.
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.
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.
You can get a "personal use license" now, but you can't distribute anything that has parts of QNX code in it.
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.
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.
FIFY :)
Greatly accelerated AGL with D-Bus (yuck) as patchwork replacement for QNX IPC
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
seL4 exists.
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...
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.
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.
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).
If you drop me a line on jacques@modularcompany.com I'll send you back a zip file.
Edit: sent. Enjoy!
Hah, I feel that pain. Currently hacking some bare-metal Zig on PinePhone, and on top of the USB reconnect power cycle, I am transferring an SD card back n forth. I wonder if I'll be making a similar post in 30 years time.
Anyway, well done, and I look forward to browsing the code for some inspiration. Thanks for making it PD.
I did try QEMU for the first time last week, but started thinking I'd need some way to mock out all the hardware, and I only got as far as UART. But now that you mention it I'll take another look. There is a lot of multi-core mbox? IRQ stuff I'm about to tackle next, and I dont see why I cant develop all of that independent of the hardware.
I seem to be learning the hard way. I spent the first 12 months debugging via the only thing I could get working, an onboard RGB LED.