1. 13

  2. 1


    1. 5

      According to the guy behind handmade hero:

      The fact that we currently have hardware vendors shipping both hardware and drivers (with USB and GPUs being to major examples), rather than just shipping hardware with a defined/documented interface, a la x64, or the the computers of the 80s, is a very large contributor to the fact that we have basically 3 consumer-usable OSes, and each one is well over 15 million lines of code. These large codebases are a big part of the reason that using software today can be rather unpleasant

      He proposes that if hardware vendors switched form a hardware+drivers to hardware that was well-documented in how it was controlled, so that most programmers could program it by feeding memory to/from it (which he considers an ISA of sorts), we’d be able to eliminate the need for drivers as such, and be able to go back to the idea of a much simpler OS.

      I haven’t watched the whole thing yet, but that’s the highlights

      1. 7

        Oh I would so, so, so, love that to happen…..

        …but as a guy whose day job is at that very interface I will point this out.

        The very reason for the existence of microcomputers is to soak up all the stuff that is “too hard to do in hardware”.

        Seriously, go back to the original motivations for the first intel micros.

        And as CPU’s have become faster, more and more things get “winmodemed”.

        Remember ye olde modems? Nice well defined rs-232 interface and standardized AT command set?

        All gone.

        What happen?

        Well, partly instead of having a separate fairly grunty/costly CPU inside the modem and a serial port… you could just have enough hardware to spit the i/q’s at the PC and let the PC do the work, and shift the AT command set interpretor into the driver. Result, cheaper better modems and a huge pain in the ass for open source.

        All the h/w manufacturers regard their software drivers as an encryption layer on top of their “secret sauce”, their competitive advantage.

        At least that’s what the bean counters believe.

        Their engineers know that the software drivers are a layer of kludge to make the catastrophe that is their hardware design limp along enough to be saleable

        But to bring their h/w up to a standard interface level would require doing some hard (and very costly) work at the h/w level.

        Good luck convincing the bean counters about that one.

        Of course, WinTel regard the current mess as a competitive advantage. It massively raises the barriers to entry to the market place. So don’t hold your breathe hoping WinTel will clean it up. They created this mess for Good (or Bad depending on view) reasons of their own.

        1. 1

          All the h/w manufacturers regard their software drivers as an encryption layer on top of their “secret sauce”, their competitive advantage.

          I thought the NDA’s and obfuscations were about preventing patent suits as much as competitive advantage. The hardware expert that taught me the basics of cat and mouse games in that field said there’s patents on about everything you can think of in implementation techniques. The more modern and cutting edge, the more dense the patent minefield. Keeping the internals secret means they have to get a company like ChipWorks (now TechInsights) to tear it down before filing those patent suits. Their homepage prominently advertises the I.P.-related benefits of their service.

          1. 2

            That too definitely! Sadly, all this comes at a huge cost to the end user. :-(

        2. 1

          The obvious pragmatic problem with this model is that hardware vendors sell the most hardware (and sell it faster) when people can immediately use their hardware, not when they must wait for interest parties to write device drivers from it. If the hardware vendor has to write and ship their own device drivers anyway, writing and shipping documentation is an extra cost.

          (There are also interesting questions about who gets to pay the cost of writing device drivers, since there is a cost involved here. This is frequently going to be ‘whoever derives the most benefit from having the device driver exist’, which is often going to be the hardware maker, since the extra benefit to major OSes is often small.)