Catch up on stories from the past week (and beyond) at the Slashdot story archive


Forgot your password?

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."
This discussion has been archived. No new comments can be posted.

Linus Torvalds Considering End To Linux 2.6 Series

Comments Filter:
  • by Anonymous Coward on Monday May 23, 2011 @06:32PM (#36222598)
    As much as I dislike Windows... what purpose does a case-sensitive file system serve? It just confuses people.
  • Re:First number (Score:5, Insightful)

    by Hooya ( 518216 ) on Monday May 23, 2011 @07:11PM (#36222930) Homepage

    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)

    by PReDiToR ( 687141 ) on Monday May 23, 2011 @07:12PM (#36222932) Homepage Journal

    scripts that look for "2.6" in the result of "uname -r"

    Those scripts are already broken.

  • Take from this what you will, but to say the version numbers are arbitrary is just plain ignorant.

    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,"

  • by Tetsujin ( 103070 ) on Monday May 23, 2011 @07:25PM (#36223040) Homepage Journal

    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?

egrep -n '^[a-z].*\(' $ | sort -t':' +2.0