New directions in Linux driver management
We have a long way to go before you can insert a new device and have reliable driver discovery, but we'll likely get there in the end. Many people are enthusiastic about the recent developments in driver support. Others worry that these efforts will make it easier for proprietary drivers, or that developers won't have a motivation to get their third-party drivers into the official Linux kernel.
To a certain extent, it is true that such processes will make life easier for those who don't want to play by the established rules of the Linux community, but then, there's no guarantee that they were interested in playing by the rules in the first place. All these efforts offer a means to eliminate binary drivers without placing the onus on the end user.
You might wonder why obtaining and installing drivers is so difficult on Linux, when on Windows and Mac systems it is simply a matter of dropping in a single driver file. The difference is that both Microsoft and Apple have driver development "models," complete with standardized APIs, that allow a developer to write the driver using a kernel interface that will not change. Microsoft calls this the "Windows Driver Model" (WDM). If you have ever used a Microsoft Windows system, you have perhaps seen drivers listed in the Windows Device Manager as being "WDM." There is no equivalent "Linux Driver Model."
Driver development models and APIs are a double-edged sword. On the one hand, they can be great for users who need to install drivers from third-party sources without worrying about their compatibility. Microsoft even has a driver signing program that allows developers to submit their drivers for official certification by Microsoft. Signed drivers will install without any kind of warning and be trusted by Windows to play by the rules. But in return for this driver interface, Microsoft is tied into supporting a "stable" kernel API for a number of years, which in reality means almost indefinitely. Because the API cannot change, Microsoft's Windows kernel developers are limited by what pieces of the kernel they can change and by how much.
Microsoft is forced to make such trade-offs because they work under a proprietary software development model in which source code is not available. But because Linux is open source, and the barrier to entry for getting code into the kernel is reasonable, Linux kernel developers have taken the view that supporting an official "Linux Driver Model" would artificially limit the ability for the kernel to evolve over time. For this reason, compatibility is not, in general, guaranteed between one Linux kernel and the next – even a relatively small change might completely alter the interface used by an installed device driver.
The Linux kernel community has taken remedial steps to make life easier for driver developers to get their drivers into the official kernel. Greg Kroah-Hartman (known within the community as "Greg K-H") created a Linux Drivers Project several years ago to facilitate giving free programming resources to those want to create Linux drivers. In recent times, Greg has also created a special part of the Linux kernel sources where unfinished drivers can live. If distributions want to make these drivers available to users, they need only flip a configuration option. It's not a perfect situation, but it should help to encourage more third-party developers to get their code into the official kernel.
Some finished drivers do not make it into the official kernel for one reason or another. Often, these are proprietary kernel drivers (drivers for which the source is not fully available) that are only available from a particular hardware vendor. But it is not just proprietary drivers that don't make it into the kernel. Some developers aren't ready to submit to the rigorous process of submitting their code to the official kernel.
MSBuild is now just another GitHub project as Redmond continues its path to the light.
Malware could pass data and commands between disconnected computers without leaving a trace on the network.
New rules emphasize collegiality in coding.
Upstart lands in the dust bin as a new era begins for Linux.
HP's annual Cyber Risk report offers a bleak look at the state of IT.
But what do the big numbers really mean?
.NET Core execution engine is the basis for cross-platform .NET implementations.
The Xnote trojan hides itself on the target system and will launch a variety of attacks on command.
Spammers go low-volume, and 90% of IE browsers are unpatched.
Adobe scrambles to release patches for vulnerable Flash Player.