Does this new kernel include the latest snapshot of ext3?
Ext3 is both distributed in the kernel and as a separate package, and I'm a bit lost : what ext3 code should we use for more reliability? Should the previous kernel be patched with the latest ext3? Does the new kernel include it? Does the latest ext3 cleanly applies to Linux 2.4.13?
Right now ext3 is not in the official kernel but it is in Alan Cox's which is also synched to the latest version, of course you can patch the official to use ext3 with patches from here. They usually lag a couple of days behind for a patch to be available for the latest kernels , but a cvs snapshot should work fine if you can't wait that long for them to release an official patch.
'Does this mean Alan Cox will maintain this series now, and will use the different VM ?!'
or
'When will 2.5.x be started?'
ChangeLog
by
Anonymous Coward
·
· Score: 2, Troll
final:
- page write-out throttling
- Pete Zaitcev: ymfpci sound driver update (make Civ:CTP happy with it)
- Alan Cox: i2o sync-up
- Andrea Arcangeli: revert broken x86 smp_call_function patch
- me: handle VM write load more gracefully. Merge parts of -aa VM
pre6:
- Stephen Rothwell: APM idle time handling fixes, docbook update, cleanup
- Jeff Garzik: network driver updates
- Greg KH: USB updates
- Al Viro: UFS update, binfmt_misc rewrite.
- Andreas Dilger:/dev/random fixes
- David Miller: network/sparc updates
pre4:
- Al Viro: mnt_list init
- Jeff Garzik: network driver update (license tags, tulip driver)
- David Miller: sparc, net updates
- Ben Collins: firewire update
- Gerd Knorr: btaudio/bttv update
- Tim Hockin: MD cleanups
- Greg KH, Petko Manolov: USB updates
- Leonard Zubkoff: DAC960 driver update
pre3:
- Jens Axboe: clean up duplicate unused request list
- Jeff Mahoney: reiserfs endianness finishing touches
- Hugh Dickins: some further swapoff fixes and cleanups
- prepare-for-Alan: move drivers/i2o into drivers/message/i2o
- Leonard Zubkoff: 2TB disk device fixes
- Paul Schroeder: mwave config enable
- Urban Widmark: fix via-rhine double free..
- Tom Rini: PPC fixes
- NIIBE Yutaka: SuperH update
pre2:
- Alan Cox: more merging
- Ben Fennema: UDF module license
- Jeff Mahoney: reiserfs endian safeness
- Chris Mason: reiserfs O_SYNC/fsync performance improvements
- Jean Tourrilhes: wireless extension update
- Joerg Reuter: AX.25 updates
- David Miller: 64-bit DMA interfaces
pre1:
- Trond Myklebust: deadlock checking in lockd server
- Tim Waugh: fix up parport wrong #define
- Christoph Hellwig: i2c update, ext2 cleanup
- Al Viro: fix partition handling sanity check.
- Trond Myklebust: make NFS use SLAB_NOFS, and not play games with PF_MEMALLOC
- Ben Fennema: UDF update
- Alan Cox: continued merging
- Chris Mason: get/proc buffer memory sizes right after buf-in-page-cache
Whoops. Forgot an important one.
by
jawad
·
· Score: 2, Funny
Whoops. Forgot an important one...
Prediction lists (and their addendums)...
Re:Whoops. Forgot an important one.
by
gowen
·
· Score: 3, Funny
Prediction lists (and their addendums).
Don't forget
Grammar flames (and their addenda)
-- Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
Direct link to mirrors
by
chrysalis
·
· Score: 4, Redundant
Security fixes
by
sting3r
·
· Score: 5, Informative
What they didn't mention were a few interesting security fixes from bugs in 2.4.12, probably due to the self-imposed DMCA "gag order." Since I am not in the US, I will take the liberty of posting them here:
Changing some I2O settings now requires the CAP_NET_ADMIN privilege. Previously any user could alter these settings and possible cause a DoS (lock up the box or lock up the I2O bus).
A race condition in the inode cache was repaired. This would allow stale inode data to be used (under the right circumstances), most likely only on SMP systems.
Several potential vulnerabilities involving ptrace() have been closed, preventing a few kernel-based local root exploits.
Bugs in the USB code which could have been leveraged to obtain direct hardware access have been fixed. These bugs may have resulted in local root exploits if security-critical hardware (such as hard drives) was on the USB bus.
What they didn't mention were a few interesting security fixes from bugs in 2.4.12, probably due to the self-imposed DMCA "gag order." Since I am not in the US, I will take the liberty of posting them here:
Wow, talk about waving the red flag in front of the bull!
You, my friend, must have balls the size of tank bearings. My hat is off to you!
Doesn't everyone know? Linus is recovering from alcholism. He just started the 12 step program. This week has been really hard for Linus because Alan Cox keeps talking about "putting away a few pints at the pub" (he is English) on the linux kernal mailing list. There have been a few flame wars too between the people working on the vm subsystem. Apparently one is a tea-totler and the other a hard core drinker so Linus is leaning towards using the tea-totler's code but Alan says the hard core drinkers code is better...
I think we all need to try to support Linus and Alan without choosing sides. Just grab the latest kernel of your choice and compile away... Try not to mention free beer on the linux kernel mailing list in the next couple weeks. Think free tea or something similar.
I was excited reading the kernel changelog until I got to this line:
- Trond Myklebust: make NFS use SLAB_NOFS, and not play games with PF_MEMALLOC
I'm sure NFS won't mind using SLAB_NOFS, but it's cruel to prohibit it from playing games with PF_MEMALLOC. NFS has reached the point where playing games with PF_MEMALLOC is the sole respite from the drudgery of its mundane life. None of the other protocols will play with it since the Trivial Pursuit incident of 1998, and it's banned from EQ for excessive Britishing.
Sure, we've all been inconvenienced a little now and again when NFS is playing games with PF_MEMALLOC, but it wasn't that bad, and it brought a glimmer of joy into NFS's otherwise bleak existence. Now NFS will be forced to sit alone in its room playing X Bill all alone until it goes mad and starts initializing remote filesystems at random.
Then where will we be?
Trond Myklebust, I hope you're happy with yourself. What did NFS ever do to you? It's just cruel, and we'll all have to deal with the consequences when people start running NFS on 2.4.13. You should be ashamed.
*telekon
--
To understand recursion, you must first understand recursion.
print "Looks like Linux X.Y.ZZ is out. You can get it at the usual place (kernel.org) and the mirrors. Check out the Changelog."
if(CmdrTaco just upgraded to ZZ-1 ||
weekday=tuesday) {
print "This is lame."
} else {
print "Grab. Test. Enjoy"
}
}
-- Thomas S. Iversen
Re:ptrace vulnerability fixed?
by
sting3r
·
· Score: 2, Redundant
They have not stated it because of DMCA concerns (see my other post) but it has been fixed. Take a look at the patch around line 17253 (ptrace.c) to see what they did.
Patches are simple! If you are using the linus tree see the other reply. If you are using the -ac (alan cox) tree than grab the incremental patches from bzimage.org. To apply the patch go to/usr/src/linux (instead of/usr/src like with the linux patches) and patch away...
If you had provided an example of your pains with patching you would have got a much more detailed reply from somebody. Thoughts to ponder...
Which releases are production stable?
by
S.+Invicta
·
· Score: 5, Interesting
I must say that I am getting a little bit leary about using the 2.4.x series in production. The fast releases don't inspire confidence. On one hand people (perhaps rightfully so) say don't use a kernel that is newer than 6 mo. old or you are a beta tester. But of course those older kernels were once bleeding new as well...how to know which to use and which to avoid? That 6 mo. old one might be the right age and yet perfectly horrible. Perhaps what is needed is a kernel stability/security chart that shows how well different kernel versions have "aged". Anyone know of such a beast?
Re:Which releases are production stable?
by
Builder
·
· Score: 3, Funny
FreeBSD (http://www.freebsd.org/)
Re:Which releases are production stable?
by
Anthony+Boyd
·
· Score: 2
The fast releases don't inspire confidence.
Linus used to release new kernels daily. In fact, it was part of the foundation for The Cathedral And The Bazaar. It's a feature, not a bug. 8^)
Re:Which releases are production stable?
by
oconnorcjo
·
· Score: 3, Informative
I must say that I am getting a little bit leary about using the 2.4.x series in production. The fast releases don't inspire confidence. On one hand people (perhaps rightfully so) say don't use a kernel that is newer than 6 mo. old or you are a beta tester.
For a production enviroment, I would get a Red Hat or SUSE (or any other large distributor's) kernel and just use that. They are heavily tested and heavily used kernels.
I for one would not upgrade to 2.4 on a serious production server yet unless thier is something 2.2 is missing that you need.
-- I miss the Karma Whores.
Re:Which releases are production stable?
by
GigsVT
·
· Score: 3, Insightful
This is not the way it's "supposed" to be. It might be true, but don't present it that way. Even versioned kernels are SUPPOSED to be stable. All of them. Patchlevel kernel revisions on the even number trees are not supposed to be anything but bugfixes.
-- I've had enough abrasive sigs. Kittens are cute and fuzzy.
Re:Which releases are production stable?
by
ajs
·
· Score: 4, Insightful
If you're grabbing the kernel-o-the-week, I suggest you're always going to be "less than production quality". Vendors like Red Hat, SuSe, Mandrake, etc. spend a whole lot of time integrating new kernel releases with their operating systems. This can include bug-fixing, testing on a number of hardware platforms, retro-fitting patches from development versions that are required for certain business segments and even beta periods for certain cutting-edge features (e.g. Red Hat's long trails internally and externally of the ext3 filesystem).
You should probably think of the stable kernels as just that: stable. That doesn't mean they are ready for prime-time. It's more like a "stable branch". You expect this to be the branch from which the distributions will craft The Right Kernel for their platforms.
Should you use such a kernel, then? Yes, but only if a) you're in a non-mission-critical situation or b) you "must have" a certain bug-fix and are willing to put in the Q/A yourself.
Think of the linux kernel as released on kernel.org like Mozilla. This is like a milestone release. Netscape will come out with something based on it which has Java, Flash, some back-ported bug fixes from later nightlies, etc. The corporate user should probably wait and go with a Netscape release, but here I am submitting this comment from a nightly;-)
Re:Which releases are production stable?
by
G27+Radio
·
· Score: 2
This is not the way it's "supposed" to be. It might be true, but don't present it that way. Even versioned kernels are SUPPOSED to be stable. All of them. Patchlevel kernel revisions on the even number trees are not supposed to be anything but bugfixes.
I think people need to realize that brand new kernels are like software 'release candidates'. In the case of Linux kernels they are made available to everyone for testing therefore they get somewhat widely tested. When [Debian|RedHat|SuSE] determine that a kernel is ready for prime-time they incorporate the kernel into their distribution and/or release it as an upgrade. These kernels should be though of as 'final realeases.'
As always, even with final releases of ANY software, there is no guarantee of 'buglessness.' <g> You really never know how software is going to react in your own environment until you actually test it.
It's really unreasonable for people to expect any kind of guarantee of stability from software that was realeased in the last 24 hours and hasn't been widely tested.
Re:Which releases are production stable?
by
Spencerian
·
· Score: 2, Funny
Mac OS X 10.1.
Aw, hell, even Darwin sounds better than the holy hell that a Linux kernel update can bring. The current yelling in here makes me wonder if the yellers should just blow up their PCs and use an abacus.
But then, they would be back, complaining that they can't use their DVD or joysticks with their abacus, and want the latest abacus kernel...
/./././.
-- Vos teneo officium eram periculosus ut vos recipero is.
Re:Which releases are production stable?
by
JoeBuck
·
· Score: 2
If Linus shipped the kernel, it's not production.
If Alan did, and it doesn't have an -ac after it, it's production.
Re:Which releases are production stable?
by
Dwonis
·
· Score: 2
Does *BSD have stateful packet filtering (i.e. connection tracking)? iptables is the main thing that keeps me with Linux (and Linux 2.4).
Re:Release Often?
by
Barry+Wilkes
·
· Score: 3, Funny
Alan Cox keeps talking about "putting away a few pints at the pub" (he is English) on the linux kernal mailing list.
Well, I guess that proves Alan doesn't read slashdot. He is Welsh. BIG difference. Especially when it comes to things like Rugby.
Alan's branch
by
BlowCat
·
· Score: 5, Interesting
SlashDot seems to pay more attention
to the Linus' branch, but if you really
want to be on the edge, you should
track the Alan's branch (i.e. the "ac"
series). The branches are synchronized
with each other from
time to time, but if you want to fix some
problem, check the code in the AC branch -
it may have the fix already.
That's especially true for the sound
drivers.
As for stability, the Linus' releases
don't seem to be formally tested anyway.
Maybe Linus is more conservative in
applying patches before the release,
but the recent events (2.4.11 and 2.4.12)
show that the kernel may not compile
in a common configuration and
be released notwithstanding.
Re:Linux Rocks
by
Billly+Gates
·
· Score: 2, Insightful
A little offtopic but quit correct. It turns out Bill Gates went even further and stated "..you need to look at other peoples code and improve upon it..". Hmmm Kind of sounds like un-american opensource doesn't it?
Linus interview on osnews.com
by
felipeal
·
· Score: 2, Funny
Q.(The kernel) 2.4.13 just came out a few days after the 2.4.12 release, which was a broken one. Aren't you worried about the kernel reputation?
Linus:I couldn't care less.
Q.But that's the second time that happens in 2 weeks (2.4.12 was released just 2 days after 2.4.11). Are you sure there is not a problem with the 2.4 branch?
Linus:See my answer to the previous question.
Tips for Testing and Those New to Kernels
by
goingware
·
· Score: 5, Informative
If you are new to installing your own kernel, or you want to get started on kernel programming, see http://www.kernelnewbies.org/ and join them on IRC in #kernelnewbies on the Open Projects Network.
If you'd like to program or debug the kernel, I recommend a couple of books:
Kernel Projects for Linux by Gary Nutt, ISBN 0-201-61243-7 - this is a lab manual with hands-on kernel programming projects that address a variety of kernel components
Understanding the Linux Kernel by Bovet, Cassetti, and Oram, ISBN 0596000022 - I bought a number of kernel programming books, and this seemed to be the best written of the books that covered recent kernels. It's mainly 2.2, with short addenda in each chapter for the changes that were expected at the time of writing for 2.4
Re:Gotta love Cable Modems and bzip2!
by
goingware
·
· Score: 2
Tourette's syndrome gives the sufferrer the uncontrollable urge to curse. The illness is not a joke, it's a serious neurological illness, and can have lasting unfortunate consequences on the sufferrer's ability to be accepted by others.
I've read a few of your responses and I must say you've got a pretty negative attitude. Is that really the impression you mean to give us?
I agree with you that the quality of/. is decreasing steadily, when you can't even post patches! My god! Well, that is commercial stuff for you. Anyways thank you for the attempt to use this miserable forum, here is a link to the kernel list archive and the post with the patch.
I just wish that some day I will see a working Linux bttv driver. For some reason, I always drop WAY too many frames with every Linux video capture program I use. (MainActor has been best so far - it only drops a few frames, almost gets perfect video quality, almost keeps A&V in sync and almost saves in format that can be read to Virtualdub in Windows, or any other Win32 editing app).
I need to use Windows programs to do video captures, which technically isn't nice either because the driver really doesn't work perfectly there either - it either works perfectly or not at all, depending on the phase of the moon.
Better multimedia support is always nice. One day, I will be able to use Linux for everything. =)
ok.
I haven't asked a stupid question all day, so now's my chance.
Are the frame drops related to the low-latency stuff? Ie, perhaps the card only has so much buffer space, and linux takes too long to read it?
I admit, it sounds weak, as memory is cheap and I would expect the card to DMA the stuff into main memory... but hey, it IS a possible explanation.
Re:Kernel 2.4.13 is out..yay....
by
bfree
·
· Score: 2
I would have to agree that you are better off running a stock distribution kernel IF your stock distribution kernel supports what you want, but if you are going to recompile the kernel in any way you are breaking the QA experience. Once you compile any kernel yourself you could be introducing issues and the only way to be sure to be sure is to then test your own kernel before implementing it in a mission critical setting. I personally have always found that the debian kernels are very good becuase they usually spend months in unstable and testing where users run them as is AND compile there own kernels for whatever crazy hardware or software config they need. RH (and as you did, I am just choosing them as an easy example) is not an open company, and their kernels are not tested in such a wide way (debian gets a good run at multiple platforms straight away) and their users are not as "powerful" as debian users (sweeping generalisation that I would say is fair, the % of debian users running self-compiled kernels must be higher than the same % for RH). I think it would be brilliant if we could get all linux distributors (from embedded to RH to Linus) to publish information on the kernels they use and test in one place so that anyone who needs to compile their own kernel can view the experiences of the most relevant people/kernels/settings and get a good idea of the issues they might experience with different setups.
Re:What bothers me is not the frequency of release
by
nagora
·
· Score: 2
and a release to fix that bug took almost 2 weeks!
Actually, there was a patch out the same day, available from all good kernel mirrors.
TWW
-- "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Re:Gotta love Cable Modems and bzip2!
by
JabberWokky
·
· Score: 2
Tourette's syndrome gives the sufferrer the uncontrollable urge to curse. The illness is not a joke, it's a serious neurological illness, and can have lasting unfortunate consequences on the sufferrer's ability to be accepted by others.
It's a nice sentiment, but only a small portion of people with Tourette's curse. For most people, it causes them to repeat actions several times, or to touch things near them repeatedly.
I knew a guy in college with Tourette's - he generally never told anyone because they then kept expecting him to launch a blue streak, or simply didn't believe him. He had a heck of a time using a mouse; everytime he was done, he kept grabbing it, and had to make an effort to quit and go back to the keyboard. Kinda like physical stuttering.
--
Evan
-- "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
2.4 is viable for production but requires thought
by
FreeUser
·
· Score: 2
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I must say that I am getting a little bit leary about using the 2.4.x series in production.
I can't say that I blame you (although your reason of "fast releases" not inspiring confidence is IMHO misguided)... some of the 2.4.x kernels have not been good.
I do use 2.4 in production in several environments, but in order to assure you have a stable kernel you need to do more than just dowload the latest and greatest.
Don't run it on a production system day 1. Wait a few days to see if there are any widespread complaints (they come in quickly if they exist), then test it for a week or two on a development/test system before putting it into a production environment.
Use the -ac series rather than the Linus tree. I use both (some machines use xfs, which won't patch against -ac kernels and therefor requires the Linus tree, but everywhere else I stick to Alan Cox's fork), but have found Alan Cox's kernels to be more stable (and more feature rich) on the whole than the Linus tree. YMMV, and if you follow the procedure outlined above either should be adequate.
If it aint broke, don't fix it. Don't upgrade gratuitously just to have the current revision number displayed in your "uname -a" command.
If it is broke (ie security fixes, such as occurred in 2.4.9 and 2.4.13), then you should upgrade if possible. Of course, if you are unlucky enough to be using a Znyx 4 port (tulip) card like me, you'll be stuck running 2.4.3 until the bugs in the driver get fixed (maybe in 2.4.13?), so upgrading even for security purposes isn't always an option. This sort of cock-up is very rare, but, as in this case, it can happen with some drivers.
I too have been irritated with some of the overreaching changes in a kernel series that is supposed to be stable (2.0 and 2.2. were very solid, some 2.4 kernels can be used in critical environments, but others cannot), but have found the above mentioned precuations/practices sufficient to avoid getting burned by the unstable releases which have appeared from time to time (eg 2.4.11), and 2.4 does
have a number of features that make it very, very useful in many production situations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
you call that lazy? i have a cron script that uses rsync to mirror the v2.4 source from kernel.org a few times a day... so when i see a new kernel announcement, i just patch from my local mirror (where, invariably, it has already been downloaded) and recompile.
this might get +1 funny, but i assure you, it is not a joke.
That's an okay hint, but why not try this? I've been doing it since the early 2.2 kernels:
Put all your patches (.gz or.bz2) in/usr/src (or wherever your linux source is)
from/usr/src, type linux/scripts/patch-kernel
... The script will churn away, patching up to whatever latest patch you have...
now enter the linux/ directory and run make oldconfig
that will run through the current.config and prompt you for any new config items
now the standard make dep clean bzImage modules modules_install is in order.
From there, I copy arch/i386/boot/bzImage/bzImage.[kernelver] and update lilo.
I find this is the cleanest and fastest way to patch a kernel. The patch-kernel script will stop if it runs into trouble and you can try to fix it. Be sure to remove any.rej and.orig files before rerunning the patch-kernel script or it will think there's still trouble.
Re:Predictions [OT]
by
sracer9
·
· Score: 4, Funny
Shoot - might as well go for the gusto:
chmod +x/dev/random
/dev/random
Yep. That ought to do it. Hey, why is windows booting?!?
vcr with the Indeo 5.0 codec. vcr for me drops about 1 frame in 2000 - not as good as it should be, but acceptable. And the resulting files are VirtualDub readable, which is good - I haven't found any better way to cut commercials and merge multiple AVI files in Linux.
There's a nice symbiosis there, because the Windows bttv driver generally bluescreens on me within the first minute or two of recording. I don't know what I'd do if I wasn't dual booting.
If you have lm_sensors and i2c 2.6.1, you need to do a "make clean" and a "make depend" in those source trees (after building kernel 2.4.13) to deal with an apparent change in a kernel file name. Other than that those packages work fine with the new kernel (so far...).
It's probably wise to do that every time, but I've been able to get away with "make clean all install" until now.
kernel pre-emption patch
by
DGolden
·
· Score: 5, Informative
If you're on a desktop machine, try the kernel pre-emption patch - it's nice, and will make everything feel more responsive and smooth, since in addition to the normal user-space pre-emptive multitasking, the patch allows a lot of kernel calls to be pre-empted.
Even if you don't want to use the patch, you might want to try renicing X negatively to make it feel a bit snappier.
-- Choice of masters is not freedom.
Re:kernel pre-emption patch
by
be-fan
·
· Score: 2
Does it help?
-- A deep unwavering belief is a sure sign you're missing something...
Well, firstly... should the kernel developers change the whole system so it's slightly more convenient for you?
Secondly... I dunno what your problem with patches is.. but I've been patching for about 9 years, and had very few problems; and those problems are usually due to some foreign patch I applied previously.
And why do you upgrade your kernel every week? That's rediculous. There is no need for it. There are plenty of stable kernels out there you can use.
Re:Kernel 2.4.13 is out..yay....
by
bfree
·
· Score: 2
yep, but if you make ANY change to the kernel you are no longer covered by their QA. The inclusion or exclusion of any part could lead to unpredicatable behaviour even in the components that were already there. They test exact kernels, any change means that while it might be more likely to be good thanks to their QA, you can no longer accept their QA as they didn;t test what you are doing (did they even compile it with the same compiler, asm tools etc.). I'm not saying that this is a bad thing or criticising or anything, I'm just saying that if you are caring about reliability you must be aware of all the variables you introduce (what sort of stress testing did they do on your motherboards chipset let alone changing software)
--
Never underestimate the dark side of the Source
Re:Gotta love Cable Modems and bzip2!
by
odaiwai
·
· Score: 2
Yeah, I'll explain. You can't seem to express yourself without personal abuse and swearing. I wondered if you had some medical condition which made you subject to uncontrollable impulses but it appears you're just like that anyway.
I'm glad, though, because it looks as if, on your first postings to slashdot, you karma has been chopped down to minus a lot.
yours very sincerely,
dave.
ps. I know I'll lose karma for this, I lost it for my first comment, but someone has to inform the lusers what they're doing wrong.
Is the kernel just going through a natural rough-spot or is something different going on?
Well, Linus is really good about pursuing groundgreaking new technologies and trying to add them to the kernel. He is not so good at attaining rock-solid stability...
Alan Cox is the other way, though. Now that Linus is working on the 2.5 series, we can expect:
1: Fewer bugs
2: Fewer new features.
The nvidia drivers are a kernel module and an X library driver, not a kernel patch.
Slightly OT, but what would be handy for people like me who can't code worth shit are utilities like mkpatch.pl in the lm_sensors package that make a custom patch for whatever your current kernel source is.
2.4.12 last week, 2.4.13 this week! Woohoo! Time to compile another one for the workstations and servers! Gotta love Linux, wouldn't see this from Microsoft, ever!
Slashdot Mirror
Does this new kernel include the latest snapshot of ext3?
Ext3 is both distributed in the kernel and as a separate package, and I'm a bit lost : what ext3 code should we use for more reliability? Should the previous kernel be patched with the latest ext3? Does the new kernel include it? Does the latest ext3 cleanly applies to Linux 2.4.13?
I'm lost...
{{.sig}}
"Use the mirrors!"
"Make sure you patch, don't waste bandwith!"
"Damn, there goes my uptime"
"Heh, I'm STILL running Kernel 1.2.1!"
"Does anyone NEED to use the latest kernel? What does it add?"
"Use the latest kernel! Testing is vital!"
"2.4.13? I thought Linux was at 7.2?!"
If I've forgot any, post to this thread. Hell, if you're any of the above postings, post to this thread....
final:
/dev/random fixes
/proc buffer memory sizes right after buf-in-page-cache
- page write-out throttling
- Pete Zaitcev: ymfpci sound driver update (make Civ:CTP happy with it)
- Alan Cox: i2o sync-up
- Andrea Arcangeli: revert broken x86 smp_call_function patch
- me: handle VM write load more gracefully. Merge parts of -aa VM
pre6:
- Stephen Rothwell: APM idle time handling fixes, docbook update, cleanup
- Jeff Garzik: network driver updates
- Greg KH: USB updates
- Al Viro: UFS update, binfmt_misc rewrite.
- Andreas Dilger:
- David Miller: network/sparc updates
pre5:
- Greg KH: usbnet fix
- Johannes Erdfelt: uhci.c bulk queueing fixes
pre4:
- Al Viro: mnt_list init
- Jeff Garzik: network driver update (license tags, tulip driver)
- David Miller: sparc, net updates
- Ben Collins: firewire update
- Gerd Knorr: btaudio/bttv update
- Tim Hockin: MD cleanups
- Greg KH, Petko Manolov: USB updates
- Leonard Zubkoff: DAC960 driver update
pre3:
- Jens Axboe: clean up duplicate unused request list
- Jeff Mahoney: reiserfs endianness finishing touches
- Hugh Dickins: some further swapoff fixes and cleanups
- prepare-for-Alan: move drivers/i2o into drivers/message/i2o
- Leonard Zubkoff: 2TB disk device fixes
- Paul Schroeder: mwave config enable
- Urban Widmark: fix via-rhine double free..
- Tom Rini: PPC fixes
- NIIBE Yutaka: SuperH update
pre2:
- Alan Cox: more merging
- Ben Fennema: UDF module license
- Jeff Mahoney: reiserfs endian safeness
- Chris Mason: reiserfs O_SYNC/fsync performance improvements
- Jean Tourrilhes: wireless extension update
- Joerg Reuter: AX.25 updates
- David Miller: 64-bit DMA interfaces
pre1:
- Trond Myklebust: deadlock checking in lockd server
- Tim Waugh: fix up parport wrong #define
- Christoph Hellwig: i2c update, ext2 cleanup
- Al Viro: fix partition handling sanity check.
- Trond Myklebust: make NFS use SLAB_NOFS, and not play games with PF_MEMALLOC
- Ben Fennema: UDF update
- Alan Cox: continued merging
- Chris Mason: get
Prediction lists (and their addendums)...
Please avoid slashdoting the main server. Here is list of direct links to mirrors. Version 2.4.13, full tarball : [al] - [dz] - [as] - [ad] - [ao] - [ai] - [aq] - [ag] - [ar] - [am] - [aw] - [ac] - [au] - [at] - [az] - [av] - [bs] - [bh] - [bd] - [bb] - [by] - [be] - [bz] - [bj] - [bm] - [bt] - [bo] - [ba] - [bw] - [bv] - [br] - [io] - [bn] - [bg] - [bf] - [bi] - [kh] - [cm] - [ca] - [ic] - [cv] - [ky] - [cf] - [ea] - [td]
{{.sig}}
-sting3r
Doesn't everyone know? Linus is recovering from alcholism. He just started the 12 step program. This week has been really hard for Linus because Alan Cox keeps talking about "putting away a few pints at the pub" (he is English) on the linux kernal mailing list. There have been a few flame wars too between the people working on the vm subsystem. Apparently one is a tea-totler and the other a hard core drinker so Linus is leaning towards using the tea-totler's code but Alan says the hard core drinkers code is better...
I think we all need to try to support Linus and Alan without choosing sides. Just grab the latest kernel of your choice and compile away... Try not to mention free beer on the linux kernel mailing list in the next couple weeks. Think free tea or something similar.
I was excited reading the kernel changelog until I got to this line:
- Trond Myklebust: make NFS use SLAB_NOFS, and not play games with PF_MEMALLOC
I'm sure NFS won't mind using SLAB_NOFS, but it's cruel to prohibit it from playing games with PF_MEMALLOC. NFS has reached the point where playing games with PF_MEMALLOC is the sole respite from the drudgery of its mundane life. None of the other protocols will play with it since the Trivial Pursuit incident of 1998, and it's banned from EQ for excessive Britishing.
Sure, we've all been inconvenienced a little now and again when NFS is playing games with PF_MEMALLOC, but it wasn't that bad, and it brought a glimmer of joy into NFS's otherwise bleak existence. Now NFS will be forced to sit alone in its room playing X Bill all alone until it goes mad and starts initializing remote filesystems at random.
Then where will we be?
Trond Myklebust, I hope you're happy with yourself. What did NFS ever do to you? It's just cruel, and we'll all have to deal with the consequences when people start running NFS on 2.4.13. You should be ashamed.
*telekon
To understand recursion, you must first understand recursion.
Linus is planning on handing 2.4 over to Alan Cox and starting on the 2.5 branch pretty soon... Maybe 2.4.14? Who knows though...
I want to be a slashdot editor too (looks easy):
if(new_kernel_arrived) {
version=X.Y.ZZ
if(slow_week) {
version=X.Y.ZZ-preWW
}
print "Looks like Linux X.Y.ZZ is out. You can get it at the usual place (kernel.org) and the mirrors. Check out the Changelog."
if(CmdrTaco just upgraded to ZZ-1 ||
weekday=tuesday) {
print "This is lame."
} else {
print "Grab. Test. Enjoy"
}
}
Thomas S. Iversen
-sting3r
Patches are simple! If you are using the linus tree see the other reply. If you are using the -ac (alan cox) tree than grab the incremental patches from bzimage.org. To apply the patch go to /usr/src/linux (instead of /usr/src like with the linux patches) and patch away...
If you had provided an example of your pains with patching you would have got a much more detailed reply from somebody. Thoughts to ponder...
I must say that I am getting a little bit leary about using the 2.4.x series in production. The fast releases don't inspire confidence. On one hand people (perhaps rightfully so) say don't use a kernel that is newer than 6 mo. old or you are a beta tester. But of course those older kernels were once bleeding new as well...how to know which to use and which to avoid? That 6 mo. old one might be the right age and yet perfectly horrible. Perhaps what is needed is a kernel stability/security chart that shows how well different kernel versions have "aged". Anyone know of such a beast?
Alan Cox keeps talking about "putting away a few pints at the pub" (he is English) on the linux kernal mailing list.
Well, I guess that proves Alan doesn't read slashdot. He is Welsh. BIG difference. Especially when it comes to things like Rugby.
As for stability, the Linus' releases don't seem to be formally tested anyway. Maybe Linus is more conservative in applying patches before the release, but the recent events (2.4.11 and 2.4.12) show that the kernel may not compile in a common configuration and be released notwithstanding.
A little offtopic but quit correct. It turns out Bill Gates went even further and stated "..you need to look at other peoples code and improve upon it..". Hmmm Kind of sounds like un-american opensource doesn't it?
http://saveie6.com/
Q.(The kernel) 2.4.13 just came out a few days after the 2.4.12 release, which was a broken one. Aren't you worried about the kernel reputation?
Linus:I couldn't care less.
Q.But that's the second time that happens in 2 weeks (2.4.12 was released just 2 days after 2.4.11). Are you sure there is not a problem with the 2.4 branch?
Linus:See my answer to the previous question.
If you are new to installing your own kernel, or you want to get started on kernel programming, see http://www.kernelnewbies.org/ and join them on IRC in #kernelnewbies on the Open Projects Network.
Also helpful to newbies, or to convince you it's worthwhile to help with testing, is my other article Why We Should All Test the New Linux Kernel.
And finally there is the Kernel HOWTO.
If you'd like to program or debug the kernel, I recommend a couple of books:
-- Could you use my software consulting serv
I've read a few of your responses and I must say you've got a pretty negative attitude. Is that really the impression you mean to give us?
-- Could you use my software consulting serv
Yeah, am trolling.
;)
But I still wonder why has FreeBSD had a stable
rw support for NTFS, and the linux kernel is still
lagging...
I mean, can't they copy^H^H^H^Hmodel it after
the BSD code like they have done in some many cases?
To relieve a bit of stress from kernel.org, heres the gzipped tarball...
g z
http://beresm.stu.rpi.edu/~mike/linux-2.4.13.tar.
Monday is a horrible way to spend 1/7 of your life.
Here is a hint to use patches
/usr/src/linux
/usr/src)
1) make sure your kernel source lies in a directory called 'linux'
EG.
2) Now goto the parent directory (eg
3) Now execute the following commond with the downloded patch (be sure you have write permissions in the linux subdirectory)
$ bzip2 -cd | patch -p0
(that is p zero at the end)
Remeber that patches are incremental, so you have to patch from 2.4.10 to 2.4.11, and then to 2.4.12, and not directly with a single patch to 2.4.10
I have personally patched all the kernel relases (from 2.4.1 till 2.4.12) this way, and it worked every time.
If you stil have problems, do get back to me, and I'll help you
This Post was entirely made up of recycled electrons making up recycled signals to generate recycles ASCII to generate t
I agree with you that the quality of /. is decreasing steadily, when you can't even post patches! My god! Well, that is commercial stuff for you. Anyways thank you for the attempt to use this miserable forum, here is a link to the kernel list archive and the post with the patch.
1 09 .3/0599.html
http://www.uwsg.iu.edu/hypermail/linux/kernel/0
Hello Linus? Wake up? How about some reacting on feedback?
Hello CmdrWacko? How about a less intrusive filter?
Moritz
- Gerd Knorr: btaudio/bttv update
@whee. Sounds good.
I just wish that some day I will see a working Linux bttv driver. For some reason, I always drop WAY too many frames with every Linux video capture program I use. (MainActor has been best so far - it only drops a few frames, almost gets perfect video quality, almost keeps A&V in sync and almost saves in format that can be read to Virtualdub in Windows, or any other Win32 editing app).
I need to use Windows programs to do video captures, which technically isn't nice either because the driver really doesn't work perfectly there either - it either works perfectly or not at all, depending on the phase of the moon.
Better multimedia support is always nice. One day, I will be able to use Linux for everything. =)
I would have to agree that you are better off running a stock distribution kernel IF your stock distribution kernel supports what you want, but if you are going to recompile the kernel in any way you are breaking the QA experience. Once you compile any kernel yourself you could be introducing issues and the only way to be sure to be sure is to then test your own kernel before implementing it in a mission critical setting. I personally have always found that the debian kernels are very good becuase they usually spend months in unstable and testing where users run them as is AND compile there own kernels for whatever crazy hardware or software config they need. RH (and as you did, I am just choosing them as an easy example) is not an open company, and their kernels are not tested in such a wide way (debian gets a good run at multiple platforms straight away) and their users are not as "powerful" as debian users (sweeping generalisation that I would say is fair, the % of debian users running self-compiled kernels must be higher than the same % for RH). I think it would be brilliant if we could get all linux distributors (from embedded to RH to Linus) to publish information on the kernels they use and test in one place so that anyone who needs to compile their own kernel can view the experiences of the most relevant people/kernels/settings and get a good idea of the issues they might experience with different setups.
Never underestimate the dark side of the Source
http://www.uwsg.iu.edu/hypermail/linux/kernel/0110 .2/0463.html
Moritz
Actually, there was a patch out the same day, available from all good kernel mirrors.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
It's a nice sentiment, but only a small portion of people with Tourette's curse. For most people, it causes them to repeat actions several times, or to touch things near them repeatedly.
I knew a guy in college with Tourette's - he generally never told anyone because they then kept expecting him to launch a blue streak, or simply didn't believe him. He had a heck of a time using a mouse; everytime he was done, he kept grabbing it, and had to make an effort to quit and go back to the keyboard. Kinda like physical stuttering.
--
Evan
"$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
Hash: SHA1
I must say that I am getting a little bit leary about using the 2.4.x series in production.
I can't say that I blame you (although your reason of "fast releases" not inspiring confidence is IMHO misguided)
I do use 2.4 in production in several environments, but in order to assure you have a stable kernel you need to do more than just dowload the latest and greatest.
I too have been irritated with some of the overreaching changes in a kernel series that is supposed to be stable (2.0 and 2.2. were very solid, some 2.4 kernels can be used in critical environments, but others cannot), but have found the above mentioned precuations/practices sufficient to avoid getting burned by the unstable releases which have appeared from time to time (eg 2.4.11), and 2.4 does
have a number of features that make it very, very useful in many production situations.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE71rXX2TX54E1iXfYRApE3AJwJRSIv1o/69RrrOY5
gJOvzuIKtWwLZ0hH3LFN8q4=
=7OlV
-----END PGP SIGNATURE-----
The Future of Human Evolution: Autonomy
It would be really helpful for lazy people like myself who actually use the links people post on here.
Sticking feathers up your butt does not make you a chicken - Tyler Durden
Here is a hint to use patches
That's an okay hint, but why not try this? I've been doing it since the early 2.2 kernels:
From there, I copy arch/i386/boot/bzImage
I find this is the cleanest and fastest way to patch a kernel. The patch-kernel script will stop if it runs into trouble and you can try to fix it. Be sure to remove any .rej and .orig files before rerunning the patch-kernel script or it will think there's still trouble.
Shoot - might as well go for the gusto:
/dev/random
chmod +x
/dev/random
Yep. That ought to do it. Hey, why is windows booting?!?
No thanks. I don't smoke anymore.
vcr with the Indeo 5.0 codec. vcr for me drops about 1 frame in 2000 - not as good as it should be, but acceptable. And the resulting files are VirtualDub readable, which is good - I haven't found any better way to cut commercials and merge multiple AVI files in Linux.
There's a nice symbiosis there, because the Windows bttv driver generally bluescreens on me within the first minute or two of recording. I don't know what I'd do if I wasn't dual booting.
If you have lm_sensors and i2c 2.6.1, you need to do a "make clean" and a "make depend" in those source trees (after building kernel 2.4.13) to deal with an apparent change in a kernel file name. Other than that those packages work fine with the new kernel (so far ...).
It's probably wise to do that every time, but I've been able to get away with "make clean all install" until now.
If you're on a desktop machine, try the kernel pre-emption patch - it's nice, and will make everything feel more responsive and smooth, since in addition to the normal user-space pre-emptive multitasking, the patch allows a lot of kernel calls to be pre-empted.
Even if you don't want to use the patch, you might want to try renicing X negatively to make it feel a bit snappier.
Choice of masters is not freedom.
Well, firstly... should the kernel developers change the whole system so it's slightly more convenient for you?
Secondly... I dunno what your problem with patches is.. but I've been patching for about 9 years, and had very few problems; and those problems are usually due to some foreign patch I applied previously.
And why do you upgrade your kernel every week? That's rediculous. There is no need for it. There are plenty of stable kernels out there you can use.
yep, but if you make ANY change to the kernel you are no longer covered by their QA. The inclusion or exclusion of any part could lead to unpredicatable behaviour even in the components that were already there. They test exact kernels, any change means that while it might be more likely to be good thanks to their QA, you can no longer accept their QA as they didn;t test what you are doing (did they even compile it with the same compiler, asm tools etc.). I'm not saying that this is a bad thing or criticising or anything, I'm just saying that if you are caring about reliability you must be aware of all the variables you introduce (what sort of stress testing did they do on your motherboards chipset let alone changing software)
Never underestimate the dark side of the Source
Yeah, I'll explain. You can't seem to express yourself without personal abuse and swearing. I wondered if you had some medical condition which made you subject to uncontrollable impulses but it appears you're just like that anyway.
I'm glad, though, because it looks as if, on your first postings to slashdot, you karma has been chopped down to minus a lot.
yours very sincerely,
dave.
ps. I know I'll lose karma for this, I lost it for my first comment, but someone has to inform the lusers what they're doing wrong.
Is the kernel just going through a natural rough-spot or is something different going on?
Well, Linus is really good about pursuing groundgreaking new technologies and trying to add them to the kernel. He is not so good at attaining rock-solid stability...
Alan Cox is the other way, though. Now that Linus is working on the 2.5 series, we can expect:
1: Fewer bugs
2: Fewer new features.
LedgerSMB: Open source Accounting/ERP
Hey UNIX! Ever hear of a patch?
try this from the csh and get:
Hey: no match.
(works better with Got a light?)
LedgerSMB: Open source Accounting/ERP
The nvidia drivers are a kernel module and an X library driver, not a kernel patch.
Slightly OT, but what would be handy for people like me who can't code worth shit are utilities like mkpatch.pl in the lm_sensors package that make a custom patch for whatever your current kernel source is.
2.4.12 last week, 2.4.13 this week! Woohoo! Time to compile another one for the workstations and servers! Gotta love Linux, wouldn't see this from Microsoft, ever!