> Skimmer's design intentionally echoes DragonFly BSD's LWKT and msgport
subsystems — the per-CPU runqueue, the lwkt_* API surface, the rule
that cross-CPU work flows as messages rather than as direct foreign
writes. DragonFly's source under ~/proj/OS/DragonFlyBSD/6.4.2/sys/kern/
was studied as a structural reference during v0.1 bring-up.
Do you have any plans (maybe in the far future) to re-implement the Photon microGUI system?
Just asking because for me, that's half of what made QNX so great back in the day. Even today I keep raving about that 1.44MB demo floppy, about how polished, performant and efficient Photon was.
Well.. who knows. My interests are not exactly in the area of GUIs, but I do agree that Photon was great. When the main system stabilizes; when it runs RT tests (such as the audio test I'm planning) under heavy load for e.g. one week -- AND when all important "syscall-like" APIs are implemented and proven to be correct -- I might return to this.
Question to you: on which hardware platform would you like to have Photon running?
Currently, the only system I got is SiFive Unmatched with NVidia GK-208 card. Re-using Nouveau in QSOE should be possible, but it's a big pile of work.
Low-spec/embedded/vintage devices. Mainly RISC-V, or old x86 hardware like a Pentium III with a Matrox Millennium AGP card or something.
For context: I'm sick and tired of modern hardware, modern GUIs and modern Internet... all of which keeps getting more and more complex, commercialised, controlled and demanding.
I miss the old days, when hardware resources were paltry, when you could mostly understand what went on in your hardware and OS, when developers coded in native languages, didn't rely on bloated toolkits and infinite dependencies and didn't take a user's system resources for granted and were able to make really cool programs in mere kilobytes, when the OS didn't impose arbitrary restrictions on you in the name of "security" and you were free to do whatever you wanted with it, and when the Internet wasn't controlled by mega corporations and there was no Javascript and browsers didn't need gigabytes of RAM and the web wasn't the bloated mess that it is today.... I really, really miss those days.
My dream is to either have a RISC-V box or a vintage PC, hook it up to a LoRa network like Meshcore or something, run an efficient 90s-style OS like QNX/Haiku/SerenityOS/KolibriOS, and run some old-school networking apps similar to IRC, BBS or even Web 1.0, all over LoRa... and rediscover the joy and magic of computers again, relive the spirit of the 90s whilst being able to communicate with others freely without corporations and governments getting in your way... that's my dream.
Sorry if I went off on a tangent, I just saw "QNX" in the headline and it got me all nostalgic and emotional.
Fully support your dream -- and out of similar reason/sentiments I created GateMate PC (google for it) and GateMate S/359. I will return to these systems in autumn; it's a pure joy to work with them.
As for the video controller -- if during the next couple of days I have zero success with GK-208 initialization in U-Boot, I have a plan B. I will throw away that card completely and will buy DragonBoard (Xilinx Artix 7). I already have a video controller implementation for it.
Own video-controller + own OS + own bootloader on RISC-V. What could be better! :D
Raspberry Pi was a shot in that direction. But it's still a complex beast with 3D GPU, some embedded RTOS to get everything started, etc.
Personally I think software size should reflect the complexity of the task. And yes, a modern GUI does subpixel rendering of scalable fonts, decoding complex video codecs etc etc. But the bulk of today's massive software size is just pointless abstractions, inefficient 'frameworks' or eyecandy.
In the late 90s and early 2000s, I could not have imagined a scenario where an editor takes up 200+ MB! The entire Office 97 suite was well under 192MB closer to 130MB! Adobe Photoshop CS2 installed was under 370 MB.
Memory usage now is also insane.
Office 2000 would run on 32MB of RAM and run really well on 64MB! Now a single tab on Firefox or any other browser on a static website takes up well over 400MB.
A single tab showing Facebook on my laptop takes up about 390MB! Even Hackernews website takes up 36MB!
I too want to go back to the days when things were a lot simpler.
I HATE how modern & locked down the web is now, feels like we need to fork the internet. I want an internet that doesn't assume you're always online. I want an internet that is accessible and useful even even if you only connected a few times a day, or especially even if you were on a spacecraft a light-hour away.
I contacted the QNX community relations manager a little time ago and (if I remember correctly) they said they weren't going to release any of the microGUI source as they wanted the community to focus on their current projects. Very saddening that all that useful historical source code is being left to rot.
I wonder if we couldn't just use LLMs to completely reverse engineer a QNX 4.25 demo image into usable source code. Possibly translate it directly into rust code.
Bun had it easier in many ways, given that they're based on a well-documented public API surface & have the node.js test suite etc.
In the case of QNX I'm guessing it might help to find a way to intercept the message passing of running QNX instances in order to use it as a test harness while reverse engineering all the components.
I reckon it should be feasible - especially if you start with the code in the 1.44MB demo disk. If you exclude the kernel, the network stack, the drivers and all the other apps, the binaries for Photon itself should be in kilobytes. Far more complex projects have been decompiled with LLMs.
For QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
I don't think a MIPS version ever existed. The only public releases that ran on MIPS (6.4 and pre-SP1 6.5) only bundled a handful of Photon-related binaries, which if my memory serves were just input drivers.
There were x86 and more or less complete ARMv7, PowerPC, and SuperH ports.
Depending how recent the card is, you might need to implement UEFI & GOP instead. Might be better approach to read any open source driver code on Linux or BSD to find out how to get basic framebuffer
> Skimmer's design intentionally echoes DragonFly BSD's LWKT and msgport subsystems — the per-CPU runqueue, the lwkt_* API surface, the rule that cross-CPU work flows as messages rather than as direct foreign writes. DragonFly's source under ~/proj/OS/DragonFlyBSD/6.4.2/sys/kern/ was studied as a structural reference during v0.1 bring-up.
https://gitlab.com/qsoe/nq/-/blob/bfe5337676ee3818d24db4101b...
Is this Claude going unsupervised? There are also references to CLAUDE.md ("see CLAUDE.md for scope") which is nowhere to be found.
Don't worry, it's being fully supervised :) . Yes, almost the entire product is developed with Claude.
Do you have any plans (maybe in the far future) to re-implement the Photon microGUI system?
Just asking because for me, that's half of what made QNX so great back in the day. Even today I keep raving about that 1.44MB demo floppy, about how polished, performant and efficient Photon was.
Well.. who knows. My interests are not exactly in the area of GUIs, but I do agree that Photon was great. When the main system stabilizes; when it runs RT tests (such as the audio test I'm planning) under heavy load for e.g. one week -- AND when all important "syscall-like" APIs are implemented and proven to be correct -- I might return to this.
Question to you: on which hardware platform would you like to have Photon running?
Currently, the only system I got is SiFive Unmatched with NVidia GK-208 card. Re-using Nouveau in QSOE should be possible, but it's a big pile of work.
Low-spec/embedded/vintage devices. Mainly RISC-V, or old x86 hardware like a Pentium III with a Matrox Millennium AGP card or something.
For context: I'm sick and tired of modern hardware, modern GUIs and modern Internet... all of which keeps getting more and more complex, commercialised, controlled and demanding.
I miss the old days, when hardware resources were paltry, when you could mostly understand what went on in your hardware and OS, when developers coded in native languages, didn't rely on bloated toolkits and infinite dependencies and didn't take a user's system resources for granted and were able to make really cool programs in mere kilobytes, when the OS didn't impose arbitrary restrictions on you in the name of "security" and you were free to do whatever you wanted with it, and when the Internet wasn't controlled by mega corporations and there was no Javascript and browsers didn't need gigabytes of RAM and the web wasn't the bloated mess that it is today.... I really, really miss those days.
My dream is to either have a RISC-V box or a vintage PC, hook it up to a LoRa network like Meshcore or something, run an efficient 90s-style OS like QNX/Haiku/SerenityOS/KolibriOS, and run some old-school networking apps similar to IRC, BBS or even Web 1.0, all over LoRa... and rediscover the joy and magic of computers again, relive the spirit of the 90s whilst being able to communicate with others freely without corporations and governments getting in your way... that's my dream.
Sorry if I went off on a tangent, I just saw "QNX" in the headline and it got me all nostalgic and emotional.
Fully support your dream -- and out of similar reason/sentiments I created GateMate PC (google for it) and GateMate S/359. I will return to these systems in autumn; it's a pure joy to work with them.
As for the video controller -- if during the next couple of days I have zero success with GK-208 initialization in U-Boot, I have a plan B. I will throw away that card completely and will buy DragonBoard (Xilinx Artix 7). I already have a video controller implementation for it.
Own video-controller + own OS + own bootloader on RISC-V. What could be better! :D
> GateMate PC (google for it) and GateMate S/359
Don't use Google, it doesn't deliver. Duck duck go does.
I share that dream, and surely it's not just us.
Raspberry Pi was a shot in that direction. But it's still a complex beast with 3D GPU, some embedded RTOS to get everything started, etc.
Personally I think software size should reflect the complexity of the task. And yes, a modern GUI does subpixel rendering of scalable fonts, decoding complex video codecs etc etc. But the bulk of today's massive software size is just pointless abstractions, inefficient 'frameworks' or eyecandy.
Right.
That's why I love good text mode interfaces so much.
Same here.
In the late 90s and early 2000s, I could not have imagined a scenario where an editor takes up 200+ MB! The entire Office 97 suite was well under 192MB closer to 130MB! Adobe Photoshop CS2 installed was under 370 MB.
Memory usage now is also insane.
Office 2000 would run on 32MB of RAM and run really well on 64MB! Now a single tab on Firefox or any other browser on a static website takes up well over 400MB.
A single tab showing Facebook on my laptop takes up about 390MB! Even Hackernews website takes up 36MB!
I too want to go back to the days when things were a lot simpler.
I HATE how modern & locked down the web is now, feels like we need to fork the internet. I want an internet that doesn't assume you're always online. I want an internet that is accessible and useful even even if you only connected a few times a day, or especially even if you were on a spacecraft a light-hour away.
I contacted the QNX community relations manager a little time ago and (if I remember correctly) they said they weren't going to release any of the microGUI source as they wanted the community to focus on their current projects. Very saddening that all that useful historical source code is being left to rot.
I wonder if we couldn't just use LLMs to completely reverse engineer a QNX 4.25 demo image into usable source code. Possibly translate it directly into rust code.
Bun had it easier in many ways, given that they're based on a well-documented public API surface & have the node.js test suite etc.
In the case of QNX I'm guessing it might help to find a way to intercept the message passing of running QNX instances in order to use it as a test harness while reverse engineering all the components.
I reckon it should be feasible - especially if you start with the code in the 1.44MB demo disk. If you exclude the kernel, the network stack, the drivers and all the other apps, the binaries for Photon itself should be in kilobytes. Far more complex projects have been decompiled with LLMs.
For QNX/Blackberry it would make sense to opensource Photon since they are not using it anymore. Porting it to the modern QNX and other systems would be great.
If anyone knows where to find a legitimate MIPS version of Photon, I’d be interested in starting a decomp project.
I don't think a MIPS version ever existed. The only public releases that ran on MIPS (6.4 and pre-SP1 6.5) only bundled a handful of Photon-related binaries, which if my memory serves were just input drivers.
There were x86 and more or less complete ARMv7, PowerPC, and SuperH ports.
To all experts in video cards reading this:
Do you know, how to initialize a NVidia card in the RISC-V system (such as Unmatched or Polarfire) to the basic VGA mode 3 (text mode, 80x25)? :)
I really wanted to get the Real Console for QSOE, but so far all my efforts to run video BIOS (via U-Boot's bios_emulator) are not successful...
Depending how recent the card is, you might need to implement UEFI & GOP instead. Might be better approach to read any open source driver code on Linux or BSD to find out how to get basic framebuffer
Is it a micro-kernel based? Because writing kernel drivers is not the most convenient approach.
Well, obviously: if it's "QNX-like", then it IS microkernel-based.
:-)
will this work with liteX? fascinating project
Hmm.. how liteX is related to the QNX-inspired OS with selectable kernels? :)
Use litex to define/build a riscv soc-on-fpga, boot qsoe instead of Linux on said fpga?
Thanks for the clarification! Till today I didn't know you can build a 64-bit RISC-V CPU with LiteX. Cool!
The only problem (for me) is the availability of suitable hardware to implement it :) The only FPGA board I got is GateMate EVB-A1.
Where are you based, I can get you something beefier?
I got a Tang Primer for one of my own projects recently.
[dead]