Announcement

Collapse
No announcement yet.

Linux 2.6.36-rc1 Kernel Released

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Do ATI HDMI audio chips handle multichannel LPCM yet?

    Comment


    • #17
      Originally posted by xeros View Post
      Anyone know if Ubuntu is going to switch from 2.6.35 to 2.6.36 with Maverick (10.10) or not?
      Extremely doubtful. Better chance that Fedora 14 will ship with 2.6.36 but even Fedora 14 will more likely stick with 2.6.35. Still I'm sure Ubuntu will backport some stuff from 2.6.36 to their 2.6.35 kernels like they usually do.

      Comment


      • #18
        Originally posted by xeros View Post
        Anyone know if Ubuntu is going to switch from 2.6.35 to 2.6.36 with Maverick (10.10) or not?
        No. .36 will be out in November or December, which is after 10.10 would be out.

        Comment


        • #19
          Originally posted by airlied View Post
          For instance someone on a forum has no clue what they are talking about?

          Dave.
          Whatever. It's not like this -- where a bug was present in multiple drivers but was only fixed in a few -- has never happened before.

          Comment


          • #20
            Originally posted by ssam View Post
            worst case was the corrupting of firmware for a specific network card, leaving the computer with no network.
            http://lwn.net/Articles/300202/
            there was a workaround fairly quickly, and the true cause was eventually found
            http://lwn.net/Articles/303390/
            and it was possible to re-upload the firmware in most cases. i think only a very small number of people were effected, you won't find more than a couple of angry rants (compared to hundreds when ubuntu moved the window buttons).

            the odds of this kind of thing are very small. a more likely, but still rare possibility is filesystem corruption bug. as long as you have a backup you should be fine.
            bingo !

            Filesystem corruption with 2.6.36-rc1-wl+ and ecryptfs

            so hands off 2.6.36-rc1 if you're using ubuntu & ecryptfs (encrypted /home folder) !

            another (small) bug is a segfault with reiserfs partitions

            catalyst / fglrx 10.7 also doesn't work with it yet

            anyone cares to provide a patch for it - so that we can start testing 2.6.36 with >=rc2 or rc3 ?

            Comment


            • #21
              Fedora is messing with testing of 34 kernel on 13 right now and is using 35 on 14. But they could switch to 36 at end of beta or do like 13 and test it out mid release and include it as final updates to eol. Which is pretty slick. I intalled a defunk one and it connected and updated everything to right at end of support. I was shocked.

              Comment


              • #22
                Is there any good reason for linux to continue the 2.6.xxx versioning scheme nowdays? The major version numbers seem to have little meaning anymore.

                Comment


                • #23
                  Originally posted by deanjo View Post
                  Is there any good reason for linux to continue the 2.6.xxx versioning scheme nowdays? The major version numbers seem to have little meaning anymore.
                  They really don't have any meaning:
                  Originally posted by Linus
                  ... I think the time-based releases (ie the "2 weeks of merge window
                  until -rc1, followed by roughly two months of stabilization") has been so
                  successful that I'd prefer to skip the version numbering model too. We
                  don't do releases based on "features" any more, so why should we do
                  version _numbering_ based on "features"?

                  For example, I don't see any individual feature that would merit a jump
                  from 2.x to 3.x or even from 2.6.x to 2.8.x. So maybe those version jumps
                  should be done by a time-based model too - matching how we actually do
                  releases anyway.

                  So if the version were to be date-based, instead of releasing 2.6.26,
                  maybe we could have 2008.7 instead. Or just increment the major version
                  every decade, the middle version every year, and the minor version every
                  time we make a release. Whatever.
                  http://kerneltrap.org/Linux/Kernel_R...umbering_Redux

                  Comment

                  Working...
                  X