Slashdot Mirror
Linux 2.4.16 Released
tekniklr writes: "They just released Kernel 2.4.16. Download it
here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount." Update: 11/26 14:14 GMT by T : p.s. Don't forget to look in the mirrors.
Current bandwidth utilization 96.75 Mbit/s
.tar.gz from the slashdot homepage was not a good idea, timothy.
Out of 100mbps..
Linking directly to the
You should have pointed to the mirrors, instead:
Alexis 'jeriqo' BRET
Hahaha. Hello stoopid. Ever heard of backups? Ever take notice of the fact that the quality control on new kernel releases has been more akin to the unstable branch than for the stable branch. Clearly, something is going wrong in the kernel release camp...
I was under the impression that the corruption could be corrected by an fsck, and that while the ext structure was invalid, the data was left intact, that the issue was more with lock files, so an fsck would restore a valid inode table, and the actual data should still be intact, did I misunderstand this? I didn't ever actually use the beast, so I could be wrong...
XML is like violence. If it doesn't solve the problem, use more.
for those who are brave enough to immediately try out fresh kernels that may break one's system so I don't have to - and for those responsible for putting the fix out so quickly.
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
Ouch that must have hurt. 24 gigs. But, you really did have a back up. Everyone knows that you don't do the updates for a while if your system is critical.
Onepoint
if you see me, smile and say hello.
I for one am not touching a new Linux kernel until other people have risked their systems with it and verified that it works fine. I will possibly stick with using an OS with proper quality control procedures (name your own out of FreeBSD, OpenBSD, NetBSD, Windows, etc...)
2^4 = 16
--
The Cap is nigh. Time to get a fresh new account.
I've been following all the kernel releses, and their bugs. I was just curious, what is the best way to tell which kernel is currently the most stable, without jumping immediately to the latest release? Obviously there is no way of knowing if it is, without it being out there for at least a couple of weeks.
I was hoping that kernel.org or somewhere would list what is currently the most stable. I know that from roughly 2.4.5 through to 2.4.11 or so suffer from some sort of swapping/memory leak, I can't remember. This is just from loosely following what has been posted to slashdot in the past few weeks.
Is there any resource tracking for this? What is the most stable of the latest kernels?
dude, the disk checker is called 'fsck', not 'fdisk'. The issue was that it did not save recent filesystem changes to disk before shutting down - no way possible to destroy a whole drive with that, only corrupt the recent files.
Do you still have a job? You don't deserve to.
If this loser was for real, I'd have to agree...I have to think that this is some guy who's either a *BSD nut or sitting in an office in Redmond somewhere.
Either way, let that be a lesson to everyone: don't use new releases for production machines! That doesn't go for just Linux, either.
Stating on Slashdot that I like cheese since 1997.
Now I'll have to wait for patch-2.4.16-to-2.5.0.bz2! Maybe next week...
insecurity asks the wrong question irritation gives the wrong answer
Although I like to be as "leading edge" as everyone else, I've held back on migrating to the 2.4 kernel because of the sorts of things that have been happening to this release.
Although the 2.4 kernel seems to be overall a major step forward from the 2.2 kernel, there have been too many major changes with too little testing to make it a 'stable' kernel yet. It was only a couple of 'mod levels' ago that the VM was entirely rewritten to fix a performance problem that the original 2.4 VM (rewritten from 2.2) introduced. And, the 2.4 kernel (finally having been pronounced 'stable' by the kernel team) is discovered to have a major file corruption problem (now, apparently fixed in the +1 mod).
Not to disparage the kernel team (whom I think have done a wonderful job in giving us the next generation kernel), but I think I'll wait until this 'stable' kernel stabilizes a little more.
"values of beta will give rise to dom!"
It's time to admit that most people don't need the newest kernel, and should just run whatever their favorite distro has properly tested. Unless you enjoy pain and you have no data of consequence, chasing kernel versions is a losing proposition.
We're awaiting x>y (in 2.4.x and 2.2.y).
my other sig is a 500 page novel
I looked at the 2.4.15 and 2.4.16 changelogs but I cannot understand if they fixed whatever problem happens with the disk cache. I often find myself with 2^32-1 Kb of RAM devoted to cache, which has some interesting results.... If you just ignore it goes away after a bit, so it's probably a counter somewhere which underflows. :)
But it's certainly fun, have you ever seen bubblemon turn pink? Or blood-red?
I've had 2.4.14 running for about month. Stable as hell, and that new VM code works an absolute treat keeping my baby zipping along. Give it a whirl. It doesn't work with VMWare yet
For those interested, the preemptable patch against 2.4.16-pre1 also applies cleanly to 2.4.16 final.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
IIRC there was also a nasty bug in a kernel released a couple of weeks back (can't remember if it was the 2.4 or 2.2 series) that broke one distribution's installer.
Now this one can corrupt volumes on umount.
I know the philosophy of 'release early, release often' is held sacred, but surely there are limits?
PS. Sorry I didn't look up the details about the other bug, but I suspect there's no point checking if search is working...
PPS. A slap with a bony kipper to the first person to champion Linux because it only took 2 days after his HDD was corrupted for a fix to be released. This is not something to boast about.
2^4 = 16
And this one is an even number, they are supposed to be stable.
2.2.x --> stable
2.3.x-> development
2.4.odd --> seems to heve unexpected bugs.
2.4.even --> might be stable. who knows?
2.5.0 --> unstable! it had to be. now everyone who said that 2.5.0 would be the last 2.odd stable one will be proven wrong.
Didn't this have to to do with the odd and even numbers of the start trek movies 8-). Or don't you think this is funny after downloading 2.15 just a few hours ago and syncing/fscking like hell now?
Seems that there's always a bug in every new kernel release lately and it either is so major that it warrants switching to a previous kernel lest I suffer catastrophic effects or its minor but it's still something that affects me (such as ntfs or emu10k support).
I somehow missed the 2.4.15 announcement so fortunately I wasn't hit by any problems (I also missed the 2.4.13 release, dunno how), but even though I normally pop in the newest kernel upon release I'm pondering waiting this one out.
STOP MISUSING APOSTROPHES, YOU MORONS!!!
Most people should wait a day or so to grab the latest kernel. As I'm finding (most of the US mirrors at least), 2.4.16 hasn't been mirrored to many of the mirrors yet :-)
Which Apple partition destroying software would that be? I must have missed that one. I am only aware of two.
The iTunes partition destroyer was pulled in something like 24 hours and replaced not long after.
Some years ago there was a problem with certain models of hard drives (Quantums I believe) that didn't handle their write caches well on a scsi reset. That went on for quite a while, but was not an issue with supported Apple hardware, it was some 3rd party drives that had tweaks to enable write behind caching. (The very large Oracle installation on Alphas that I work with had the same problem with them. Unable to resolve it with the vendors we finally scrapped all the disks and replaced them with a different vendor's drives.)
Why is it that every time this happens we /. the hell out of all the home and mirror sites. It seems to me that the first thing to do would be to get it out on as many distributed file sharing systems as posable. I'm getting this onto all the file sharing programs that I use as soon as the DL finishes. It would be nice if everyone did the same.
That's logic - you can wait forever then because of the bugs in 2.4.17 and so on... I hope you get an endorphin overdose from your precious 1.0.0.
--
The Cap is nigh. Time to get a fresh new account.
Not likely. The changes from 2.4.15->2.4.16 were basicly the inode bug, and a driver fix for 8139too.
Now ext3 is in the 'stable'-release, could someone please point me at a document describing
1) how to migrate the filesystems to ext3
2) what flags to set in lilo.conf so that I will be able to have the root-partition in ext3
3) tell what slackware boot-scripts I should change (and how)
4) what packages I should upgrade
I could find it out myself, but I'm convinced someone did all of that already
www.vanheusden.com - home of Multitail, HTTPing, CoffeeSaint, EntropyBroker, rsstail, bsod, listener, nagcon, nagi
At least with FreeBSD I never had to worry when I cvsup'd to the latest sources in the -stable branch and built a new world and kernel. If the Linux kernel people are going to bother to have separately labeled stable and development versions, they should do at least some rudimentary testing before slapping a stable version number on some code and pushing it to the mirrors. Sure, there's no rules to this game...nothing says they have to do that...but they better do it, if they want Linux to ever get anywhere.
And yes, using new stuff on production machines is a bad idea...doesn't change the fact that if Linux ever wants any sort of market respect, showstopper bugs like this can't be allowed to make it into versions that are indicated to be "stable".
"That's Tron. He fights for the Users."
Thank you kernel developers for all your hard work.
Did this patch make it into 2.5 yet? :)
Apple on the other hand released their partition destroying software and let it run rampant for weeks
[FUD ALERT]
... surely you mean less than 24 hours
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
Okay, isn't the convention supposed to be that even-numbered middle-dot releases (2.2, 2.4...) were supposed to be stable with the experimental stuff in odd-numbered (2.1, 2.3...)? While 2.4 in general has many nice things about it, the whole thing feels too much like a "2.3" series for my taste. This umount error is just one more example.
I note that 2.4.x broke my system badly -- it decided (as supplied with both Mandrake 8.1 and RedHat 7.2) that my ATAPI CD-RW was a DMA device, regardless of what I told the BIOS. With ide-scsi loaded over it, mounting caused kernel panic. An extremely helpful person on comp.os.linux.development.system helped me debug it with hdparm. But even building a custom 2.4.13 kernel didn't "solve" the problem (meaning that I have to leave hdparm in place and not use devfs). The kernel README is way, way out of date too. I'd expect this kind of stuff on an odd-numbered series. Perhaps even-numbered kernels need a bit more of a testing stage before release.
Wouldn't it be strange if 2.5 became the more stable one? At this rate, it could happen.
This is one of the reasons I havent switched over to Linux full time lately ... And if I was a novice, I would be real hesitant to switch . It seems like everybody who uses linux has to join to Kernel of the week club. And it's not like these bugs are minor annoyances, some of them have been straight out pain-in-the-ass ones.
I used to run linux steadily a couple of years ago, but ever since I saw development type bugs showing up in 'Stable' releases, I got the hell out of there...
I lost my concept of community when my community lost all concept of me.
Having just joined the x86 camp, I wondered whether running 2.4.15 within User Mode Linux would have been helpful in this case. For that matter, how large is the actual user-base for UML?
To-do List: Receive telemarketing call during a tornado warning. Check.
Kick back, relax, take it easy, and run some automated burn-in tests for the kernel. Releasing code doesn't need to be a strain, or rushed. Remember, you're not doing it for "them". There is no "them", except in Sci-Fi, or paranoid extremist literature. Rushing is a self-inflicted injury. If you need to do self-harm, use a rubber razor-blade or something.
Many of the major shifts in the kernel have been the Right Thing To Do(tm), but those are the times you need to relax -MORE-, not less. Anyone with a penguin as a mascot understands cool. Cool is good. Cool is exactly what that penguin needs. Cool is what YOU need. You can't run at top gear, indefinitely, and expect to be even close to 100% of your ability.
As I recall, we went through something in excess of 120 pre-releases for one early kernel, and other early kernels often went through 20-30 pre-releases. (Oh, for the days of using a-z for the pre-release number! Sometimes the kernel fell off the end of z, and I think that was part of the incentive to switch to numbers.)
When Alan Cox maintained his series, he would often get into the tens, I suspect much for the same reason. A kernel is a complex thing, and the interactions can be hideously obscure. It takes a lot of testing and validating to work even just the worst of these glitches out.
If we reach 2.5.0-pre100, with the understanding that 2.5.1 will be solid enough to do new work, without forever struggling to figure out if a bug is in new code or a cold kipper from 2.4.x, nobody is going to complain. Well, nobody with any sense. The rest we can secretly smuggle into Afghanistan, where nobody'll care what they think.
I'd rather see 2.5.1 for Thanksgiving -NEXT- year, than be unable to do any serious development work for it. A solid foundation and a late, but perfect structure, is a billion times better than a sky-scraper made from twigs and built on straw, even if the sky-scraper is built on time.
You, like anybody, are undoubtably feeling all sorts of pressures - from work, to the family, to the economy, etc. Many of those pressures are bogus. Worrying about job security won't give Transmeta a greater profit. If it itches, scratch it (just be careful what you scratch in public), and if it doesn't, forget about it. You don't need to go creating problems. We have a Government to do that for us.
None of what I've written is new to you. Little, if any, is probably new to anybody. But it's all stuff we need to hear, from time to time. And when I see someone who is no idiot repeatedly making some very basic coding errors over a relatively short time, I think it's not unreasonable to think that there's a guy who is burning themselves out in the hamster wheel of life, and that that guy might benefit from kicking back & kicking the wheel over. Sometimes we go the furthest by making the least effort.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Would remounting the filesystems read-only help? Or would that also trigger the bug?
And, if your filesystems are reiserfs, do you need to worry too, or does this only affect the traditional filesystems.
Say no to software patents.
(for the humor impaired: it's just a joke on the oddness of even kernels with odd release numbers, like 2.4.11 and 2.4.15).
Alright. That's it!!! I'm sick of Apple's reckless behavior -- I finally have to agree that there's only one solution for all this!
there was also a nice slashdot article which links to
;)
IBM which explains in lengthy yet interesting details
what exactly ext3 is and how to implement it:
LINK,/a>
if you read the older articles as well, there is a bit about ReiserFS and devFS.
enjoy
Like I'm going to try this kernel! I used to grab kernel sources nearly right away, but with the latest releases, I'm going to wait until any serious bugs are found.
2.4.13 has been stable for me, and i'm not going to upgrade from it unless there is a bug/security problem that affects me.(or untill i start testing the 2.5.x series)
Shouldn't they also release a 2.5.1 to fix their little screw-up?
I tried Mandrake 8.0...didn't get passed the lilo
stage after all the compile, bzImage and so on
I tried with RH6.2 and failed utterly in getting
so many apps running properly with v2.4.13
i just give up. (Suspect it's the old libraries)
Finally, tried the latest slackware CDs and presto!
Works fantastically, but i must admit it's not
as easy with it's pkgtool instead of rpm
I don't know about other distros, care to share?
Reality is what we taste, smell, see, hear and touch yet we cannot comprehend it...only approximate it.
vmware 3 appears to work on my 2.4.13 machine w/ no problems.
anyone have any compile problems with 2.4.15? after the entire kernel was done compiling and about to create the bzimage it dies with some bootsector 32 bit error messages.
Blah.
Since 99% of Linux users get their kernel from their distributer, who patches it and tests it thoroughly before giving it out, this unstable kernel business has zero with Linux's popularity or lack thereof.
If it ain't broke, you need more software.
I would cry. then I would start the "nasty restore"
if you see me, smile and say hello.
Releasing buggy operating systems without extensive testing sounds like a certain software company we all love to hate. I guess the Linux developers are trying to get the same level of prominance as Microsoft by mimicking them at the deepest level.
You know what? As Linus posted to LKML[1], it doesn't matter if there are a million pre releases, as long as it's a pre release, most people don't download it and run it on their hardware and workloads. Not to mention the fact that Linus doesn't like to maintain kernels and turns them over to other maintainers (Alan and Marcelo) for maintenance.
Hence, bugs don't turn up until after real releases are made.
Anyone who goes out and runs a shiny new kernel on a mission critical machine which was released 20 minutes ago is just asking for trouble. These kernels simply don't get the QA they need to be determined to be stable for a number of days after they're released.
If you want a QA tested kernel, go to RedHat, Suse or any of the other Linux distributions, shell out whatever they charge for bundling it up and use their kernel. When that kernel breaks, go whine to the distribution maintainers. (I've done this personally with RedHat, and found them to be very responsive to bug reports.)
Its either that, or fix it yourself, it's that simple. What, you want something for nothing? That's not how free software works.
Whining about the problem will not fix it. Going out and fixing it yourself, will.
1. See posts about Linus and maintaining stable kernels here and here.
init 1, sync then hit the reset button. Boot with your rescue floppy, (you have one right?) and force a fsck on your partitions. Note: The >/forcefsck will NOT work with reiserfsck. You must run reiserfsck manually.
Rich
ayottesoftware.com
The 2.4 series of kernels have been out for almost a year, which hardly makes them bleeding edge. There are plenty of things that make moving 2.4 compelling.
The last 8 or so kernel releases have been released largely in response to major bugs in crucial kernel areas like virtual memory management. Upgrading to fix these problems seems like a reasonable thing to do if you are crazy enough to run linux on production boxes that do anything besides run DNS, SMTP gateways or some similar purpose.
You can call me a troll if you wish, but the writing is on the wall. Linux is in serious trouble due to feature bloat and releasing too early. I for one am glad that the idea of Linux has motivated the Unix vendors to open up a bit, and has exposed some fresh blood to the advantages of Unix.
Unfortunately, the implementation of Linux is falling apart by trying to do too much.
After typing this I realized that I'm not talking to a troll, but a know-it-all 15 year old. So I'll post under my actual moniker.
Conformity is the jailer of freedom and enemy of growth. -JFK
If you had waited for that on 2.0 vs 2.2, you still wouldn't get to upgrade. I think that it's 2.0.32 and 2.2.20 at the moment.
-- The act of censorship is always worse than whatever is being censored. Always.
That's hardly the point. Anything to keep the blame off those we hold in high regard.
That even number in the middle is supposed to mean *stable*. Sure, there's always going to be a collection of minor bugs that'll get through just about any reasonable level of testing...but come on...this bug was simply huge. Even if you don't feel that it is necessarily the duty of kernel programmers to do extensive testing, I hope you do think they have enough ethics to do *some* testing before kicking a version out the door.
"That's Tron. He fights for the Users."
I know it's not the point, I was just commenting on it. I agree; it's terrible they would put out what is, in the eyes of most power-user types, a stable kernel with so little testing, and something should change in that respect. I was merely pointing out that while it's important, it's not going to have any effect on Linux's popularity as was implied, any more than IIS worms make desktop people switch from Windows.
If it ain't broke, you need more software.
And it works fine. Rock solid.
Exceeding the recommended torque is not recommended.
This is off topic. Feel free to moderate it as such. The parent is on topic, so don't pretend it isn't.
Alternative moderation:
Personally I think 1 is the right level - no need to mod it up, no need to mod it down.
Off-topic is just plain wrong.
</sulk>
Would it work to just have runlevel 6 sync as the last thing init does? There shouldn't be much disk activity after that.
My server
Actually 2.0.39. 2.2.39 won't happen for a long time, methinks.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
0) Make sure you have compiled and installed a patched kernel.
/dev/partiton
1) "shutdown now" or "init 1" as root to go single-user.
2) sync
3) umount all non-busy filesystems (usually only root is busy for most people).
4) sync
5) mount -n -o remount,ro /
(so now the root filesystem is read-only -- this step *is* important).
6) e2fsck -f
(once for each partition, starting with root [/] device, substitute e2fsck with reiserfsck, etc., as necessary -- force a check on each filesystem)
7) sync, hit reset
8) make sure not to ever boot into the buggy kernel again!
STOP . AMERICA . NOW
This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount.
And hopefully it does not introduce another serious one...
You guys beta test and let me know, OK? :P
-Legion
You mean VMWare doesn't work with 2.4.14 yet. Not the other way around. Since VMWare is closed-source (yes there is an open-source shim layer but it is just a shim layer) it is their responsibility to make it work with Linux.
If a regular application breaks with a new kernel release, it is the responsibility of the kernel maintainers. (Oh, except that Java thing from 2.2.18 or so - the JRE was relying on undocumented behavior so too bad.) But VMWare is not a regular application, it is more of a kernel mod.
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
You're absolutely right. Linus and company should regularly make available tarballs and patches of the current progress, encouraging people to download them and to report any bugs before they put out tarballs and patches and expect people to download them!
er, wait...
(Now setting up integration boxes in a compile farm, that's a good idea!)
how to invest, a novice's guide
You can get the patch here.
-Fialar
The fundamental difference between 'Soft and 'nux in this case is the amount of green lining left in the user wallet.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Am I stupid? No. There is no better test of a kernel than a real situation. There never will be. Real Life will always throw up situations that can never be anticipated in the laboratory.
What else do I do? I compile patches. Pre-releases, new releases, ANY releases. I bundle them together, release them on Sourceforge, and watch the counters fly. You say that nobody would run a pre-release? 400-800 people regularly say otherwise, whenever I upload a new FOLK patch. That is as "pre-" as you can get, yet hundreds of people actually use it!
I have used Linux since 0.1, the BSD's since William Jolitz first ported the Berkeley tapes to the Intel, and I can tell you this from first-hand experience -- the BSD releases are damn-near rock solid, BECAUSE the people behind them insist on extensive pre-release cycles. HOWEVER, Linux overtook the BSDs within 2 years of coming out, because Linux development was open.
What I am asking for is to re-merge the two approaches. It's as simple as that. Re-merge? Yes! As I said in the letter, early Linux kernels went through tens, sometimes hundreds, of development itterations, before a release was made.
"Nobody uses pre-release versions"? Methinks you and he have forgotten that ftp.funet.fi was saturated, every pre-release that was made.
Sure, Linus can't QA a complete kernel. I wasn't asking him to. I don't even believe in the entire QA philosophy. Stoccastic testing is comparable to throwing darts in a map, in an effort to find gold. You =MIGHT= be lucky, but the odds are that you will miss the bloody obvious many times more.
To really test a kernel requires exhaustive testing of EVERY function call, under EVERY possible entry condition & state, OR a formal proof, neither of which is terribly practical, whether you're an individual or a distribution manufacturer. Red Hat may be rich, compared to Joe Average, but they still can't afford the 10,000 Ph.D mathematicians they'd need to check a kernel rigorously, in any realistic time-frame.
So, how do you achieve a decent quality? Easy! You run the program in much more compact cycles. By compacting the software life-cycle, and running many many more itterations, you can produce (in much less time, and for much less money) a quality comparable to having a few gigantic life-cycles of enormous cost.
Linus know this. He isn't an idiot. If he has to change the versioning, so that there isn't a "pre-" label, but rather a sub-sub version, to get people to run the kernel, then that's what he should do. There is NO excuse for umount() bugs in a 2.ANYTHING kernel. Development, pre, or otherwise. That kind of bug should not exist, even in the darkest imagination, beyond version 0.1
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Just take a look at the 2.4.16 changelog. There really weren't that many changes to the kernel, and this bug is a fairly troublesome one. I would only sit on 2.4.15 if I had a UPS and I touched the /forcefsck file in root (you should do that now, anyway).
There really is no reason NOT to install the new kernel. You probably haven't racked up much uptime anyway, and not that uptime on 2.4.15 is really worth bragging rights anyway.
Personally, I upgraded when 2.4.16-pre1 came out. I also converted many of my partitions to ext3 (finally). I've been waiting for ext3 to be merged in with stable for a very long time!
Another improvement that wasn't detailed because of the famous "...merge with Alan..." messages in the ChangeLog was that most of LVM is up to date in the stable kernel now. LVM has been at the 1.0.1rc4 release for some time now, and not having to patch my kernel is pretty nice (although, the LVM crew made creating patches quite simple). If you haven't checked out LVM yet, do so. It's quite sweet!
assert(expired(knowledge));
Now, I've got Red Hat 7.2 on my machine, running the 2.4.7-10 kernel that came with the distro. All my partitions are ext3, and that's why I need a pretty recent kernel. Since ext3 was accepted by Linus in his tree, I figured I should upgrade, and indeed, I rushed to upgrade to 2.5.0 (cool, eh!) the minute it was released. Well, I got my file systems down apparently undamaged.
So, when you're saying
I'm happy for any advice I can get! :-)
Employee of Inrupt, Project Release Manager and Community Manager for Solid
Leave RedHat out of that list...I've seen plenty of botched RedHat upgrades, and let's not forget that little problem they seem to have of requiring 2 iterations past each major version before they get it decently solid.
Maybe this is a level of abstraction that *should* be removed?
"That's Tron. He fights for the Users."
I'm not sure where you think I say Nobody uses pre-release versions, I said most.
If you run pre-release kernels on mission-critical servers, why are you complaining about the quality of the so-called release kernels? Obviously you know what you're doing and know enough to not trust a kernel until you can test it under your workload and hardware.
I can't argue with the fact that a full-regression test-suite for the kernel is a good idea. In fact, people are already working on it over at the Linux Test Project.
It will have a big effect on Linux's popularity.
IIS worms do not affect most Windows users directly.
The Kernel corrupting a volume while it gets unmounted affects every user using that kernel.
Linux is already considered a joke in many IT departments. These high-profile Linux bugs only make the joke funnier.
Conformity is the jailer of freedom and enemy of growth. -JFK
And neither do kernel bugs that never get to most Linux users. That was the point.
Oh, you're a troll. Never mind then.
If it ain't broke, you need more software.
It's typical for a slashbot loser to call anyone who thinks for themselves a troll. You are reminiscent of a fourth grader in the schoolyard.
The bug never got to most Linux users because the bug was so trivial it was discovered almost instantly.
Since the kernel coders apparently do no testing beyond trying to make everything compile, there are plenty of other, more subtle bugs waiting.
Large IT departments see Linux as a joke. As the price barriers to purchase commercial Unix systems drop, the incentive to use Linux drops with it. In smaller shops, there is more incentive to use Linux since they are more price-sensitive.
Conformity is the jailer of freedom and enemy of growth. -JFK
It's typical for trolls to think that just because they blindly follow a different groupthink, they "think for themselves."
If it ain't broke, you need more software.
http://saveie6.com/
It is unfortunate that a bug like this slips through and ofcourse it should be avoided if possible. But if the price of avoiding situations like this is that the Linux kernel development slows to a crawl then I'd much rather keep the current system.
Releasing buggy operating systems without extensive testing sounds like a certain software company we all love to hate.
If Microsoft does not test their software, then why was Windows 2000 three years late? They were fixing bugs, bugs discovered from testing.
cpeterso
Now I wait a couple of days (reading Slashdot) before plugging a new kernel into my systems...
Idiot! You must NEVER EVER EVER rely on slashdot for anything..... ever
SLAP!
Please tell me that was sarcasm....... Pleeeeessseeee
Burma?
>>So stop with the "did you do a backup" thing
No way, Back-ups are the only thing that will protect you in the long run. And I'll be the first to tell you that I hate doing them. But I'm happy that I do. Last Febuary my system crashed ( hard drive failure ) . The only way to recover and get back up to speed was to go out and buy a drive and spend the next 11 hours restoring, reconfigurating and a hole buch on other stuff.
I lost 5 days of productivity on that crash ( 7 people entering data all week long ). That was a very costly mistake ( I was backing up weekly on sunday's ) Now I'm daily and using a "somewhat" better back-up platform, now it's only 3 tapes per backup instead of 14 tapes.
if you see me, smile and say hello.
If Microsoft does not test their software, then why was Windows 2000 three years late?
Because that was the length of time marketing felt they needed to run the Windows 2000 advertising campaign to its full impact.
Don't listen to the rumours pal. I have 56k and I cvsup everyday. The more frequently you do it, the less time it takes (to a point). Don't let cvsup scare away from freebsd. Also, you can use CTM, which is supposedly very bandwidth friendly.
Warning: with 2.4.11, 2.4.12, 2.4.14 and 2.4.15 Slashdot carried quite soon some kind of bug reports (don't remember about 2.4.13, sorry). Now there are over 290 comments and there's no "SERIOUS BUG" in them. Maybe 2.4.16 is a "good" kernel?
I'm fat, you're ugly. I can get slimmer, and you?
You should edit /etc/fstab to specify your ext3 partitions as type "auto" rather than ext3. That way, your /etc/fstab is now independent of whether you're running an ext3-enabled kernel, and fsck will know to do log replays (rather than a full fsck) -- however, this latter issue may have been resolved in your distribution, or in later versions of e2fsprogs.
Don't use Rivafb. I was having that problem. I'm not sure if you can use vesafb or not.
1, 1, 2, 3, 5, 8, 13, 21 -- Mathematics is the Language of Nature.
I am using vesafb on both a NVidia TNT2 and a Savage MX card, it works fine.
I'm fat, you're ugly. I can get slimmer, and you?
Going back to FreeBSD...on my home machine, a machine that I used to run Linux for weeks (even months) on end on, I put FreeBSD stable on the machine...and had the machine freeze 3-4 times a day. That was this year. I put Slack on the box and haven't looked back since.
Stating on Slashdot that I like cheese since 1997.