If anyone is wondering about the future builds of Linux, here they are.
(This message is long, but hopefully interesting? Please read it!)
An idea for a "variation on the theme" for version numbers occurred to me a
while back, but with 2.4 coming soon, this seems like an opportune time to
suggest it and see if anyone likes it...
The Linux kernel established the current scheme with version 1.0, and it
has been widely copied since. (Was it used before then by anyone else?)
Even numbers in the version number for stable releases and odd numbers for
development releases has worked quite well. This encodes some meaning into
the version number, which makes the status of kernel versions easier to
identify. I'd like to extend this further by adding a digit to development
version numbers representing the current phase of the development cycle.
This is easiest to explain by way of an example proposal:
2.4.xx Current stable release series. (Well, almost current.)
2.5.0.xx Initial integration -- No architectural changes allowed
while the inevitable backlog of pending patches from the
last stabilization effort are integrated and stabilized.
The final 2.5.0.xx release should be re-released as a new
2.4.1 stable release. This series should resemble a
combination of 2.5.8.xx and 2.5.9.xx below, and should be
suitable for non-mission-critical production use. This is
a fork from the stable series that re-merges once before
diverging again for radical development work.
2.5.1.xx EXTREMELY unstable -- Major architectural changes, any new
features and major feature changes allowed as the tree is
thrown wide open for bizarre and wild experimental work,
much of which may be discarded as experimental prototypes
prove that some ideas that sounded good weren't so good.
Suitable only for the extremely brave or foolish. Even
developers may wish to avoid this series unless they're
doing the experimenting. Expect constant crashing.
2.5.2.xx VERY unstable -- Much like 2.5.1.xx series, but experiments
should a little less wild now. Best time to focus on the
major architectural changes that are goals for the 2.6.xx
stable series. Most developers would want to work with
this series, but not depend on it heavily for daily use.
Expect nearly constant crashing.
2.5.3.xx Unstable -- Significant architectural changes, new features
and major feature changes allowed. Most experimental work
should be finished by now; new experimental work should be
developed in a forked tree until suitable for integration
into development tree. Suitable for developers, should be
stable for short periods of time. Expect frequent crashes.
2.5.4.xx Almost stable -- Reasonable architectural changes allowed,
new features and major feature changes allowed. Suitable
for developers only, but "bleeding edge" users may want to
try it out briefly. Expect random crashes, but should be
stable enough to be more-or-less usable.
2.5.5.xx Somewhat stable -- Small architectural changes allowed,
new features and significant feature changes allowed.
Suitable for developers and "bleeding edge" users only.
Expected to crash once or twice per day, but should be
stable for hours at a time.
2.5.6.xx Reasonably stable -- Minor architectural changes allowed,
medium feature changes allowed. Suitable for experimental
servers or the more patient of the average desktop users.
Not suitable for any production use; may crash several
times per week.
2.5.7.xx Mostly stable -- No architectural changes allowed, new
features and small feature changes allowed. Should be
suitable for the average desktop user or for a test server.
Not suitable for most production use; expected to crash
every few weeks or so.
2.5.8.xx Initial release candidates -- No architectural changes, and
only minor feature changes or clean new features allowed.
Bugfixes and carefully selected patches only. Should be
suitable for production use only on non-mission-critical
systems. (This series would be equivalent to "pre" series
in the past preceding a new stable release series.)
2.5.9.xx Final release candidates -- No architectural, new features
or feature changes allowed at all. Bugfixes ONLY; final
tuning before 2.6.xx stable release series. Final release
candidates should be almost suitable for production use on
mission-critical systems, as any stable series release
should be. (This depends on getting 2.5.8.xx used on some
production systems first...)
The 2.5.9.xx series should REPLACE the traditional initial
stable series stabilization efforts. The final release in
this series should be re-released as 2.6.0 and 2.7.0.0 with
no changes but the version number -- if more bugfixes are
needed, it's not time yet. Only when it's time to fork for
a new development series should the stable series be
declared. (This should avoid embarassments like 2.2.0 --
a "stable" release that crashed rather easily...)
2.6.xx Next stable release series.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Launched in 1992, the satellite lasted much longer than its intended three years. It studied the extreme ultraviolet spectrum for NASA and later the University of California, Berkeley, until it ceased operations in December 2001.
I say it could have made the release date of Windows 3.1, which was released in April of that year.
I don't know if anyone put a link down the WinSuperSite so there it is. It has screenshots, some fake, some real, and a long description of the operating system. Worth a look.
If it's just a title change, how about Goldphallus, Goldshlong, Golddong, Goldhairybanana, Goldbigchap, GoldflyingScotsman or something to that effect.
But then if the call it GoldflyingScotsman they could get sued for damaging the reputation of Scots.
From CNN: Rappers 2 Live Crew, for example, took their use of the Roy Orbison song "Pretty Woman" all the way to the Supreme Court, which then reached the explicit conclusion that a parody falls within the scope of the fair-use defense. It would, however, be impossible to market the film as "Goldmember" during that process.
Great! So we find another planet, travel to it and fuck it up just like we have already done to earth.
I agree with Agent Jones' speech, or was it Agent Smith's?, in The Matrix. The human species is a virus. We move in, take everything in the process, and then move on.
We should just let the human race die out. It would be better for everyone.
An article is at At New York.com dated back from August 2, 2001. It says the speed will allow Web surfing at speeds as high as 144Kbps and full 3G service promises to support speeds of 384Kbps and higher. Since the newer article from CNN doesn't say what the speed is, it could still be the same.
Can be found here. It is dating back to Novemeber 05, 2001.
WINE discourages native Linux apps
on
Wired Talks Wine
·
· Score: 1, Redundant
WINE should be stopped, it hurts Linux from meeting its full potential. Sure it is nice to run Windows programs on Linux and everyone would like to do that but it discourages developers from creating programs for Linux (either ported or native). WINE only helps benefit Microsoft by giving them more software for their operating system. For Linux to truely win it must have its own large base of programs.
It is easy to port software with only 2 common base OS's--all the *NIXs and Windows. Programs can easily be recompiled and run between all the *NIX systems so it is no biggie to port Windows software.
What about programs that will never get ported like MS Office? Well, I do not see a need for it since StarOffice is as good if not better. There is already OSS on Linux that mirrors Windows'. Anything that comes out of Redmond can be matched by programmers coding in their spare time.
The WINE team will be burdened by having to up implement Windows features. If they do not keep up they will fall behind and be blamed for the small ammount of software on Linux.
There will always be problems with Windows problems because of bugs in the APIs that some programs depend on so again WINE is a problem.
The biggest beer producers in the world meet for a conference, and at the end of the day, the presidents of all the beer companies decide to have a drink together at a bar.
The president of Budweiser naturally orders a Bud, the president of Miller orders a Miller, Adolph Coors orders a Coors, and so on down the list. Then the bartender asks Arthur Guinness what he wants to drink, and to everybody's amazement, he orders tea!
"Why don't you order a Guinness?" his colleagues ask suspiciously, wondering if they've stumbled on an embarrassing secret.
"Naaaah," replies Guinness. "If you guys aren't going to drink beer, then neither will I."
Slashdot Mirror
Looks like I might get two right in a row!
Although the 2 min wait almost got me.
Go here to give Windows a complete Goatse makeover!
Note: no Goatse pictures on site.
Hmmm... could be modified to improve my car's performance...?
If anyone is wondering about the future builds of Linux, here they are.
(This message is long, but hopefully interesting? Please read it!)
An idea for a "variation on the theme" for version numbers occurred to me a
while back, but with 2.4 coming soon, this seems like an opportune time to
suggest it and see if anyone likes it...
The Linux kernel established the current scheme with version 1.0, and it
has been widely copied since. (Was it used before then by anyone else?)
Even numbers in the version number for stable releases and odd numbers for
development releases has worked quite well. This encodes some meaning into
the version number, which makes the status of kernel versions easier to
identify. I'd like to extend this further by adding a digit to development
version numbers representing the current phase of the development cycle.
This is easiest to explain by way of an example proposal:
2.4.xx Current stable release series. (Well, almost current.)
2.5.0.xx Initial integration -- No architectural changes allowed
while the inevitable backlog of pending patches from the
last stabilization effort are integrated and stabilized.
The final 2.5.0.xx release should be re-released as a new
2.4.1 stable release. This series should resemble a
combination of 2.5.8.xx and 2.5.9.xx below, and should be
suitable for non-mission-critical production use. This is
a fork from the stable series that re-merges once before
diverging again for radical development work.
2.5.1.xx EXTREMELY unstable -- Major architectural changes, any new
features and major feature changes allowed as the tree is
thrown wide open for bizarre and wild experimental work,
much of which may be discarded as experimental prototypes
prove that some ideas that sounded good weren't so good.
Suitable only for the extremely brave or foolish. Even
developers may wish to avoid this series unless they're
doing the experimenting. Expect constant crashing.
2.5.2.xx VERY unstable -- Much like 2.5.1.xx series, but experiments
should a little less wild now. Best time to focus on the
major architectural changes that are goals for the 2.6.xx
stable series. Most developers would want to work with
this series, but not depend on it heavily for daily use.
Expect nearly constant crashing.
2.5.3.xx Unstable -- Significant architectural changes, new features
and major feature changes allowed. Most experimental work
should be finished by now; new experimental work should be
developed in a forked tree until suitable for integration
into development tree. Suitable for developers, should be
stable for short periods of time. Expect frequent crashes.
2.5.4.xx Almost stable -- Reasonable architectural changes allowed,
new features and major feature changes allowed. Suitable
for developers only, but "bleeding edge" users may want to
try it out briefly. Expect random crashes, but should be
stable enough to be more-or-less usable.
2.5.5.xx Somewhat stable -- Small architectural changes allowed,
new features and significant feature changes allowed.
Suitable for developers and "bleeding edge" users only.
Expected to crash once or twice per day, but should be
stable for hours at a time.
2.5.6.xx Reasonably stable -- Minor architectural changes allowed,
medium feature changes allowed. Suitable for experimental
servers or the more patient of the average desktop users.
Not suitable for any production use; may crash several
times per week.
2.5.7.xx Mostly stable -- No architectural changes allowed, new
features and small feature changes allowed. Should be
suitable for the average desktop user or for a test server.
Not suitable for most production use; expected to crash
every few weeks or so.
2.5.8.xx Initial release candidates -- No architectural changes, and
only minor feature changes or clean new features allowed.
Bugfixes and carefully selected patches only. Should be
suitable for production use only on non-mission-critical
systems. (This series would be equivalent to "pre" series
in the past preceding a new stable release series.)
2.5.9.xx Final release candidates -- No architectural, new features
or feature changes allowed at all. Bugfixes ONLY; final
tuning before 2.6.xx stable release series. Final release
candidates should be almost suitable for production use on
mission-critical systems, as any stable series release
should be. (This depends on getting 2.5.8.xx used on some
production systems first...)
The 2.5.9.xx series should REPLACE the traditional initial
stable series stabilization efforts. The final release in
this series should be re-released as 2.6.0 and 2.7.0.0 with
no changes but the version number -- if more bugfixes are
needed, it's not time yet. Only when it's time to fork for
a new development series should the stable series be
declared. (This should avoid embarassments like 2.2.0 --
a "stable" release that crashed rather easily...)
2.6.xx Next stable release series.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Why does the kernel go through stable and then unstable forks? Can't it always be a stable build, like with Windows?
And I am logged in too!
At least we can agree on one thing, the abundance of stupid consumers.
Launched in 1992, the satellite lasted much longer than its intended three years. It studied the extreme ultraviolet spectrum for NASA and later the University of California, Berkeley, until it ceased operations in December 2001.
I say it could have made the release date of Windows 3.1, which was released in April of that year.
Oh, so out of 6 billion people you mention 3.
I can honestly say you have changed my mind and I am sure many others about purchasing space insurance.
Keep informing the public!
Insurance? Well, you would have to find some really dumb people considering the odds.
Perhaps the man who robbed a store with a tree branch might be interested.
I don't know if anyone put a link down the WinSuperSite so there it is. It has screenshots, some fake, some real, and a long description of the operating system. Worth a look.
007 dismembers Austin Powers
Oh, you gotta feel sorry for his wife.
Yes but what do they mean by major tweaking?
If it's just a title change, how about Goldphallus, Goldshlong, Golddong, Goldhairybanana, Goldbigchap, GoldflyingScotsman or something to that effect.
But then if the call it GoldflyingScotsman they could get sued for damaging the reputation of Scots.
I will, but only by the cor... oh, wait, nevermind.
I remember one such file. Flesh Gordon, a parody of Flash Gordon. Nice sci-fi flick, I recommend it to the Slashdot readers.
Other articles:
Movies.go.com
Yahoo
BBC news
CNN
From CNN: Rappers 2 Live Crew, for example, took their use of the Roy Orbison song "Pretty Woman" all the way to the Supreme Court, which then reached the explicit conclusion that a parody falls within the scope of the fair-use defense. It would, however, be impossible to market the film as "Goldmember" during that process.
Did you even read the article? It says MGM and Danjaq only want the title of the movie changed.
The characters and the plot do not need to be changed, even though there is a character in the movie called Goldmember.
It is strange how the film companies only want the title changed but not the character that infringes the copyright
Great! So we find another planet, travel to it and fuck it up just like we have already done to earth.
I agree with Agent Jones' speech, or was it Agent Smith's?, in The Matrix. The human species is a virus. We move in, take everything in the process, and then move on.
We should just let the human race die out. It would be better for everyone.
An article is at At New York.com dated back from August 2, 2001. It says the speed will allow Web surfing at speeds as high as 144Kbps and full 3G service promises to support speeds of 384Kbps and higher. Since the newer article from CNN doesn't say what the speed is, it could still be the same.
There is also an old article at CNN here.
Just do a search on Amazon Books and find the one right for you.
The best ones I have found are
Mac OS X: The Missing Manual
Mac OS X Unleashed
Mac OS X Server Administrator's Guide
Mac OS X Power User's Guide
Macworld Mac OS X Bible
Can be found here. It is dating back to Novemeber 05, 2001.
WINE should be stopped, it hurts Linux from meeting its full potential. Sure it is nice to run Windows programs on Linux and everyone would like to do that but it discourages developers from creating programs for Linux (either ported or native). WINE only helps benefit Microsoft by giving them more software for their operating system. For Linux to truely win it must have its own large base of programs.
It is easy to port software with only 2 common base OS's--all the *NIXs and Windows. Programs can easily be recompiled and run between all the *NIX systems so it is no biggie to port Windows software.
What about programs that will never get ported like MS Office? Well, I do not see a need for it since StarOffice is as good if not better. There is already OSS on Linux that mirrors Windows'. Anything that comes out of Redmond can be matched by programmers coding in their spare time.
The WINE team will be burdened by having to up implement Windows features. If they do not keep up they will fall behind and be blamed for the small ammount of software on Linux.
There will always be problems with Windows problems because of bugs in the APIs that some programs depend on so again WINE is a problem.
The biggest beer producers in the world meet for a conference, and at the end of the day, the presidents of all the beer companies decide to have a drink together at a bar.
The president of Budweiser naturally orders a Bud, the president of Miller orders a Miller, Adolph Coors orders a Coors, and so on down the list. Then the bartender asks Arthur Guinness what he wants to drink, and to everybody's amazement, he orders tea!
"Why don't you order a Guinness?" his colleagues ask suspiciously, wondering if they've stumbled on an embarrassing secret.
"Naaaah," replies Guinness. "If you guys aren't going to drink beer, then neither will I."
How big of an alcoholic do you need to be before you can buy a gps watch designed soley for the purpose of getting wasted?
Crap, I didn't realize the Matrix Binary Watch shows decimal time as well.