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."
There are a lot of new features in it, might as well bump the version
Great! The Linux kernel is on schedule to change at 2.6.42.
That kind of version jump will show Microsoft and Apple that Linux now has professional marketing behind it.
If they go with 3.0 I hope they include major changes in it. Otherwise what's the point ?
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.
Great. Now I can haz case insensitive filenames please?
The previous answer boiled down to "the appropriate time to make the change is a development kernel such as 2.7."
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
Why not version 50.0? Beat all the browsers and antimalware scanner programs and rise above with a foolish number? or do something stupid and rename it mm/dd/yyyy
Windows 2008 R2D2 is so old fashioned. Release Linux 3000 and I am there.
Sure this is a site for nerdy news, but this literally has no impact on anything. It's just a number.
I swore I read him saying that versioning no longer matters. So if that is the case, lets give it a long version name that corresponds to something mathematically nerdy like the first few digits of Pi, or Fibonacci Sequence.
I generally change the minor number when something important has happened, but this are still compatible. And after all of the effort that they've gone through to finally remove the Big Kernel Lock, I think they deserve a new minor version number. It really is a very different architecture inside the kernel now as compared to the start of the 2.5 series.
It's just a number. Is there a real roadmap as to what 2.8 or 3.0 is slated to feature?
Non impediti ratione cogitationus.
Muttering Mongoose for the next version.
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.
seems like 2.6.99 would be the last 2.6.xx kernel line before the version jump to 2.8.xx... but its his kernel and he can number em as he wants to..
Politics is Treachery, Religion is Brainwashing
Just to keep up with the Chromes and Winderzes and whomever.
Plus, he should be naming releases alphabetically after a cutesy trope, like Ubuntu (Maverick Meerkat, Natty Narwhal) and Android (Gingerbread, Honeycomb, Ice Cream Sandwich) do.
Starting with the letter I, for "I invented the fucking thing."
They should call it GNU Linux 1.0 kernel and make a middle aged guru happy.
Sig? Heil
Well, as long as it's nothing like Gnome 3.0 we should be ok.
I knew that random guy on slashdot shouldn't have recommended a change to chrome versioning numbers! Guys, linus listens!
"People don't want to learn linux" hasn't been a valid excuse since '03.
Its been the old name for a while now: ...too bad the nvidia drivers haven't worked with any git version since 2.6.39 (the old can't find kernel sources problem)... and you can point it to the sources in 3 or four different ways (even at the same time), and it just bellyaches.
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 39
EXTRAVERSION = -git7
NAME = Flesh-Eating Bats with Fangs
Linux Vista
Nullius in verba
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.
After they got rid of the odd = devel, even = stable version conventions (which I actually miss as an end user/sysadmin [but I can see why the devs wanted it the other way around]) So wouldn't linux-next become 2.7? (Or are my ideas of the branching/version conventions wrong.)
Linux 9 Ultimate, Home Premium and Server OF COURSE!
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.
So Torvaldis is THINKING of changing the version number? Doesn't that basically mean that the number is entirely arbitrary and thus it doesn't make a difference?
+1 IDisagreeSoHeMustBeATrollOrAnAstroturferOrAShill
Aren't we a bit late for an April fools day joke?
Two of my imaginary friends reproduced once
development code name: forrester
Anybody want my mod points?
I'll never look back. That shit's for the birds.
Not Marketing only - communication.
If they want to communicate "this release has more big changes and is worth more people checking out" - increasing the first number is an effective way of doing so.
If they want to communicate "there's some bleeding edge stuff in here, and we think it works but if you're really conservative wait a bit" - making it end in ".0" is one way of doing so.
We use a dating system due to the large number of minor revisions, but keep the major revision number - so for instance,
1.2011.03.23.1 := The first minor revision of version 1 of the software that took place on 23rd March 2011.
It gives us the best of both worlds. We spent way too long coming to that solution, but it suits us a lot.
Maybe for Linux it may make sense to move the first minor revision to the left of the revision date.
Outside of that, subdivisions become pretty meaningless anyhow.
If I were Linus, I would start the next revision as 3.2011.mm.dd, using version 3 just to indicate the change in the versioning system is maybe a bit too much of a leap, but it makes a clear break - and also provides an easy enough transition for implementations.
This comment was written with the intention to opt out of advertising.
. . . because it appears that Linus doesn't give a crap. Personally, I agree with you, that if you choose a numbering scheme, just stick with it unless there is a compelling reason to change. And "40 is too big of a number" does not seem like a compelling reason.
Based on past experience then the 3.0 release will be faster but buggier than the 2.6.40 release would have been.
I've always wanted to write my own IDE just so I could get to the point where my IDE would be good enough to write inside itself.
Thanks for the reference to St. Vidicon. Gotta dig up that series and re-read them.
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
In some senses, you can also use a version # as "ye who shall go before this version number beware of a Grue". After 36 increments of the 2.6 series, I'm sorta for the "freshness" of a 3.0 series. Just to say that "here is our dividing line, we've made all this progress, let's lock it in."
I know, there will be a little fuss, but thinking like a 5 year plan, it's good sometimes to make some dividing lines that progress has been achieved.
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
...we'd already be on Linux 160.0
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.
Right now, if you download the latest Linux kernel via Git (see git.kernel.org), you'll get EVERY commit that ever happened since the Linux 2.6 kernel was hosted by Git. That's a LOT of commits; in fact, so many that there are several commits that have exactly the same SHA1 hash, so we're hitting SHA1 collisions.
Git is surprisingly good at compressing the Git history, but even it has its limits. For instance, we can examine the disk space usage of linux-2.6.37.y.git verses the decompressed tarball for linux-2.6.37.6.tar.bz2:
$ du -sh linux-2.6.37.y/
890M linux-2.6.37.y/
$ du -sh linux-2.6.37.6
469M linux-2.6.37.6
So this means that the Git version of linux-2.6.37.6 takes up about TWICE the disk space as f linux-2.6.37.6 does from the tarball. This means that the space being taken up by the Git history is now about the same size as the source code itself is. [And, obviously, 2.6.38 and now 2.6.39 are going to be even more so.]
The only way to fix this is to create a new major branch and migrate, possibly along with seeding the new repository with some recent history to allow 'git bisect' to be able to do something reasonable.
when ending existing series in an open ended fashion that allows for producing new seasons and movies that is - 'Our fight really begins here on !'
Read radical news here
Just because Linus is god doesn't mean he knows everything.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Not exactly what you said, but there's a javascript x86 emulator running Linux: http://bellard.org/jslinux/
Honestly, I think this is the worst reasoning I have ever heard. Calling it 2.8.0 instead of 2.6.41 because 41 is too big a number? Seriously!? In my mind 2.8.0 would mean a major redesign, a bit like the transition from 2.4 to 2.6. It sounds to me like this would simply be a 2.6.41 in disguise. Not worth changing the version unless major changes are made. How about a micro-kernel or some hard real-time Linus instead of wasting your time renaming things?
Eric
Hah! It's a shame Ubuntu went with Feisty Fawn.
Fanged Flesh-Eating Bat is a much cooler name.
Back in the day, major version number increments were for significant functionality changes. Not simply because "oh well 40 is a big number".
Changing this number "just because" is quite likely going to break plenty of apps that check version number for various things - for what exactly?
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
So, the news is that Linus is *thinking* of changing the text "2.6.x" to "2.8.0" or "3.0"? That's the news today? "Some numbers may be changed soonish, to maybe follow a more logical pattern"? Moving on....
I expect other East Asian languages contain similar challenges.
Chinese traditional vs. simplified characters?
And how about German? It has several cases of orthographic equivalence - for example the letter "u with an umlaut, which I can't write here because Slashdot is fucking retarded" is considered equivalent to "ue". This means that if the system locale is German, then the filesystem should follow these rules. And of course, if you change the locale, then you risk breaking the filesystem. Sounds like great fun.
Half-width katakana (JIS) are generally only used as phonetics on systems that don't support UTF- or another native language character encoding; and can be transparently re-coded to the full-width equivalent for storage or transmission in systems that do.
As for kanji, Japanese users expect written homonyms to be distinct (as do we) - although some application interfaces provide search by particle or phonetic (furigana by dictionary or metadata) I haven't seen it used a great deal (not that I necessarily would, even when I was living in Japan I still used English-language tech nearly exclusively). It's been attempted in more platform-wide situations, but I think it has the same sort of stigma as voice-recognition in English; the matches are just too fuzzy to be useful.
This calls for urgent measures ,,,
If the Windows dweebs are suggesting we remove case sensitivity in Linux, it's time to retaliate by disallowing their beloved whitespace in filenames.
Maybe that'll teach 'em to lie low next time.. :-)
They should increment the major number each decade, the minor number each year, the maintenance number monthly, and the build number weekly. So for example, today's kernel would be 3.1.5.4. This would make it very easy to tell how old a particular kernel is.
Half-width katakana (JIS) are generally only used as phonetics on systems that don't support UTF- or another native language character encoding; and can be transparently re-coded to the full-width equivalent for storage or transmission in systems that do.
But that's not what happens. Presently you can have two distinct filenames which differ only in kana width. Obviously there's a lot you could do to implement equivalent-name rejection but my argument is that that's the wrong apprach. Just focus on implementing equivalent-name matching and it doesn't matter if there's "identical" names.
As for kanji, Japanese users expect written homonyms to be distinct (as do we)
There is no equivalent situation in English. You could spell a word with kana or kanji, the same word, same reading, same meaning and everything, but different characters - the distinction is merely whether you're spelling it out by sound or in kanji - or in some cases there could be different kanji as well (and, yes, still the same reading and meaning - the same word in every sense except the writing) - I think equivalence becomes a difficult problem when you consider the international cases.
Bow-ties are cool.
"simply treating uppercase as equivalent to lowercase is fine for English"
Not if you want to use names.
Don't forget Turkish I. And lowercase Greek sigmas.
NTFS doesn't even try to handle it all. It uses a locale invariant mapping - if it works for your locale, good; if not, you're SOL.
At least numbers are infinite. What is Ubuntu going use for the name of the version after "Zealous Zebra"?
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
As for kanji, Japanese users expect written homonyms to be distinct (as do we)
There is no equivalent situation in English. You could spell a word with kana or kanji, the same word, same reading, same meaning and everything, but different characters - the distinction is merely whether you're spelling it out by sound or in kanji - or in some cases there could be different kanji as well (and, yes, still the same reading and meaning - the same word in every sense except the writing) - I think equivalence becomes a difficult problem when you consider the international cases.
If I'm writing a file called 'sensor data', I don't expect it to conflict with 'censor data' (homonym), 'detector data', or 'sensor recordings' (synonyms) - while the words are interchangeable when spoken, or equivalent in meaning, they are not the same words. The same is true of alternate writings for Japanese kanji, especially in names.
If it has a different writing, it is a different word; complete with its own (although possibly equivalent) entry in the dictionary.
I mean really, if the numbers are meaningless enough that you can just make them up... Why not just say, hey the Linux kernel is now 6.5.0 we're really in the future now!! This is pretty silly IMHO, the numbers should go up naturally, there's no reason to jump. It's entirely psychological, and stupid.
As for kanji, Japanese users expect written homonyms to be distinct (as do we)
There is no equivalent situation in English. You could spell a word with kana or kanji, the same word, same reading, same meaning and everything, but different characters - the distinction is merely whether you're spelling it out by sound or in kanji - or in some cases there could be different kanji as well (and, yes, still the same reading and meaning - the same word in every sense except the writing) - I think equivalence becomes a difficult problem when you consider the international cases.
If I'm writing a file called 'sensor data', I don't expect it to conflict with 'censor data' (homonym), 'detector data', or 'sensor recordings' (synonyms) - while the words are interchangeable when spoken, or equivalent in meaning, they are not the same words. The same is true of alternate writings for Japanese kanji, especially in names.
If it has a different writing, it is a different word; complete with its own (although possibly equivalent) entry in the dictionary.
If I could write Japanese on here maybe I could offer a decent example. As I said, there's not really an equivalent in English.
"Sensor" and "Censor" is not an equivalent example. (And those are homophones, not homonyms)
As I said: there are Japanese words which can be written with different kanji. Not merely homophones or synonyms, and not cases where the meaning is the same but the pronunciation is slightly different (like "minna" vs. "mina") but the same word in every sense but the writing. I don't know all the historical reasons, but I have seen cases of it when I was looking stuff up. Some of 'em are probably "archaic" forms still in use, some of them may be a result of efforts to streamline the writing system, some may be cases where there was historically no single, agreed-upon way to write the word, or the written form varied regionally or something. In some cases a single kanji may have more than one glyph associated with it - and in some of these cases the one kanji actually occupies multiple Unicode data points. Anyway, such cases do exist.
Bow-ties are cool.
You can't write ü? (Hint: HTML numeric entity).
So, almost 20 years ago Linux operating system was born. About 17 years ago RMS got greedy and started demand that Linux be called as GNU/Linux based to fact that Linux would be like a microkernel and not Monolithic (Monolithic kernels are operating systems in pure/original form before Server-Client aka Microkernel architecture was invented).
And now when Linux OS is closing 20th release day, the OS is having huge version jump from 2.6 to X.y.
But would it be as huge jump as 2.0 > 2.2 where Linux OS got even 30% speed improvements and graphic subsystem in drivers (what were moved from Xorg)?
Or how about 2.4 > 2.6 jump? Would the possible 2.6 > 2.8 or 2.6 > 3.0 be as huge jump?
Well, what the version is, the Linux OS has changed the world. Where GNU project failed with their own HURD operating system, by swapping the microkernel from Mach to L4 to what ever and never getting their microkernel work in HURD.
Same time in last 20 years BSD's have been forked and their market shares have been going down for huge times.
Other monolithic OS's like SunOS has been out of luck as well while finally Oracle gave the neck shot for it as well.
Is the Linux the only last monolithic OS what really is successed as Unix were originally designed? I would say yes. But even that Unix can be designed as Server-Client architectured OS and not just Monolithic, they do not feel like "real Unix's".
"We're not happy with a 99.9% solution, it must be 99.999999% solution" is a pretty good summary of what you said. Even if you're bilingual in Japanese and English, I doubt you'd interpret the lack of a "This file already exists" error any other way than "The computer isn't smart enough to realize these forms are identical". That would only apply to a very, very small group of bilinguals, I speak three languages and read five but they all use Latin characters and it's also a perfectly sensible rule for Cyrillic, Greek, Armenian and Coptic alphabets - and if you speak one of the unicase languages like Arabic or Hebrew then the rule is irrelevant. So for any individual user the alleged confusion is extremely unlikely to occur.
Secondly, you assume all tools will be smart which is silly to say the least. I've had that issue with files copied from my Windows machine to Linux over samba - they differed only by case, so the system silently figured that yes I did want to store the same file twice with different case *BZZZZZZZZT* wrong. Almost every piece of software in existance has to access the file system, and they will get it wrong. Even if you implement it right at the toolkit level, there's many toolkits and always software doing their own thing, it'll never work correctly and consistently. Fix it once at the file system level, case preserving not case sensitive is the way to go. Make that the default, have the people who desperately want it enable it - there's no problem going from a preserving to a sensitive system, only the other way around.
Live today, because you never know what tomorrow brings
>At least numbers are infinite. What is Ubuntu going use for the name of the version after "Zealous Zebra"?
They're gonna continue from A onwards, using different animals than on the previous run.
Some of my favourite people are from th US; Vonnegut, Chomsky, Bill Hicks.
Why not use the logical entities? It is a "u" with "umlaut", which translates to ü which renders as ü You can remember a lot of them just knowing what they are called.
Ahhh...the great dumpster continuum. Many a free computer will be found there. -- sowth (748135)
ü also works: ü
The Tao of math: The numbers you can count are not the real numbers.
Yea, I know about the invisible $UpCase file that stores the mappings.
Actually, i think the most recent release is 2.6.39...
comment first, facts later. http://chem.tufts.edu/AnswersInScience/RelativityofWrong.htm
Windows UI has hidden filename extensions by default for years.
Which has been enabling social engineering attacks for years. I am shocked that they still think this is a good idea.
a man was driving down the road when his odometer rolled over
he said, and I quote "I was just driving down the road then my odometer rolled over."
no?
3.11 for workgroups ?
"We're not happy with a 99.9% solution, it must be 99.999999% solution" is a pretty good summary of what you said.
Because the missing 1% will be a big security hole. Right now case-sensitivity reminds people that the computer cares about the exact name, and is very fussy. If we want the computer to have a notion of equivalence between filenames, it must be a good and rigorous one, otherwise it creates a huge exploit vector.
I am trolling
I rather liked the old system of dual trees. The unstable branch gave the developers a place to alpha test their work before merging it back in to the stable tree. The only problem was that the new tree was merged in all at once rather than piecemeal. The stable bits should be merged in as they mature. A three tier system, sorta like Debian (Sid (aka unstable), testing, and stable) makes sense, and here the the unstable branch would be the 'ODD' tree such as 2.9.x, the testing tree would be the even branch to three or four digits (say an ODD number of digits) and the stable tree would be to an even number of digits.
So 2.9.x.x unstable, 3.x.x testing, and 3.x stable. For "oops" fixes to stable and a letter such as 3.xA.
I am hoping Linus will not let himself be drawn into the version wars.
Put the damn thing out of its misery. Hopefully the new kernel will be object based.
Actually I realised just after clicking submit that I hadn't used a numeric entity after all. Doh!