Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QSOE: QNX-inspired OS with dual-kernel architecture

qsoe-dev.blogspot.com

Post reply on HN
Print view View original

31–36 of 36 posts

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#31

Post by ymz5 »

joshu wrote: post #27
ymz5 wrote: post #26

Earlier quoted context omitted.

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.

Oh, don't worry (and thanks for the offer!) -- I'll soon have Artix 7 powered board (or may be even something "beefier"). At least the "Dragon Board" with Artix 7 I will need for the video controller for my Unmatched: it has a PCIe connector & HDMI connector.

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#32

Post by dvt »

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?

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#33

Post by ChuckMcM »

ymz5 wrote: post #17
m132 wrote: post #13

> 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…

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

Thanks, I wondered if I could ignore this 'announcement'

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#34

Post by ChuckMcM »

dvt wrote: post #32

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…

In the other thread (mentioned above) the author says that nearly the entire thing was created by Claude. So yeah, no.

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#35

Post by Retr0id »

dvt wrote: post #32

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 was going to say dual-kernel seems pretty pointless other than that it's something you can prompt an LLM to implement.

Re: QSOE: QNX-inspired OS with dual-kernel architecture

#36

Post by O1111OOO »

d3Xt3r wrote: post #6
ymz5 wrote: post #5

Earlier quoted context omitted.

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 Photo…

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…

> 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...

I like the way you think. Do you have a site or blog somewhere?

Post reply on HN