Slashdot Mirror

← Back to Stories (view on slashdot.org)

LTSI Linux Kernel 3.4 Released

Posted by Soulskill on 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."

37 of 61 comments (clear)

  1. Re:LTS by Anonymous Coward · · 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.

  2. Re:LTS by Anonymous Coward · · Score: 1

    Try telling my dad ununtu isn't linux.

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

  3. Re:LTS by Osgeld · · Score: 2

    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

  4. Re:LTS by Sulphur · · Score: 1

    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.

  5. Re:LTS by jones_supa · · Score: 1

    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.

  6. Good, I suppose by jones_supa · · Score: 2, Interesting

    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.

    1. Re:Good, I suppose by martin-boundary · · Score: 2

      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.

    2. Re:Good, I suppose by jones_supa · · Score: 3, Insightful

      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.

    3. Re:Good, I suppose by hobarrera · · Score: 1

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

  7. How about 64 bit time on 32 bit systems? by Anonymous Coward · · Score: 2, Interesting

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

    1. Re:How about 64 bit time on 32 bit systems? by Drinking+Bleach · · Score: 2

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

    2. Re:How about 64 bit time on 32 bit systems? by squiggleslash · · Score: 1

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

      --
      You are not alone. This is not normal. None of this is normal.
    3. Re:How about 64 bit time on 32 bit systems? by Tarlus · · Score: 1

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

      --
      /* No Comment */
    4. Re:How about 64 bit time on 32 bit systems? by Bill_the_Engineer · · Score: 1

      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.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    5. Re:How about 64 bit time on 32 bit systems? by higuita · · Score: 1

      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)

      --
      Higuita
    6. Re:How about 64 bit time on 32 bit systems? by Bill_the_Engineer · · Score: 2

      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.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
  8. AF_BUS -- a[n] implementation of the D-BUS" by Anonymous Coward · · 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.

    1. Re:AF_BUS -- a[n] implementation of the D-BUS" by GrievousMistake · · Score: 3, Informative

      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?

      --
      In a fair world, refrigerators would make electricity.
  9. Re:LTS by jsuhre · · Score: 1

    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.

  10. Re:whats the difference? by Ginger+Unicorn · · Score: 2

    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.

    --
    (1.21 gigawatts) / (88 miles per hour) = 30 757 874 newtons
  11. Re:LTS by Likes+Microsoft · · Score: 1

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

    --
    -- Who am I? How did I get here? My God, what have I done?!
  12. Distros? by Likes+Microsoft · · Score: 2

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

    --
    -- Who am I? How did I get here? My God, what have I done?!
    1. Re:Distros? by Tarlus · · Score: 1

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

      --
      /* No Comment */
  13. Re:LTS by RabidReindeer · · Score: 1

    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.

  14. Stupid question by aaaaaaargh! · · Score: 2

    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?

    1. Re:Stupid question by DeSigna · · Score: 3, 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.

    2. Re:Stupid question by tlhIngan · · Score: 2

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

    3. Re:Stupid question by Anonymous Coward · · 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 and containers, which is often superior to GC, since it applies not only to memory but also other resources like locks and files.

  15. Re:whats the difference? by Anonymous Coward · · Score: 1

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

  16. Re:LTS by bill_mcgonigle · · Score: 1

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  17. Re:Backporting features? by Osgeld · · Score: 1

    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

  18. Re:LTS by Tarlus · · Score: 1

    RMS, is that you?

    --
    /* No Comment */
  19. Re:LTS by Runaway1956 · · Score: 1

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

    --
    "Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
  20. Not very long term by Myopic · · Score: 3, 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.

    1. Re:Not very long term by Likes+Microsoft · · Score: 2

      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.

      --
      -- Who am I? How did I get here? My God, what have I done?!
    2. Re:Not very long term by Myopic · · Score: 1

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

  21. Re:Backporting features? by wolrahnaes · · Score: 1

    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.

    --
    I used to get high on life, but I developed a tolerance. Now I need something stronger.