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.

▲

baq 6 days ago | parent | next [-]

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.

▲

sitkack 6 days ago | parent [-]

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)

	▲	rcxdude 5 days ago \| parent [-]
		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)

▲

toast0 7 days ago | parent | prev | next [-]

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.

▲

foxglacier 7 days ago | parent [-]

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

	▲	toast0 7 days ago \| parent [-]
		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.

▲

eru 7 days ago | parent | prev | next [-]

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

	▲	sitkack 6 days ago \| parent [-]
		Responded https://news.ycombinator.com/item?id=45075820

▲

mbac32768 6 days ago | parent | prev [-]

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