Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×

Linux 2.6.16 released 277

Posted by Hemos from the build-the-iso-while-you-can dept.
diegocgteleline.es writes "Linux 2.6.16 has been released after two months and two weeks of development. You can check the comprehensible changelog (text mirror of the site). The new features include OCFS2, a clustering filesystem contributed by Oracle, new unshare(), pselect()/ppoll() and *at() system calls, support the moving of the physical location of pages between nodes in NUMA systems, support for the Cell processor, cpufreq support for G5s plus thermal control for dualcore G5s, improved power management support for many devices and subsystems (libata, alsa...), a new mutex locking primitive, high-resolution timers, per-mountpoint noatime/nodiratime, 64-to-32-bit ioctl compatibility for the v4l2 subsystem, IPv6 support for DCCP, the TIPC protocol (Transparent Inter Process Communication, ACL support for CIFS filesystem, HFSX filesystem support, new configfs filesystem (which complements sysfs, not replaces it), support for running executables from v9fs (plan9 9P distributed filesystem), support for many new devices, improved support for others and lots of other changes. Check it out from kernel.org"
This discussion has been archived. No new comments can be posted.

Linux 2.6.16 released More

Linux 2.6.16 released

Comments Filter:

  • But.... (Score:5, Funny)

    by Anonymous Coward on Monday March 20, 2006 @10:01AM (#14956656)
    does it run Linux?

  • Inconcievable! (Score:5, Funny)

    by old_skul ( 566766 ) on Monday March 20, 2006 @10:03AM (#14956667) Journal
    "Comprehensible"? I do not think that word means what you think it means.

    • Re:Inconcievable! (Score:5, Insightful)

      by slavemowgli ( 585321 ) on Monday March 20, 2006 @10:06AM (#14956688) Homepage
      It's definitely much more comprehensible than the automatically-generated changelog, at least.
      • And it's the...linux kernel changelog. I mean, there're things there that you're not going to understand if you don't understand a bit of kernel internals, just like you won't understand many details from the X.org changelog if you know nothing about graphics

    • Re:Inconcievable! (Score:3, Informative)

      by Anonymous Coward
      Actually, the usage is correct in this case. The full changelog has nothing but single fix entries which hardly give a good picture of what was actually changed in the kernel. A comprehensible changelog gives an overview of the changes rather than a patch-by-patch listing. Therefore, it is more comprehensible for someone outside of kernel development.
    • "Comprehensible"?

      Well, as opposed to the old changelog, which was so muddled and complex as to be incomprehensible. The new version is a definite improvement. ;-)
  • Any point in me upgrading the kernel from 2.6.14? My suspicion is for myself is "no" since everything still works as usual. Alright, maybe I'll just go download and compile it.
    • Yes, there are bugs in previous versions. These bugs were found with coverity and resolved in 2.6.16.
    • Hey, man, in the grandest governmetn tradition: if it ain't broke, fix it until it is. ;)
    • In any case, what's the harm, you can have multiple kernel present on your system. If the new one doesn't boot, you can always boot back the old one.

      All this provided, the new one doesn't fuck up your system, which I highly doubt will be the case.

    • Re:Obligatory question... (Score:3, Informative)

      by garcia ( 6573 )
      Any point in me upgrading the kernel from 2.6.14?

      1. Read the changelog. Do you see anything in there that applies to you (new features, bugs that you have encountered that are now fixed, or serious security updates)?

      2. Do you have any stability issues with 2.6.14?

      3. Are you really that concerned with upgrading your kernel again? It's not a status symbol afterall.

      4. I'm still running 2.4.x because I have no need to run 2.6.x (I use it strictly as a console machine) Linux supplication 2.4.32 #4 Tue Jan
      • 3. Are you really that concerned with upgrading your kernel again? It's not a status symbol afterall.

        4. I'm still running 2.4.x because I have no need to run 2.6.x (I use it strictly as a console machine) Linux supplication 2.4.32 #4 Tue Jan 3 18:35:16 CST 2006 i686 GNU/Linux

        But yet you've bothered to compile the latest 2.4.x release?! Do you see still running 2.4 as some kind of inverted status symbol? :)

        Having said that, they still don't have as good SW RAID support in 2.6 as they did in 2.4 (in the most
        • But yet you've bothered to compile the latest 2.4.x release?! Do you see still running 2.4 as some kind of inverted status symbol? :)

          I'm not the parent poster, but that strategy (sticking with 2.4) seems prudent to me-- especially for a console machine. All my new linux installs get 2.6.x but anything that currently has 2.4 on it will stay with 2.4.x until that box reaches end-of-life (which with any luck could be years from now.) And, yes, that involves periodically compiling and rebooting into the late

    • Re:Obligatory question... (Score:5, Informative)

      by ookaze ( 227977 ) on Monday March 20, 2006 @11:03AM (#14957158) Homepage
      It depends really.
      Lately, the kernel has put lots of improvements for desktop frameworks.
      For example, 2.6.15 put forth uevent for managing devices. Wich the latest udev needs.
      Udev keeps being more and more powerful, and latest hal takes advantage of it, and DE like Gnome and KDE also take advantage of this.
      For the desktop, power management (and suspend) is the reason to go 2.6.16.
      Most distros still don't use these features, but I already do, and some tools already use even the 2.6.16 features (no kidding).
      That means you don't have to go 2.6.16 now, but eventually, distro will have to install it if they want to upgrade their desktop features on Linux.
      The kernel and all the Utopia framework that goes with it.

      Udev is still moving fast, some distro are stuck at udev 036. We are already at udev 087 (unusable on anything below linux 2.6.15) !!
    • Either there was a bug, or (much more likely) I configured it wrong, but I had some issues with my new 2.6.15 kernel I built the other day for a new attempt at using this fine OS on a more persistant basis (well, until I can afford a mac...). Dmesg mostly complained about the timer missing ticks, and this new version has a lot of timer code changes, so I wonder if it will (directly or indirectly) fix my problem...

  • Cell (Score:3, Interesting)

    by cosmotron ( 900510 ) on Monday March 20, 2006 @10:05AM (#14956681) Journal
    support for the Cell processor

    I guess the PS3 HDD with Linux was true...
  • Slightly OT, but have Linux and Schilling decided to let cdrecord work right when acting as an IDE device yet? Last I checked, it's still been broken since 2.6.8.

    • Re:cdrecord (Score:3, Informative)

      by keshet ( 135766 )
      Broken I guess in terms of "doing the right thing",
      but I have burned with cdrecord on 2.6.13 like this:

          $ cdrecord dev=ATA -scanbus
          $ cdrecord dev=ATA:1,0,0 ..

      see this discussion:

      http://community.livejournal.com/debian/186598.htm l [livejournal.com]
      • Your link is basically a synopsis of the eternal flame war that's been going on since 2.6.8, lengthened by two asshats (Jorg and Linux) who are so set on their way being 'right' that they refuse to cooperate.

        It seems impossible to record to an IDE CD burner as non-root users, at least for me, without the ide-scsi crap.

    • Re:cdrecord (Score:5, Interesting)

      by gmack ( 197796 ) <gmackNO@SPAMinnerfire.net> on Monday March 20, 2006 @10:29AM (#14956862) Homepage Journal

      The problem is that Schilling wants linux to behave exactly like Solaris' incomprehensable s,b,l format even though Linux has to support more devices and refuses to even read patches that make things easier for Linux users. It's at the point that if cdrecord accidentally supports something that doesn't look like the solaris way Schilling will add code to disable it.

      Combine that with the fact that the DVD tools from Schilling are no longer open source and requires a License key [berlios.de] The project has been forked [arklinux.com].

      If your having trouble with cdrecord I'd suggest using the alternate version [arklinux.com] instead.

      • Re:cdrecord (Score:2, Interesting)

        by m50d ( 797211 )
        The problem is that Schilling wants linux to behave exactly like Solaris' incomprehensable s,b,l format

        He wants something consistent, is all. Remember how towards the end of the 2.4 lifespan linux people were saying "ide-scsi is obsolete, move to the new ATAPI: method"? And then in a few months that was old and deprecated and it was all "move to the ATA: method"? And then it was changed around again around 2.6.9 for no discernible reason at all?

        It's at the point that if cdrecord accidentally supports some

        • Re:cdrecord (Score:5, Insightful)

          by Mr. Underbridge ( 666784 ) on Monday March 20, 2006 @11:10AM (#14957217)
          He wants something consistent, is all. Remember how towards the end of the 2.4 lifespan linux people were saying "ide-scsi is obsolete, move to the new ATAPI: method"? And then in a few months that was old and deprecated and it was all "move to the ATA: method"? And then it was changed around again around 2.6.9 for no discernible reason at all?

          I'm reminded of an Emerson quote, "Foolish consistencies are the hobgoblin of small minds." In this case, Schilling wants something that 1) is consistently *bad*, and 2) in general makes life difficult for anyone *not* using a SCSI drive, which 3) is 90%+ of the population. An "elegant" solution that doesn't work isn't a solution.

          The sooner people stop their hero-worship of Linus, stop the persecution of Schilling, and start looking at the facts, the sooner something can be done.

          I think "persecution" is a tad much, and if there are any ill feelings Schilling has earned them.

          • Re:cdrecord (Score:4, Insightful)

            by m50d ( 797211 ) on Monday March 20, 2006 @11:18AM (#14957277) Homepage Journal
            In this case, Schilling wants something that 1) is consistently *bad*, and 2) in general makes life difficult for anyone *not* using a SCSI drive, which 3) is 90%+ of the population. An "elegant" solution that doesn't work isn't a solution.

            It worked. Under 2.4.20 my cd burner worked flawlessly. In fact, it still doesn't perform as well as it did then (since I can't have cdrecord setuid root now, I have to burn a bit slower so I don't get buffer underruns). It was fine from the hardware perspective - any atapi drive worked, any scsi drive worked, the clunky 2x parallel port drive I was able to dig out worked. It was fine from the application's perspective - atapi drives support the scsi commandset, so all you had to do is send scsi commands, much like how you send ip packets and don't care what kind of networking hardware is underneath. The only people who didn't like it were kernel people who seemed to have some grudge against ide-scsi - though the only real criticism I've ever seen offered was that it was "ugly". The people going for an elegant solution that doesn't work are the kernel devs.

        • Re:cdrecord (Score:4, Insightful)

          by Overly Critical Guy ( 663429 ) on Monday March 20, 2006 @11:53AM (#14957581)
          It was forked before (dvdrtools), and will doubtless be forked again. The forks will die out once the maintainers realise that it's not Schilling being awkward, it's the kernel people. Last I knew, the fork you mention was depending on ide-scsi, which had a witch hunt against it towards the end of 2.4, was declared obsolete a few times as the latest poorly-thought-out replacement arose, and when this didn't get people to abandon it, was intentionally crippled around 2.6.9 or 2.6.10 time. Whoops. CD writing on linux is bloody hard - the only other project which has lasted any amount of time is cdrdao, and that uses Schilling's libscg for drive access. The sooner people stop their hero-worship of Linus, stop the persecution of Schilling, and start looking at the facts, the sooner something can be done.

          All this crap is why I stick with the BSDs. They actually act professional and make it a point to retain common sense and stability in their operating systems. I've watched Linux over the years become something like a spiraling rocket that looks a little out of control.
    • Slightly OT, but have Linux and Schilling decided to let cdrecord work right when acting as an IDE device yet? Last I checked, it's still been broken since 2.6.8

      No. I did not take side for Linux or Schilling before.
      My wife uses K3B, and I try to update kernel as soon as they are out lately on my desktop PC, because they have features that improve the desktop (and latest udev needs latest kernels). And when she comes telling me burning errors out, it's really irritating.
      When I saw that cdrdao works perfectly

    • Re:cdrecord (Score:5, Interesting)

      by Just Some Guy ( 3352 ) <kirk+slashdot@strauser.com> on Monday March 20, 2006 @11:58AM (#14957637) Homepage Journal
      And on that subject, what's so inherently difficult about writing CD recording software? FreeBSD comes with an IDE burning tool, burncd [freebsd.org], that has worked perfectly every time I've used it. Is it harder to do the same under Linux, or does cdrecord include some advanced, hard-to-implement functionality that burncd skipped?

  • I'm mixed up here (Score:3, Insightful)

    by Adult film producer ( 866485 ) <van@i2pmail.org> on Monday March 20, 2006 @10:08AM (#14956706)
    I thought the 2.6.x series of kernels was stable ? Shouldn't all of these new features being showing up in 2.7.... ?
  • I don't understand the need for all these new calls. Why not make chdir thread-safe? Is there any reason not to have a per-thread working directory?
    • Is there any reason not to have a per-thread working directory?


      Yes- becuase I guarentee you that every existing program that supports threads and makes use of chdir() calls it once and expects the program to function. Call it within a master thread and you expect it to affect all other threads.

      The way to do this is to introduce a new function that wraps it and does it only in the thread it was called in, but that's a pain.

      -M
      • The way to do this is to introduce a new function that wraps it and does it only in the thread it was called in, but that's a pain.

        No, the way it WOULD be implemented is as a new CLONE_ flag to clone(2) which would indicate that the child thread would not share the working directory with its parent. So in addition to CLONE_PID, CLONE_VM, CLONE_FILES etc we would have CLONE_CWD.

        It's not done, but if it was going to be done that's HOW it would be done.

        • Exactly. Then the existing functions could use the per-thread CWD so no new functions would be required. That would be backward compatible as well, since code that didn't use the flag could still fall back to the per-process CWD.
  • When will 2.6 be the default kernel for Slackware?

    • Re:Slackware (Score:3, Informative)

      by Daxster ( 854610 )
      When Slackware 11.0 comes out, it'll use the 2.6 kernel as default. It looks like Pat is still keeping 2.4 support built in, so it's similar to what 10.2 is - built for 2.4, but contains full support for 2.6. Now it's built for 2.6 but still supports 2.4, in case your hardware really requires it.

    • Why do you bother? (Score:2, Informative)

      by amightywind ( 691887 )

      Give Gentoo a try. You can keep a stable kernel and experiment with a number of new ones. Slackware is hopelessly outdated.

    • the 2.6 line has been kinda dev-ish with distros taking up
      alot of the work. 2.4 is still maintained and slackware has
      backported sets for newer hardware (acpi, sata, etc)

      if you want to run 2.6, you probably want to update your
      kernel anyway, the 2.6 packages (in testing) make this easy,
      including a good config to start with. the notes warn
      about the 2.4/2.6 header issuses, so use the slackbuild
      script in the glibc source package. and also, this time,
      use the alsa drivers in the kernel (theyll work with the
      provide

  • hows about (Score:2, Interesting)

    by Anonymous Coward
    everyone get together and create 1 really good filesystem instead of 20 halfassed bugridden ones?

    • Re:hows about (Score:4, Informative)

      by m50d ( 797211 ) on Monday March 20, 2006 @11:10AM (#14957221) Homepage Journal
      Have you ever tried to hack someone else's filesystem code? It's no fun. Most of them are small-team efforts, and the code is so low-level they have to be - anything else kills performance, so it's at the stage where you need to be deeply into the filesystem before you can do anything with it.

      I would go on about how reiser4's plugin system makes it much easier for people to contribute their own small parts to the filesystem and means we could have the best of everything if only the bloody kernel devs would accept it, but that's a rant for another day.

      • Re:hows about...FIXING it? (Score:4, Insightful)

        by Anonymous Coward on Monday March 20, 2006 @11:49AM (#14957540)
        if only the bloody kernel devs would accept it

        The kernel devs actually accept it, as long as the bloody reiser devs fixes the obvious defiencies the code has. It has been more than one? two? years since reiser 4 "was ready to be merged" according to hans reiser and the haven't even tried to submit it in the 2.6.16 time frame - a sign that there is not a lot of work to do, for sure (they last time reiser tried it people pointed out him a list of things that haven't been fixed - yeah, reiser sure "was ready to be merged").

        Maybe we should accept low-quality code in linux just because it's...reiser and it's c00l? Hey, that's the Microsoft Way, and it works for them! Apparently some people thinks that just because reiser 4 has plugins and plugins sound cool it mean it has zero bugs and all the design mistakes are magically fixed by some sort of magic.

          Are you aware that lots of "cool features" were rejected in the past in linux?. Being able to use 1 GB of memory, 64-bit processors, SMP, rmap-based memory management: Those features that sound "natural" today were rejected by Linus because the implementation was HORRIBLE and they weren't merged until someone implemented them in a cleaner way. Why reiser should be different? Linux developers are not going to allow people to fuck up everything because something is "great". It has taken a lot of hard work to take linux where it's now and make it work in 512-cpu SGI beasts, lowering the bar is not going to make linux any better.
      • To me that smells like bs, that the fs has to be very low level or it kills performance. I think it's the other way around, that the filesystem being low-level is what kills performance. For example, if you are reading 50gb/sec you might expect at least 200 instructions to process each 4k page. But you aren't going to get that data rate unless the file is contiguous, in which case you could instead spend 20000 instructions finding a 400k page. So in other words the processor only has to keep up with the

  • Linus' new philosophy of development in main tree (Score:5, Informative)

    by tayhimself ( 791184 ) on Monday March 20, 2006 @10:19AM (#14956786)
    I must say that I am not happy with the 2.6.x kernel development. It has given me problems on both my server/desktop (dual P3-866 VIA board) and my laptop (toshiba portege p3 750). There are too many new features being added that seem to break others on working hardware. I would prefer if only hardware compatibility and bug fixes stayed in the main kernel tree while development continued in the 2.7.x tree like it used to previously.

    I would like to know other peoples experiences with upgrades on 2.6.x. BTW, I run the debian testing kernels and the hotplug to udev switch has given me problems as well.

    • Well, you basically have two options:

      - Use the STABLE-tree (2.6.15.2 for example)
      - Use a vendor-kernel. Vendor-kernels are the ones that are considered stable these days.

      As for me.... I haven't had any issues with the kernels. But I use vendor-kernels mostly, not vanilla-kernels.
    • I agree, it's less stable. However, you're free to use your distro's more stable tested and patched kernels (assuming your distro maintains its packages like Debian does). Unless you're deliberately running the latest and greatest GNU/Linux desktop, or trialling new hardware setups, then you should certainly be doing that.

      What the new 2.6 development model gets us though, is much faster turnaround between kernel developers and kernel users. I think in the end, this will give us more features and a genera
      • Er... When you configure your kernel, leave the checkbox for DRM unticked?

        What's so hard about that, that you'd rather be willing to jump ship?
        • Because, the default will become the standard, and soon, software will require it. That would be fine, of course -- I could just use it until it invaded my life or my rights too much, then switch. However, I also contribute to the GNU/Linux community in various ways, and I won't continue to lend my voice to something that's going down a road towards DRM, however slowly its getting there. If Linux goes DRM, I'll go elsewhere, and develop for and support that instead.
    • I haven't had any problems with Debian testing kernels, other than the fact that the most recent is still 2.6.8.

      If you want to talk about problems in Debian testing, look at X.org (6.9 freezes many radeons) and PAM (tally still broken).
    • You are using an unstable release of the kernel. Linus had made sevral lenghty posts addressing this and has made it abundantly clear that 2.6 is not stable and it will be under development.

    • Re:Linus' new philosophy of development in main tr (Score:5, Insightful)

      by archen ( 447353 ) on Monday March 20, 2006 @01:29PM (#14958475)
      I'd say I'm an open source advocate, but the Linux kernel hasn't made me very happy with the quality of Linux. When someone says "So is Linux more stable than windows?" I have to answer with they're about the same.

      In my opinion its coming down to version-o-phobia. Everyone is so scared to incrament a version number that they pushed the problem farther down the number set. I've become really impressed with the quality of FreeBSD releases, which dropped the ball initally in the beginning of 5x, and now have gotten into a more steady release schedule - that also means increasing version numbers. On Linux we arbitrarily screw with the current version and dump the problem of stablizing them on the distros. What in the hell sort of solution is that? Linux needs to get back to developing far away from the stable tree. Linux needs to start with a real testing/release cycle on a regular basis. You don't need to break compatability when you increase version numbers. As Linux has developed into a stable non-hobbiest OS, it needs to step up to the plate and stablize itself. Using the stable version (2.6.x.x.x) or whatever isn't really fooling anyone. No distro is going to maintain ALL kernel versions, sooner or later you have to bite the bullet and upgrade and accept all the new garbage that has introduced bugs in THIS version of the kernel.

      And it's sort of funny that everyone shuns the BSDs because they are some sort of "leet" club, yet the reason for the messed up situation is because the finall word must always come from Linus. And this time Linus is wrong. Get the hell out of the stable branch!

  • Two Months, and Two Weeks! (Score:3, Funny)

    by tyleroar ( 614054 ) on Monday March 20, 2006 @10:19AM (#14956791) Homepage
    Linux 2.6.16 has been released after two months and two weeks of development.
    Goddamned I can't believe they made an entire kernel in two months and two weeks.
  • I'm just writing this to congratulate and thank the Linux developer community on yet another innovative release.

    That's all there is to my post - nothing interesting to say, just express my gratitude. Mod me down if you wish.
  • What would an upgrade to the Linux Kernel have to do in order to be ordained 3.0?
    3.0 Looks better than 2.6.16.3.14159265eeee+ IMHO ;)
    • What would an upgrade to the Linux Kernel have to do in order to be ordained 3.0?

      Make it to 2.9 and release a new stable version?

      Seriously--what differance does it make. We all just 'apt-get update && apt-get upgrade' (or yum upgrade) and get whatever the newest kernel version has been put into our repository gets loaded anyway. Right?
  • "support for the Cell processor"

    What do I need to do to recompile my P4 OS and apps to run on my PS3? Or some other Cell box that doesn't lie beyond the Magic Gate?

  • NVIDIA drivers broken in 2.6.16 (Score:5, Informative)

    by JimBowen ( 885772 ) on Monday March 20, 2006 @10:56AM (#14957091)
    In order to install them you must use a patch here [suselinuxsupport.de], or they won't work.

    ~ Jim
  • Looks like a lot of general updates to the EHCI and USB BIOS interfacing, doesn't specifically mention SiS USB chipsets but I'll have to try this kernel in the hopes that my laptop USB ports will finally work, having been useless since kernel 2.4 and all bug reports falling on deaf ears.
  • I have a dual Opteron 265 (dual core) server running AMD64, which, so I understand, uses the NUMA architecture. I am no expert, but I understand that my 4GB RAM is split between the two processors on this architecture, at 2 GB each. Thus I have always wondered how exactly the OS can move tasks efficiently between processors if the memory for each task is so tied to a particular memory bank. For example, if you happen to have some tasks that are on one of the CPUs and they all suddenly start taking up more p

  • ATI installer (Score:2, Interesting)

    by phorm ( 591458 )
    I have a laptop with an ATI mobility (X600) chipset. I've consistently had issues compiling the ATI-provided drivers in various 2.6.x kernels, but I've heard from many that it should compile cleanly under 2.6.16. I'll try to update this post when I know more, as the kernel is currently compiling as I write, and the driver will soon (hopefully) follow.
  • I can't wait for NCQ support [linux-ata.org]. Hopefully 2.6.17.

  • More syscalls (Score:4, Funny)

    by DrSkwid ( 118965 ) on Monday March 20, 2006 @11:42AM (#14957476) Journal
    Great, that's just what Linux was lacking.

Slashdot Top Deals

Stellar rays prove fibbing never pays. Embezzlement is another matter.

Close