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

LTS

[slackware 3.6]

should be at least 5 years.
Do you know what a pain in the ass it is keeping all your relatives pc's backed up and updated? And the phonecalls about the updates not working anymore. And trying to explain that the repositories don't work anymore and they need to reinstall a new version of ubuntu and you can't really help them over the phone because you don't use ubuntu very often and oh yah this is about the kernel not ubuntu.
Try telling my dad ununtu isn't linux.

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

[Anonymous Coward]

Try telling my dad ununtu isn't linux.

Ubuntu is a linux distribution, which is more than just linux.

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

Re:LTS

[Anonymous Coward]

Try telling my dad ununtu isn't linux.

Ubuntu is a linux distribution, which is more than just linux.

one could even say it's GNU slash Linux. Or, as I've taken to calling it more recently, GNU plus Linux.

Re:LTS

[Anonymous Coward]

funny, Ubuntu 9 on my old beater laptop and the repos work fine

funny, indeed. the repos may still 'work' but their condition is far from 'fine'

Re:LTS

[Sulphur]

Try telling my dad ununtu isn't linux.

Ubuntu is a linux distribution, which is more than just linux.

one could even say it's GNU slash Linux. Or, as I've taken to calling it more recently, GNU plus Linux.

Then someone will say two slash two equals four.

Re: LTS

[Anonymous Coward]

Who's the new guy?

Re:LTS

[jones_supa]

one could even say it's GNU slash Linux. Or, as I've taken to calling it more recently, GNU plus Linux.

Linux distributions are much more than just Linux and GNU.

Re:LTS

[Anonymous Coward]

Hmm, they certainly stopped working on my install of 9.10, After a bit of searching I managed to find the archive repositories that still worked, but it was still a bit of a pain in the arse.

Re:LTS

[jsuhre]

In ubuntu assuming you don't have many (any?) 3rd party repos upgrades are relatively smooth. Step 1) Edit /etc/update-manager and set Prompt=normal then a Step 2) sudo do-release-upgrade I updated my home file server this past weekend from 11.10 -> 12.10 without issue.

Re:LTS

[Likes Microsoft]

I'm surprised. I thought 8.04 LTS, 10.04 LTS, 12.04 LTS & 12.10 were the only currently supported releases.

Re:LTS

[RabidReindeer]

one could even say it's GNU slash Linux. Or, as I've taken to calling it more recently, GNU plus Linux.

Linux distributions are much more than just Linux and GNU.

More properly, it's Linux plus GNU. Plus other things.

You want a GNU OS, try the Hurd.

Re:LTS

[bill_mcgonigle]

funny, indeed. the repos may still 'work' but their condition is far from 'fine'

Specifically she's vulnerable to all sorts of security issues that have been patched since then in supported versions.

What the OP wants is CentOS 6. I think it has 8 years of life left on it now.

Re:LTS

[Anonymous Coward]

I'm surprised. I thought 8.04 LTS, 10.04 LTS, 12.04 LTS & 12.10 were the only currently supported releases.

Actually, 11.10 is still supported too, though only until April this year. (LTS releases are supported for 5 years, in-between/normal releases for 18 months, for details see https://wiki.ubuntu.com/Releases)

That said, I'm equally surprised the repos still work for ancient releases. Especially considering I've seen bug reports about older EOLed releases which are unable to install any packages or updates.

Re:LTS

[Tarlus]

RMS, is that you?

Re:LTS

[Runaway1956]

That's what I say, too. When they release a working distro of Hurd/Gnu, then they can call it anything they like.

Backporting features?

[Anonymous Coward]

Just wondering, is the plan really to backport new features, not just fixes/improvements?
If yes, then what is the difference compared to installing always the latest kernel version?

Re:Backporting features?

[Anonymous Coward]

386 support, among other things.

At least assuming they do rigorous testing to make sure they don't host a bunch of other features by backporting. (I'm looking at you 2.2/2.4 maintenance kernels!!!!)

Re:Backporting features?

[Osgeld]

Define 386 support, cause the kernel wont work on a 386 chip, hell its hard to find one that supports a pentium, think 2.4 or somewhere around there was the death of that

Re:Backporting features?

[wolrahnaes]

Define 386 support, cause the kernel wont work on a 386 chip, hell its hard to find one that supports a pentium, think 2.4 or somewhere around there was the death of that

No, this was very recent. http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=743aa456c1834f76982af44e8b71d1a0b2a82e21

Sure, most distros compile for 486 or Pentium and above these days, but the kernel itself could still be built for 386 until just over a month ago.

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.

Re:Good, I suppose

[Anonymous Coward]

Because if you don't make a stable release, the big game companies will tell you to go to hell, that's why. They do not want to deal with people bitching about how Ubuntu broke sound again.

Re:Good, I suppose

[Anonymous Coward]

The problem with Debian stable is it is TOO conservative...Say I see some software that doesn't have a package and I need to compile it..I tend to have to compile 6 other libs to get it to work because debian stable is too out of date. You end up having a computer you can't really do much on, best used for a small server for random services you may like to run.

Now the difference between testing..i look at it this way, there are things broken in testing, and in unstable, unstable are most likely to get fixes first...so I end up with unstable. It only makes the most sense... So while I want new updates, I mainly want relatively new'ish software that works. If pidgin is a version or two behind I won't be crying.

anyway, I don't think its as black and white as you say it can be

Re:Good, I suppose

[hobarrera]

Really? What kind of wild changes have there been in recent linux kernels? In particular, what kind of API breakages have there been?

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?

[Anonymous Coward]

Are you really expecting to be using a 32 bit kernel in 25 years?
You can also use a 64 bit kernel with a 32 bit user environment if there's some program that's 64 bit hostile.

- Peder

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?

[squiggleslash]

Can Torvalds not add another API to get the 64 bit time for 32 bit systems (or has he already done that and the original poster was wrong)?

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

[Anonymous Coward]

never breaks the ABI? hahahahaha

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

[Anonymous Coward]

Linux never breaks the ABI, which means keeping 32-bit time on 32-bit systems

Completely incorrect. You can version syscalls as well as libraries and even symbols (at least with ELF). Have a look at NetBSD's code.

It's just that Linux, but more importantly glibc, do not care about historic 32 bit code. They prefer fixing that in x32 ABI. However they miss the point that the world outside is not x86-only: you have a bunch of systems (embedded, SCADA, microcontrollers...) that will likely use 32 bits by 2038 and even after. So the point "just use x32-ABI and leave us alone kid" is plain moot.

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

[Tarlus]

It's Long-Term Support, but not that long...

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

[Anonymous Coward]

You can still run ancient bins on current linux as long as the bins don't hook into internal kernel interfaces the nvidia blobs do for instance.

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

[Anonymous Coward]

Linux never breaks the ABI

Really? Have you programmed Linux long?

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

[Bill_the_Engineer]

I think you may be confusing the userland ABI offered by glibc with the kernel API which is more relevant to the article.

The stable kernel API is where the real work savings is at. Now that the embedded market is gaining momentum, the big players formed the LTSI to stabilize the kernel API long enough to be of use. I'm on the LTSI bandwagon since the time I save from not having to use LXR to modify driver code WHICH DOESN'T BELONG TO MY ORGANIZATION the more time I have to spend working on my own code.

Excuse the emphasis. I always get a "release the code to the kernel" response despite the fact that it's not my code to release. The LTSI is the industry's mitigation to the "fuck you" response from the kernel devs every time a more stable API is requested. Unfortunately more often than not, the response is a direct quote.

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

[Anonymous Coward]

Then tell the writer of that device driver, "FUCK YOU, YOU FUCKING WHORE, AND FIX YOUR OWN DAMN SHITTY CODE", or convince them to GPL it, and send it, as a series of patches, to the kernel-devs.
If you are part of an "Organization", you have money and can either get the code under reasonable terms, or not use whatever piece of shit hardware is causing you problems.

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

[higuita]

you are the one that don't know the difference between kernel calls and the glibc and other libs calls. (that can change many times, depending of the lib upgrade policy)

yes, there exists some ABI broken in some kernels, but they are VERY rare and were required to fix bigger problems (like security problems)

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.

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

[Anonymous Coward]

Hahahahaha, except driver ABIs, which get broken all the time in order to try to force device makers to open source their drivers.

Now how about 3.6?

[Anonymous Coward]

Fuckers.

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"

[Anonymous Coward]

I sure as hell hope it doesn't. Such things have no place in kernel, or anywhere.

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?

whats the difference?

[Anonymous Coward]

if you backport new features (not only fixes). whats the difference between this 3.4LTSI and the shiny new 3.7?

am i missing something?

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.

Re:whats the difference?

[Anonymous Coward]

Unless they included hardened features like SELinux or PAX that are not found in regular kernels, it's not actually hardened.

Distros?

[Likes Microsoft]

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

Re:Distros?

[Tarlus]

Worst-case, if they don't offer it in their repos then compiling vanilla is pretty easy in Debian.

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

Re:Stupid question

[Anonymous Coward]

Because the kernel does memory management on a page level and (more importantly) protects different user space processes from each other. Finer grained memory allocation can be done in user land. The idea is to do in kernel only that which is necessary and why should the kernel impose one of the many GC methods over the other?

For example in most modern C++ or D applications (there are exceptions) there is no need for garbage collection, because you can implement *predictable* resource management using RAII and containers, which is often superior to GC, since it applies not only to memory but also other resources like locks and files.

charge them money...apk

[Anonymous Coward]

as i "always" say => cash, gas, hash &/or ass! even for relatives, btw. I "simply" install my hosts file (assuming their hard drive is big enough... lol) & windows is just as secure as linux.

APK

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

[Anonymous Coward]

And my 8 year old laptop is running the current version of Debian testing. Two years on one kernel is plenty long, and unless you're using a 286 to run it, your processor should be supported into the next 10 years. This news article only refers to the kernel, so userland apps are exempt. I can't guarentee that ten years from now your laptop will still run a DE, but X11 will start, and you can use links2 just as well dillo for webbrowsing.

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.

Re:Not very long term

[Anonymous Coward]

Backporting to an old kernel is PLAIN STUPID. Red Hat should just stop doing it. Sad to see the Linux Foundation support the WRONG IDEA that it is somehow interesting to pursue old kernels. Backported drivers ARE LESS TESTED and thus lead to LESS STABLE kernels.
We have a professional Linux Support organisation since 1998. We see currently only kernel problems with Red Hat's crapware. Finally SuSE also realised the stupid idea to stay with an old kernel (which was really only valid reasoning in the 2.4 days).

The only argument Red Hat currently still has, is that they 'cannot retest nor certify' their ISVs for another kernel. Quiet absurd if you know that since day one Linus made the kernel TO BE 100% STABLE to userspace. Internal API's can change, but the way it deals with userspace remains the same - guaranteeing even (very) old applications will keep on working. And Linus takes that VERY SERIOUSLY.

Of course it's Open Source, and they can do whatever they see fit. But I for one think it's just stupid. The main issue is of course that device driver support for the Linux kernel grows almost exponential, and back porting everything will not be done. Meaning that it will keep on being an installation nightmare to install these old kernels - instead of going for a recent kernel release (like for example Ubuntu is doing).

Re:Not very long term

[Myopic]

Agreed. Five to eight years feels like exactly the right range to me too.

WTF is it with "impersonating" me?...apk

[Anonymous Coward]

See subject-line above... whoever's doing it is seriously stupid!

APK

P.S.=> GROW UP...

... apk