Slashdot Mirror
Linus Torvalds Considering End To Linux 2.6 Series
An anonymous reader writes "With the Linux 2.6 kernel set to begin its 40th development cycle and the Linux kernel nearing its 20th anniversary, Linus Torvalds has expressed interest today in moving away from the Linux 2.6.x kernel version. Instead he's looking to change things up by releasing the next kernel as Linux version 2.8 or 3.0."
I remember hearing somewhere that Linus said if he ever changed the first number, it meant he had snapped and rewritten it in Python.
Funny may not give karma, but +5 Informative never made anyone snort coffee out their nose.
Why not make it 20YY.x where x is major release that year. and YY would be current 2 digit year. they been pushing releases every 3 months about.
Seriously -- Version numbering does mean something, and when someone says 2.8 or 3.0 to someone who knows the version numbering scheme it actually means something.
As usual, FTWA:
Since 2004, after version 2.6.0 was released, the kernel developers held several discussions ... ultimately Linus Torvalds and others decided that a much shorter release cycle would be beneficial. Since then, the version has been composed of three or four numbers. The first two numbers became largely irrelevant, and the third number is the actual version of the kernel. The fourth number accounts for bug and security fixes (only) to the kernel version.
The first use of the fourth number occurred when a grave error, which required immediate fixing, was encountered in 2.6.8's NFS code. However, there were not enough other changes to legitimize the release of a new minor revision (which would have been 2.6.9). So, 2.6.8.1 was released, with the only change being the fix of that error. With 2.6.11, this was adopted as the new official versioning policy. Later it became customary to continuously back-port major bug-fixes and security patches to released kernels and indicate that by updating the fourth number.
Additionally, When you change the first (major) version number it usually means a significant re-write. Whereas the second version number would mean still mostly the same code-base, but with major features added/removed/rewritten.
Take from this what you will, but to say the version numbers are arbitrary is just plain ignorant.
Repeat to yourself: It's just a kernel, I really should relax.
With both RHEL6 and Debian Squeeze on their own versions of 2.6.32, as well as the last Ubuntu LTS 10.04, that version will effectively be the end of the 2.6 line for many places if version numbers jump like this. The kernel versions actively targeted by the -stable team are the only ones some people (including me) are interested in, and this cluster of distributions on 2.6.32 is a good thing in my book. The main issues I'm seeing in newer kernels that I'm concerned about backports of are the continued fixes to weird ext4 bugs happening in newer kernels. Keep those coming, backport drivers for the most common hardware out there, and the rest of the kernel development can march along without me being so worried about it. (Context disclaimer: I worry about PostgreSQL database servers for a living, so my customers are more paranoid about stability than most)
The eventual release of btrfs is one of the things I'd would be glad to see happen only in a kernel that's clearly labeled part of new, less stable development. New filesystems are one of the hardest things to get right, and there's no other class of bugs as likely to lead to major loss of data.
It needs to be Linux Kernel 6.1, but the OS should be Linux 7. For marketing, of course.
Just crank it up to 11.0, putting it ahead of Mac OS.
(+1, Disagree)
scripts that look for "2.6" in the result of "uname -r"
Those scripts are already broken.
Do not meddle in the affairs of geeks for they are subtle and quick to anger
It seems rather strange to label others as ignorant when there is Linus saying "since we no longer do version numbers based on features, but based on time,"
Boffoonery - downloadable Comedy Benefit for Bletchley Park
As much as I dislike Windows... what purpose does a case-sensitive file system serve? It just confuses people.
Well, for starters it would allow the OS to be properly compatible with systems and software that use case-sensitive file storage. :) (Yeah, kind of circular logic there.)
I think you have a reasonable point there - but it's mostly something that can be dealt with at the application level. Like if you're typing a filename in a file dialog, the UI can do a case-insensitive match regardless of the underlying filesystem. The OS doesn't need to prevent creation of files whose names differ only in case to provide that.
There's also a much larger issue: simply treating uppercase as equivalent to lowercase is fine for English, but for international languages, providing that kind of feature gets you into issues of Unicode normalization. Japanese gets you a good collection of degenerate cases: for instance distinguishing between filenames in hiragana, katakana, half-width katakana, kanji (of which there may be multiple equivalents)... I expect other East Asian languages contain similar challenges. I don't know about other languages... But shouldn't all those filenames be equivalent, too? Is that a problem that's not solved just because it's harder to solve? Isn't that disparity a bit awkward?
Again, it seems to me that the place to address the issue is in UI, in response to user input - not at the underlying file handling calls. If the user searches for a filename - it's fine if there's multiple matches, and appropriate to return matches based on what the software "thinks" the user intended. And UI already does this to some extent. If you're typing in a filename to load, the UI can display approximate matches. File dialogs for save are very similar to those for loading - so again, you'll see, as you're typing, if there's a naming clash that could confuse you later. So why the ham-fisted rule of "no filenames which differ only in case"?
To take it a step further - do filenames even need to be unique any more? Windows UI has hidden filename extensions by default for years. So you could have two files "with the same name" (apparently, anyway) in a single directory already. If you're going to do that, I think it may be time to start letting go of the idea that filenames are unique. There's been a trend toward identifying files by metadata anyway - content indexing, tagging, and so on. Certainly traditional filesystem calls depend on filename uniqueness - but at the UI level, is it really still an appropriate restriction?
Bow-ties are cool.
Hal's problem was not sentience, but the fact that a paradox drove it insane. Hal was built to never distort or conceal information, yet was told to do precisely so.
Just as well, Linux may go insane if it is commanded to contradict its core purpose, so... wait, did anyone add DRM to it yet?
Circumcision is child abuse.