Slashdot Mirror
Linux 4.2-rc1 Is One of the Largest Kernel Releases of Recent Times
An anonymous reader writes: Linus Torvalds ended the Linux 4.2 kernel merge window today by releasing Linux 4.2-rc1. He quickly wrote, "I thought this release would be one of the biggest ones ever, but it turns out that it will depend on how you count." By most metrics, Linux 4.2 is shaping up to be a very large release. Linux 4.2 is bringing plenty of new features including the new 'AMDGPU' kernel graphics driver, Intel Broxton support, NCQ TRIM improvements, F2FS file-system encryption, new ARM CPU/board support, Renesas R8/300 arch support, and many other additions.
The same way it has always been done - unpack it, move into the directory, and use "make menuconfig" for a nice easy menu system to pick the parts that you want. If you really want to trim things down only compile in the options you need and remove loadable modules (useful in some setups).
I'm starting to think GNU is the problem with "GNU/Linux" these days.
http://lkml.iu.edu/hypermail/l...
They held off for a release.
Many trusted kernel hackers feel that kdbus -in its current incarnation- feel that kdbus does one or more of the following:
* Needs more work to meet the quality standards for such a major new system
* Doesn't actually solve a problem that needs solving (Analysis of benchmarks presented in the 4.1 kdbus merge request thread showing 2x speedup over userspace DBUS revealed trivially achievable 10x speedups in the code used by the benchmarking code. If it's "clear" that the 2x speedup by moving to kernelspace is enough for the folks that "need" kdbus, then it's clear that the trivially achievable 10x speedup from cleaning up the DBUS libs would be preferable. Why? It keeps a controversial, complex patchset out of the kernel, AND it gives DBUS users 5x more performance.)
* Might have actually serious security issues
* Could be more simply expressed using existing kernel primitives, or small reworks of existing primitives
* Will probably straitjacket future container generalization work (Several folks working on kernel container stuff mentioned several currently-used-in-the-field container strategies where the kdbus design would absolutely not work. The kdbus people's response was effectively "Oh. That's too bad. That's not how you're supposed to use containers, anyway." (One of the affected projects is CRIU: http://criu.org/Main_Page ) )
The dismissive attitude taken towards the LKML community by everyone who has been banned from the LKML for being too argumentative, abrasive, and handwavey in regards to their own errors (read: pretty much everyone on the kdbus project who's not Greg K.H.) is extremely disturbing.
kdbus might be cool.
It's not clear that it's actually required. (The new-and-improved C library for interfacing with DBUS was only made stable *AFTER* the 4.1 merge window closed. This is the same API that (according to the kdbus people) solves the userspace perf issues in the kdbus vs. DBUS benchmark revealed during the 4.1 merge discussion. NOONE has been able to use this API before Linux 4.1, so the folks clamoring for kdbus for speed reasons will probably be satisfied with rewriting their software to target this new lib.).
It's not clear that it's correctly designed.
It's not even remotely clear that the *real* maintainers of the software will listen to outside criticism and requests for bug fixes or redesigns.
386 is supported up to the 3.7 kernel, and the 3.8 kernel was widely announced (and designed) to break 386 support. I've got an ARM system with 128MB of RAM, and it runs GCC 4.2 just fine. I can't imagine that an X86 version would be *that* much heavier that it wouldn't run. Of course, if I try to compile large, modern projects (with output binaries in the hundreds of MB, sometimes), it goes to swap *really* darned fast, but what did you expect? If I'm compiling the size of project that will actually run in the amount of RAM available on the system, without swapping, it works just fine.
It is pitch black. You are likely to be eaten by a grue.