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

> You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux.

Not the parent, but of course they're wasting their time... That's the point of a hobby OS.

I'm working on a hobby OS, and I have no illusions that it's most likely fewer than 10 people will ever run it, and less than 100 will hear about it, but it lets me explore some interesting (to me) ideas, and forces me to learn a little more about random pieces of computing. If I ran on GCP, I'd want the reboot button to work. That sounds useful.

On the topic, I don't see why anyone would want to build a general purpose OS. There's enough already and even with the shrinking of hardware variety, there's a lot of stuff to support to make a general purpose OS work on enough hardware for people to consider using it. You can take Linux or a BSD and hack it up pretty good to explore a lot of OS ideas. Chances are you're going to borrow some of their drivers anyway, and then you'll end up with at least some similarity... may as well start there and save a lot of time. (My hobby OS has a custom kernel and custom drivers, but I only support a bare minimum of devices... (pc) console i/o, one real NIC, and virtio-net... that's all I need; I might add support for more NICs and more consoles later)

I didn't say they were wasting their time on their hobby OS, they are wasting their time trying to get it to do very esoteric thing on GCP.

They aren't trying to get reboot to work, they are trying to get their version of kexec to work so their hobby os reboots faster.

https://wiki.archlinux.org/title/Kexec

The biggest scam in the OS world is drivers, we should demand more out of our hardware. Drivers shouldn't be necessary.

They said they wanted the soft reboot button to work. I assumed they meant catching the button press, which having seen some of this stuff is probably very tricky.

I don't see why a kexec alike wouldn't work about the same on GCP vs qemu vs bare metal... Or what that has to do with a GCP soft reboot button (which again, I think is referring to the reboot button in the GCP console)

Either way, the whole thing is a waste of time, yes? Why not waste time on the part that's engaging?

> The biggest scam in the OS world is drivers, we should demand more out of our hardware. Drivers shouldn't be necessary.

I can't even fathom what you mean here? You've got to have some interface to communicate with hardware. That's a driver. Some hardware only needs a very small driver... Tell the hardware where to send input, how to notify when input is ready and when its ready for output, and tell the hardware where data to output is. Maybe some setup stuff for modes and whatever if the needs aren't obvious and universal. I don't see how you could possibly avoid that.

It would certainly be possible for more devices to use common interfaces so a single driver could operate many different devices. Maybe that's what you mean? There's some movement towards that... SATA controllers generally speak AHCI, human interface devices generally appear as USB HID devices, etc. NICs tend to have a wide variety of setup sequences, but data queues usually fit into one of a limited number of patterns.

> Tell the hardware where to send input, ...

I agree you need a driver but for most hardware, that should be pretty simple, and easily documented by the hardware vendor, shouldn't it? A button has to be about the simplest possible I/O device imaginable.

Yeah, problem is it's likely an acpi button, which ties you into all the fun of that.

Of course, ACPI is supposed to make interfacing with lots of similar things easier, kind of, so there you go.

> The biggest scam in the OS world is drivers, we should demand more out of our hardware. Drivers shouldn't be necessary.

What do you mean by that?

Hardware is so broken that getting useful functionality basically amounts to casting magic spells and drivers are supposed to be master wizards who know all the points where the spell book is wrong or incomplete. If you think drivers are bad, don’t look at the hardware, you’ll get depressed.

I misremembered (since it was 4 years ago).

I was actually just trying to support "power off" in GCP, with the stretch goal of being able to support graceful power off from the GCP console (which is part of supporting power off then power back on restart).

This is fundamentally the problem. Just like being able to send OTA updates has enshittified all software, having this magic shim layer that fixes hardware problems has enabled shit hardware, and then foisted all this complexity into the OS. Many abstractions are like bondo, they just cover rot.

I am addressing your comment and eru's question about drivers.

The hardware that would normally need drivers should present itself over a fixed, well documented protocol. Think virtio, or usb device classes but more comprehensive. This would also allow for said hardware to rigorously tested before it ever sees an OS. As it is now, because the hardware is shit and requires a driver, you can't really test the hardware in a way that an OS would expect because it requires the OS driver to even start to function. The job of the OS is now to repair broken hardware.

https://docs.oasis-open.org/virtio/virtio/v1.3/virtio-v1.3.h...

https://wiki.osdev.org/Virtio

https://en.wikipedia.org/wiki/USB_communications_device_clas... (the only good thing to come out of usb)

Responded https://news.ycombinator.com/item?id=45075820

The problem with your wish is that's you're kinda getting it in some cases, and it's a bit of a monkey paw. Hardware vendors are increasingly creating systems that abstract away the underlying hardware from the OS (usually by writing their own software on some other core that really drives the hardware), but the problem is they're generally closed, buggy, and leaky, and so the OS stops really being the OS of the system and instead you have a collection of barely-related subsystems that it's really difficult to get to work together effectively, and way more security holes than you can shake a stick at. (Oh, and they're usually only ever tested against one particular OS and so they're not actually particularly portable)