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."
Thread beginning with comment 566221
To view parent comment, click here.
To read all comments associated with this story, please click here.
lemur2
Member since:
2007-02-17

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.

http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

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.

https://en.wikipedia.org/wiki/Loadable_kernel_module

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.

http://en.wikipedia.org/wiki/Mode_setting

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.

http://www.phoronix.com/scan.php?page=news_item&px=NzM2MA

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

lucas_maximus Member since:
2009-08-18

That's a fib.


No it isn't. You are being a dick. If you have a el cheapo graphics card is over 6 years old you are going to have problems. I have it on my intel based Dell, so I have to run Mate instead of the newer DEs.

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.

http://en.wikipedia.org/wiki/Dynamic_Kernel_Module_Support

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.

https://en.wikipedia.org/wiki/Loadable_kernel_module

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.

http://en.wikipedia.org/wiki/Mode_setting

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.

http://www.phoronix.com/scan.php?page=news_item&px=NzM2MA

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.


Look I know how it works. I had to do it quite a few times back at the start of the last decade.

But lets be realistic the package manager on most distros do all the hard-work for you. Wayland isn't around yet and tbh I've seen the X server crash a handful of times over the years.

You know if you were using like a decent operating system like Windows 7 that has a stable ABi/API and could recover the driver properly when it crashes .. it wouldn't matter whether the driver was open source or not.

Edited 2013-07-04 12:22 UTC

Reply Parent Score: 2

lemur2 Member since:
2007-02-17

"That's a fib.


No it isn't. You are being a dick. If you have a el cheapo graphics card is over 6 years old you are going to have problems. I have it on my intel based Dell, so I have to run Mate instead of the newer DEs.
" [/q]

It is a fib without a doubt. I have two el cheapo graphics card is over 6 years old and I run a feature-full compositing desktop (KDE 4.10.4, the very latest version) without the slightest problem. Fast, slick, responsive, powerful, stable, and elegant. What is wrong with you? Why would you deny this?

Look I know how it works. I had to do it quite a few times back at the start of the last decade.

But lets be realistic the package manager on most distros do all the hard-work for you. Wayland isn't around yet and tbh I've seen the X server crash a handful of times over the years.


It does the hard work of installing a binary blob driver for you when it works. When it doesn't work you are in a world of pain.

You ignore another major problem:
http://en.wikipedia.org/wiki/Kernel_mode-setting
"User-space mode setting would have needed superuser privileges for direct hardware access, so kernel-based mode setting increases security because the user-space graphics server does not need superuser privileges."

Also with regard to X-server crashes, the wikipedia article on modesetting refers to the page on "screens of death".

http://en.wikipedia.org/wiki/Screens_of_death
"A kernel panic is used primarily by Unix and Unix-like operating systems: the Unix equivalent of Microsoft's Blue Screen of Death. It is used to describe a fatal error from which the operating system cannot recover."

Without a doubt the biggest cause of kernel panics these days are binary blob drivers.

You know if you were using like a decent operating system like Windows 7 that has a stable ABi/API and could recover the driver properly when it crashes .. it wouldn't matter whether the driver was open source or not.


You know that with a decent operating system like Linux, if you use an open source driver instead of a binary blob driver, you can recover the driver properly when it crashes. All that is required is that the driver is part of the kernel, it doesn't matter whether the OS was Windows or not.

So I repeat myself for the sake of those a bit slow on the uptake: one really doesn't want to run a binary blob driver with Linux unless one really has to. Binary drivers are really, really worth avoiding.

Edited 2013-07-04 13:20 UTC

Reply Parent Score: 2