Slashdot Mirror
2.4, The Kernel of Pain
Joshua Drake has written an article for LinuxWorld.com called
The Kernel of Pain.
He seems to think 2.4 is fine for desktop systems but is only now, after a year of release, approaching stability for high-end use. Slashdot has had its own issues with 2.4, so I know where he's coming from. What have your experiences been? Is it still too soon for 2.4?
2.4.x has been OK, albeit not totally stable. I've got 2.4.17 running and I like it quite a bit. As for me, it has probably been benifical since it got me reading a bit of the LKML, and learning more of how to do stuff with my kernel.
--Josh
There are exactly 42,935,718 letter sized sheets in a square mile.
I'll tell ya, I tried the preemptive patches, and all the -ac stuff naturally, and well, the desktop just isn't snappy ... I mean, Windows (follow me here) just feels better. I don't need a force feedback mouse or anything, it just doesn't not show me that it is rendering a window... and that's something that Gnome was doing even on 450 mhz machine.
Also, even with the preemptive patches, I could hold down a key in, say, star office or abi word, and it would stutter! Hold down the arrow key, and it stutters.
These are basic inferace issues that could use some due attention before Linux is ever ready for the desktop.
I really like using USB, and I like not having to use ALSA for my sound card (not that I have anything against ALSA).
After playing around with debian the other day and seeing all of my hardware that WON'T WORK with the 2.2 series it has basically come to my attention that I am all for the 2.4 series.
Linux is a continously developing system, whether it be the kernel, distribution, or software. Linux will always be "In Developement". Which is perfect for linux.
So yeah ... if you don't like 2.4 ... go back to 2.2 ... yeah ... thought so :-P
Ignore the "p2p is theft" trolls, they're just uninformed
I've had a lot of poor swap perfromance on my 2.4.x kernel compared to my 2.2.x kernel. On my dual processor machine with 1G ram I haven't had problems, but then I use it so lightly it has never had to swap anything! On anything where normal load causes some swap out, I get mighty slow response when I go to do something after some idle time: type, change input focus in X, etc.
I imagine I could suss it out, but it isn't a big issue for me. I'm told later 2.4.x kernels fix this (I'm running 2.4.9).
Anecdotal, I know. For myself, I'd run 2.2.x still on production systems. But I don't run any big production systems...
We've got a 2.4.7 kernel with RTAI real-time extentions for a house automation system running for several months now without ANY problem. Besides the house automation stuff, this box also acts as a mail,web,ftp,file,whatever server. 2.4 unstanble? I don't think so!
And this guy appears to be talking about only x86 machines. My lab has had a horrible time with 2.4 on Alphas. In fact, we've moved back to 2.2.18 on some macines. (2.2.20 for Alpha didn't compile properly, and I didn't want to mess with it -- anyone know if which 2.2 kernel is best for number-crunching Alphas right now?). Oh, the pain. The lost time. "Kernel of Pain" is a fine description of our 2.4 experience on Alphas.
-Paul Komarek
I've been using linux for nearly 7 years and the 2.4 tree has been pretty buggy for a stable kernel. 2.2 was always pretty rock solid for me, and 2.4 was quite unuseable for me until after 2.4.7 when SCSI emulation and loopback filesystems started working for me again. I think 2.4 was a bit rushed, but I'm glad it was, I will start experimenting with the unstable trees now, its much more exciting!
Erik
+= E
Throwdini the Great thinks:
Cliffom could have saved 78 characters by simply writing: "Me, too."
*rimshot*
What have your experiences been?
;-)
Well:
8:33pm up 45 days, 5:49,
Shameful I know, but I had to move city before that I had 6 months. Should had a UPS
This is pretty much a desktop/development box running postgres, JBoss, tomcat, apache, JBuilder and (occasionally) kylix. No problems so far, touch wood.
I also used to work at the comp-sci department of a university were we had 40 boxes in the linux lab, no real problems except they were running ext2 so only the occasional manual fsck. Now the maclab, that is another story (OS9 not OSX).
He who defends everything, defends nothing. -- Fredrick The Great
not for a productive use server...
Freudian slip? I have to agree, though, the biggest productivity killer I have is SameGnome...
They that would sacrifice their
As a sysadmin, I have to state that the 2.4 kernels have ruined whatever reputation that existed before about the 2.2n series kernels being stable. Atleast in the 2.0 and the 2.2 series, you had islands of stability where really careful distributions could pick a kernel version as their default kernel. One of the main problems with Debian not finalizing a 2.4 kernel has been due to the fact that there hasnt been an island of stability so far in the 2.4 series.
And I've been waiting a long time now. The early 2.4 series didnt really work out on my SMP servers. The 2.4.6 onwards kernels broke Tulip support for me. Then came the VM switch. Then just when I decide, ok, 2.4.16 seems stable enough, we have the OOM problem. And I also keep hearing statements being made about the new VM being more friendly to desktop systems than servers.....
Now if only 2.2 offered iptables.....
There is no such thing as luck. Luck is nothing but an absence of bad luck.
This guy is complaining that he had troubles on a production server with Mandrake8.1 and its kernel 2.4.
But Mandrake 8.1 ships with both kernel 2.4 and 2.2.
The idea behind it is: if you need all the fancy stuff use 2.4 but if you want stability use 2.2.
So using 2.4 on a server and then complaining that it isn't stable enough is silly IMHO.
That said I agree that 2.4 has been slow to stabilize (VM mess apparently caused by communications problems between Linus and Rick Van Riel).
Oh yeah, and the machine would crash randomly and lose data. We were using ext3, so the file system was (supposedly) still consistant, but whatever was being worked on would be lost.
Ultimately, we upgraded the kernel to 2.4.17, and the problems have been fixed. But the "even number == stable reliable" rule failed us that time.
Since then, I've read that "the entire VM system in 2.4 was replaced around 2.4.10". This really scares me. I hope that Linus and Alan Cox have learned to manage things better now. If not, someone else will have to pick up the slack (maybe RedHat) and manage a stable kernel.
Cryptnotic
My other first post is car post.
First, he replaces a known working server with something new. Then he keeps on adding bleeding edge newest kernel upon newest kernel to this box (following his narrative, it sounds as if he installed new kernels upon release).
Second, nowhere does he mention why he needed a 2.4 kernel in the first place. In fact, he mentions how he finally decided to downgrade to 2.2.
So, in conclusion: He upgrades to the bleeding edge without proper need, and when trouble ensues, instead of rolling back, he continues upgrading. Tell me why this guy is not a hopelessly incompetent sysadmin who's trying to blame Linux for his shortcomings?
Hell, even I as a home user waited until 2.4.17 before upgrading my main box from 2.2.19. If I can perceive the weaknesses of the 2.4 kernel, why can't a professional do so?
Mart"I know I will be modded down for this": where's the option '-1, Asking for it'?
We're running the Red Hat 2.4.9-13 kernel on several SMP database servers and they have been perfect (not rebooted since 'rpm -U' of the new kernel) for several weeks. Before that, we were running 2.4.7-something from Red Hat and they were the same -- ran straight from the day we installed the kernel to the day we updated without needing to be restarted.
On my desktop machine, I've taken more risks (installed pretty much every official 2.4.x-linus release as they have come out) and some have been good, while others have been total dogs.
I'm running 2.4.17 right now. It seems okay; I've only had a freeze-up once over the last couple of weeks, though it was a total hard freeze (i.e. no ping, no magic SysRq, no nothing), which I haven't had in Linux for several years.
The obvious issue is VM; if you keep lots of memory (768M, or preferably 1.0G+) in your system, things to much more smoothly, though MP3 playback still skips a little.
Right now, I'd prefer some work on the RAID and IDE performance issues. One or two of the 2.4 series have had disk performance 100%+ better than the current 2.4 kernels. Why? I'd like to get the disk I/O back to reasonable levels.
STOP . AMERICA . NOW
Yeah, but Windows doesn't have kernels like "Greased-Turkey," so there, nyah. Who wants to run "kernel32?" Boooooring!
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
Oke, so we're talking:
/not proven/.
1. Mandrake 8.0, *the* desktop distribution _and_ a dot zero release.
2. A kernel lt/eq 2.4.6 with known problems and definetaly
3. A large-scale *production* server.
Somebody hit this guy with a cluestick! Please?
Thimo
Avoid the Gates of Hell. Use Linux!
Your formatting reminds me of this post from alt.(somethingorother).metallica in '93 or so. It looked so poetic that I saved it. Check it out:
Well about two months ago
I found Garage Days Re-revisited
on tape in a used record shop
for about ten dollars
I came back two weeks later and
found Kill 'Em All with the two extra
songs-on tape for 3.50
I came back last week and found a rare
Soundgarden CD (Badmotorfinger w/the
Somm EP) for around 15.00
SO, hope is alive, those albums are still
floating around in some form
"If he thinks he can hide and run from the United States and our allies, he's sorely mistaken." Bush on bin Laden
I run Linux 2.4.16-pre1 on both my desktop machine and a server and have never had any probs (except for the odd system slowdown due to ext3 sync()`ing, but winME was much worse.) Ironicly, I run windows XP as a NAT server on my dialup box, because it also has to run some windows-only software that doesnt like wine. It took me HOURS to get the bloody thing setup and working, and I spent another 3 hours downloading all the patches, plus a virus scanner (AVG... very good- www.grisoft.com), ZoneAlarm, and then had to wrestle with XP's bullshit "User friendly" configuration while it told me that everything I did wasn't a good idea. After all that, XP's built in 'firewall' (which is on even though I turned it off) conflicts with ZoneAlarm, and constantly locks down all internet traffic, requiring a reboot. It also runs like a sloth with 520mb ram on a 1.5 ghz p4. And to top it all off, XP constantly refuses to connect to my ISP... which are running "Incompatible" windows2000 servers.
There was a bad period where the Soundblaster Live driver (particularly mixer settings) was broken. That lasted through at least three kernel releases. There was a worse period where the VM had fits, and where performance degraded way too rapidly if the system had to swap. That lasted at least six kernel releases. There were at least one or two releases where I discovered that Alan Cox's (usually more bleeding edge) tree was being better behaved.
Of course, whenever I'm playing around with this stuff I don't delete my "last known good" kernel, so if after a couple hours or a couple days I noticed a problem, I just booted back to what worked. The default (albeit heavily patched) Red Hat kernels were good, so "last known good" always existed for me.
To summarize: this hasn't been a source of inconvenience for me, but it has been one of vicarious embarrassment. I've only been using Linux since 2.0.somehighnumber, but this is the worst mess I've seen the "stable" kernel tree go through in that time. Don't get me wrong, I've experienced system-crashing bugs (a tulip driver that freaked at some tulip chipset clones, some really bad OOM behavior a couple years ago) before, and pragmatically I guess that's worse... but those problems were always fixed fast enough that the patches predated my bug reports. Watching even the top kernel developers seem to flounder for months over bugs in a core part of the OS like the virtual memory system just sucked.
I have a kernel 2.4.16 + preempt patch.
It is the most stable config I ever had using this kernel generation.
I explain :
Before, with kernel 2.2.1x I only had "some" preformance issues (mostly disk access related) and what I thought were apm problems (this is a laptop).
Since I have been using kernel 2.4 I happened to have good times but mostly bad surprises.
pcmcia (I use the pcmcia-cs package) is not quite plug'n play (system even hanged once) but symptoms vary from version to version.
So, the big PROS is that, yes, I boot a much quicker way.
The CONS is that since the 2.4.6/7, I bitterly regret upgrading this kernel since the functionality I gained was compensated by the new bugs.
Note that I don't mention the APM because besides the Windowmaker apm applet, I don't even imagine using the suspend/resume on this laptop.
BTW, when I see the difference with and without the preempt kernel, I wonder why this is not implemented in the official tree (radio button : "server or desktop" ?).
Trolling using another account since 2005.
Interesting what the author was saying about 2.2 versus 2.4 in terms of stability. We have 3 Linux machines which are used quite heavily here at the moment:
1) A dual PIII-800/Intel 440GX/512MB ECC RAM based server, with a Mylex AcceleRAID 170 adapter, an Adaptec AIC-7896 SCSI adapter, Intel EtherExpress Pro 10/100, and an external 450GB SCSI RAID-5. This box is used for NFS/Samba file serving and an e-mail server for around 100 users.
It runs kernel 2.2.17
2) A dual PIII-800/VIA 133 server/1GB PC-133 RAM server, with an Initio A100U2W SCSI adapter, Intel EtherExpress 10/100 and 70GB of external SCSI RAID 1/0. It runs MySQL, Apache, and a collection of internally developed Perl, C and Java server apps, on kernel 2.4.3
3) A dual PIII-450/Intel 440BX/512MB PC-100 RAM server, with an Adaptec 2940UW adapter, Intel EtherExpress 10/100 and 170GB of external SCSI RAID-5. It is used as a development system, and runs MySQL, Apache, and assorted Perl, C and Java apps, on kernel 2.4.1.
Systems 2 and 3 have both been up for 197 days as I type this, and would have been up for over 250 days had we not needed to power them down to move them to a new server room.
System 1 (with the 2.2.17 kernel) has never stayed up for more than 55 days. It hard crashes without anything informative being written to the logs, and obviously required the reset button to be pressed.
Has anyone got any ideas, given the hardware configs and software running on these machines why 2.2 is so horrendous, yet 2.4 so stable?
Is Linux 2.4 unstable? It depends on your perspective and luck. I'm running 2.4.8 and 2.2.19 (Debian potato) on my systems successfully; 2.8.9 thru .12 have been glitchy for me, especially when it comes to running big jobs that stress the VM. Haven't tried anything above .12 yet; I'm waiting for .18. My old cluster runs 2.2 simply because I have no reason to change.
Your mileage, of course, may vary.
I do think that 2.4 has been managed poorly. People complain that Microsoft beta-tests software on thier customers -- yet that is precisely what the kernel team does to Linux users when they release a "stable" kernel with an entirely new VM. A couple months' (weeks'?) testing on developer workstations is not sufficient for an "enterprise" class operating system. Anyone who understands the least bit about complex systems knows that you don't replace critical architecture (the VM) without jeopardizing stability.
It's all water under the bridge now; I hope Linus and company have learned from the 2.4 battles. If 2.6 has the same kinds of problems and controversies... well, I prefer not to think about it. For my part, I plan to beat 2.5 beta kernels to death, to help the testing along. Testing is as important as kernel hacking -- even if it isn't as sexy.
All about me
as an electronics student, i wouldn't dare criticizing the kernel programmers: if you ever tried to program a kernel from scratch, you'd know what a damn job that is...
for all of you interested, there's a great book over at o'reillys, understanding the linux kernel. it covers the changes from the 2.2 to 2.4 version and explains into every very detail the structures behind all the features you enjoy in you everyday linux life ;-)
cu, mephinet
Use the source, Luke!
Having said that, there are some serious issues with 2.4 on some 8-way 8GB machines that I manage. They have been running 2.4.13-ac7 since November, because that is the last kernel that is usable for me (-ac11 would probably be ok). Newer kernels have terrible behavior under the intense IO load these machines go through. They get 14-30 days of uptime, and then hang or get resource starved or something and have to be rebooted.
I think part of the issue is that there simply aren't that many people running 8-way boxes, so bugs aren't found as easy, this is of course on top of having 8-way SMP being much more complex than a defacto single user, single processor desktop machine. To make it even worse, the machines are pushed hard. They move around GBs of data every day, and often will run for extended periods with loads over 25.
Of course, it is still mostly ok. While the machines are working they mostly work fine. Of course 20 days of uptime is totally unacceptable. I have an alpha running Tru64 pushing 300 days of uptime, and the last time it was down was due to a drive failure, not an OS problem.
My only remaining issue with Linux on "small" machines is an oscillation problem in IO. Data will fill up all available memory before being written to disk, and then everything from memory will be written out, and then memory fills up again before anything new is written to disk. This is a bit inefficient, and the machine's responsiveness at the memory-full part of the cycle is poor.
What are my options though? I guess I could try FreeBSD, but a bit of lurking on their lists and forums reveals plenty of problems there, too. Do I switch and hope things get better, or wait out 2.4 and hope it comes around soon? Aside from a few nasty bugs in some releases, pretty much each successive 2.4 kernel has been better than the previous one, at least on small systems.
Several years ago I was having a hard lockup problem with Tru64 (Digital Unix, at the time) and that was very scary. It took time to get the problem escalated to the OS engineers, instead of just sending an e-mail to lkm. Even then I could only hope that the issue was being addressed, but I had no way to know if anybody was doing anything about it or not. (Turned out to be an bug in the NFS server that would cause the machine to lockup when serving to AIX.) For all of its problems though, it is extremely reassuring for me to be able to monitor the development process of Linux through the linux-kernel-mailing list, and other specialized lists. If I feel that people aren't aware of some problem I am experiencing, I can raise the issue. I am not in the dark about what is happening, and what fixes are being made. I know what changes have gone into each kernel update, so I know if there is a chance of it fixing my problems.
He seems to think 2.4 is fine for desktop systems but is only now, after a year of release, approaching stability for high-end use.
I don't get it. I use Linux on the desktop. I have to admit that I don't run linux on my main machine. This is only because I've taken my second hard drive out, and put it back into an older machine. [sorry, wine doesn't like Red Alert 2]
Before I did this though, I ran 2.4 kernels on my desktop. None of the problems I may have had were with the kernel. Problems I had were mainly with certain applications and when I pushed them to their limits. Pan, for instance, crashed a lot on me, but that was because I was downloading gigs per day. A simple Pan upgrade fixed that.
In my humble opinion, 2.4 is prime for the desktop. Linux is more than ready for the desktop. I know he says it's ready for the desktop, but not ready for high end systems. To me 'high-end' is what you ask of a computer. I've got a 333MHZ running Red Hat 7.2. The computer is running webmin, proftpd, apache, and many mail daemons. I must also mention that SETI runs 24/7, it only has 64 MB of RAM. It never goes down, it never 'crashes', and is up as long as there is power running to it.
So... it's ready for the desktop? Sure, 2.4.x is prime. All the drivers I've needed supported are there. Even my >$50 webcam.
The question of 'desktop' use isn't with the kernel though. Desktop users don't patch or compile the kernel... how many times do they do it in *indows or MacOS X? They install complete distributions. IMHO, again, the only thing that keeps Linux off the desktop is easy program install. RPM has killed itself with dependencies, and apt-get is console based. Apt-get is waaay better, and it has worked wonders on my Red Hat machine [apt-rpm]. The problem is not being able to download an app and install it like *indows.
Solve this and I will sit outside my local computer store and hand out CDs. I don't know about high end systems, but dammit!, desktop users are ready... format that *indows crap and get a real OS!
Gimme a good apt-get gui... or have the system run apt-get in the background solving dependencies when needed... my g'ma will have it.
BTW, I just saw a guy on TV and his name is... get this: Joe Householder
Get your Unix fortune now!
Call me precautious but I usually test out everything, including the kernel by running it on clients and development servers before putting it on any mission critical servers. As much as I like the improvements I didn't find it stable enough for heavy usage until recently so I just never upgraded any major servers to use it until now. No pain at all because as an admin I did my job. Anyway it always did pretty good for me unless I put it on a total crap box (of which I have many) and stressed it a lot (which I tend to do) so I don't think it had that big of problems to begin with. In reality Netscape was the only program I found that caused consistant problems with the 2.4 kernels. From time to time programs like Xine would also but that was usually when I did something stupid like trying to run several movies at once on a low end machine with barely enough RAM to breath. My development web servers don't get a lot of traffic but they do some heavy data processing and I never noticed any problem there.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
And in other news, the Associated Press is reporting that Linus Torvalds has sent out a memo to the core Linux development team telling them to make stability their "highest priority". In his memo he called this strategy "Trustworthy Computing", saying that it should not be the case that people have to use previous versions of the OS in order to find a stable working environment.
Woody's working fine for me, I've been pulling down 2.4.x kernels
as they've been made available.
You're absolutely right, though, Woody base install still
uses 2.2.19(?), the 2.4.x kernels are available options.
I still keep 2.2.19 in lilo as an alternative in case I run into
any problems, but once I got all the module configs fixed
for 2.4, there's been no need to use it.
Bob-
The Ludwig von Mises Institute. The reasoning individuals economics
jakob@unthought ~> uptime
9:21am up 181 days, 13:25, 3 users, load average: 3.57, 3.33, 2.79
jakob@unthought ~> uname -a
Linux unthought.net 2.4.0-test4 #1 SMP Fri Jul 14 01:56:30 CEST 2000 i686 unknown
I suppose that ain't too bad. Other than that, with real 2.4 kernels, on UP and SMP systems, I've been fairly satisfied.
There was a RAID bug (RAID-1) in 2.4.9 or there about, which they forgot in the article. I think, except for the fs/raid corruption problems (which are horrible when they happen), that the 2.4 kernel has been a nice experience.
Think back for a moment: How would you like *not* to have iptables, reiser, proper software RAID, etc. etc. etc.
I think I would miss 2.4 if I went back, although the fs/raid corruption bugs made me "almost" do that.
I notice that a few people mention they don't have problems with 2.4. I find that true based on certain conditions.
For home use, I really don't find a lot of problem with 2.4 except minor driver problems. But at work, things are very different. I run a few high load critical servers at work that are still on 2.2, the lab attempt to upgrade 2.4 (at early stage) failed because of lock up and performance issues (yes, some due to VM)
It was till recently, I tried again with 2.4.16 that I am getting some reasonable results with the 2.4 series. For your information, performance are about the same on 2.4 with my application, I cannot confirm high load stability issue yet as I need more time to test. But initial results tells me 2.4.17 are resonably stable, only one lockup so far (for two weeks).
The problem is the "release" level kernels usually aren't really ready for release. Most hard-core linux people tend to know this, but those that are coming in from elsewhere expect that a "release" product is, well, ready for release... maybe with some hesitation on a .1, but by .2 or .3 the thing should be good.
Maybe holding on to "beta" status for a little longer, or having a "unstable", "testing" and "stable" like debian. So that when someone wants the latest stable kernel, they don't end up with something the kernel guys think is stable... till they release the next "stable" version a day later...
- running a distribution with bad compatiblity between libs,tools,compilers and the kernel (i.e. Redhat 7.0)
- upgradings the kernel without regard to upgrading libs,tools,compilers, etc.
- upgrading for the purpose of upgrading's sake - no real reason.
- Not that much knowledge of what's really goining on in their machine.
I have set-up enterprise level production servers on Linux for many years and haven't ever <knock on wood - my head > had stability problems. I know of 4 Servers runnig at my most recent employer that have been running 2.4.x Kernels since they were put into service and have never crashed or even hiccuped - over 2 years ago. They are running Oracle, MySQL, Apache with multiple modules, Perl Apps, Samba and NFS filesystems, and other stuff I can't think of right now. Why haven't they had problems -- Good STABLE distribution
- conservative upgrades (2.4.1 to 2.4.5 to 2.4.12)
- running in test before placed in production
Eveyone seems to think that with a kernel from the "stable" tree you shouldn't have any problems whatsoever. Keeps in mind that the kernel alone doesn't make the OS the user space tools are also part of it. Therfore running a kernel in the 2.4.x tree and bleeding edge alpha versions of user space software and server daemons != a stable system necessarily. How many people are running a version of Apache in the 1.3.x tree? Well if you are that's a development tree and not necessariliy stable. Yes there are stable versions, but you must test! Also remember to separate device drivers from the kernel. Just because many are distributed with the kernel doesn't make them part of it.The other problem I've noticed that started with the 2.4.x tree was the 'ac' or Alan Cox branch. Don't get me wrong I think Alan has contributed meny good thing to the kernel; however, I do think Alan has gotten to feeling a little to self-important to Linux's success. Also keep in mind that he works for Red Hat now and everything I've seen with Red Hat's politics is they want to "control" Linux. So, I say stay away from any '-ac' kernel. But that's just my opinion and I could be wrong.
As far as the 'new' VM being put into the 2.4.x kernel - I don't completely agree or disagree with it being done when it was but there were various reason to do it then. I was holding up some important things and the kernels wasn't ready for a 2.5.x tree yet. It was a hard decision on Linus's part but not one I'm going to second guess.
Don't get me wrong. you can get a stable machine with just about any distribution; howver, I have found, from experience, that Slackware has a track record for being the most stable 'out-of-the-box'.
Also keep in mind that with Winblows you'd be rebooting every 14 to 30 days. Even with 2000 and XP.
On the other hand I still have one box at home still running 1.3.72 with an uptime of over 3 years. It's running as my router and is my experiment on just how long with a Linux box run without crashing.
Some people have already mentioned this in passing, but I think its an important point to make.
I've found that the kernel is pretty stable for me. I use my system mostly for code development and as a server for files and web pages.
I find that the kernel itself is pretty stable, although as the article says, it does seem less stable that 2.2 series did. But even so it's not bad for the use I've made of it.
The old style applications are also very good. The command line tools, and the development tools (gcc etc) are all totally solid and are why linux gained it's early reputation for reliability.
*BUT* I find that much _new_ software. Both gnome, kde and others GUI software to be terribly unreliable. Say what you like about microsoft outlook but it rarely just crashes. On the other hand, every "modern" mail program I've used on linux tends to end with a crash eventually. And it's not just mail programs. I find that many of the programs I would use tend to crash quite a lot. Not all the time, but just once is too much.
It's rather sad in my opinion that such a solid base of reliable code is being let down by the stability of some of the more modern software. Frankly it doesn't matter how stable the kernel is if the programs that run on it crash.
This isn't indended to be a complaint, and I realise that before applications can be considered reliable the kernel needs to be, but it does concern me that the overall reliability of linux systems does seem to be going downwards.
Sig is taking a break!
For example, why do you put USB support into the kernel? Cant this be moved to a driver or external module or something? The same applies for file systems etc.
Uh... You can compile USB and many other parts as a module.
What I find truley ironic about the 2.4 series is that, before it was released, there was a big delay because they wanted it to be perfect. It was held up and held up, thinking that the fate of 2.4 was the fate of Linux, it was going to be the kernel that everyone was watching.
What do we get? Stability problems, kernels with DO NOT USE warnings, massive changes to the core of the OS, the list goes on. All on what was supposed to be the flawless kernel that proved the worth of Linux to the masses.
my sig's at the bottom of the page.
Didn't say all my programs are crashing, or ever that they crash often. I said that they are not as reliable as they should be.
There are some great, reliable programs out there too, but I just get the feeling that quality of many of the *applications* is going down recently. And if the applications are not reliable, then it probably doesn't matter too much if the kernel crashes every few months...
Sig is taking a break!
No, that's wrong. Red Hat, for instance, which is generally designed to be an industrial-strength server distribution, applies something like 200 patches to Linus's kernel. Red Hat knows that its customers expect a solid, stable server operating system, so they will do what it takes to build one. Mandrake, on the other hand, knows that its customers are mostly desktop users, so it has other priorities (providing games, etc.) than testing and patching the kernel.
I agree with you re: a small, stable kernel with memory and processor management, but when you think about it, USB hardware is very common. I bought my box 3 years ago and it has USB (even though I have never used it).
This is my opinion:
optional hardware, devices, peripherals -> modules
hardware found on most x86 machines -> built in
I have used 2.4.* since the very beginning on my firewall (to get IP-tables). arch/i386/kernel/bluesmoke.c is broken for my IBM PC Server, Dual P90 since 2.4.5 or something but just replacing with the old version works fine.
/dev/hda and then shutting down the hard drive). I had problems with this in 2.2 and early 2.4 (perhaps 2.4.10) because for some reason double amount of RAM was required. Allocating 20 Mb of RAMdisk cost me 20 Mb of ram, but when I filled the filesystem another 20 Mb was used. sync did not help. Unmounting and remounting helped... but it was my root filesystem and no good solution.
;)
I am running the entire system in RAM (loading a 96 Mb almost empty ramdisk from floppy, populating the filesystem via rcS from
Conclusion:
If you run old hardware, puts little load on it, and patches the kernel before you compile it you will be quite satisfied with 2.4.*
Oh, btw. I run 2.4.* on a laptop (with more than enough RAM). 2.4.* has been stable and satisfactory since the first release, for me.
Now, what problems am I talking about? The latest 2.4 kernels still have compilation problems in some drivers (2.4.17 has problems in USB, 2.4.18pre4 has problems in one of the sound drivers). Important and mature packages like MOSIX require patching the kernel and aren't integrated into the kernel. Many hardware setups require recompiling the kernel and experimenting endlessly. Every time you recompile the kernel, you need to recompile some kernel modules. Dependencies and recompilation aren't working correctly--some things don't recompile when they should, and lots of things recompile over and over and over again. The kernel itself is a 30Mbyte download. And the list of problems goes on and on.
People seem to have gotten used to it and think there is nothing wrong. The kernel hackers keep telling us that C and make are just great tools for building kernels. But as a user and sometime driver hacker, I think the kernel is falling apart under its own weight. This is not a system I can recommend to non-technical users--commercial distributions can't cover all the possible kernel configurations (even with fully modularized kernels), and recompilation is out of the question for many users. What is needed?
I think, ultimately, if the kernel wants to survive and be able to keep up with the world, it needs some kind of more flexible dynamic binding of functions at runtime. It also must allow people to start writing kernel components in languages other than C, foremost C++. No, C++ isn't the epitome of good language design, and, yes, people can write even more horrible code in C++ than in C, but C++ can really help with safety, security, resource management, and modularity.
If those things don't happen, I think the Linux kernel will simply fall so far behind that it will get replaced by something else. And that would be a shame because the Linux kernel actually does have a lot of useful functionality, and once compiled and configured, works very well.
I think kernel 2.4 has what I always dreamt of on my linux firewall: Stateful firewalling and NAT. It is great for building inexpensive firewalls that can be as good as those costing grands.
Also, the VM system is much improved, when compared to the 2.2.
The only thing I think was a little too risky was replacing the entire VM (originally built by Rik van Riel) with a new one, by Andrea Arcangeli. I believe such dratic changes should be reserved for developmente kernels. But the important thing is that now it's working wonderfully, and is much improved.
I don't think 2.4. should be called the Kernel of Pain. We're what, in 2.4.17 ? Remember 2.2.17 or 2.0.17 ? Heck, 2.0 had DoS bugs till release 2.0.35.
I am running 2.4 on some production boxes. They're behaving fine and very stable, thank you, and I think 2.4 is ready for production.
-
Roses are #FF0000, Violets are #0000FF, find / -name '*base*' |xargs chown -R us && mv zig greatjustice
Linux isnt ready for the -
Server?
Wait a minute...
The people reporting problems are talking about heavily loaded systems usually on SMP systems. This is the stuff 2.4 promised to deliver, and while it's delivered them, it's delivered unstable stuff.
But this is the way of open source - it's obvious this stuff wasn't tested to destruction while still in the 2.3 phase, or we wouldn't be seeing this stuff. However distribution developers should be doing this testing before releasing a new OS, and they're obviously not doing so.
Matt. Want XML + Apache + Stylesheets? Get AxKit.
The RAID-0 in 2.4 has so far been between -18% and 0% faster over the raw hdd speeds for those same md partitions on my system. The 2.2 kernels were giving me about 30% speed increase.
PS, notice thats negative 18%, I say negative 18% faster, since RAID-0 is supposed to give a speed increase above all else.
War crimes, torture, lies, illegal spying... Would someone give Bush a blowjob, already, so he can be impeached?
I'm happily running Debian stable (potato) with a 2.2.18pre21 kernel. I'm only vaguely aware that some 2.4 kernel features could be nice to have. The main attraction is iptables, which of course wouldn't be any use on my desktop and laptop machines.
I'm about to play around with 2.4.17 on my current firewall server using Adrian Bunk's 2.4 kernel package, for that very reason. Would it be wiser to hold off? ipchains does an adequate job under 2.2, after all, and I'm perfectly happy with 2.2 on the desktop machines until Woody (the Debian candidate in testing) is moved to stable, by which time all the major gotchas will have been ironed out.
Dude, where's my stability?
Where's your stability dude?
Dude! Where's my stability?
Where's your stability dude?
Oh! There it is! (points to linux-2.2.20.tar.gz)
;)
IMHO, the real problem is the stock kernel.
It is commom to see that the stock kernel has lots
of missing patchs to increase stability and as pointed out by
Rik van Riel which was posted
here in slashdot, Linus rejects
random patchs which cause some areas of the kernel to not be "as good as it should".
The VM is one part which Linus just got random
patchs from Riel and rejected some of them randomically which made the VM suck so hard in
earlier stock 2.4 kernels.
OTOH, kernels shiped from distributions includes
(at least it should) the missing parts and should
be better than the stock kernel from kernel.org .
I don't use Mandrake to tell how good their
kernel is or is not. But I use
Conectiva Linux and I know how good their kernel package is.
Their kernel includes missing fixes that do not get over the stock kernel.
Better of all, their kernel maintainer is
Marcelo Tosati
who maintains the stable kernel tree now.
I think that we will see an improvement into new
2.4 releases.
The latest 2.4.17 kernels from Conectiva can be found in here .
Comment removed based on user account deletion
Comment removed based on user account deletion
Is it not significant the new experimental kernel series 2.5 is being launched just as the `stable' 2.4 series finally becomes stable?
:)
Maybe even number kernels should only be declared stable when they have an experimental branch
Saying that, I've not had many problems with 2.4, bar terribly IDE performance on my hpt370 controller.
I've always found it incredible how hypocritical SOME peole can be.
The big arguement FOR linux up until recently was stability of the OS. With Windows 2000 (and XP I assume) it seems that Linux users are now the ones willing to put up with the more problematic OS, and for some of the same reasons Windows users clung to not-long-ago.
Now my question... Why use Linux? It's that needlessly complex and clunky operating system in-between Windows/OS X.1 & the *BSDs. Windows & the *BSDs being far easier to configure than Linux, with the *BSDs being faster, more secure, more stable, and simply smoother (less clunky) all around.
The *BSDs are PnP (no need for Kudzu) no kernel modules to be manually configured, and the configuration files are far simpler than ANY Linux distro (although you CAN use Sys V scripts instead if you are so inclined-anyone who uses the BSD-style scripts for awhile will not want to use anything else though).
So I ask politely, hoping to avoid flames and rants... Why choose Linux? It's not the most stable, the most secure, the fastest, the most free, the easiest.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
yep it is. :)
however, there is another machine running 2.4 that does get reasonably loaded at times, eg it often has context switch / second rates in the many thousands/sec for sustained periods of time. (highest seen this month so far 7873.12 c'switches/sec). it's a dual cpu 1GB compaq server. (the other was a uni proc, 128mb compaq server), and it's been up for 27 days so far with 2.4.9 - only 27 cause of a reboot due to an nfs problem (which was probably due to a mistake in firewalling).
2.4 does indeed have problems with corner cases. however, this is probably more of a problem for desktops than for servers that have admins paid to watch and tune them.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Rather gutsy of you, doing a '-U' on a kernel upgrade. I sure hope you didn't forget to run lilo, and had your boot/rescue disk handy.
Most of us '-i' the new kernel, and check it out a bit before removing the old one. One of the errata kernels under RedHat 7.x (I forget the exact time, I think it was 7.1.) simply wouldn't boot on one of my systems, though the one issued shortly after did.
The living have better things to do than to continue hating the dead.
I had been running 2.4 on our router for many months. That's not to say those months were consecutive running. :) I had so many problems. I reached the point where I had to reboot the box at least once a week (usually twice) or else it would suddenly become unresponsive. If I had an uptime over 10 days I was doing REALLY well. I tried about 10 different 2.4 kernels (up to 2.4.13), as well as RedHat's 2.4.7 kernel. (I was forced to use 2.4 because of features I required.) At any rate, after about 6-8 months of this, I was resigned to putting either freeBSD on the router or recommending we buy a hardware solution next fiscal year (i.e. cisco router).
Well, I put 2.4.14 on the box and I haven't rebooted since. I have 61 days of uptime and that's the most I've seen on that box ever. It is finally stable. The only thing I can conclude is that it's AA's VM that is doing the trick. And in hindsight, it makes sense. The behaviour of the box was that it was thrashing, but at the time it didn't seem that way because I hadn't noticed the HDD light was disconnected from the box and I couldn't hear the disk in the noisy server room.
So, Linux 2.4 is (knock on wood) stable for my servers, now.
Jason.
Granted, the servers don't get pushed too hard, but my desktop does. :-)
Any compilation problems I've had have always traced back to PEBCAK.
almost from the start (2.4.3 if I remember correctly). We patched XFS into the kernels and some other stuff we needed and the transition to 2.4 was relatively painless using a fresh install (for XFS).
We ran into some trouble with a number of Athlon systems but that was due to the 'Athlon bug' and was soon fixed. More worrisome was the performance of pre-2.4.9 kernels on the desktop: sometimes they slowed down to a crawl (and i'm talking about lightly loaded ~750MHz machines here).
We got over that with the -ac kernels however, and it's been a breeze ever since. We currently use 2.4.14 with XFS patched in (although we're ditching it in favor of ext3 now that it's been integrated and the RH installer supports it) and we're looking at 2.4.17 now.
Why use 2.4 on servers (as some have asked)? Well, iptables is a good reason, for one. Other security-related things count heavily too. And XFS seemed a good reason to do it at the time too. It can deliver very good performance.
Some stats:
zuse [1] > uname -a
Linux zuse 2.4.14-xfs_MI10 #1 Tue Nov 6 17:34:04 MET 2001 i686 unknown
zuse [2] > uptime
2:25pm up 61 days, 21:21, 1 user, load average: 1.07, 1.02, 0.93
--
Just my (22/7)x10^-1 cents.
-=fshalor
2.2.19 for servers @ Work, which all have uptimes aproaching 1 year.
At home I use RH 7.2, with 2.4.17 vanilla. Can't seem to figure out what uses so much memory, because I have 768MB of RAM, and after a few days, it starts to swap. The 2.2.19 machines @ work, have never dipped into swap, and most of them are 256MB or lower.
I think 2.4.17 needs to iron out VM issues, before it will start being loaded on production machines.
2.4.5 has fried my box twice. It corrupted the partition, comes up with a freakout message and such. Ran fsck, but it never was quite right afterwards, so I re-installed both times. Never seemed to happen with later versions (9 through 16) Then again, I probably should be blaming the VIA chipset ;0
Don't call my crazy, that's what they called me back in the home!
Mandrake puts a lot of patches in the kernel too. I think both Mandrake and Redhat tended to base their kernels off of the -ac series rather than the vanilla Linus kernel.
However, you are absolutely right that Mandrake focuses on ease of use and new desktop-like features while Red Hat focuses on stability at the expense of "coolness."
Both can be frustrating if they're used in the "wrong" places.
The idea here, my friend, is that stability on the desktop means something different than stability on the server. Different requirements, different end results. It's kinda the difference between sprinting and distance running; they're different disciplines with different training regimines and different requirements, but both involve running.
Vintage computer games and RPG books available. Email me if you're interested.
There were some lingering problems with NFS (even v2 using UDP) in the 2.2.x kernel series until 2.2.19.
I recommend that you upgrade the machine that's running 2.2.17, or else apply the NFS patches. If you're using NFS v3 or TCP, you definitely want to upgrade to the latest version, and get the latest NFS utils.
I'm beginning to feel like a broken record, and maybe Linus should just change the terminology so that people stop making the same assumption over and over, but people: wake up and smell the bogomips!
"Stable", in the context of a kernel release refers to the interfaces. When Linus releases 2.<leven>.0, he is saying that this kernel is one that has reached some arbitrary plateu of development stability, and it's now ready for others to begin actuall release engineering on.
You have to understand that the Linux Kernel is released by Linus in a state that is very reasonable for a development team, but that will never be "production quality". Debian puts a lot of realease engineering work into a Kernel. As does Red Hat. As does SuSe, etc, etc.
If you just grab 2.4.x and install it, you're acting as Linux Q/A, and I applaud your effort, but when it breaks in your environment, you should not be stunned.
Once again, production release != stable release. A stable release is just one the developers are happy with (and I've yet to see a 2.4 kernel that I can say developers should not be happy with).
So, maybe next time, 2.6.0 should be called the "post-development" release so that people don't go off half-cocked installing it on production systems.
So it took the Linux community a whole YEAR to stablize their Kernel? If MS doesn't have a patch out in 2 days everyone screams. I guess this proves that MS does not have the most unstahle software. Just the most talked about.
It proves no such thing.
Microsoft Windows 95, 98, or ME are not stable, and never will be. Windows NT, after, what 6 years? is still lagging behind any kernel that RedHat has supplied it's users as far as stability.
Win 2000 is STARTING to approach something akin to the stability of a 2.4 kernel release, although it is nowhere near the stability of the current 2.2 kernel.
Do this for your ide hard drives: /dev/whatever
hdparm -u1 -ci -d1
I can't believe I was running without it. Does anyone know why this is not turned on by default?
Use
man hdparm to learn what these settings do.
However, your problems sound more like Xwindows problems than kernel problems.
A great many people think they are thinking when they are merely rearranging their prejudices. -- William James
If the code is unreadable for most advanced users (people with enough C background to follow execution flow in readable code), then you really can't get the benefit of having a large community debugging the software.
What you have here is a LARGE body of (l)users, and a small cadre of kernel hackers who are separated and out of communication. The three times I've found a problem in FreeBSD-STABLE (to be honest, I think one was the 2.2.6, and two were 3.x branches), I sent my bug report in with instructions on how to repeat the problem, and a patch for the ugly hack I made to make the problem go away. I never beat the committers to the bug. Now, before I do all the work, I watch the WebCVS for commits for a couple of days and email the committer who touched the effective files last with a quick question "hey, I see this problem.. have you?"
I tried to read some Linux (the kernel) code a long while ago. There were some funny comments, error messages, and variable identifiers, but otherwise it gave me a headache. I just felt being a Linux participant was beyond my tolerance. I browsed the FreeBSD source code though, and even in the midst of reorganization, both organising schemes were apparent, well documented, and there is a clean style to all FreeBSD code I've seen that makes for (relatively) easy reading.
I guess that the difference is culture, but in this case it seems to be a serious problem. I have to wonder why the Linux kernel people haven't broken the Linux VM code out for modularity and borrowed the FreeBSD VM as an option? I mean: FreeBSD is free-as-in-beer and also free-as-in-software. I'm not volunteering, but after all these years wouldn't it make sense to hack out some Linux wrappers for the FreeBSD VM system? I think I remember reading a Matthew Dillon interview where he talks about all the good stuff he's done to FreeBSD VM recently...
--- Nothing clever here: move along now...
If my memory serves me correctly, one reason to release 2.4 a year ago is to get more people to use the damn thing.
There is a relatively small number of people that use the odd-numbered, experimental kernels. At the end of 2000, it was becoming clear that having the same people running the development kernels on their hardware wasn't fixing many more bugs - I remember a post from Linus to LKML to that effect.
2.4 was stable enough for mass consumption, and so it was released. However, it is important to remember that this is free software, and frequent incremental updates are the rule. Free software can't work if it is not constantly evaluated by users, bugs reported and fixed, and new versions shipped out.
Software is an evolutionary process; it is important to remember that free software (especially the Linux kernel) fully embraces this notion.
OS 9 isn't that old.
Timewise, a better analogy would be someone running the early 2.4 series. Possibly a recent 2.2.
I almost took this guy seriously until this part:
The kernel seemed to show more stability. Then we hit kernel 2.4.15.
Linux version 2.4.15 contained a bug that was arguably worse than the VM bug. Essentially, if you unmounted a file system via reboot -- or any another common method -- you would get filesystem corruption. A fix, called kernel 2.4.16, was released 24 hours later.
Look, anybody who is deploying a kernel on the day it is released on a production server deserves what they get. One day turnaround on a bug fix is phenomenal. Even if these are marked as "stable" kernels, trying to track the new versions in real time is a dumb thing to do.
This guy has written a moan and groan article based on a small set of bugs, some of which he only could have experienced if he is experimenting on his production system. He obviously requires extreme stability and says he needs this over the new 2.4 features (SMP, 2G memory, 2G files), which makes me ask: why was he putting new kernels on his production system before emperical evidence was there about high stability?
Open source will fix bugs faster the proprietary. It doesn't change reality to make bugs impossible. This is true even in "stable" releases, especially if you are talking about highly stressful production environments.
... you are absolutely correct in observing that the 2.4 debacle has used up a great deal of Linux's reputation for being stable. I use 2.4.x with SGI's xfs patches both in production systems at work, and at home (like others, we need various features of 2.4.x not available in 2.2.x), and while it has never been anything close to as flakey as the most stable of Microsoft systems, it has in comparison to 2.2.x (and FreeBSD for that matter) been pretty damn unreliable. In comparison to just about everything else it is still quite stable, so happiness is indeed to some degree relative.
And now for some arm chair quarterbacking, all that having been said, I really think Linus needs to excersize some self discipline and stay away from maintaining even-numbered kernel releases (x.0.x, x.2.x, x.4.x, etc.). By his own admission he isn't good at being a stable kernel maintainer and prefers the more interesting work done in development kernels, and his track record in 2.2 wasn't fantastic (particularly in comparison to 2.0, where he did a fantastic job) and was pretty abysmal in 2.4. As someone who's been using GNU/Linux since the early pre 1.0 days I hope he'll put his efforts where his talents are (managing changes in odd numbered development releases) and leave stable maintenance to Cox and Marcelo (who are very good at maintaining and improving stable releases). But enough commentary from the peanut gallery...
The Future of Human Evolution: Autonomy
Vendors test (in Red Hat's (where I work) case, a lot), fix and create known good kernels. He should use them, instead of whatever is new (and untested) this week.
I run it on my "unimportant" box (the one I use for games and don't care if it crashes) and 2.4.17 has been a "so far so good" situation, but I've only had it a couple of months, I think. Considering the turmoil 2.4 went through in it's "early teen" revisions, I simply don't have a lot of confidence. Maybe 2.4 is ok now, but it takes time to earn trust, and 2.4 didn't do that in 2001.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
I saved this one for last:
You see, that's what we call not in the linus kernel. Your impressions of importance and maturity of the patch are really something you should take up with Linus himself. I, for one, wish Ingo's TUX subsystem makes it into the linus tree sometime soon. But you have no basis to say that just b/c a kernel patch is out, and linus hasn't integrated it into his stable tree, the linux process is flawed. Get a clue! Independent patches come out much faster than anyone can pull them into the core; they are usually conflictive and compete with other patches to solve the same problem. So it takes a while. If you want it in the linus tree sooner, help out. Welcome to open source.2.4.0-? frame buffer had some problems with edge offset.
-2.4.5 usb-storage was flakey.
2.4.6 usb stablized.
2.4.15 broken
2.4.16 first stable version with ext3
2.4.16 ide-scsi hangs with some cd-recorders
2.4.17 seems stable for me.
First, I don't know what compelled Joshua to choose Mandrake, whose "bleeding-edgeness" usually keeps them a bit unstable and unpolished.
Second, I've no idea why he backed his customer down to red hat 6.2, maybe he didn't know that red hat 7.0 still has a 2.2 kernel and is way more modern than 6.2. Was he really *that* frightened?
Finally, I don't know what qualifies as "production use", but I have at least 3 servers with Red Hat 7.2, kernel 2.4.7, in "production" (meaning serving a lot of database-driven web pages, serving up files and working as X servers) and I've yet to have a kernel-related crash. Actually, my only downtime has been due to power outages.
ipchains does an adequate job under 2.2
One case where you could really want to run iptables (which requires 2.4.x) is if you run an ftp server. With ipchains, you have to leave port 20 and a range of ports > 1024 wide open to connections from anywhere (to allow both active and passive ftp). With iptables, you only need to open them to folks who have already established a port 21 ftp negotiation. I'm much happier running 2.4.17 on several systems because of this.
"with their freedom lost all virtue lose" - Milton
Every single machine I have (a few dekstops and a few laptops) has required recompilation, even with recent kernel installs. Why? APM configuration requires different settings (if they are wrong, the machine crashes or hangs), drivers are missing from the default kernel, etc.
You are in no way forced to compile anything as a module -- the kernel will live quite happily as a solitary elf executable. So don't tell me 'every time'.
You are missing the point, which is that if you have modules, many of them need to be recompiled.
I've been pulling kernel sources off a 33k modem link for the last 6 months, and I'm not hurting for the speed.
Well, wonderful for you. But imagine where Windows or OSX were if the premise was "in order to make your sound card work, please download these 30Mbytes of stuff, a complete development environment, and recompile everything". Don't you even begin to see the folly of that suggestion?
I agree with you that make sucks. Unfortunately, it still sucks less than almost everything on the field. Please suggest an alternative.
Well, for starters, you could get rid of hierarchical make files, which simply don't work right. There are several alternatives to "make", any of which could be distributed with the kernel.
OTOH, C++ sucks even harder, and for its extra demands of space and time and its ability to obfuscate,
And you accuse me of trolling? C++ imposes no unexpected overhead in space or time. If you don't use a feature, it doesn't cost you (at least in a good C++ implementation).
You can do that. Say yes to 'attach version information to modules' in the kernel config.
I do, and it doesn't work. The kernel keeps complaining about version mismatches when tryikng to load those modules.
I agree with you, but that's pretty far off. The MIT exokernel is I think the shining example of what you are looking for.
No, it's not "far off". Microkernels have been around for years. But what Linux could do is, rather than imposing a microkernel architecture throughout, allow the loading of some modules into a protected space.
There *is* no reason to recompile the whole kernel to add a module. What are you smoking?
I follow the instructions in the kernel: after changing configuration parameters in menuconfig, I type "make dep; make; make modules". That recompiles the whole kernel. How am I supposed to know in what cases it is safe to type just "make modules"?
You see, that's what we call not in the linus kernel. Your impressions of importance and maturity of the patch are really something you should take up with Linus himself.
If so many bits and pieces of functionality need to be approved by one person, that really is an architecture problem. Imagine where the whole Linux system were if any command line program needed to be approved by the shell maintainer and then merged into a single, huge source tree.
It's easy to throw around accusations of trolling, but I think you are just out of touch with reality. I think the majority of Linux users either recompile the kernel, or they put up with significant chunks of missing functionality (no audio, no APM, etc.) on their installations. Rebuilding the kernel is an arcane and time consuming process out of the reach of even many technically savvy users. And new functionality takes forever to make it into the kernel.
If you do something long enough, you don't see the problems with it anymore. Try to take a fresh look at how cumbersome the kernel actually is, even if it works like a charm once you get it installed. And keep those accusations of "trolling" down--listen for a change and try to understand what people are saying.
he prolly put on Win 2K by mistake...
t_t_b
I'm on PJ's "enemies" list! Are you?
If this was due to a bug in Slash, then shame on someone.
If it was due to me accidentally selecting "Flamebait" instead of "Insightful," although I can't imagine how that could have happened, I sincerely apologize.
I built a new box when 2.4.1 was new, installed that, and didn't have any problems with it. When Linus started 2.5, I decided to get the next 2.4 version, so I'm now running 2.4.17. I've had one lockup, with the ALSA driver for 2.4.17. Of course, this is on my desktop box, which I only turn on when I actually go home from work and still want to do computer things.
With 2.4.1, it didn't have any trouble with giving up cleanly on building Mozilla in too little memory. I don't actually have any swap, since I haven't quite recovered from 1.2.13 with a small swap partition on the only hard drive (with swap, it would slow to a crawl for half an hour *before* killing some things and recovering. Without swap, it would just kill things and recover). I haven't tried doing anything extreme on 2.4.17, although I've been meaning to now that I'm using ext3.
So true. I often have to reboot my home machine, because X crashes and locks up the console. The kernel itself is ok, I just can't type anything. On the occasions when I have my laptop available, I can just telnet in and reboot the system cleanly. Unfortunately, most of the time I have to hard-reset it and experience the joy of fsck.
I can live with it, but yes, my system was more stable before. USB-storage is also quite quirky with the new kernel, whereas with the backport into 2.2 I never had problems. I've also been having problems with USB HID (Mouse) since the change.
On the plus side I gained ext3.
Yes, with iptables I might actually think about running a ftp server. At the moment ssh serves my needs quite well, but it isn't a good solution for, say, publicly sharing source code.
While the facts in this guy's article are correct, he is way overstating stability problems. My company, a high-traffic dot-com survivor, has been running on 2.4 since the pre-releases, and we have never had a single incident on any of our servers.
Although known problems with 2.4 might account for his troubles, it's equally likely he has been having hardware problems. These "bugs" may very well be a straw man, drawing attention away from faulty hardware, which is usually the problem when a machine just suddenly locks up.
I, for one, welcome our new Antichrist overlord.
After I upgraded to 2.4.17 on my home machine (with a Linksys card using the tulip driver), I noticed that networking would intermittently stop. I asked around on IRC & apparently this is a known problem, so for now I'm sticking with 2.4.16. Anyone else experience this?
"...when I upgraded from 2.2 to 2.4 (Mandrake 7.2 to 8.1), I had (still have) many stability problems..."
"...I don't know what compelled Joshua to choose Mandrake, whose "bleeding-edgeness" usually keeps them a bit unstable and unpolished..."
"...He's using MANDRAKE on a SERVER. For crying out loud, you don't use Mandrake on a server. Get something realistic like Slackware or Debian, and if you want to be a idiot use redhat, not Mandrake..."
"...First of all, who would used Mandrake for a server. We are talking about an installation that is meant for a laptop environment..."
"...i was running a 2.4 on mandrake 8.0 and had nothing but problems...."
"...I've noticed that most of the comments both in the article and others complaining about the 2.4.x kernels and various stability problems are running RedHat [redhat.com], Mandrake [mandrake.com], and even Debian [debian.org] Distros..."
huh..
Perhaps we have a Mandrake issue, here, and not really a 2.4.x kernel issue, and certainly not, as the few M$ trolls have tried to suggest, a Linux issue...
dunno..
Food for thought.
t_t_b
I'm on PJ's "enemies" list! Are you?
You should try window maker, it never crashes, there's not much to it is why. It's been around a while and doesn't get or need updates frequently so it's never bugged out on me yet! also there the new version of evolution from ximian is great. With wmaker you can still intall qt libs and gtk and gnome libs and run your old favs without the hassle of gnome nor kde! Try wmaker it's simple, lightweight, and insanely stable. i reboot here at work, well i don't actuall i shut down on friday nights. i just logout(which doesn't actually restart x, every other evening. it's rare for me to reboot! just some suggestions for ya...
...There's nothing wrong with Southern California that a rise in the ocean level wouldn't cure...
What the hell is wrong with you? This thread is highly informative, and I'm not a troll.
It was the kernel of fire... the kernel of destruction... the kernel that took back what was ours. It was the kernel of rebirth... the kernel of great sadness... the kernel of pain... and the kernel of joy. It was a new age. It was the end of history. It was the kernel where everything changed. The year is 2001. The version: Linux 2.4.5
Cue martial music
Edith Keeler Must Die
I don't know about anyone else, but I'm fairly unsatisfied w/ 2.4.17 - which is (was?) reputed to be quite stable and such. I get it to compile fine, etc., but I'm unable to get it to boot. It consistently stops booting after the "Loading linux........." bit. Sometimes it'll just sit there, sometimes it'll sit there and beep randomly/sequentially at me. I've tried everything, including using the default config, and disabling everything I can, to no avail. I've tried other configs that others used to make their kernels, with teh same effect. Grr. Any ideas if it's just me or my system, or what the deal might be?
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
The kernel that shipped with Mandrake 8.0 was completely broken. Processes, especially mozilla, would go into 'D' uninterruptible sleep every hour or so, requiring a reboot to be killed.
This was immensely frustrating and made a joke out of Linux's claimed 'stability'. I blame Mandrake for this one, whats worse is that this distro is one i paid for. Will i buy another Mandrake Linux distro? Not likely.
The 2.4.15 'issue' was one i luckily missed, but it would have been all too easy to download 30MB of kernel, spend several hours configuring and compiling on my P-75, only to have a broken system that inexplicably corrupted my disks.
That being said, every other 2.4 kernel i have tried has worked pretty well, and the 2.4.17 kernel i run on my routers seems to work flawlessly and fast, while providing significant extra capabilities over 2.2. 2 out of 17 aint bad i guess.
I am not complaining, i got this stuff for free, and in general, it is good stuff, but I there is definitely room for improvement in the way kernel releases are tested and labelled.
I mean, on kernel.org, 2.4.15 is listed identically to the other kernel releases - there should at least be a 'broken' sub-directory with kernels with major issues that prevent safe operation of your system.
The changelog on kernel 2.4.15 and 2.4.16 don't make specific reference to '2.4.15 would corrupt your disks when unmounted', which might be understandable to the average user.
'Correctly sync inodes in iput()', in the 2.4.16 changelog only makes sense if you already knew what the problem was, or if you are already a kernel hacker.
In general, the 2.4 kernel has been a huge step forward in functionality and performance, but i think it would be very helpful to flag kernel releases with issues somewhere prominent on kernel.org.'
I gots ta ding a ding dang my dang a long ling long
Although I'm sure this is already lost in the flood of comments :)
I started out running Debian 2.2r2(3?), which had a 2.2 kernel. I never had any problems with it, and I didn't have very fancy hardware. I did have a fun ride getting integrated i815 audio/video to work (that was all I had then). Upgrading to 2.4.4 didn't really help with that issue ... I had impeccable stability, but I never really pushed the envelope :)
Things got more interesting around 2.4.10, partly because my HD crashed (the Deathstar effect) and I rebuilt my system. Lack of MIDI for the SB Live! finally drove me to use ALSA drivers (SB Live! MIDI hasn't worked for me with OSS drivers). No problems support-wise for the Radeon-based card I had for kernel-related issues (kernel DRI mainly). Nice USB support except for the cheap Visioneer 4400 scanner I had (which isn't the kernel's fault). Stability and performance under medium loads has been generally good. I flirted with the pre-emptive and lock-breaking patches for a while, but things got really messy under 2.4.17 (stuff happened that I stopped using Windows to get away from, ie, sudden hard system freezes), so I dropped back to 2.4.16 with no patches. I'll probably try again with .18 or something. The only speed complaint I've really had is gmc takes a long time to scan directories with lots of stuff in them :)
Now, I haven't really had many problems. 2.4.13-ac8 oopsed, but since I was panicking about midterms at the time I didn't really look at it that closely, and never got around to actually reading the oops screen (I took a pic of it with someone else's camera ... ). I haven't taken time to find out why yet, but XMMS' memory footprint has this habit of growing unbounded ^^; The ALSA output plugins make it worse.
For the curious: my system is a P3 866 with 128 megs of RAM to start. I upgraded to 512 megs in July when I was running 2.4.4; that's the most memory my motherboard can take, alas. Heaviest loads include running XMMS, apache, xinetd, xchat, and compiles at the same time, so not too bad. Apache was mainly serving stuff to one or two people at maybe 20-30k/sec. I've been generally happy with the 2.4 series, but since I haven't really pushed my system hard yet I may experience problems later when I do :3
Have you made performance mesurement ?
How did you came with those number?
I always thought that 4 was really the culprit having seen the *huge* amount of communications needed between the toolkit and the X server (used to do some Xlib programing).
So I was thinking that Berlin was really the way to go..
I'd really like to see numbers.
Joshua, great article. Thanks a bunch for writing it. But.... do you have a better idea of when that book is going to ship? The publishing date posted keeps slipping... ;)
Davo -- Free speech, free software, AND free beer.
This was never intended to be a dissertation, but as an answer, I think you haven't read or experimented enough.
Darwin is bloated, yes. It needs 96MB to perform, and it's pretty monolithic.
This is not Linux conventional wisdom, in fact Linus believes in monolithic systems -- that's a factor in the current inadaptable, hard-to-change, hard-to -test situation. Do yourself a favor and look for the famous exchange between Linus Torvalds and Professor Tannenbaun (is this the name?) of OS design and Minix fame.
Darwin is a kind of half-baked microkernel, because it is integrated with a single server. So it has the performance problems, isn't compatible with other BSDs drivers, and looses flexibility. Besides, Apple and its users aren't really interested in flexibility.
Linux hope can't be in Hurd, because Hurd and Linux are mutually exclusive, Linux having being created because Hurd was taking too long. Go see Linus' announcements in Linux start of life. Rather, Hurd is a hope for the GNU Project and the free software community, especially that part of it that believes in copyleft and has lost hope in monolithic kernels. Meanwhile Linux was created out the GNU Project, while having a symbiotic relationship to it and depending on it; Linus believes in copyleft but not strictly; and he's more aligned to Open Source than to Free Software.
And Hurd has a chance at viability because of the microkernel plus multiple servers architecture inherent flexibility. So it could theoretically scale from small to big systems, and each configuration needn't include anything non-funcional or ill-suited.
Please do your research before babbling out.
Leandro Guimarães Faria Corcete DUTRA
DA, DBA, SysAdmin, Data Modeller
GNU Project, Debian GNU/Lin
As a matter of fact, my latest Linux box is coming together in an ancient IBM 5160 (PC/XT) case with no reset button. I remember when this came out (actually its predecessor the 5150 PC) and it was remarkable in its day for the same lack of a reset button, which was de rigeur for personal computers in a day when CP/M had reduced the battery of data-entry switches called a "front panel" to a single reset switch.
IBM must be pretty confident, the reviewers figured, to leave the reset button out (Apple subsequently did the same on the Mac)(Did the Apple ][ have a reset button?). Bill Gates and DoS proved them (IBM) merely arrogant, and the 286-based PC/AT a couple of years later (5170? I know not the model number) had a reset button.
Now, twenty years later, I've removed the reset switch I eventually added to the 5160 cabinet for the sake of DoS. I'll need it no more.
Exceeding the recommended torque is not recommended.
An article by Michael J. DeMaria over at networkcomputing.com.
The response I received from a number of kernel developers was that there wasn't such a thing really but it would be great if I did the work of organizing it.
SunSITE.dk seemed to be the best site of the many kind folks who offerred to host it, and so was born The Linux Quality Database.
What my plan was, and is, to organize serious QA efforts among people other than the normal kernel developers, in support of the developers, so they can get faster and more thorough feedback on their code.
Unfortunately, my consulting work has always been very hectic, and so I have not been able to do the work on this that I want to, at least not yet. Things are getting a little more rational in my business, so I have high hopes for resuming my work on it sometime soon.
There is something of value on the site that can help everyone though, I wrote a few articles on the topic of linux kernel and web application quality. The articles of interest to kernel testing are:
-
Why We Should All Test the New Linux Kernel
-
Using Test Suites to Validate the Linux Kernel
I placed these under the GNU Free Documentation License in hopes that they would get widely distributed, perhaps included with distros. I plan to write a lot more articles - I like to write when I have the time.I was happy to see that the Open Source Development Lab took advantage of the GFDL on the articles and reproduced them at its own site here.
Some might ask why I don't use an existing bug database such as bugzilla. I may well adapt bugzilla, I'm still trying to figure out what to do, but a central part of what I plan is a bug database optimized for tracking kernel bugs.
A database user will be able to enter in the configurations of the machines they have at their disposal, drawing on a database of known hardware, and give names to particular configurations.
When they report a bug, they can report the bug against selections from a list or menu of the configurations they have previously configured.
Also, they can upload the kernel .config file used in the kernel build.
Doing this will allow developers who are researching bugs to determine whether their code has been used on certain hardware, or to do boolean searches on both hardware and .config options to find out about interactions of kernel code with hardware.
I think bugzilla could be expanded to do this, or another bug database, but this is not a capability in any bug database I've used so far, either open source or proprietary ones at companies I've worked for.
-- Could you use my software consulting serv
I recognise your point that following kernel code isn't that hard, but I still wonder why Linux couldn't borrow some FreeBSD VM code where FreeBSD drivers often come from a rewrite of Linux drivers.
--- Nothing clever here: move along now...
I said "when X crashes and hangs the console." That is, the console driver itself is hung because X f*cked it up. ctrl-alt-bkspc does nothing, nor does ctrl-alt-num to switch consoles. Only way in is via telnet, and sometimes I can't.
Analogies should use REAL products, the whole EvilViper Corp. thing was not helpful and truly obsecure, so I can't well address your example.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Hands down. The answer is a solid yes. I doubt you'll be able to find a benchmark that will put EXT2 over FFS with comparable options (EXT2 does beat it when softupdates are not enabled, etc.) This is not to mention that you can manually enable async mode on any filesystem you like, it's just not the default (and definately not recomended) opposed to Linux which, as always, chooses the half-assed performace solution over stability.
I have used BeOS quite a bit. It does boot to the GUI quickly, but not because it's a well-performing OS. It boots and runs apps quickly because (like Windows 9x) it is a single user OS, without the multiuser/multitasking file and memory protection most Unixes put in place. I'm fairly sure that with quite a bit of tweaking to make FreeBSD run everything near real-time priority, and remove the parts of the kernel that protect the system from the application's bad behaviors, we could well out-do BeOS.
I do not worry about my karma. I've been at the karma cap for some time now so being moderated down does not worry me, and the slashdot system defaults to giving my comments +2 points. I do not have the ability to change the default (I'd just have to check a box every time I post a comment). The primary reason is this: If the
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
I think I've pretty clearly illustrated I am a proponent of BSD/Public Domain, but not GPL/Free Software (except in a few fringe cases). The reason our discussions went they way it has is simply because we obviously disagree on why you would be releasing it as Open Source. You believe it's because you no longer have the resources to maintain it, and I believe it is because you want to:
a) widen the acceptance of a program (i.e. release Netscape, BeOS, DR-DOS, so it gains public acceptance and once again surpasses it's competitor)
OR
b) you want to do something in the public interest (security programs, operating systems, consumer information programs, etc).
Neither of those qualifies as 'not having the resources to maintain it', although that may be true IN ADDITION to the above, but not the sole reason for releasing it.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
It's hard to rationally argue with someone what fails to grasp things we all take for granted. Windows NT/2k takes _much_ longer to boot than 95/98. It's just not something that is debatable. Install 95/NT/98/2000 from scratch on identical machines and time the bootup.
Pretend I didn't say that... My point didn't come across the way it was supposed to. It does indeed do multitasking very well, but I stand by my point that it is painfully single user, unprotected, etc. No, what would be needed is to strip the priorities and multiuser capabilities out of the kernel and programs. An OS would simply have to be as indifferent to the stability of the system as BeOS is.Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant