Announcement

Collapse
No announcement yet.

The End Of The Road For Linux 2.6 Looks Likely

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

  • The End Of The Road For Linux 2.6 Looks Likely

    Phoronix: The End Of The Road For Linux 2.6 Looks Likely

    It was just a few hours ago that we were the first news site to point out the message by Linus Torvalds on the kernel mailing list about his desire to end the Linux 2.6 kernel series and move future releases to the Linux 2.8 or even Linux 3.0 series. While efforts to change the Linux kernel versioning have been voiced in the past and ultimately failed, it looks like the effort this time around is building momentum and the change could very well happen...

    http://www.phoronix.com/vr.php?view=OTQ3Ng

  • #2
    The hype of this one is going over my head. I've never gotten excited about arbitrary version numbering systems.

    It reminds me a bit of when Slackware jumped from 4.0 to 7.0.
    http://www.slackware.com/faq/do_faq.php?faq=general

    Hell, I wouldn't care if it was just an integer that started at 0 and incremented with every release.

    Comment


    • #3
      One suggestion to Kernel 3.x

      Please make the development branch splitted. Kernel 3.x can drop supports for old stack/framework/structure/drivers and make code clean and robust. Those old stuffs can still get support from 2.6.40+.

      Comment


      • #4
        Originally posted by enihcam View Post
        Please make the development branch splitted. Kernel 3.x can drop supports for old stack/framework/structure/drivers and make code clean and robust. Those old stuffs can still get support from 2.6.40+.
        old interfaces always get deprecated and removed in linux kernel.

        there is nothing groundbreaking to justify a switch from 2.6 to 2.8 or whatever. i think somebody has a feeling of middle-age crisis and doesn't want to go over 40

        naming the kernel by date would be pretty logical, but it would make it harder to figure out which release is official/stable and which is not. and it would confuse a lof of userspace scripts during transition.

        Comment


        • #5
          first media site? hardly

          lwn was first. sometimes your shameless posing is not that exiting.

          Comment


          • #6
            We'll keep monitoring the highly-active mailing list to see what is reached... This is also really great timing because, errr, just wait and see.
            Steam will be merged into Linux? ;>

            Comment


            • #7
              Now!?

              I don't care about schemes either, but at least they could fix the power bug before making such a massive increment.

              Comment


              • #8
                Originally posted by yoshi314 View Post
                old interfaces always get deprecated and removed in linux kernel.
                Only internal interfaces, not userspace facing ones; those are pretty much set in stone from what I understand. That was one of the reasons Jerome Glisse had given for the proprietary drivers having an advantage over the free ones. They can change their interfaces as much as they want since the blobs bundle together the kernel module with userspace pieces.

                Comment


                • #9
                  Originally posted by yoshi314 View Post
                  there is nothing groundbreaking to justify a switch from 2.6 to 2.8 or whatever. i think somebody has a feeling of middle-age crisis and doesn't want to go over 40
                  I opened the article hoping to read about a new major feature, too. Like when the switch to 2.6 was made and the kernel received a much improved scheduler and such.
                  Without these, they may call it 6.6.6 or 31.33.7 for all I care.

                  Comment


                  • #10
                    what's in a name?

                    Here! Here!
                    The rate at which they rip/replace major features is astounding
                    I haven't seen a stable kernel across all my systems since 2.6.32.
                    but keep those gfx driver updates coming!! ;-)
                    These version numbers are useless. might as well be integers or a calendar month.

                    To your distribution, is the only place to look for stability/sanity.



                    Originally posted by bug77 View Post
                    I opened the article hoping to read about a new major feature, too. Like when the switch to 2.6 was made and the kernel received a much improved scheduler and such.
                    Without these, they may call it 6.6.6 or 31.33.7 for all I care.

                    Comment


                    • #11
                      Originally posted by bug77 View Post
                      I opened the article hoping to read about a new major feature, too. Like when the switch to 2.6 was made and the kernel received a much improved scheduler and such.
                      Without these, they may call it 6.6.6 or 31.33.7 for all I care.
                      Major features are released in 2.6 as they come along. The CFS scheduler was released in 2.6.23. I don't know anything about the 2.6.0 scheduler, but they released a new one without bumping to 2.8 or anything.

                      There have been tons of other huge features like GEM memory management for GPUs and all the other work in DRM, new filesystems, etc

                      Comment


                      • #12
                        Originally posted by pvtcupcakes View Post
                        Major features are released in 2.6 as they come along. The CFS scheduler was released in 2.6.23. I don't know anything about the 2.6.0 scheduler, but they released a new one without bumping to 2.8 or anything.

                        There have been tons of other huge features like GEM memory management for GPUs and all the other work in DRM, new filesystems, etc
                        I didn't mean to say there's no major feature going into the kernel. I just meant that if major features aren't awarded a major version, version numbers don't mean much.

                        Comment


                        • #13
                          Cleanup / Wishlist

                          Lets tighten APIs to make things easier & reduce security holes:
                          1 Virtualization API
                          1 security api

                          Fix message-passing:
                          It's how complex systems are built. There are too many ways to do it. All are improve on Linux/Unix pipes. Lets fix pipes to that the message-passing API proliferation isn't necessary.

                          Too many Daemons!
                          Investigation is needed. Maybe kernel modules API needs improvement. Maybe we should let modules start userspace processes (perhaps by writes to pipes held by systemD assigned to start-when-needed components).
                          This would speed startup, reduce code running at any given time (taking memory)

                          Native GrandCentralDispatch (GCD)
                          Parallelizing code is dangerous using either Unix threads (a focus on locks) or OpenMP (messes up debugging). GCD makes it easier, and it runs faster (for Mac). Linux implementations require slow Daemons emulating Mac kernel calls.

                          These break compatibility (ugly), or require vast changes, so they're what you'd expect of a version bump (like 2.4 -> 2.6 did).
                          Last edited by snadrus; 05-24-2011, 04:39 PM. Reason: Readability

                          Comment


                          • #14
                            Originally posted by kraftman View Post
                            We'll keep monitoring the highly-active mailing list to see what is reached... This is also really great timing because, errr, just wait and see.
                            Steam will be merged into Linux? ;>
                            OilRush will be merged into Steam which will be merged into Linux?

                            Comment


                            • #15
                              Originally posted by damg View Post
                              Only internal interfaces, not userspace facing ones; those are pretty much set in stone from what I understand. That was one of the reasons Jerome Glisse had given for the proprietary drivers having an advantage over the free ones. They can change their interfaces as much as they want since the blobs bundle together the kernel module with userspace pieces.
                              The driver doesn't necessarily have to live in the Linux tree. It thereby wouldn't be bound by Linus's rules (assuming this one exists -- I don't know if it does or doesn't). Distros obviously have no problem including non-kernel software since ls, cat, etc. are included on even the barest of distros. If someone can greatly enhance the state of Linux graphics drivers just by doing open-source development separately from the kernel tree then I really hope they do so ASAP, that's a pretty small holdup.

                              Comment

                              Working...
                              X