Posted by
michael
on from the we-don't-need-no-steenkin'-patches dept.
cybercyst writes: "You know the drill... Lets go hit those servers!" As usual, see kernel.org for the download or the changelog. Anyone using 2.5 for anything except testing?
(1) If you get any link errors when compiling your new kernel which refer to lock_kernel and unlock_kernel. Just add #include to whatever files generate the complaints.
(2) If you have any SCSI drives that were broken because of the Block IO Layer changes, then this kernel most likely fixes them. Apparently, the "various scsi driver fixes" includes the parallel port zip driver (ppa.c) for any who care:).
Ok ok ok - we all know that kernel.org's got some cashflow problems, so people PLEASE use the mirrors and patches!! To apply the patch, from the older version, CD in, then use patch -p1 kernel-2.5.3.patch (or whatever.) Make sure to make clean first also, just for paranoia. Anyway, have fun.
--joshua
P.S. Not redundant, no one's said this yet.
You know, the kernel.org guys never claimed cash flow problems, they just wanted another "main site" mirror for redundancy.
After the outage when/. ran the story, everyone just ASS-U-ME ed that it was cash flow problems, when the LKML archive clearly shows it was just technical difficulties.
That said, people should be getting diffs when they can anyway, there is no point in wasting bandwidth.
-- I've had enough abrasive sigs. Kittens are cute and fuzzy.
Technically it's feasible because many people has already done this for commercial servers. Is there any difficulties(political? Legal? Ownership?) make it impossible?
The difficulties are administrative/ownership. We (the kernel.org staff) has no real control of the mirrors, so I can't guarantee that any particular mirror is always up to date. For that reason, it seems more fair to let users at least know that they're using a mirror.
That being said, the mirror system participants provide a huge service, without which we would certainly have bandwidth problems.
Re:Use The Mirrors, Luke!
by
tom.allender
·
· Score: 3, Informative
You should link directly to the list of mirrors.
Yeah, but not the list of sites that kernel.org mirrors themselves as they currently are.
Future of Linux kernel
by
Metrollica
·
· Score: 2, Informative
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/
--
--Metrollica
Re:Future of Linux kernel
by
Deven
·
· Score: 5, Informative
I hope you moderators appreciate this is just this guy's idea, and not actually the current release versioning system used for 2.5. The fact that he made 2.5.3 bold would lead you to believe otherwise.
Actually, it was my idea (posted to the linux-kernel mailing list on May 10, 2000), but the other poster above didn't bother to attribute credit for it. (Although I think it was really more of a sarcastic comment on 2.5.3's stability, the way that section was bolded.)
That was an idea I came up with off the top of my head, looking for a way to move the "should be stable but oops, not" kernels out of the "stable" series into the "development" series (thinking of 2.2.0 for example) -- by adding a fourth digit to indicate the status, so that release candidates could get production testing before getting branded as "stable". Once a fourth digit was added, I figured that I might as well try to fill in the other numbers with vague-but-useful state indicators for earlier stages of development. That post to linux-kernel was my first attempt, off the top of my head.
I developed this idea further, in response to some of the discussion on linux-kernel about my idea, but in the end I decided against using it. My brother convinced me that encoding this much meaning into numeric identifiers required a lot of advance knowledge about the system to make any sense of the version numbers, and harried system administrators wouldn't take the time to learn.
I finally decided to use a different approach, where "stable" releases are all-numeric numbers (e.g. 1.0.0) while "development" releases always contain an alphabetic intended-state tag (e.g. 1.0.0.beta.1) and discarding the even/odd notion from Linux. This way, development versions are more self-identifying, and release candidates (suitable for production testing) would have an "rc" tag (e.g. 1.0.0.rc.3).
The idea is that the "stable" release (e.g. 1.0.0) would be completely identical to the last "rc" release (e.g. 1.0.0.rc.3) except for the version number change. If there's a temptation to add "one last patch" (no matter how minor), make a new "rc" version and let it make the rounds first. This would avoid embarassments like 2.2.0 and certain 2.4.x releases, which are marked "stable" by their version number, but were quite unstable in practice...
I tried to include my writeup of the all-numeric system I ended up with before I gave up on it, but Slashdot's "lameness filter" rejected it. Maybe it's a sign.:-) (Interested parties can send me email and I'll mail a copy of the writeup...)
--
Deven
"Simple things should be simple, and complex things should be possible."- Alan Kay
We don't have any problem covering our bandwidth bills, because ISC graciously gives us bandwidth at no charge. I would like to get another server for redundancy, but that's a completely different issue.
As far as mirrors of other sites are concerned, that's what class-based queueing is for. If we are saturated (which we rarely are) traffic gets prioritized, with outbound mirrors getting high priority and our mirrors of other sites getting low priority.
But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.
-- "In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
"But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think."
XFS was dropped on the floor with the rest of the kernel patches that did not make it. I'm sure there is a good reason for it. I've heard good things about this aa patch for 2.4.17 http://www.digitalroadkill.net/Patches/2.4.17-xfs- aa.patch.bz2 and it seems to improve things on my box. See http://www.lib.uaa.alaska.edu/linux-kernel/archive/2002-Week-04/1028.html for the text.
Re:Is it safe?
by
ArsonSmith
·
· Score: 2, Informative
> I've been wanting to get into this Linux thing for a while, but I'm kinda confused. And nervous.
Understandable
>What is a kernal and changelog?
A kernel is computer code that makes your computer start up and lets you do stuff on it. This is all before your operating system. (the part you are most familiar with likely Windows or MacOS)
The Changelog is a developer documentation that says what has changed in this program.
> And how come everyone that uses it seems to hostile to a newbie asking questions?
Because these are the wrong people for newbies to be asking. This would be like asking the Mechanical engeneers how to change sparkplugs in a car. You need to try directing your questions to one of the distributions
http://redhat.com
http://mandrakelinux.com
http://debian.org
http://slackware.org
> Also, how do you run it?
It requires an install from a distribution first. (see answer from above)
>I tried opening it with winzip and that didn't work.
Yes opening it with winzip would work for the kernel source as you would get a bunch of "C" programming files in a nice neat directory. this is like getting the blue prints to a house to open the front door. (again please see the distribution list above)
>Adaware didn't call it (well, I downloaded something called from www.redhat.com but it didn't work) spyware or anything, but I know alot of freeware has spyware on it. Is linux like that?
Most stuff in linux does not have spyware. Although there is no technical reason for it, it is generaly frowned apon and seen as bad.
> Also, is it REALLY free?
Yes
>Or is it one of those things where you will use it for 30 days and then it takes forever to come up when you click on its icon until you pay?
no there is no payment needed to get the software.
I hope this helps.
-- Paying taxes to buy civilization is like paying a hooker to buy love.
Re:Nice release
by
daserver
·
· Score: 2, Informative
No, right now 2.4.x is using aa VM. Aa has actually mentioned that he talk the marcelo about syncing the main kernel with his aa series.
Re:Use The Mirrors, Luke!
by
damiam
·
· Score: 2, Informative
mirrors.kernel.org isn't the mirror page. It's a list of other sites mirrored by kernel.org. The correct URL is http://www.kernel.org/mirrors.
-- It's hard to be religious when certain people are never incinerated by bolts of lightning.
Re:Using it?
by
MindStalker
·
· Score: 3, Informative
No, the point is that 2.4.19 should be fixed, but it isn't. Luckly pathes (these exist in the windows world too) exist, to give you this same functionality in the 2.4.18 kernel untill.19 is ready. For example you could have practically patch windows2000 to reach the stability of XP while waiting for XP to come out. Same thing, just not as simple to understand all the time.
Re:What I'd like to see in "New Kernel" announceme
by
jsoderba
·
· Score: 3, Informative
The current development kernel release is 2.5.3, which was released on January 30 (changelog). The biggest change in the more recent prepatches has been the split of the massive (> 1MB) Configure.help file into multiple, smaller files spread out over the source tree. This change will make those files easier to maintain (it is hoped); in the mean time, however, it has broken a number of the configuration tools. Other changes include a large ReiserFS update and the inclusion of Nathan Scott's extended attribute patch, which paves the way for access control lists and other useful stuff in the future.
And it goes on into more detail after that. The previous issue talked about the new ATA drivers.
(I'm not affiliated with LWN. I just like the service.)
Re:What I'd like to see in "New Kernel" announceme
by
mathi
·
· Score: 2, Informative
A good pace to find this information is Kernel Traffic. It's like a summary of the mailing list.
(1) If you get any link errors when compiling your new kernel which refer to lock_kernel and unlock_kernel. Just add #include to whatever files generate the complaints.
:).
(2) If you have any SCSI drives that were broken because of the Block IO Layer changes, then this kernel most likely fixes them. Apparently, the "various scsi driver fixes" includes the parallel port zip driver (ppa.c) for any who care
w o r l d w i d e w e b e r
Ok ok ok - we all know that kernel.org's got some cashflow problems, so people PLEASE use the mirrors and patches!! To apply the patch, from the older version, CD in, then use patch -p1 kernel-2.5.3.patch (or whatever.) Make sure to make clean first also, just for paranoia. Anyway, have fun.
--joshua
P.S. Not redundant, no one's said this yet.
Yeah, but not the list of sites that kernel.org mirrors themselves as they currently are.
http://kernel.org/mirrors/
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/
--Metrollica
Note:
mirrors.kernel.org is NOT the list of mirrors of the kernel, it's the list of mirrors of other sites.
For the kernel, you want www.kernel.org/mirrors/ to find your local mirror of kernel.org (which is usually www.COUNTRYCODE.kernel.org).
--Xandu
But where is XFS? Extended attributes (arbitrary tuples for files) support would be cool. But we need XFS for that since that's the only Linux FS that supports this right now, I think.
"In short: just say NO TO DRUGS, and maybe you won't end up like the Hurd people." --Linus Torvalds
> I've been wanting to get into this Linux thing for a while, but I'm kinda confused. And nervous.
Understandable
>What is a kernal and changelog?
A kernel is computer code that makes your computer start up and lets you do stuff on it. This is all before your operating system. (the part you are most familiar with likely Windows or MacOS)
The Changelog is a developer documentation that says what has changed in this program.
> And how come everyone that uses it seems to hostile to a newbie asking questions?
Because these are the wrong people for newbies to be asking. This would be like asking the Mechanical engeneers how to change sparkplugs in a car. You need to try directing your questions to one of the distributions
http://redhat.com
http://mandrakelinux.com
http://debian.org
http://slackware.org
> Also, how do you run it?
It requires an install from a distribution first. (see answer from above)
>I tried opening it with winzip and that didn't work.
Yes opening it with winzip would work for the kernel source as you would get a bunch of "C" programming files in a nice neat directory. this is like getting the blue prints to a house to open the front door. (again please see the distribution list above)
>Adaware didn't call it (well, I downloaded something called from www.redhat.com but it didn't work) spyware or anything, but I know alot of freeware has spyware on it. Is linux like that?
Most stuff in linux does not have spyware. Although there is no technical reason for it, it is generaly frowned apon and seen as bad.
> Also, is it REALLY free?
Yes
>Or is it one of those things where you will use it for 30 days and then it takes forever to come up when you click on its icon until you pay?
no there is no payment needed to get the software.
I hope this helps.
Paying taxes to buy civilization is like paying a hooker to buy love.
No, right now 2.4.x is using aa VM. Aa has actually mentioned that he talk the marcelo about syncing the main kernel with his aa series.
To pick a nit, CML2 is the new config language. The new build system is kubild2.5, developed by Keith Owens.
© ilmari. All rights reserved, all wrongs reversed
mirrors.kernel.org isn't the mirror page. It's a list of other sites mirrored by kernel.org. The correct URL is http://www.kernel.org/mirrors.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
No, the point is that 2.4.19 should be fixed, but it isn't. Luckly pathes (these exist in the windows world too) exist, to give you this same functionality in the 2.4.18 kernel untill .19 is ready. For example you could have practically patch windows2000 to reach the stability of XP while waiting for XP to come out. Same thing, just not as simple to understand all the time.
(I'm not affiliated with LWN. I just like the service.)
A good pace to find this information is Kernel Traffic. It's like a summary of the mailing list.