John Carmack's arguments against building a custom XR OS at Meta

You could write a book on why it's practically impossible to create a new OS these days. Love Carmack for stating it so clearly. I also love that called out TempleOS, I also have a weird respect for it. Plan 9 is the probably the best example of a totally new OS and I hope someday it becomes viable because it's really a joy to use.

But ultimately it just makes sense to adapt existing kernels / OS (say, arch) and adapt it to your needs. It can be hair wrenchingly frustrating, and requires the company to be willing to upstream changes and it still takes years, but the alternative is decades, because what sounds good and well designed on paper just melts when it hits the real world, and linux has already gone through those decades of pain.

I would read that book.

OS isnt the hard part.

The driver ecosystem is the moat. Linux finally overcame it decades later

Yeah, the Linux kernel has ~12m lines of code. <1m are the core, the rest are drivers.

Android built a new, giant moat for Linux (or "Linux" depending on your opinions about Android) in the embedded application processor space - now the "standard" board support package target for new embedded AP hardware is almost always some random point-in-time snapshot of Android. Running "mainline" Linux is hard (because the GPU and media peripheral drivers are usually half-userspace Android flavored stuff and rely on ION and other Androidisms) and bare-metal is even worse (where previously, you'd get register-level documentation, now, you get some Android libXYZ.so library).

29 Millions according to https://www.phoronix.com/news/Linux-6.16-AMDGPU-Driver-Size

5 Millions alone for the AMD graphic driver.

What an inefficient disaster to carry around all those drivers to run hardware that isn't on the device you're running on.

* The vast majority aren't compiled into any given kernel

* Those that are are only loaded when needed

It's not that bad

It's modular so you don't have to compile drivers you don't need.

I sympathize, but the reality is that except for very specialized cases, (hyper) optimizing for CPU performance is unnecessary, even in the embedded space. A Cortex-M0 has roughly the same performance as a 486, and is cheap and power efficient enough to be bundled in disposable test kits, vapes, etc.

Much of that 5M are hardware register definitions expanded into C headers. I am not sure how you'd consolidate that but it's not like that's all bespoke C code.

Most of it is in modules that don't have to be compiled at all (and usually aren't)

I don't remember there being any time in history where you got "register-level documentation".

Those boards were always accompanied by horrific binary blobs glued to a kernel form a stone age. Or Windows.

Writing TempleOS software taught me lower-level programming! The OS is weird and idiosyncratic, but much more polished and logical than you'd expect from seeing videos of its author.

There is also ACPU OS https://www.acpul.org/blog/so-fast