David Airlie of Red Hat has sent in his major feature pull request for the Linux 3.17 merge window. This DRM subsystem update does introduce a new DRM driver, but there isn't any changes for Nouveau as part of this change set...
Facebook is hiring another Linux kernel engineer to join its growing kernel team. The goal for the new employee will be to make "the Linux kernel network stack to rival or exceed that of FreeBSD" and carry out other improvements to the Linux network stack...
NVIDIA today has announced their first beta Linux/Solaris/FreeBSD driver release in the 343.xx driver series. As expected, this release drops pre-Fermi hardware support from the Linux mainline driver code-base...
In continuing of yesterday's tests of comparing the OpenGL performance of the latest Radeon Gallium3D and Catalyst drivers with an array of AMD Radeon HD/Rx graphics cards, here's some complementary data including the performance-per-Watt and overall system power consumption for a few of the different AMD GPUs of recent generations...
Last month in Cambridge was the 2014 GNU Tools Cauldron where GCC as a JIT compiler and other interesting topics were discussed by developers. One of the topics discussed was surrounding better collaboration between GCC and LLVM developers...
Mesa 10.3 release candidate 2 is now available for testing. The current
plan of record is to have an additional release candidate each Friday
until the 10.3 release on Friday, September 12th.
The tag in the GIT repository for Mesa 10.3-rc2 is 'mesa-10.3-rc2'. I
have verified that the tag is in the correct place in the tree.
Mesa 10.3 release candidate 2 is available for download at
I'm back to the usual Sunday release schedule, and -rc3 is out there
now. As expected, it is larger than rc2, since people are clearly
getting back from their Kernel Summit travels etc. But happily, it's
not *much* larger than rc2 was, and there's nothing particularly odd
going on, so I'm going to just ignore the whole "it's summer"
argument, and hope that things are just going that well.
Please don't prove me wrong,
Revisiting How We Put Together Linux Systems
Traditional Linux distributions are built around packaging systems like RPM or dpkg, and an organization model where upstream developers and downstream packagers are relatively clearly separated: an upstream developer writes code, and puts it somewhere online, in a tarball. A packager than grabs it and turns it into RPMs/DEBs. The user then grabs these RPMs/DEBs and installs them locally on the system. For a variety of uses this is a fantastic scheme: users have a large selection of readily packaged software available, in mostly uniform packaging, from a single source they can trust. In this scheme the distribution vets all software it packages, and as long as the user trusts the distribution all should be good. The distribution takes the responsibility of ensuring the software is not malicious, of timely fixing security problems and helping the user if something is wrong.
See How Your Linux System Performs Against The Latest Intel/AMD CPUs
This holiday weekend (in the US) can be a great time to test your Linux system to see how it's performing against the latest AMD and Intel processors to see if it's time for a good upgrade.
This weekend I'm working on many Linux CPU benchmarks for the upcoming Linux review of the Intel Core i7 5960X Haswell-E system (still waiting for Intel's review sample to arrive though...) and also have some other hardware in preparation for an unrelated launch that's happening next week from another vendor. I'm testing several different Intel/AMD CPUs from the latest desktop CPUs to the Extreme Edition models to some slightly older parts. Beyond the raw performance results are also the power consumption data and much more.