What is Digg?Sponsored by Travelzoo
Take Advantage of Ridiculously Low Holiday Airfares view!
travelzoo.com - Flights $52 and up for Thanksgiving, Christmas & New Year. But move on it now.
66 Comments
- Smegzor, on 10/18/2008, -4/+77Linux 7 ;)
- canreacchio, on 10/18/2008, -6/+42I propose a system of versioning SO COMPLEX that everyone will be confused...
Linux version xx.yy.zz
WHERE zz is counting DOWN from 28
WHERE yy is counting UP to 42 in multiples of two
WHERE xx is taking counting UP... taking the distance walked by each contributing developer in the time it takes for yy to count up to 42.
THATS RIGHT... complete codswallop i say! - arjie, on 10/18/2008, -2/+19What problem would this solve?
- infiniphunk, on 10/18/2008, -5/+20Linus, please please say no to this total and utter *****. Stick to your guns, the current versioning system is FINE.
- inactive, on 10/18/2008, -1/+10As long as the ;) was kept in it too.
- linagee, on 10/18/2008, -0/+9^-- software limited to be a POS. If you want the real thing you've got to get Linux 3000 "Ultimate" Edition.
- kragil, on 10/18/2008, -1/+9Yeah, a name change is really about time.
year.month.minor
year= two digit year of the merge window
month= two digit month of the merge window
minor= fixes for .0
So 2.6.28 would become 8.10.0
next one would probably be 9.1.0
OK, it sounds like Ubuntu. But it just makes sense.
Advantages:
-most user space tools will not break ( unless they are buggy and need fixing anyways )
-you don't have to guess when the kernel will be released because you use the merge window for the name, that way it represents the state of the development pretty good IMHO
-relatively short
-meaningfull
Disadvantage:
In 2100 you will get a probelm. I guess you can call that a minor problem. - ArthurSucks, on 10/18/2008, -2/+9I think a year code would be great. It gives a more digestible understanding of where in the time line of when the kernel was made.
- webmink, on 10/18/2008, -1/+8Copying the OpenSolaris naming convention? Who'da thought it. [OpenSolaris releases are 2008.05, 2008.11, 2009.xx etc]
- cheeseplease, on 10/18/2008, -3/+9Linux 3000 Premium Edition
- rancidpony, on 10/18/2008, -3/+9Who let the marketing majors on the listserv?
Tell him to shove it up his @#$. No one pays attention to the kernel version. End users pay attention to Package version like Ubuntu 8.1. Don't make yourselves sound like Microsoft. Stay classy. - inactive, on 10/18/2008, -0/+5I'm just looking forward to 2.6.28.3.37848.37838.373847.001
- srg13, on 10/18/2008, -1/+6Why don't they just use hashes instead of version numbers, like Git does with revisions? That would be great - logical, easy to remember, and far less confusing:
"Hey, I just compiled the new Linux version d5f13b0985a!"
"Yeah, I'm just using 3f053cd34e that Ubuntu shipped with" - srg13, on 10/18/2008, -0/+4What Y2K issues? And even so - 9.x in 2009 would come 10.x, and then in another 90 years (if Linux still existed), it would be called (*gasp*) 100.x... It's not like it's confined to being a one or two digit integer...
- grg183, on 10/18/2008, -0/+4In my opinion, it wouldn't make much sense to have version numbers based on the year. Why would the version number change from 2008 to 2009 if there hasn't been any major change in the kernel??
The way it currently is (although I agree it is becoming a bit too complex), just by looking at the version numbers, you would immediately know whether the change from x.y.z to x'.y'.z' is a major one or not, a useful piece of information while deciding whether or not to upgrade to a particular kernel. If however you have two versions which are 2009.2 and 2011.4 you have absolutely no idea how large the difference is between them. Knowing only 'when' it was released is a useless info. Maybe appending or prefixing the release year to the existing version number might be better in terms of information conveyed by the version number but of course makes the situation worse :S
And I agree with beerden above, it would make releases date driven , not feature driven! - rowjimmy, on 10/18/2008, -0/+4i was about to say, "of course linux will still exist in 90 years" and then i thought about how long any OS has actually existed for - maybe 40 years at the most for something like UNIX-PDP7 (and not in any form similar to what it is today). in 90 years time, it'll be neural-net OS, or something like it. although, then we'll succumb to the self-preservation of the network as it slowly kills off people when power consumption is too much for it to handle, and erases any trace of them in our memory.... dum dum dum
- Culyt, on 10/18/2008, -1/+5Which is just a cross between the Gentoo 200Y.relesenumber and the Ubuntu 0Y.month.
☢ - koan, on 10/18/2008, -0/+4How can the "when" possibly matter to a kernel release?
With ubuntu, it is part of the philosophy of the distribution - six monthly releases. It has bearing.
Kernels are released when they are ready. - tHeSiD, on 10/18/2008, -0/+4yes nice idea
but if you name linux releases with integers..
the one currently running .. i think is
Linux 200,124 - hadphild, on 10/18/2008, -0/+4I think you mean Linux 2.6.pi
- TheCoreh, on 10/18/2008, -0/+3I don't get it. Why can't the next release be 2.8.0? and then after some time go to 3.0.0? Why exaclty are we "stuck" at 2.6.x?
- rmxz, on 10/18/2008, -1/+4"2009.x is rather stupid compared to just 9.x."
Except if they use "2009.x" I'd hope they give official aliases to all the old kernels too so I can refer to 2.0 as "2006.0.0" and 1.0 as "1994.0.0".
If they're just creating a new inconsistent scheme I think it's a bad idea -- but if they're creating a new one that can be self-consistent for both old historical and future releases it sounds good to me. - rmxz, on 10/18/2008, -0/+3I think they should rename (or give aliases to) all the past ones too that match whatever numbering scheme they pick.
If I can call whatever the next one is 2009.0.0, it'd be nice if I can call Linux 2.0 Linux 1996.0.0 too. - adkenc, on 10/18/2008, -0/+3no no no, supreme being edition.
- Echomote, on 10/18/2008, -0/+310000.1.0
- X-Istence, on 10/18/2008, -1/+4That will throw out the entirely logical progression. No more knowing what the next release is going to be, 2.6.xx or 20xx.x.x? That just seems to be a nightmare.
Open Solaris for it's releases uses yyyy.mm but it also has an internal version number snv_89 or snv_99. This makes it easy to distinguish between the various version of the OS.
Either way I would welcome the change, I can never keep track of the longer version numbers. For example Apache has it's 2.2.x stuff, and I always forget whether or not that second two is there or not. PHP is at 5.2.6 right? Or something along those lines at least. FreeBSD's version numbers make sense. 7.0, 7.1, next release is 8.0. - sweetgirls, on 10/18/2008, -1/+4Advantages:
-most user space tools will not break ( unless they are buggy and need fixing anyways )
-you don't have to guess when the kernel will be released because you use the merge window for the name, that way it represents the state of the development pretty good IMHO
-relatively short
-meaningfull
very great explanation. But let's just see the bugs after it was release - saejinn, on 10/18/2008, -1/+3Why not use Unix Epoch time? It's, IMHO, the best time measurement we've got.
It'd look like this: Linux Kernel 1224344706
Its ten digits long but "2008.10.18" has eight digits (ten if you count the "."s) and thats only accurate down to a day, whereas UET is accurate down to the second. Perhaps you don't need that level of accuracy, in which case you simply drop the five right-most digits which are all sub-multiples of a day (It doesn't fit perfectly into a natural Earth rotation-based day of 86.4ks. But it's only about 2.5 hours off) and you're left with 12243. To fit the traditional time system into that few of digits you'd have to do a lot of truncating. It'd look like: 08.10.18 which is not good since 1) it's still more digits then the proposed UET (six to eight depending on if you count the "."s), and shrinking 2008 to 08 can cause confusion, plus it's based off the stupid "60 seconds in a minute, 60 minutes in an hour, 24 hours in a day" *****.
This system has far fewer digits, is accurate down to a day (give or take about two and a half hours), is based off an SI system, no conflict of whether its universal or local time, and, as Seven of Nine would say, "is efficient". - JonDempster, on 10/19/2008, -0/+2similar to the rules for naming complex molecules.
- nageroc, on 10/18/2008, -0/+2Yes, let's break the compilation of every piece of software that checks the kernel version and force them all to release an update (including packages that have been stable for *years* and/or are barely maintained anymore) just so that we can have a pretty number when we type "uname -r".
Some people may remember Sun doing this when they went from 2.6 to 7. Guess what, folks, they did *not* change their kernel versioning scheme (uname -sr == "SunOS 5.x"). Ever stop to wonder why they didn't? - fluxion, on 10/19/2008, -0/+2they should name it linux 7.x just to piss off microsoft
- OrqwithVagrant, on 10/18/2008, -0/+2That version number scheme would be PERFECT for the Intercal rewrite of Linux!
- eruanno, on 10/18/2008, -0/+2exactly. don't fix it if it ain't broke. _definitely_ don't fix it, if you're not making it better!
- fluxion, on 10/19/2008, -0/+2it also makes it easier to identify your first-born child with a specific kernel release
- cheesejaguar, on 10/18/2008, -0/+2This is just a ploy by gentoo losers.
- jhchrist, on 10/18/2008, -0/+2I suppose it could be useful for PR purposes. It would be a more immediately understandable bullet point for a distro's new features if it were
* New 2008.9.0 kernel
than if it were
* New 2.6.27.1 kernel
Even if you don't know what a kernel is, you can recognize that the first one is fairly recent. It makes the distro look new - the other one just makes it look confusing and overly-technical to new users. - pHreaksYcle, on 10/18/2008, -1/+3I agree, that would be the best.
- noerrorsfound, on 10/18/2008, -0/+2Uncle Rico: Back in '82, I used to be able to throw a pigskin a quarter mile.
Kip: Are you serious?
Uncle Rico: I'm dead serious. - agentlame, on 10/18/2008, -5/+7Even if they just dropped the .6 it would be an improvement. It's understandable that versions numbers are arbitrary, but the 2.6.xx thing is a little dated. That said, I can't wait for: 2.6.135
- Darkhacker, on 10/17/2008, -8/+10My personal opinion is to just stop using four place holders and go back to using three, but keep the numbers the same. Thus the next release will be 2.7. Any bug fixes to that would be 2.7.x. The next major version (approximately three months later) would be 2.8.
If they do adopt "date as the version" approach, I hope they do it like Ubuntu. I think typing out 2009.x is rather stupid compared to just 9.x. - inactive, on 10/22/2008, -0/+1Linux 3.1
- linagee, on 10/18/2008, -1/+2Why not just pick all 6 digits from a ouiji board?
- Vadi0, on 10/18/2008, -0/+1Just, no need for the 20 in 2008. Skip that and make it be 9.0.0
- infiniphunk, on 10/19/2008, -0/+1It's a trap
- beerden, on 10/18/2008, -0/+1A date based version is a stupid idea, but it's in vogue, so some people with "marketing type brains" are apt to suggest it. This reminds me of something out of Dilbert.
The problem with putting a date in the version is that it implies a date based release deadline, not a features based deadline (which does have some "get your contributions submitted by midnight at this date if you want it to make the next version." but nothing else date based that is connected with how the public perceives it.) Implementing a date in the version implies that Linux kernel development would have to change its strategy. Date based development suffers from feature dropping, wherease feature based development suffers only from delays until the code is actually stable and useful. In my experience, date based development on open source projects only sets fans up for disappointment.
I prefer the current version scheme, although I think it could drop a number or two. I like referring to the Linux kernel as "two-six-twenty-six", for example, because other Linux-aware people then know what I am referring to. If it goes to the date based system, now I'll have to say, "It's running on 2009.7!" ? huh? Are you talking about Linux? Windows? Solaris? - nanostream, on 10/19/2008, -1/+2I don't know, why but your "disadvantage" made me ROFL
- fluxion, on 10/19/2008, -0/+1it seems like the 2.0/2.4/2.6 releases have such long lifetimes that the first fields become redundant an uninformative.
condensing that to a single number, like the year or something else i think would be more efficient.
also, considering how many changes were involved with going from 2.4 to 2.6, its hard to imagine something so drastic that a 3.x.x.x version is warranted.
but maybe there are plans for what a 3.x release would entail, iunno. im just saying, the 2.6 conveys very little information these days, and i think the scheme is a relic of the drastic changes between 1.x and 2.x that cant really be expected to occur at this level of maturity. although its exciting to imagine that happening....maybe that what the first field is being reserved for iunno. im just a lazy typer i guess. - DickBreath, on 10/18/2008, -0/+1This is not very Y10K friendly. What happens when we go past year 9999?
- Nephersir7, on 10/20/2008, -0/+1Windows Vista SP4 could be called Windows 8.13.22, in an attempt to confuse its customers from the failure that will be Windows 7, after what they will change the default wallpaper and release it as Windows insert_a_slick_name_here _why_not_try_Windows_Mojave?_That_sounds_like_a_successful_name,_ according_to_very_scientific_and_independent_experiments
- Filter, on 10/18/2008, -1/+2Based on the way they have been doing the version number, at least by my understanding, there probably won't be a 2.8 for a long while so why not change the version scheme. There have been some major changes to 2.6 and the version doesn't really reflect that.
-
Show 51 - 67 of 67 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is