Linked by Nth_Man on Mon 1st Jul 2013 15:37 UTC
Linux "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."
Permalink for comment 566221
To read all comments associated with this story, please click here.
Member since:

I not fibbing,

I quote: the previous VESA drivers are probably more than good enough because seriously you aren't going to be able to run anything that decently if it requires any advanced GPU features

That's a fib.

the fact of the matter is that for 5 years the hardware has been running sub-optimally and you just put up with it when in most distros it is pretty simple to install the driver with your package manager. If it was 2004, and you had to go through the procedure I did with Debian, then I would understand.

Binary blob drivers requires that the driver wrappers are re-compiled whenever a new kernel is installed, which in turn is usually managed by dkms.

DKMS is prone to occasional failure, even in 2013. DKMS also requires that you have the kernel header files installed. The version of the header files must of course match the version of the kernel. All of this makes updating the kernel a much more involved and risky process than it is compared to using open source drivers and not needing dkms.

Even once you have it installed properly via dkms, the drivers effectively become kernel-loadable modules.

The kernel loads these modules after it starts, the kernel therefore cannot initialise these devices along with the kernel itself. Open source graphics drivers do not require dkms, and they also enable kernel modesetting.

Also, because the loadable module is not part of the kernel itself, it ends up meaning that the X-Server has to be a root process. In order to run an X-server as a userland process, the driver must be part of the kernel itself, and it must be possible to use kernel modeseting.

This means that if the X-server crashes when running a binary blob driver, it brings down the entire machine. You can't just kill the program which caused the x-server to crash and then re-start the x-server.

There is a similar problem in respect to running wayland. Wayland also depends on kernel modesetting.

One really, really doesn't want to run a binary blob graphics driver unless one really has to.

Edited 2013-07-04 10:36 UTC

Reply Parent Score: 2