Show HN: An Open Source XR(AR/VR) Operating System

Cool idea to use your own kernel though it does sound like you could find yourself in perpetual development hell. And, don't forget all the sufficiently powerful SoCs are super closed. You won't be able to leverage any of their existing driver work and you will need some serious clout to get access to their documentation, with some really scary NDAs attached. However I'm sure you know this and took it into account. Very cool. I hope you will manage to get it to market!

by sdallagasperina8 hours ago|

parent|

[-]

This is a huge point. Even if you write the perfect kernel, the reality is that XR hardware is tied up in vendor drivers and NDAs. Without access to those, you end up reinventing the easy part while still locked out of the hard parts. Curious if the team has a strategy for this, or if the kernel is mainly a sandbox for now.

by potatolicious1 days ago|

prev|

[-]

> "A: Using our own kernel helps us get rid of the baggage of legacy codes, bring the most optimal performance on our target hardware (XR/AR/VR) and achieve more efficiency than what we would've achieved on an existing kernel."

This is kind of a non-answer, no? What baggage does it get rid of? What kind of performance optimization does it bring that cannot be fulfilled with an existing OS/kernel?

by janice19991 days ago|

parent|

[-]

Exactly this. The kernel seems like the least interesting part of an AR system. Also targeting x86, ARM and RISC-V for a new kernel is such a huge workload it makes no sense not to just re-use something already existing.

by sdallagasperina8 hours ago|

parent|

prev|

[-]

I had the same reaction! “legacy baggage” is a vague phrase. Without examples (like specific subsystems or bottlenecks), it’s hard to see how a custom kernel helps XR more than existing lightweight or RT kernels. If the team has benchmarks or case studies where Linux/Android gets in the way, that would make the argument much stronger.

by sdallagasperina8 hours ago|

prev|

[-]

Really ambitious project, but I’m not convinced building a brand-new kernel is the best way to tackle XR. The hardest problems in AR/VR usually aren’t about the OS itself, but about latency, hardware drivers, and closed SoCs.

Saying “we’re removing legacy baggage” sounds nice, but it’d be more convincing if you could point to concrete examples where existing systems like Linux actually get in the way. Otherwise this risks becoming a never-ending side quest instead of a platform people can realistically use.

by Serenacula11 hours ago|

prev|

[-]

When you say "deep AI integration at the OS level", what exactly does that mean? A built in chatbot? Or AI is used in OS functionality itself?

by password43211 days ago|

prev|

[-]

Related recent discussion:

MentraOS – open-source Smart glasses OS

https://news.ycombinator.com/item?id=45140381 (4 days ago; 200+ points, 120+ comments)

by koolala19 hours ago|

prev|

[-]

Is this really not based on some existing system? How were you able to implement all that stuff from scratch? Looks cool.

by verdverm1 days ago|

prev|

[-]

Qualcomm is supposedly telling developers to target AndroidXR instead of Spaces

Is this building on that or a complete bottoms up writing of the full AR software stack?

by adfm1 days ago|

prev|

[-]

What hardware is currently supported?

What open standards does it support? OpenXR, WebGPU, WebXR?

What industries are best suited? Games/Entertainment/ Sports? AEC?

by awanacode8 hours ago|

parent|

[-]

I think this is the real question: which standards (OpenXR, SteamVR, WebXR, etc.) are you aligning with? Because in XR, ecosystem compatibility matters more than OS purity. If the kernel doesn’t play nicely with those, adoption will be tough no matter how elegant it is internally.