LTSI Linux Kernel 3.4 Released

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."

Comments

Re:LTS

[Anonymous Coward]

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.

Re:LTS

[Osgeld]

funny, I still have Ubuntu 9 on my old beater laptop and the repos work fine, hell I have Debian potato on a Pentium that still reads the repos 13 years later

why is it your family is using Ubuntu, cant figure out basic operation, and then call you, when you don't use Ubuntu?

Thats like calling the Ford dealer for your volkswagon

Good, I suppose

[jones_supa]

If we want the Year of Linux on Desktop to come, we will need more these kind of strict, conservative standards. One of the top reasons why developers don't want to target the platform is that things are changing way too wildly.

Re:Good, I suppose

[martin-boundary]

Why? If you want conservative, just use Debian stable. However, most people don't, and that's because they don't _want_ conservative, they _actually_ want lots of updates all the time. Open source caters for all types. Use what you like, and if you change your mind, use what you like after.

Re:Good, I suppose

[jones_supa]

There can be many distributions, but there could be one reference distribution, which the likes of Steam, Quartus and MATLAB could target and have a sanely supportable platform.

How about 64 bit time on 32 bit systems?

[Anonymous Coward]

If QNX and NetBSD can hack it, why the heck can't Linux?

Re:How about 64 bit time on 32 bit systems?

[Drinking Bleach]

Linux never breaks the ABI, which means keeping 32-bit time on 32-bit systems (or 32-bit for 32-bit applications on a 64-bit kernel).

Re:How about 64 bit time on 32 bit systems?

[Bill_the_Engineer]

Then tell the writer of that device driver...

We fantasize about doing that all the time. Unfortunately we have to work in the real world.

Here's how it happens most of the time. You need a device that has a very niche market (i.e. not many competitors to choose from). Out of the very few devices available, you pick one from a vendor who advertises it supports linux. You purchase the device only to find out that the driver is for a very old 2.6 kernel which doesn't work well with the other devices that are directly supported by the current kernel version. You have two options:

(1) You use their blessed linux distribution which is little more than a very old snapshot of Slackware or LFS and attempt to back port all the other device drivers.

(2) You use LXR to make the necessary changes in their driver code to get it to work with the current kernel. Since your modified code is not part of the official kernel tree and you don't have money budgeted to maintain the code outside of the project, you are committed to always update this driver when a new project comes along and we have to use this one device with the new system.

#2 is our only real option and having LTSI back port the important stuff to their 2-year kernel makes our job much easier.

AF_BUS -- a[n] implementation of the D-BUS"

[Anonymous Coward]

which may or may not materialize in the mainline.

Backporting uncontested features, those which will go into mainline is fine, but I don't get this.

Caveat emptor.

Re:AF_BUS -- a[n] implementation of the D-BUS"

[GrievousMistake]

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

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:whats the difference?

[Ginger Unicorn]

It's 3.4.25 with 3 specific features backported to it that were deemed necessary for the kernel to be useful in it's intended purpose. That's still a lot more stable and hardened than just using 3.7.

Distros?

[Likes Microsoft]

Are there any distributions that are known to plan on using this? Debian would be a natural fit, I suppose.

Stupid question

[aaaaaaargh!]

Reading about this Contiguous Memory Allocator feature, and since I'm currently developing a (toy) programming language in my spare time, I was wondering why Linux doesn't include a garbage collector as system-wide service. It's not easy to implement GCs and particularly concurrent ones, so wouldn't it make sense to offer garbage collection as an OS service?

Re:Stupid question

[DeSigna]

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.

Re:Stupid question

[tlhIngan]

Reading about this Contiguous Memory Allocator feature, and since I'm currently developing a (toy) programming language in my spare time, I was wondering why Linux doesn't include a garbage collector as system-wide service. It's not easy to implement GCs and particularly concurrent ones, so wouldn't it make sense to offer garbage collection as an OS service?

In a strict sense, no. The OS kernel views the userspace as a collection of resource users - each process has memory (for code, data, stack, and heap), processor time (to run threads), and other things the OS manages - network resources, storage, etc.

The OS kernel only knows your program uses memory. It doesn't know how it uses the memory - just because the kernel ests up code/data/stack/heap sections with appropriate permissions doesn't mean you can't intermix your heap and stack, or use data as part of your stack, etc. So the OS kernel can't really do any form of "garbage collection" without knowing the intricacies of how your program uses memory.

However, an OS is more than just a kernel - it usually encompasses stuff like libraries, utilities and APIs that programs can use for convenience. These libraries generally are for user applications to make use of to simplify their life (e.g., the C library encompasses system calls into the kernel, but also many other non-kernel related things like math, string formatting, varargs, etc).

Basically your request boils down to a user library that handles garbage collection - the OS kernel doesn't care about it (all it knows is your process takes memory, in some form - it doesn't care if you allocate every byte yourself or use some framework to do so).

Not very long term

[Myopic]

Why is two years considered Long Term? In my short career I've worked with many machines which have run the same version of an OS for a lot longer than that. I would think ten years would be a *minimum* threshold for "long term support". Ten years from now, yes, some machines will need that critical security update. No, we can't expend six months every two years to re-test the systems to make sure they work with the new kernel.

There's a sliding scale of how reasonable it is to keep backporting bug fixes but two years? Two years doesn't seem long enough. Even my laptop has a three-year-old version of OS X on it.

Re:Not very long term

[Likes Microsoft]

Ubuntu's current practice is a 5 year term for LTS. Microsoft's 10 years leads to supporting pretty ancient stuff (in Internet time, anyway). They were forced to extend XP support all the way to 13 years since Vista and Windows 7 can't run reasonably on a lot of the hardware that XP was happy on.

For the previous decade, I personally think 5-8 years somewhere is a good LTS term for operating systems and kernels.

Now that CPU's aren't really getting faster, just more cores and energy efficiency, perhaps 10-20 years may again be reasonable.