The End Of The Road For Linux 2.6 Looks Likely

[pvtcupcakes]

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

[bug77]

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.

[snadrus]

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

[devius]

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?

[cookiecaper]

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.

[Lestibournes]

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.