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.
Very interesting. I do have a bit of a "vids or it didn't happen" feeling about this.
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!
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.
> "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?
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.
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.
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.
Related discussion:
John Carmack's arguments against building a custom XR OS at Meta
https://news.ycombinator.com/item?id=45066395 (11 days ago; 527+ points; 646+ comments)
Love to hear whether you agree or not and how your project is different?
Cons: it's costly
Pros: it's fun
Bad for business, good for hobbyists.
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.
Very interesting. I do have a bit of a "vids or it didn't happen" feeling about this.
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!
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.
> "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?
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.
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.
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?
Related recent discussion:
MentraOS – open-source Smart glasses OS
https://news.ycombinator.com/item?id=45140381 (4 days ago; 200+ points, 120+ comments)
Is this really not based on some existing system? How were you able to implement all that stuff from scratch? Looks cool.
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?
What hardware is currently supported?
What open standards does it support? OpenXR, WebGPU, WebXR?
What industries are best suited? Games/Entertainment/ Sports? AEC?
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.