Ubuntu & Linux Hardware Support: Working With OEMs Is Key
When it comes to improving hardware support for Linux, there are two traditional strategies: The Do-It-Yourself method, by which geeks write their own device drivers, and the Beg-And-Plead approach, or asking OEMs for open-source drivers and hoping they comply. But Canonical seems to be forging a third path by actually cooperating with upstream manufacturers to bring better hardware support to Ubuntu. Here’s how, and what it means for the lives of Linux users everywhere.
First, though, it’s worth observing that hardware support on Linux has come a long, long way in recent years, especially on the desktop. Complaints about missing drivers or hit-and-miss compatibility for devices like wireless cards, digital cameras and printers will probably remain a perennial refrain within the Linux community for a while to come. But for those of us who remember what things were like as recently as the mid-2000s — when almost no wireless cards were natively supported and users were lucky if even their video cards worked out-of-the-box — it’s hard to deny that the situation has improved vastly since that time.
The Cooperative Approach: Working With OEMs
That said, some hardware still lacks good support on Linux. And as the Linux world continues to creep onto new devices, like tablets, phones and TVs, demand for more and better hardware compatibility will doubtless remain steady.
That’s why it’s encouraging to see Ubuntu developers actively addressing these sorts of issues, with their process outlined in a recent blog post by Victor Tuson Palau, commercial engineering director at Canonical.
What I like especially about the approach as described by Palau is the emphasis on active cooperation with OEMs. Instead of ignoring device manufacturers by trying to engineer drivers independently, or making itself subservient to OEMs by begging for Linux-compatible drivers and having to accept whatever they decide to deliver regardless of its quality or GPL-friendliness, Canonical’s objective is to collaborate with device manufacturers by sharing information and engineering resources.
A cooperative approach may seem like a no-brainer. But given the history of the hardware-support scene in the Linux world, where there has typically been little direct engagement between open-source developers and OEMs, Canonical is actually doing something rather innovative. By no means, of course, is it the first organization in the open-source world to work with device manufacturers on drivers — Red Hat has done the same, although its chief interest tends to be in server hardware, and companies like Intel and ATI have compiled good records of cooperation with Linux developers. But Canonical is remarkable for pursuing systematic collaboration on the desktop and beyond.
Another key point of the Canonical’s hardware-support strategy as outlined by Palau is that there’s no mention of licensing issues. This is also a bigger deal than it might seem at first glance, since in many instances a reluctance on the part of some portions of the Linux community to accept non-GPL’d device drivers has hindered cooperation between the community and OEMs. Without a doubt, fully open-source drivers are always preferable to proprietary blobs. But the fact that Ubuntu developers won’t let philosophical issues get in the way of the simple goal of making stuff work is important.
Since I’m writing this post from a computer where I still need ndiswrapper to get the wireless card running, I can attest that hardware support on Ubuntu remains far from perfect. Nonetheless, it’s great to see the distribution developers working to make it better in a pragmatic and effective way.
quote::But Canonical seems to be forging a third path ::quote
How about a 4th way, it works a treat for Apple, it’s also the way KDE has chosen for the Spark. build your own Ubuntu/Linux compatable hardware.
There is a fifth way: legally mandated hardware information availability.
And a sixth way: legally mandated compatibility with free software.
Canonical surely was helpful to the Raspberry Pi folks:
http://www.linuxuser.co.uk/features/raspberry-pi-interview-eban-upton-reveals-all/
Any VAR that deals with canonical needs to know that, like with Apple, you’re dealing with an organization of near-sighted, self-obsessed control freaks who will dictate to you what they expect you to do, and if you don’t do that, not only won’t they help, they actually try to thwart you or counter you. There’s a long line of people who have already learned it’s best to not deal with Canonical at all. Start with the Gnome and Banshee guys, and you’ll learn what others have.
“AC Says:
March 12th, 2012 at 1:13 am
There is a fifth way: legally mandated hardware information availability.
And a sixth way: legally mandated compatibility with free software.”
Could you elaborate on this? It sounds a bit radical to me, even if I do like the idea.
…please tell me I’m not missing the sarcasm or something.
Canonical/Ubuntu’s fame got little to do with their contribution on the hardware/driver side of things. IF they stand out in that area it would be for minimalism (wrt contribution). Same goes for any kernel development.
When stuff is plug’n play in Ubuntu, much of it is because of PackageKit (origin Fedora Project and RedHat), and e.g their campaign to collect all device ID’s to ensure that all printers are identified. PolicyKit? Also Red Hat.
Who financed the no 1 driver maintenance guy in Linux? Greg Kroah-Hartman was paid by Novell/SuSE for years and years.
Pulse Audio? Red Hat. (The very poor implementation in Ubuntu gave Pulse Audio a really bad name for 2-3 years). Compiz? Red Hat. (Ubuntu’s great popularity origins from Compiz as Ubuntu was the easy way getting it)
Ubuntu is normally pretty good at putting it all together, and e.g how Ubuntu handles swapping between different monitor setups is simply excellent.
They deserve plenty of credit in many areas. But not on the driver side of things where they are mostly freeriding.
Drivers for hardware in general (Linux) is excellent. I’ve been using Linux for 12-13 years, and never had to use NdisWrapper. Ever.
So, where are the REAL problems wrt drivers?
Nvidia Optimus:
One have to ensure that the machine has a BiOS that allows for selecting between Intel and Nvidia GPU or be aware of which GPU will be available for Linux.
Apart from that: Nvidia has been working just fine with Linux for over a decade. Linux users always has up to date drivers.
ATI Legacy:
ATI performed a cut-off wrt drivers to old hardware some years ago. The cut-off affected all operating systems. Thing was: At cut-off, they were seriously behind on the Linux side, and Nvidia was way ahead.
ATI GPU in general:
Catalyst is way harder to maintain for the distros compared to Nvida. That means that in most cases users will do fine, but some GPU’s may cause problems.
With ATI there are Ubuntu Unity specific problems. Simply because Unity is under heavy development thus all support is not completed on Ubuntu’s side. That’s not really a problem because anybody using Unity at this stage is an early adopter and should relate accordingly.
Intel GPU:
Early GMA (eg 950) was trash on any platform. Sadly, these GPU’s were popular in the Netbook dumping ground.
Intel did a HUGE mistake in contracting driver development for Poulsbro (GMA 500) to Tungsten (propietary). Avoid old Intel GPU’s and you’ll be safe.
Wifi/Networking:
As far as I know, NdisWrapper usage is extremely limited. Therefore, someone’s need for it should NOT be construed as evidence for a general problem with drivers in Linux.
Broadcom and Ralink was the two vendors “providing issues” for Linux and they both came around. NdisWrapper is probably still needed for a few old Broadcom cards – but that’s just about it.
Transferring all driver development to the vendors is not really the “thing”. If FOSS/Linux communities sat down waiting for the vendors drivers would have been a significant problem. Instead reverse engineered drivers have contributed significantly. Linux would have been extinct without that.
In fact, the vendors recruits the reverse engineering guys when they realise that they want to support Linux. ATI, Google and Intel have done that, and same goes for Wifi driver devs other places.
When it comes to connectivity it is actually far easier to set up and use HSDPA/3G with OpenSUSE and Ubuntu than it is with Windows 7 and OSX.
When installing Ubuntu or OpenSUSE or e.g Arch all drivers are available during installation. Not so with Windows 7 retail.
There is no general driver problem with Linux.
Lovely bit of misinformation this, ‘forging a third path’ by doing exactly what every other commercial Linux distribution has done before… 5 paragraphs talking about how forward thinking Canonical are before acknowledging the fact that this is not new. Wonderful…
Danny Sepley Says:
March 12th, 2012 at 3:23 am
Could you elaborate on this? It sounds a bit radical to me, even if I do like the idea.
…please tell me I’m not missing the sarcasm or something.
No sarcasm. In the first case, hardware would be barred from sale unless *full* technical specifications were openly available for it (this is the better solution of the two, IMO). In the second case, hardware would be barred from sale if it did not function fully with free software – leaving the manufacturer with the option of either building compatible black-box hardware, or making their own GPL’s code available.
I wouldn’t call either solution radical; black-box hardware is not in the best interest of society, and where a manufacturer’s interests are in conflict with the general welfare of society, the interests of society need to triumph over commercial concerns if a society is to endure.
@AC
“black-box hardware is not in the best interest of society” ‘ – hear, hear! I would love this solution (no more surfing HCL lists to see which laptop of the gazillion works), but isn’t it a bit much to assume fiat on this plan? IE how do we garner a force big as KONY 2012 and march on Congress to get this done?