Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • will this work with liteX? fascinating project
  • Hmm.. how liteX is related to the QNX-inspired OS with selectable kernels? :)
    by ymz5
  • This is one of the few AI hills I will die on: not disclosing AI tool usage when you produce a product where the writing is the end result (in this case, the website I'm being sent to) is disrespectful to your readers and users.

        `The quickest way to see QSOE run — no hardware, no -kernel juggling.`
    
        `Real hardware, real disk.`
    
        `A working plan, not a contract: milestones may shift as the work reveals what's really next.`
    
    I have no problem with using AI to draft docs, or as an editing tool, or even to help writing (if, e.g., you are not a native speaker) but this is just egregious low-effort slop. If you can't even put the time to write your own documentation (or at least disclose AI tool use), why would I trust you to even test your own sofware?
    by dvt
  • In the other thread (mentioned above) the author says that nearly the entire thing was created by Claude. So yeah, no.
  • I was going to say dual-kernel seems pretty pointless other than that it's something you can prompt an LLM to implement.
  • 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.
    by ymz5
  • 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...

    by ymz5
  • 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
    by p_l
  • 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.

  • If anyone knows where to find a legitimate MIPS version of Photon, I’d be interested in starting a decomp project.
  • 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 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.

    by fouc
  • 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.
  • 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.

    by ymz5
  • > 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.

    by m132
  • Don't worry, it's being fully supervised :) . Yes, almost the entire product is developed with Claude.
    by ymz5