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!
Thank you for your comment and yes we totally get the things that you've mentioned. We're well prepared and ready to tackle a possible "perpetual development hell" and are also aware about the issues with closed source SoCs. It's quite a challenging route and journey but we do not intend on looking back and are sure about figuring out things one way or the other.
Coming to the "vids or it didn't happen" feeling, we totally get that as well. To be fair, we would've had the same feeling if we watched ourselves from a third person perspective. But we're actively working on bringing visible proof (benchmark is a better work) on the claims and promises that we're making. And in your analogy, the vids are coming soon, stay tuned ;)
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?
We're doing research on some new way of handling things, like why always "Everything is a file?" "The Philosophy on Unix" and other approach can be taken with optimization on mind. Figuring out the best possible ways to avoid extra memory allocation and resource allocation without degrading performance. Though we're at the early stage of this Philosophy but we're working on that. So that modern OS comes up some modern approach with optimization on mind.
We intend to plain a clearer picture with proven results of what we're doing in the coming few weeks and months. Stay tuned!
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.
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.
Thank you for your comment and we agree that saying "we’re removing legacy baggage" is more like a blank marketing statement if not backed by any real technical answers but yes, the reason for that happening is due to the state of our venture, we're still in initial stages but hopefully the case wouldn't be that for long. The last discussion that we had internally among the team was on bringing real benchmarks in comparison to the industry giants (such as Linux) in the coming few weeks.
Also you're right in one sense about how building a new kernel from scratch may not be the best way to tackle XR. But our whole point in creating this kernel was to be able to solve issues like latency and resource optimization on a completely different level and create a lively playground/environment for both software developers and hardware engineers to work on.
Basically, we're currently actively working hard towards proving the claims and fulfilling promises that we're currently making!
We do mean AI being as an OS Functionality, although this has a long way to go and we transparently admit that we're still in initial stages. One of the primary use cases or functionality for AI integration would be for app development. The idea is to leverage AI by training an advanced model on our own data, thus making it capable to help developers port their existing software and applications to XenevaOS conveniently. Also it'll help beginner programmers create an app on XenevaOS from scratch easily.
App development wouldn't necessarily be the only functionality of AI in the OS but it will definitely be a primary one.
We've looked closely into MentraOS and respect them for what they're doing! We see that they're funded by YC and are doing great but although both Team Xeneva & Team Mentra operate in similar fields, both of our ventures are fundamentally different. We've planned our own route & path that is filled with a set of unique goals & milestones.
Thank you for your comment and yes, totally from scratch! You can look at our GitHub commit history to get a hint of how we were able to implement all of this.
Speaking of hardware, we're targeting SOCs like Rockchip, Raspberry Pi 3,4 and Qualcomm Snapdragon Chips.
It currently doesn't support any open standard but we're targeting OpenXR standard and also some native way of application writing where developer doesn't need to care about whether they are writing for XR devices or other devices. The OS will take care of it.
Currently we are more focused on building a lifestyle product experience, which includes Games, Entertainment and general daily use cases like navigation, etc.
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.
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!
Thank you for your comment and yes we totally get the things that you've mentioned. We're well prepared and ready to tackle a possible "perpetual development hell" and are also aware about the issues with closed source SoCs. It's quite a challenging route and journey but we do not intend on looking back and are sure about figuring out things one way or the other.
Coming to the "vids or it didn't happen" feeling, we totally get that as well. To be fair, we would've had the same feeling if we watched ourselves from a third person perspective. But we're actively working on bringing visible proof (benchmark is a better work) on the claims and promises that we're making. And in your analogy, the vids are coming soon, stay tuned ;)
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?
We're doing research on some new way of handling things, like why always "Everything is a file?" "The Philosophy on Unix" and other approach can be taken with optimization on mind. Figuring out the best possible ways to avoid extra memory allocation and resource allocation without degrading performance. Though we're at the early stage of this Philosophy but we're working on that. So that modern OS comes up some modern approach with optimization on mind.
We intend to plain a clearer picture with proven results of what we're doing in the coming few weeks and months. Stay tuned!
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.
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.
Thank you for your comment and we agree that saying "we’re removing legacy baggage" is more like a blank marketing statement if not backed by any real technical answers but yes, the reason for that happening is due to the state of our venture, we're still in initial stages but hopefully the case wouldn't be that for long. The last discussion that we had internally among the team was on bringing real benchmarks in comparison to the industry giants (such as Linux) in the coming few weeks.
Also you're right in one sense about how building a new kernel from scratch may not be the best way to tackle XR. But our whole point in creating this kernel was to be able to solve issues like latency and resource optimization on a completely different level and create a lively playground/environment for both software developers and hardware engineers to work on.
Basically, we're currently actively working hard towards proving the claims and fulfilling promises that we're currently making!
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?
We do mean AI being as an OS Functionality, although this has a long way to go and we transparently admit that we're still in initial stages. One of the primary use cases or functionality for AI integration would be for app development. The idea is to leverage AI by training an advanced model on our own data, thus making it capable to help developers port their existing software and applications to XenevaOS conveniently. Also it'll help beginner programmers create an app on XenevaOS from scratch easily.
App development wouldn't necessarily be the only functionality of AI in the OS but it will definitely be a primary one.
Related recent discussion:
MentraOS – open-source Smart glasses OS
https://news.ycombinator.com/item?id=45140381 (4 days ago; 200+ points, 120+ comments)
We've looked closely into MentraOS and respect them for what they're doing! We see that they're funded by YC and are doing great but although both Team Xeneva & Team Mentra operate in similar fields, both of our ventures are fundamentally different. We've planned our own route & path that is filled with a set of unique goals & milestones.
Is this really not based on some existing system? How were you able to implement all that stuff from scratch? Looks cool.
Thank you for your comment and yes, totally from scratch! You can look at our GitHub commit history to get a hint of how we were able to implement all of this.
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?
We're building completely bottoms up!
What hardware is currently supported?
What open standards does it support? OpenXR, WebGPU, WebXR?
What industries are best suited? Games/Entertainment/ Sports? AEC?
Speaking of hardware, we're targeting SOCs like Rockchip, Raspberry Pi 3,4 and Qualcomm Snapdragon Chips.
It currently doesn't support any open standard but we're targeting OpenXR standard and also some native way of application writing where developer doesn't need to care about whether they are writing for XR devices or other devices. The OS will take care of it.
Currently we are more focused on building a lifestyle product experience, which includes Games, Entertainment and general daily use cases like navigation, etc.
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.