Linus Torvalds Considering End To Linux 2.6 Series 293
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."
Re:Case insensitive file names please! (Score:2, Insightful)
Re:First number (Score:5, Insightful)
42 decimal = 101010 binary
101010 binary = X X X roman
XXX = pr0n!
That's the answer to life, the universe and everything! That cheeky Doug A.
Re:Newsworthy? (Score:5, Insightful)
scripts that look for "2.6" in the result of "uname -r"
Those scripts are already broken.
Perhaps the commenters actually read the article. (Score:5, Insightful)
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,"
Re:Case insensitive file names suck! (Score:5, Insightful)
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?