Thank you for your comment and we love your take on this! Coming to what we think about John Carmack's arguments against building a custom XR OS at Meta,
It's kinda hard to have a single answer for this but we like to think that this project did not work out for META particularly. We believe that it was perhaps not the right project for someone like META who already had other on-going projects to deal with. Although a setback, it doesn't necessarily mean there's a fault in the idea itself. We'd like to address the problems that were mentioned with the development of a custom XROS -
1) Cost : We've managed to do everything up until this point at the cost of 0$. However, we're in initial stages and expect to incur costs in the next few months. But those costs are mostly associated with building the company and our own line of products, not in the actual development and engineering of the OS. We've managed to remain extremely cost efficient and intend to continue that practice.
2) Burden on third-party/new developers : We anticipated this problem right when we started building the OS. Over time, we've come up with plans to encounter it and are currently working on making sure that the barrier to enter and create applications and software on Xeneva remains as non-existent as possible. We intend on making the process easy, try to bring no learning curve whatsoever, thus allowing developers to port their existing software and applications to XenevaOS conveniently. Also create a beginner friendly environment so that new programmers are able to create an app on XenevaOS from scratch easily.
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.
We totally agree with you and accordingly, we've thought things through!
We do have appropriate strategies to handle challenges but once again, they're quite challenging! We would've loved to mention how exactly we plan to deal with closed sourced vendors but since that is a plan still in action, we'd love to disclose them at a later point once they're actually executed.
We've scheduled a prototype launch later this year. We would make much more progress till then and the public would get proven answers from our side once that happens!
> "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.
Targeting everything has indeed been a workload but we're trying to do the best we can! The project was initially just on x86 and we ported it to ARM in the last 3-4 months. The time it took us to port it on ARM was a fraction of what it took for us to build it on x86. Similarly, we look forward to port our OS to RISC-V even quicker and thus be ready to serve any and every use case and take up any opportunity that might present itself!
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!
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.
We get what you're saying. The claims that we're making do indeed seem like just claims for now but we're actively working on real life benchmarks in comparison to industry standards.
Stay tuned for our Public Beta/Prototype showcase scheduled later this year!
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'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.
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.
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.
A lot of great companies have come out of "bad for business, good for hobbyists" ideas... :)
Thank you for your comment and we love your take on this! Coming to what we think about John Carmack's arguments against building a custom XR OS at Meta,
It's kinda hard to have a single answer for this but we like to think that this project did not work out for META particularly. We believe that it was perhaps not the right project for someone like META who already had other on-going projects to deal with. Although a setback, it doesn't necessarily mean there's a fault in the idea itself. We'd like to address the problems that were mentioned with the development of a custom XROS -
1) Cost : We've managed to do everything up until this point at the cost of 0$. However, we're in initial stages and expect to incur costs in the next few months. But those costs are mostly associated with building the company and our own line of products, not in the actual development and engineering of the OS. We've managed to remain extremely cost efficient and intend to continue that practice.
2) Burden on third-party/new developers : We anticipated this problem right when we started building the OS. Over time, we've come up with plans to encounter it and are currently working on making sure that the barrier to enter and create applications and software on Xeneva remains as non-existent as possible. We intend on making the process easy, try to bring no learning curve whatsoever, thus allowing developers to port their existing software and applications to XenevaOS conveniently. Also create a beginner friendly environment so that new programmers are able to create an app on XenevaOS from scratch easily.
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.
We totally agree with you and accordingly, we've thought things through! We do have appropriate strategies to handle challenges but once again, they're quite challenging! We would've loved to mention how exactly we plan to deal with closed sourced vendors but since that is a plan still in action, we'd love to disclose them at a later point once they're actually executed.
We've scheduled a prototype launch later this year. We would make much more progress till then and the public would get proven answers from our side once that happens!
> "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.
Targeting everything has indeed been a workload but we're trying to do the best we can! The project was initially just on x86 and we ported it to ARM in the last 3-4 months. The time it took us to port it on ARM was a fraction of what it took for us to build it on x86. Similarly, we look forward to port our OS to RISC-V even quicker and thus be ready to serve any and every use case and take up any opportunity that might present itself!
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!
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.
We get what you're saying. The claims that we're making do indeed seem like just claims for now but we're actively working on real life benchmarks in comparison to industry standards.
Stay tuned for our Public Beta/Prototype showcase scheduled later this year!
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!
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.
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.
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!
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.
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.
Agreed.