ayush_xeneva

We are building XenevaOS because we’re tired of seeing XR hardware held back by mobile-first operating systems. Android is great for phones, but the overhead and the non-deterministic nature of any other scheduler make it a struggle for low-latency spatial computing.

Our custom kernel, Aurora, is built to handle real-time priority based interrupt handling, minimal IPC overhead & focuses on minimizing abstraction layers to achieve low latency and optimization.

Codebase is open for feedback here: https://github.com/manaskamal/XenevaOS

We're a small team and we’d love to hear from people who have worked on custom kernels or XR display stacks. What are we missing?

The attached link is for our waitlist, you can check the codebase here : https://github.com/manaskamal/XenevaOS

Interesting, noted. Here's our repo btw - https://github.com/manaskamal/XenevaOS

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!

Agreed.

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.

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!

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're building completely bottoms up!

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!

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 ;)

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.

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.

Your comment is acknowledged.

Thank you, Team Xeneva.

Thank you so much for your comment ! If you're interested, you can have a look at our website, getxeneva.com to learn more!

Team XENEVA.

Hello, thanks for your comment.

Xeneva is built from scratch with modern hardware and modern computing on mind. We're working on making a transitional shift from legacy systems. You can refer to our website, getxeneva.com to get a hint about our purpose, future goals and vision!

Thank you, Team XENEVA.

Hello, MSVC seems quite interesting for us. No doubt, the code can be ported to other build environment. For instance, The ARM64 version uses both the advantages of clang and MSVC. The build setup is not so hard, and once setup is completed it can be build within a click.

It's possible to run the system using Hyper-V. Required configuration are clearly mentioned in the documentation. Windows add extra security called Virtualization Based Security which needs to be disabled while running XenevaOS. Xeneva is well tested on VMware Workstation Pro and Virtual Box. We're working on real machine support, making the project to be beyond hobby os project.

XenevaOS is built from ground up with modern computing in mind. We're currently working on bringing it to XR systems (AR/VR devices). Compared to other OS, Xeneva doesn't holds legacy legacy hardware code which make it easy to focus on modern technologies. The project aims to be multi architectured, minimal abstractions in software for better performance and to put user as first priority rather than user fixing software requirements.

You can refer to our website, getxeneva.com to get a hint about our project's purpose, goals and vision!

Thank you, Team XENEVA.

Hello, thank you for reaching out! Yes, the GitHub repository has limited information currently, but we are working on the documentations.

- Xeneva is not intending to be Unix like, but some core principles of Unix are followed.

- Xeneva has its own libc implementation called XECLib that are attached to Xeneva's own system call interface.

- Xeneva supports IPC via shared memory, IPC via socket and IPC via its own message based communication called PostBox IPC. Xeneva currently use framebuffer for Graphics Output, no working video driver is implemented. The framebuffer is mapped onto Windows Managers address space and the Windows Manager composes the final image to framebuffer by writing to that mapped virtual address.

- Xeneva uses PE format for executable,no doubt ELF support can be implemented. XELoader is a dynamic linker and loader process which is responsible for resolving running processes symbols by linking it to its specific shared library. Whenever a new process get spawned,and an executable is loaded, the XELoader loads all required shared libraries and link them to the process.

You can refer to our website - getxeneva.com to get a hint of our future goals and vision.

Thank you, Team XENEVA.