Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Linux Software

Kernel 2.6.12 Released 291

Mad Merlin writes "Linux kernel 2.6.12 has been released! Kerneltrap has a brief summary on it. The changelog is only partial however: 'The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory. The file that says ChangeLog-2.6.12 only contains the stuff from -rc2 onward.' As always you can find the changelog and the source at kernel.org"
This discussion has been archived. No new comments can be posted.

Kernel 2.6.12 Released

Comments Filter:
  • by xafan ( 836020 ) on Saturday June 18, 2005 @04:45PM (#12852914)
    Just after hell froze over and ATI released new video drivers for Linux specifically supporting 2.6.11, 2.6.12 gets released.

    Let me start off the collective "ARRGGGHHH!"
    • Maybe? (Score:5, Interesting)

      by Saeed al-Sahaf ( 665390 ) on Saturday June 18, 2005 @05:09PM (#12853012) Homepage
      Could this be part of the reason hardware manufacturers don't put a high priority for Linux drivers?
      • Re:Maybe? (Score:5, Insightful)

        by big_groo ( 237634 ) <groovis.gmail@com> on Saturday June 18, 2005 @06:24PM (#12853348) Homepage
        This is precisely why I choose Nvidia hardware - and I always will. Nvidia took the time to ensure that I can have accelerated graphics on my choice of OS, so I will reward them with my pocketbook. You should do the same.
        • Re:Maybe? (Score:2, Informative)

          by gnarlin ( 696263 )
          Then perhaps you should take a look at this working free r300 driver [sf.net] It may not be fully stable yet (although is has worked smoothly for me for about a week) but people seem to have forgotten the fight for getting free software drivers for their graphics cards indstead if kissing the asses of nvidia and ati for not releasing any source code or much specs. I will always choose the card which has a free driver over any that don't. Even if the perfomance is not on par with the best.

          Also worth mentioning is

        • Re:Maybe? (Score:3, Insightful)

          Absolutely. Let the market be the driver. Not the courts. Not some ideology.
        • Re:Maybe? (Score:2, Insightful)

          by Anonymous Coward

          Yeah, real big of nVidia to release closed, binary drivers that may or may not run on different configurations and most assuredly will not run on anything other than Linux/i386, and to make no mention whatsoever of hardware specifications or documentation. Really nice, how they've ensured that there will be no non-trivial open development of their drivers by providing a buggy, impractical, but "good enough" solution.

          nVidia is ensuring that F/OSS graphics will continue to be criplled by establishing an ina

      • At the risk of being modded off topic -- have you tried that Slashdot W3C validation link in your sig recently?

        I can't believe Slashdot would be so embarrased by their ugly HTML to actually ban the W3C validator...

      • Re:Maybe? (Score:3, Insightful)

        by flithm ( 756019 )
        Could this be part of the reason hardware manufacturers don't put a high priority for Linux drivers?

        No.

        You don't need to release a new driver with every kernel release. ATI just has no idea what they're doing that's all.

        A good example: When 2.6 first came out, the nvidia 2.4 kernel module could be made to compile with only minor modifications! I upgrade kernels with every release, and I've never had to go out and find a new driver release.

        But to answer your question, the reason why most manufacturer
        • Re:Maybe? (Score:3, Insightful)

          by nathanh ( 1214 )
          I agree with the grandparent post. Reward nvidia with your money.

          Reward nvidia for releasing *binary* drivers? Anybody with an interest in the long-term success of Linux should be *punishing* nvidia by NOT buying their hardware.

          Reward the companies that produce open source drivers, or publish specs, or help the developers of open-source drivers. Don't reward companies who are destroying the core value of Linux.

          • Re:Maybe? (Score:5, Insightful)

            by flithm ( 756019 ) on Saturday June 18, 2005 @08:32PM (#12853901) Homepage
            Open source isn't the be-all end all. Nvidia puts out a great product and a good driver to match. I fail to see how doing this "destroys the core value of Linux."

            Without a proper nvidia driver, Linux would be basically useless for any real modern desktop use, as all we'd have is driver support comparable to say that of any of the other open sourced ones, SiS, via, intel, matrox, the open source nvidia, or ATI drivers. Which by the way all tremendously suck. Sure basic 2d operations are supported, but that's it.

            nvidia is under no obligation to release the internals of their product, and why would they in such a competetive market!

            Punishing nvidia for running a good, smart business, and support free and alternative operating systems with quality products is an absolutely ridiculous thing to say.

            Before you spout your mouth off like that, I'd like to see you create and maintain the number one graphics card company in the world, then release the source code to your driver which would give your competitors a HUGE leg up on understanding the internals of your product.

            Don't be such an idealistic ass. It's people like YOU that destroy the core value of Linux.
            • Re:Maybe? (Score:2, Insightful)

              by nathanh ( 1214 )
              Open source isn't the be-all end all.

              With Linux, yes it is. If you don't care about open-source then use something else.

              Don't be such an idealistic ass.

              Idealism is not a dirty word. Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success. If you're too short-sighted to understand that then perhaps Linux is not for you.

              • Nice way of skirting around the real issue. Please tell me how having a closed source driver destroys the core value of linux. But, in doing so, you must explain how not having this driver at all (which is the only other alternative in todays society) would be a better option.

                It's not as if I don't see how having an open source driver would be a really good thing. Of course I do!

                In your case, idealism is a dirty word. Your idealistic views keep you from seeing the reality of the situation, which makes
                • Just a clarification... when I said having no driver is the only other alternative, I meant because the alternative would be the current open source driver... which is basically unusable beyond the most basic tasks. (ie no OpenGL, or advanced accelerated 2d operations).
                • Re:Maybe? (Score:3, Insightful)

                  by nathanh ( 1214 )

                  Nice way of skirting around the real issue.

                  With Linux, open source *is* the real issue.

                  Please tell me how having a closed source driver destroys the core value of linux.

                  The core value of Linux is that it is open source.

                  It's zealots like you that keep a lot of people from adopting Linux,

                  Good. Linux will be better off without them if the mere mention of "open source" is enough to scare them away.

              • Re:Maybe? (Score:3, Insightful)

                by Nasarius ( 593729 )
                Idealism is not a dirty word. Idealism means seeing the bigger picture and foregoing fleeting fancies in the pursuit of long-term success. If you're too short-sighted to understand that then perhaps Linux is not for you.

                I agree. Unfortunately, the desktop video card market is largely binary (NVIDIA/ATI), and NVIDIA is clearly superior in their support for Linux. There are many theoretical and practical problems with binary drivers, but NVIDIA has gotten it mostly right. ATI's Linux drivers are awful, whic

                • I agree. Unfortunately, the desktop video card market is largely binary (NVIDIA/ATI),

                  All the nvidia and ati cards have open source drivers. The open source drivers sometimes lack features, or don't perform as well, but they are open source. It is not correct to say that the "video card market is largely binary". That is a choice that the end-user makes.

                  • Re:Maybe? (Score:3, Interesting)

                    by Mornelithe ( 83633 )
                    The open source nvidia drivers are only good if you want a $600 video card to perform like a $10 video card. The ati drivers are better than that on old cards, but not much on the new ones.

                    If you want to play 3D games on Linux today, you need to use binary drivers. Another alternative is to use Windows for gaming, and Linux only for desktop applications. In that case, nvidia still has no incentive to release any specifications or open source drivers for Linux.

                    A third alternative is to forgo playing any 3D
              • Re:Maybe? (Score:3, Insightful)

                by drsquare ( 530038 )
                In reply to "Open source isn't the be-all end all.":

                >With Linux, yes it is. If you don't care about open-source then use something else.


                What? I don't recall Linus Torvalds (the creator of Linux), saying that the whole point of Linux is to run entirely open source software. Perhaps you can find a quote, either from Torvalds or from the kernal copyright licence that says you're not supposed to use any non-open-source software on Linux.

                The way I see it, Linux was created to be a decent Unix-alternative,
        • A good example: When 2.6 first came out, the nvidia 2.4 kernel module could be made to compile with only minor modifications!

          I'm sorry, I'm not savvy to the mechanics of writing drivers. I, and the VAST majority of people, are not going to fuck around under the hood of a video card driver to make it work, we will simply use a different card, or a different OS.

          • Re:Maybe? (Score:3, Insightful)

            by flithm ( 756019 )
            No No, you misunderstood what I said.

            I didn't mean you have to change the driver itself. This would be impossible as it's a closed source binary only driver!

            I just meant minor modifications to the system. And I was talking about a fringe case: the case where a whole new version of the kernel is released (not just a point release). If you think about this it speaks very well on nvidia's behalf.

            Also, in their favor, they released a 2.6 version soon after the release of 2.6. (No modifications necessary
    • Wow, every negative, but valid, comments immediately gets marked as a troll. ;=)

      But, does 2.6.12 really break the new ATI drivers? That`s kinda wacky...

    • by mr_z_beeblebrox ( 591077 ) on Saturday June 18, 2005 @05:26PM (#12853087) Journal
      Just after hell froze over and ATI released new video drivers for Linux specifically supporting 2.6.11, 2.6.12 gets released.

      As someone who specifically uses 2.4.x kernels due to certain support issues, I give you permission not to upgrade. Matter of fact to go further I give you this checklist to decide any and all software upgrades in the future:
      Does your current software solve your needs?
      Does the upgrade mess with something you care about?
      Does the upgrade fix a vital security issue?
      Are you a developer?
      I would discuss the answers in an if.. then... else sort of way. But, if you can upgrade your kernel you should be able to figure it out. Oh, one more thing, if you do not know the answer to any of these questions, you shouldn't even think about upgrading. Do not run code simply because it has been written. Code is written to address needs, use the code that was wrtten for yours and be happy that there is code for other people to.
      • btw are there any sites that list kernel security issues and more importantly which versions are safe from all known issues?

        i.e. a site that will tell me which versions are safe to use without worrying about backporting security fixes.
    • I'm sure they will work with 2.6.12 fine, after all, its still Linux isn't it?
  • by NitsujTPU ( 19263 ) on Saturday June 18, 2005 @04:45PM (#12852919)
    The full ChangeLog ended up missing, because I only have the history from 2.6.12-rc2 in my git archives, but if you want to, you can puzzle it together by taking the 2.6.12 changelog and merging it with the -rc1 and -rc2 logs in the testing directory

    Nothing instills confidence in those who are not convinced that Linux is mature enough for their application like the messages: "I was too lazy to download these files to put together a changelog" and
    "the changelog wasn't in our CMS."
    • I agree, that's just embarassing.
    • Sums up Linux perfectly
    • Priorities (Score:3, Insightful)

      by etymxris ( 121288 )
      Sure, a full changelog would be nice. But Linus, I imagine, isn't too worried about appearing here isn't worth the effort. His time's better spent on actual kernel code.

      This is the type of thing that happens when engineers manage projects rather than business people. That's not a criticism.
    • by Whyte ( 65556 ) on Saturday June 18, 2005 @05:14PM (#12853037)

      commit 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2
      Author: Linus Torvalds
      Date: Sat Apr 16 15:20:36 2005 -0700

      Linux-2.6.12-rc2

      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.

      Let it rip!
    • That's why those people should employ other people to tell them that it's mature enough.
    • by TorKlingberg ( 599697 ) on Saturday June 18, 2005 @06:09PM (#12853287)
      Still better than "We won't tell you what this 20 MB binary patch does, but install it anyway. Trust us."
    • Oh come on, what does Linux maturity for applications have to do with easily complete and clearly formatted changelogs, really? It helps if you're a developer, but that has nothing to do with maturity for application usage... with the end users.
      • Try telling that to a comporate entity. With the explanation in place (Linus' explanation as to why) it's fine, however, the blank statement would leave managers somewhat concerned.

        Ironically, even ones who wouldn't have been concerned if it had never been mentioned at all.

        Quite a few businesses put a greater value on the paper trail than the quality of the system.
  • by Sheetrock ( 152993 ) on Saturday June 18, 2005 @04:47PM (#12852928) Homepage Journal
    When and why did they stop the system of releasing stable versions on the even minor releases (2.4.x, 2.6.x, etc.) and unstable/development versions on the odd minor releases (2.5.x, 2.7.x, etc.)?
    • by fprog ( 552772 )
      They should really try to froze features,
      at least subsystem by subsystem,
      for a couple of months and perform
      a deep code review (ala OpenBSD)
      for bug hunting and security analysis.

      I can understand that some part of the kernel
      still needs heavy development
      (ReiserFS, VM, some specific broken drivers),
      but other parts should be revised
      and certified gold bug free.

      At least that would give us a roadmap,
      on what is to be fixed before
      they jump to 2.7.x series.

      I mean what's the point to break stuff
      at every .x release i
      • If you handn't noticed that all of those things that break are binary only drivers. vmware, ati and nvidia all depend on a binary kernel module. I have been using 2.6.x for a long time on desktops, servers and laptops and had no issues however the only proprietary apps that are even installed are acrobat and opera and those are only for testing stuff.

        For servers none of those should be an issue at all.
        • "If you handn't noticed that all of those things that break are binary only drivers. vmware, ati and nvidia all depend on a binary kernel module."

          If that were true, I wouldn't have to have a Promise IDE card to be able to use my CD drive. It used to work... but now using the SATA and PATA ports at the same time is impossible with Linux.
      • by njcoder ( 657816 ) on Saturday June 18, 2005 @05:40PM (#12853159)
        Just make it easy
        for us to read and do not
        try and write haikus. :)
      • by jadavis ( 473492 )
        I can understand that some part of the kernel
        still needs heavy development
        (ReiserFS, VM, ...


        Speaking of VMs, I'm a little confused about the topic. Can anyone direct me to some good material that explains the differences between various VM systems? Specifically, I'm concerned about overcommitting memory and the OOM killer in linux. Do any other OSes have an OOM killer? Why or why not? If an OS overcommits memory, how can it not have an OOM killer? Does setting "vm.overcommit_memory = 2" disable the OOM k
    • Because development was going quickly and they didn't want to lose momentum. We're getting new features much sooner than we otherwise would have.

      The downside is that 2.6 kernels are now a regression-fest that makes Windows look positively stable. They claim distros are able to stabalize their own kernels, which is a theory I have yet to see put into practice. The idea now is to find a kernel version that doesn't have any show-stopper regressions for your hardware.
      • Actually... the regular 2.6 kernels are pretty stable, or at least not more unstable than past stable kernel series like 2.4 were. This is especially true if you run the 2.6.x.y kernels (like 2.6.11.12, currently) instead of staying on the bleeding (mainline) edge by constantly upgrading to the latest -rc or even git snapshots.

        I for one think that it's all a good idea: instead of backporting features (from devel to stable, or stable to old stable), we're simply back-porting bugfixes applied to mainline to
    • A year ago, and because it works better (the -mm kernels are the testbed for newer features now). It's been on Slashdot, Kerneltrap, lwn etc., too.
    • I don't know when, but the reason was this: Instead of having a 2.6 and 2.7 branch, they wanted to be able to accelerate integration of new developments. So the 2.6 series is under heavier development, and sometimes requires very minor bugfixes and such. Those go in the fourth part of the version number. I personally like this strategy since it means you can still rely on stable versions when you need them, but you also get to use nifty new features without waiting years for the development branch to be

    • by iabervon ( 1971 ) on Saturday June 18, 2005 @11:46PM (#12854613) Homepage Journal
      The problem was that starting an unstable series was exactly the kind of fork that causes problems with development. There was a substantial period when the functionality needed to run a system with recent software and on recent hardware was only in the unstable one of the official series, and was backported to the nominally stable series by each distro individually separately and to different degrees. Furthermore, there was constant pressure to add new features to the officially stable series, rather than to the unstable series (or backported from the unstable series).

      The central problem was that series progressed from unstable to stable to obsolescent to non-functioning. The solution is to always have a place for unstable features (the -mm series) and a place for stable features (the mainline series), and features move into the stable series as they become stable, rather than requiring a major upheaval and years of fussing. Then there needs to be something that corresponds to the period where mistakes in a release are fixed in a release that doesn't include anything else, even new features which are extensively tested; this is only useful until there are no known regressions in the next version with added features.

      The reason that the numbering changed is that, were the numbering maintained, the recent releases would now be 2.16.11, 2.18.0, and 2.19.0 (assuming that the new system was adopted at 2.6.6, the old numbering would make what was 2.6.7 into 2.8.0, and so forth, replacing one point release with two minors, which would just be silly). Also, it would be confusing if 2.17.x included stuff that wasn't in 2.18.0, was in 2.19.0, and was in 2.20.0; this is what happens to anything that's still in testing when a release is made and then stabilizes. Since there's always stuff in testing, no stable release could ever be made without having the existance of features be confusingly non-continguous.

      In any case, 2.6.x.y is now about as stable as 2.4.x was during the period before distros started moving to 2.6.
  • x86_64 ctl32 removed (Score:3, Informative)

    by etymxris ( 121288 ) on Saturday June 18, 2005 @04:54PM (#12852961)
    It's some compatibility thing that allows 32 bit apps to run on a 64-bit OS. Shouldn't be a problem for GPL drivers, but will break older proprietary drivers. I believe nvidia just updated their drivers to be compatible with 2.6.12. But VMWare still won't work, last I checked.
  • Poor Linus (Score:5, Interesting)

    by RickPartin ( 892479 ) on Saturday June 18, 2005 @05:12PM (#12853027) Homepage
    Sorry about being off-topic but I've been thinking, since Linus is a normal guy and not some super human CEO, he must go through a "family tech support guy" hell that only exists in only our darkest of nightmares. I pity him.
    • by Anonymous Coward on Saturday June 18, 2005 @05:49PM (#12853197)
      he must go through a "family tech support guy" hell that only exists in only our darkest of nightmares

      It seems today
      that all we see
      is Longhorn delayed
      and OS X on PeeCees
      but where's the free and open source
      on which we used to rely?
      Luckily there's our Family Tech Support Guy,
      the guy who makes the kernel
      that runs on all the hardware
      we bought at Fry's.
      He's
      our
      Family
      Tech
      Support
      Guy!

      Hmm. Sorry. I got carried away :).
      Thanks Linus for all your hard work!
    • At least you didn't compare him to Nick Burns.
  • borked (Score:3, Interesting)

    by Sparr0 ( 451780 ) <sparr0@gmail.com> on Saturday June 18, 2005 @05:14PM (#12853034) Homepage Journal
    Yet another kernel release without fixed/rolledback highpoint RAID drivers :( Kernel Oopses and Panics abound and they insist on keeping the broken code merged in around 2.6.9. Well, there's always hope for 2.6.13!
    • 2.6.13 (Score:5, Informative)

      by jd ( 1658 ) <imipak AT yahoo DOT com> on Saturday June 18, 2005 @05:27PM (#12853098) Homepage Journal
      There was a discussion on LWN about what was going to happen in the 2.6.13 and 2.6.14 timeframe. Apparently, there is speculation Linus may merge in a lot of the more stable stuff from Andrew Morton's -mm patchset. If the updated RAID drivers are in that patchset, there is a good chance they will be in 2.6.13 or 2.6.14.


      In the meantime, there are a lot of valuable, interesting and worthwhile projects that aren't in ANY of the patchsets at this point in time. I e-mailed a few of the maintainers about that, and it appears that they're aware of the problem but want general users to pressure the patch maintainers to publish patches on the kernel mailing list AND that said patches should conform to the kernel programming style.


      So, again, if you want updated drivers for RAID, or additional features you know damn well exist and are out there, lobby the maintainers until they publish the stuff in a way the core kernel maintainers like.


      There is simply far too much good stuff out there that is not being seen and not being used. It has got to the point where I will be reviving my own FOLK patch series, to start documenting the patches that live out on the fringes of kernelspace. If we want a better Linux, all we have to do is ask in a way that will be heard.

  • by Anonymous Coward on Saturday June 18, 2005 @05:20PM (#12853059)

    We were negotiating with the Pentagon.
    We had a blue screen of death.
    That was the last straw.
    When you're holding the moon for ransom, you value stability in an application.
    Linux gives us the power we need to crush those who oppose us.
    It's compatible with our orbiting brain lasers.
    I've got a beowolf cluster of atomic supermen.
    I have more friends now.
    Genetically engineered cybergoats.
    Henchmen with bad teeth.
    Georgous fembots with a penchant for evil.
    I mean Linux runs on anything.
    I'm all about open source.
    It's just changed my love life.
    You have to uh.. config it.
    Uh.. and then you have to write some shell scripts.
    Update your RPMs.
    You have to partition your drives... and patch your kernel.
    Compile your binaries.
    Check your version dependencies... probably do that once or twice.
    It's just so easy and so simple, I don't see why most people don't run Linux.
    Thank god they don't, because they'd all be super villans, wouldn't they?
    Huh uh ha!
    I'm Steve, and I'm a super villian.
  • anyone else having trouble with saa7134 based tuners (I've got a compro videomate tv/fm). My image is way off center (towards the top right). I'm currently us Dscaler in Windows because of it (great program, but Windows... ug). The weird thing is, dvds played from my PS2 are centered, but games are way off center (and some like Street Fighter Alpha 3 won't play in tvtime but will in xawtv, go figure). No luck on the v4l list yet (noone there's seen the the problem), so I'm wondering if I should try patching
  • Changelogs are great, but does someone have a link to a list of major changes (short point list summary) from 2.6.11? I read the kerneltrap blurb, and that didn't satisfy me. thanks
  • Gentoo Sources. Then I can do an eval. I will try to post results to main Gentoo list, so everyone can see it there. I assume that because this doesn't even have a changlog, that only minor changes have been made, although I may be dead wrong. Please correct me if this and true and I will sit back and wait, wait, wait

    Sincerfely, Rob
  • CPU-FREQ changes (Score:3, Informative)

    by glMatrixMode ( 631669 ) on Saturday June 18, 2005 @06:28PM (#12853363)
    Skimming through the changelogs (link in story), I found many interesting CPUFreq changes, like :

    * New governor 'Conservative' based on 'ondemand', except that it increases cpu freq step-by-step, instead of switching directly to the highest freq. This should improve battery time and address latency problems on amd64 systems.
    * Improved support for PPC32 and ARM
    * Support for dual-core opterons
  • One Change I Like (Score:3, Informative)

    by Borealid ( 838626 ) on Saturday June 18, 2005 @07:05PM (#12853552)
    I don't know if anybody cares, but this update supposedly fixes usb-audio so that disconnecting a running sound card won't eliminate your keyboard. Those of you with SB Audigy 2 NX or Extigy cards should probably upgrade.
  • by nighty5 ( 615965 )
    Doesn't look like it made it into this release :-(
  • Reiser4 (Score:2, Interesting)

    by azdruid ( 893225 )
    Well, I'm a bit disappointed that native Reiser4 support wasn't included in this release. It's one of the features I'm greatly looking forward to...and I'm too noobish to compile a Reiser4 kernel module myself.

This is now. Later is later.

Working...