If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.
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.
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.
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.
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
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.