Page 2 of 2 FirstFirst 12
Results 11 to 16 of 16

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

  1. #11
    Join Date
    Jul 2009
    Posts
    416

    Default

    Quote 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

  2. #12
    Join Date
    Dec 2009
    Posts
    492

    Default

    Quote 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.

  3. #13
    Join Date
    Sep 2009
    Posts
    59

    Lightbulb 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 at 04:39 PM. Reason: Readability

  4. #14
    Join Date
    Jan 2010
    Location
    Portugal
    Posts
    944

    Default

    Quote 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?

  5. #15
    Join Date
    Jun 2008
    Posts
    20

    Default

    Quote 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.

  6. #16

    Default

    I would suggest guaranteeing ABI stability for the Linux 3 series. If it becomes a problem, just release the Linux 4 series sooner. I would also suggest re-evaluating ALSA vs. OSS, now that the latest OSS has a compatible license, and choosing the one that has greater technical merit. I don't know which one that would be, but considering that OSS is the standard on other UNIX and UNIX-like operating system and that the reason for the switch had a lot (or everything?) to do with licensing means it would be shame not to at least give it a chance.

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •