Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).

×
Open Source Operating Systems Linux

LTSI Linux Kernel 3.4 Released 61

Posted by Soulskill
from the penguins-with-boosterspice dept.
hypnosec writes "The Linux Foundation has announced the release of Linux 3.4 under its Long Term Support Initiative (LTSI), which will be maintained for the next two years with back-ported features from newer Linux kernels. Based on Linux 3.4.25, the LTSI 3.4 is equipped with features such as Contiguous Memory Allocator – which is helpful for embedded devices with limited hardware resource availability; AF_BUS – a kernel-based implementation of the D-Bus protocol; and CoDel (controlled delay) – a transmission algorithm meant for optimization of TCP/IP network buffer control."
This discussion has been archived. No new comments can be posted.

LTSI Linux Kernel 3.4 Released

Comments Filter:
  • Re:LTS (Score:2, Informative)

    by Anonymous Coward on Wednesday January 23, 2013 @01:27AM (#42666369)

    Do you know what a pain in the ass it is keeping all your relatives pc's backed up and updated?

    Charge them money. And your post has nothing to do with the LTSI kernel.

  • by GrievousMistake (880829) on Wednesday January 23, 2013 @08:43AM (#42668423)

    Hadn't heard about AF_BUS before...
    I found the rationale [lwn.net], and a summary of the argument against. [lwn.net]

    I get that doing multicast in userspace isn't optimal, but I'm a bit mystified what people are doing with D-Bus that would require any kind of performance. Wasn't D-Bus supposed to be a simple pub-sub system for notification of events and the like?

  • Re:Stupid question (Score:4, Informative)

    by DeSigna (522207) on Wednesday January 23, 2013 @09:08AM (#42668681)

    The view that the kernel has of memory allocations is somewhat different to what the application sees - most of the work is done in the libc, which directs the kernel to map regions and size the heaps that it malloc()'s from.

    Usually, you'd have GC handled by other libraries, for instance the Boehm-Weiser GC. If you're using C++, Boost also has a few wrappers and implementations of garbage collection algorithms for a variety of use cases.

    From memory I believe the kernel CMA is mostly related to in-kernel allocations, so drivers and kernel threads.

"Who alone has reason to *lie himself out* of actuality? He who *suffers* from it." -- Friedrich Nietzsche

Working...