Announcement

Collapse
No announcement yet.

Linux 2.6.30-rc2 Kernel Released

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

  • Linux 2.6.30-rc2 Kernel Released

    Phoronix: Linux 2.6.30-rc2 Kernel Released

    Last week Linux 2.6.30-rc1 was released, but this afternoon Linus Torvalds has pushed out the second release candidate for the Linux 2.6.30 kernel series. The second release candidate introduces a new architecture (called microblaze), an input layer update, a new Intel virtual networking driver, firmware loading updates, and Intel graphics driver updates. The Microblaze processor architecture is developed by Xilinx for some of their FPGA products and is a 32-bit Harvard RISC architecture. The Linux 2.6.30-rc2 kernel release announcement can be read at LKML.org...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    Isn't a release candidate suppose to be the final version unless bugs are found?

    If that's the case, how can it be that new features are added to a RC?

    I am pretty sure Mozilla releases work that why.

    Comment


    • #3
      @Louise, read more about kernel versioning system eh?

      Btw, rc2 patch is borked and doesn't apply cleanly yet, I never seen anything like that before.

      Comment


      • #4
        I also can't understand this. Why is a release candidate supposed to contain bugs? In my opinion many RCs are actually "beta"s.

        For me RC inplies that there are no known bugs. D:

        Comment


        • #5
          Originally posted by bugmenot View Post
          I also can't understand this. Why is a release candidate supposed to contain bugs? In my opinion many RCs are actually "beta"s.

          For me RC inplies that there are no known bugs. D:
          yes, why would it else be called a "release candidate" ? Unless you of course plan to ship a bugged version

          Comment


          • #6
            They only do that, to name betas as RC, to have more people to test.

            Comment


            • #7
              It is unfortunate but unfortunately there is no set in stone standard to which software development phases are followed. Alpha, beta, RC designations are determined by the project group rather then a standard. Just look how many bugs still riddle Wine even though after 10 years of Alpha status in a few months it went as Final with pages of known bugs still open.

              Comment


              • #8
                It's still "slushy."

                Comment


                • #9
                  Originally posted by Jimmy View Post
                  It's still "slushy."
                  Heh they should rename the -ck branch to the -rip branch. Too bad they pissed the only guy that really gave a crap about desktop performance in the kernel.

                  Comment


                  • #10
                    Originally posted by deanjo View Post
                    Heh they should rename the -ck branch to the -rip branch. Too bad they pissed the only guy that really gave a crap about desktop performance in the kernel.
                    Devil's advocate:

                    If his departure from the scene was so detrimental then what does that say about the validity of benchmarking done here with PTS?

                    Surely he's not the only one who cares, but is he the only one who can influence desktop performance within the kernel? If Prey, Unreal, and Nexuiz all take a nosedive in 2.6.31 (backed by PTS) will that news cause any reaction within the kernel development community leading to better performance in say 2.6.33 or 2.6.34?

                    Comment

                    Working...
                    X