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

Yeah this. I tried to modify a hobby OS recently so it would process the "soft reboot" button (to speed up being rebooted in GCP) and it was so unbelievably hard to figure out how to support it. I tried following the instructions on the OS Dev Wiki and straight up reading what both Linux and FreeBSD do and still couldn't make progress. Yes. The thing that happens when you tell Windows or Linux to "restart". Gave up on this after spending days on it.

The people who develop OSes are cut from a different cloth and are not under the usual economic pressures.

I also think that they have access to more helpful resources than people outside the field do, e.g. being able to contact people working on the lower layers to get the missing info. These channels exist in the professional world, but they are hard to access.

The VMM on GCP has only really been tested with Linux. You are kinda wasting your time, the only way to make it work is to make the hobby OS Linux.

> 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.

To clarify, are you having trouble getting the signal to reboot from the gcp console into your OS? Or are you having trouble rebooting on gcp?

> 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 mean when the hobby OS wants to shut down, it can power the machine it's running on down. Not unlike what would happen if you clicked power off on your desktop OS menu.

Getting it to work on GCP meant properly driving something called the Intel PIIX4 controller which was emulated into the VM.

Separately from the OS being able to turn itself off, the OS needs to process a signal received by the hypervisor on this controller to support the hypervisor gracefully shutting it down. Otherwise GCP will wait 90 seconds after it has sent the shut down signal to give up and terminate the VM itself.

The problem I was trying to solve was (a) OS can shut itself down in GCP (b) restarts in GCP from the GCP console would be instant, rather than take 90+ seconds

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)