←back to thread

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

(twitter.com)
521 points OlympicMarmoto | 2 comments | 29 Aug 25 16:45 UTC | HN request time: 0.491s | source
Show context
jnwatson ◴[29 Aug 25 17:46 UTC] No.45067216[source]▶
I've written a lot of low level software, BSPs, and most of an OS, and the main reason to not write your own OS these days is silicon vendors. Back in the day, they would provide you a spec detailed enough that you could feasibly write your own drivers.

These days, you get a medium-level description and a Linux driver of questionable quality. Part of this is just laziness, but mostly this is a function of complexity. Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.

replies(13): >>45067491 #>>45069282 #>>45069287 #>>45069349 #>>45069690 #>>45070345 #>>45071036 #>>45071086 #>>45072259 #>>45072391 #>>45073789 #>>45075476 #>>45081942 #
bbarnett ◴[29 Aug 25 21:03 UTC] No.45069349[source]▶
Modern hardware is just so complicated it would take a long time to completely document, and even longer to write a driver for.

That's what's claimed. That's what people say, yet it's just an excuse. I've heard the same sort of excuse people have, after they write a massive codebase, then say "Oops, sorry, didn't get around to documenting it".

And no, hardware is not more difficult than software to document.

If the system is complex, there's more need to document, just as with a huge codebase. On their end, they have new employees to train up, and they have to manage testing. So any excuse that silicon vendors have to deal with such immense complexity? My violin plays for them.

replies(3): >>45069603 #>>45070341 #>>45073345 #
makeitdouble ◴[29 Aug 25 22:57 UTC] No.45070341[source]▶
> "Oops, sorry, didn't get around to documenting it".

That's obviously the wrong message. They should say "Go ask the engineering VP to get us off any other projects for another cycle while we're writing 'satisfying' documentation".

Extensive documentation comes at a price few companies are willing to pay (and that's not just a matter of resources. Look at Apple's documentation)

replies(3): >>45071005 #>>45072212 #>>45072560 #
MathMonkeyMan ◴[30 Aug 25 00:55 UTC] No.45071005[source]▶
I write documentation as I'm writing the code. In my opinion, the code is only as good as its documentation -- they're two parts of the same thing. It's mostly comments at the top of files, and sometimes a markdown file in the same directory.

This way, good documentation is priced into my estimate for the project. I don't have a work item "spend a few days documenting." Nope, if I'm doing a foo then that includes documenting a foo at the same time.

replies(3): >>45071326 #>>45072618 #>>45073289 #
1. makeitdouble ◴[30 Aug 25 09:37 UTC] No.45073289[source]▶
> the code is only as good as its documentation

This heavily depends on your niche I think. If you're writing closed source vendor software and your client's only guiding light is your documentation, it's 100% true.

If you're working on a 5 people project that evolves at a fast pace, and everyone touching the code is expected to be familiar with the domain and operations, you'll mostly leave comments (todos, meta info, external ticket links etc), not documentation per se.

replies(1): >>45076157 #
2. MathMonkeyMan ◴[30 Aug 25 17:01 UTC] No.45076157[source]▶
Everywhere I've worked, there is software written by those five people, who are now all rich and don't write code anymore, and I still would appreciate the courtesy of an explainer.

The trouble with good docs is that they are work to maintain, like good code. If we decide to change this component in a substantial way soon, which we likely will, I'd have to practically rewrite the docs! Why bother?

Because the docs are part of the code. Write the docs.

I don't expect to win this crusade, but I'll keep writing docs anyway. Then later people will modify the code without modifying the docs, and so the docs will be a lie, but still useful, I think.

It's like asking three people who are not closely familiar with a component, but who have worked with it, "what is this thing, how does it work?" You will get three different answers. It would be nice if one of them were a written description straight from the horse's mouth, even if the component is now more of a camel.