4 ms·

The BeOS "reimplementation" is called Haiku. It is a pretty remarkably mature project, though unfortunately not what I'm looking for in a new OS personally. Th

The BeOS "reimplementation" is called Haiku. It is a pretty remarkably mature project, though unfortunately not what I'm looking for in a new OS personally. The reason we don't see new OSs is pretty simple: there is entirely too much hardware you have to accommodate to be usable. There are klocs of actual kernel code in Linux, and Mlocs of driver code.

Koshkin 6y ago
I think the answer is to have device drivers implemented as part of device firmware.
- yjftsjthsd-h 6y ago
  Oh, like UEFI or openfirmware drivers? That's... a pretty neat idea, actually. That would lower the barrier to entry, certainly. About the only issue I see is then trusting those drivers (I don't really trust hardware mfgs, and you'd have to update them somehow), but that seems doable.
- giantrobot 6y ago
  That becomes extremely problematic as a lot of devices anymore ship with bare minimum firmware to turn themselves on and require the host to upload firmware to actually work. The "drivers" on disk are then the modules required by the OS and a big blob of firmware. Other times devices are just a thin PHY interface and all of the work is done in software inside the driver. There's nothing on the device to even run onboard firmware. So many devices can't store their own drivers for the host to use, let alone store drivers for multiple operating systems.
  - Koshkin 6y ago
    So the idea is similar to the one at the base of (the original) OpenGL, i.e. that of a hardware API that can be used by any OS.
    - giantrobot 6y ago
      There's a bit of that already with USB device classes. A keyboard might have a bunch of special features if it at least works with the USB HID keyboard class it will have base level keyboard functionality. For some things like HIDs this can be pretty workable. For more complicated peripherals it is far more challenging if not impractical. That's not to say device drivers should be an insane Wild West of compatibility shims and edge cases but some blanket solution doesn't solve all problems.

Koshkin 6y ago

I think the answer is to have device drivers implemented as part of device firmware.

yjftsjthsd-h 6y ago
Oh, like UEFI or openfirmware drivers? That's... a pretty neat idea, actually. That would lower the barrier to entry, certainly. About the only issue I see is then trusting those drivers (I don't really trust hardware mfgs, and you'd have to update them somehow), but that seems doable.
giantrobot 6y ago
That becomes extremely problematic as a lot of devices anymore ship with bare minimum firmware to turn themselves on and require the host to upload firmware to actually work. The "drivers" on disk are then the modules required by the OS and a big blob of firmware. Other times devices are just a thin PHY interface and all of the work is done in software inside the driver. There's nothing on the device to even run onboard firmware. So many devices can't store their own drivers for the host to use, let alone store drivers for multiple operating systems.
- Koshkin 6y ago
  So the idea is similar to the one at the base of (the original) OpenGL, i.e. that of a hardware API that can be used by any OS.
  - giantrobot 6y ago
    There's a bit of that already with USB device classes. A keyboard might have a bunch of special features if it at least works with the USB HID keyboard class it will have base level keyboard functionality. For some things like HIDs this can be pretty workable. For more complicated peripherals it is far more challenging if not impractical. That's not to say device drivers should be an insane Wild West of compatibility shims and edge cases but some blanket solution doesn't solve all problems.