"This release adds support for bcache, which allows to use SSD devices to cache data from other block devices; a Btrfs format improvement that makes the tree dedicated to store extent information 30-35% smaller; support for XFS metadata checksums and self-describing metadata, timer free multitasking for applications running alone in a CPU, SysV IPC and rwlock scalability improvements, the TCP Tail loss probe algorithm that reduces tail latency of short transactions, KVM virtualization support in the MIPS architecture, many new drivers and small improvements."

In windows the drivers are as much as part of the kernel as they are in linux (with lernel modules). The only difference is that Windows provides a stable kernel API/ABI, whereas linux only provides a stable userspace API/ABI (look at the ntfs-3g driver implemented in userspace). You can bitch all you want, that's how it is. Both approaches have their merits.

Just a reminder : the XP -> Vista transition broke that API, and drivers had to be rewritten...

I agree that binary blobs are to be avoided, 90% of all issues I encountered I traced to blobs.

Now to the radeon driver : it provides everything BFUs need right now. It works out of the box. What else do you want? Extreme performance? The devs were catching up on supporting 5 hardware generation up to today, I'd say what we have now is pretty good. A lot of the performance might be in powermanagement, and some in the shader compiler that is still WIP.

I know there are pros and cons about it but whichever way you look at it video card drivers have been a problem for a while on the desktop ... in a perfect would we would have open source drivers for everything ... but that the thing we don't.

Correct. If you write a graphics card driver to a stable API as freedom software, then your driver can become part of the kernel source tree, and so it will be automatically re-compiled, packaged and shipped with every new kernel release. It therefore doesn't require a stable ABI.

In fact, as a device maker, you don't even have to write your own Linux driver. The Linux Driver Project developers will happily write one for you:

"We are a group of Linux kernel developers (over 400 strong) that develop and maintain Linux kernel drivers. We work with the manufacturers of the specific device to specify, develop, submit to the main kernel, and maintain the kernel drivers. We are willing and able to sign NDAs with companies if they wish to keep their specifications closed, as long as we are able to create a proper GPLv2 compliant Linux kernel driver as an end result. "

In windows the drivers are as much as part of the kernel as they are in linux (with lernel modules). The only difference is that Windows provides a stable kernel API/ABI, whereas linux only provides a stable userspace API/ABI (look at the ntfs-3g driver implemented in userspace). You can bitch all you want, that's how it is. Both approaches have their merits.

Just a reminder : the XP => Vista transition broke that API, and drivers had to be rewritten...

Exactly so. People who owned machines for which the graphics card was perfectly functional and had decent performance, but which was out of production, faced the strong possibility that they would have no upgrade path to Vista and Win7.

I agree that binary blobs are to be avoided, 90% of all issues I encountered I traced to blobs.

Exactly so. Furthermore, Linux kernel maintainers have no ability to address the issue. One is entirely dependent on the whims of a proprietary supplier who in turn has little motivation to fix the issue.

Now to the radeon driver : it provides everything BFUs need right now. It works out of the box. What else do you want? Extreme performance? The devs were catching up on supporting 5 hardware generation up to today, I'd say what we have now is pretty good. A lot of the performance might be in powermanagement, and some in the shader compiler that is still WIP.

Bottom line is : I use it, and I'm happy with it.

My point exactly. How could anyone really logically conclude otherwise? One would have to have some kind of ideological devotion to closed source software in order to put up with binary blob drivers (when there was a perfectly usable open source alternative).