LTSI Linux Kernel 3.4 Released 61
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."
LTS (Score:1)
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: (Score:2, Informative)
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: (Score:1)
Try telling my dad ununtu isn't linux.
Ubuntu is a linux distribution, which is more than just linux.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
That's what I say, too. When they release a working distro of Hurd/Gnu, then they can call it anything they like.
Re: (Score:2)
RMS, is that you?
Re: (Score:3)
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: (Score:2)
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: (Score:1)
Re: (Score:1)
Re: (Score:2)
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: (Score:2)
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 [kernel.org]
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 (Score:3, Interesting)
Re: (Score:3)
Re:Good, I suppose (Score:4, Insightful)
Re: (Score:2)
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? (Score:2, Interesting)
If QNX and NetBSD can hack it, why the heck can't Linux?
Re: (Score:3)
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: (Score:2)
Re: (Score:2)
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: (Score:2)
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.
Exc
Re: (Score:3)
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 d
Re: (Score:2)
It's Long-Term Support, but not that long...
AF_BUS -- a[n] implementation of the D-BUS" (Score:3, Insightful)
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: (Score:3, Informative)
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: (Score:3)
Re: (Score:1)
Unless they included hardened features like SELinux or PAX that are not found in regular kernels, it's not actually hardened.
Distros? (Score:2)
Re: (Score:2)
Worst-case, if they don't offer it in their repos then compiling vanilla is pretty easy in Debian.
Stupid question (Score:3)
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 (Score:4, Informative)
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: (Score:3)
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),
Re: (Score:1)
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
Not very long term (Score:4, Interesting)
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: (Score:3)
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
Re: (Score:2)
Agreed. Five to eight years feels like exactly the right range to me too.