4 ms·
It would be nice if there was a unified driver model that the OS developers could easily add a wrapper level to accomodate there needs. If hardware companies h
by Zenst 14y ago
It would be nice if there was a unified driver model that the OS developers could easily add a wrapper level to accomodate there needs. If hardware companies had full open source drivers then this would be less of an issue, this is not the rosey situation we have and in many area's we have binary blobs. Binary blobs targeted at an OS and CPU.
Now with the advent of ARM, the sence to have open source drivers becomes more palatable and hopefully sainer. More options for your hardware to run upon and be sold upon is more sales. If you open source things and let the community help then they help and you get more win win. It is the area's were companies want to protect IP they have above and beyond the patent protection. There are cases if they are using others IP in there product which they pay to use that prevents them from releaseing the source and at best able to do binary blobs. If we had binary blobs that you could add your own wrapper around and accomodate a OS's needs, then you would still have more platforms than not open to you.
But this realy is mostly down to fancy networking cards, graphics cards and anything with a radio in it mostly. But there are always options and with the right purchaseing you can vote with your money. Support the ability to change your OS even if you don't plan on it today, think of the children :).
- meaty 14y agoARM is even worse when it comes to binary blobs. Take a look at any major SoC out there and you will see BLOBs for the LAN and graphics interfaces. Occasionally boot firmware is a BLOB as well. We need a completely open patent unencumbered platform as well as software. Unfortunately the barrier to entry on this is seriously high; much larger than even bringing medicine to market.
- justin66 14y agoI'm sure that's true but it's important to keep one thing in mind: not all binaries are the result of an Nvidiaesque attempt to keep from open-sourcing something. Loading updateable binary microcode to implement an ISA is often a beneficial processor design technique and it dates back to seventies. There's some irony in the OpenBSD objection to handling binary blobs. A lot of the cool old systems OpenBSD supports are LOADED with microcode and ROM the user can never see or understand. It's hidden. To a degree this is even true in the case of the everyday AMD64 machine (which loads microcode updates and some of its boot logic from BIOS ROM/EFI, thank you). OpenBSD's position, in conjunction with its support of these systems that load all that stuff from ROM at boot time and its lack of support for the ones without a proper ROM to store the stuff (raspberry pi, for example), keep it from having to handle these blobs personally. The principle involved here isn't "let's shun the use of binaries for which we don't have the source code." The principle is "binaries are yucky, don't get any on you." It's not hugely impressive.
- sedachv 14y ago> It would be nice if there was a unified driver model that the OS developers could easily add a wrapper level to accomodate there needs. At the source level, NetBSD developers came up with exactly this idea, which is now colloquialy known as bus_dma (http://en.wikipedia.org/wiki/Busdma http://en.wikipedia.org/wiki/Busdma). FreeBSD and OpenBSD picked up the interfaces modulo a few changes, and now get to share drivers relatively easily.