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.
you missed it by one. sorry about that. try again later
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
I have had 2.4 installed on the linux servers at work since 2.4.10 and haven't had a single issue, granted I usually wait a few weeks after a release to review any possible bugs that may have been introduced...
blah blah blah....
drightler@technicalogic.com
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
I've been running 2.4.13 since the end of December with little or no trouble. However, there's an unexplainable occurrence where kswapd takes a dump and just starts chewing up all my CPU cycles. I haven't invesitigated this (mainly because I'm lazy) because it goes away after awhile. I've never experienced this with any other kernel I've used -- going back to '94.
mstyne: real name, no gimmicks
The big problem I've had with 2.4 is that the TCP stack constantly stalls. I'll transfer a few hundred k at 30k/s or more, and then it'll just totally stall. I usually have to abort the transfer and try it again. apt-get is rather painful like that, as I have to constantly hit ctrl-c then run it again.
I've got a 3com 905 card. Works perfectly in Windows. Passes the 3com diagnostics tests perfectly. Works fine in kernel 2.2, so that's what I stick with.
Congrats, yours was the first of many anecdotal posts. I've been running 2.4.XP for quite some time now and it's been stable as a house, save for the occasional power outage.
MikeAtIF*ckStuffedAnimalsDotCom
I've been running 2.4 on a server since
the early days with no lock ups. On the
other hand Windows XP locks up on me
every few days on the desktop. Suck it
and see, if 2.4 crashed on you, go back
to 2.2 until it's ready for YOU.
"However, after about a month into deployment I started noticing strange problems with the machine. Intermittent lockups were the most common. The lockups appeared physical, and the machine was unrecoverable without a reboot.
While performing research on the problem, I learned there was a serious sync() bug in the 2.4 kernel. This bug exists in all kernel 2.4 versions until 2.4.6."
Intermittent lockups? Serious bugs in the kernel? For five straight minor releases, no less! This is beginning to sound like Windows! Where are the trolls who post about the Open-source movement completely preventing and/or eliminating this sort of thing?
As if I didn't have enough to worry about now I'm going to loose sleep because I have so many machines running various 2.4.x kernels. I realize that open source is better than anything else I could run considering my applications, but how do you explain this to a client? "Sorry Mr. BizOwner, the people that program the Linux kernel in their spare time are experimenting with various things, you'll just have to wait until they are done. No, I don't know who they are. And no, if I e-mailed them they probably wouldn't care." Yikes. It's already hard enough to keep clients due to the economic pressures they are facing. At least the author of this article was able to find a solution to the problem, unfortunatly I can't afford to roll my servers back to the 2.2 kernel. Most of the kernel problems described are way beyond my understanding. But one interesting thing about this is that we have no one to blame but ourselves. I don't have a clue how to program kernel code, but those that do here is a message for ya: PLEASE HELP US! There are guys out there smart enough to fix this I'm sure. Let's hope they do it quickly and accuratly. I'm sure there are going to be business owners out there that aren't going to understand this and are going to run out and install Windows 2000 as soon as they can. Bad Linux press is just so damaging, here is hoping that the powers behind Linux can turn this around and do one of those magical "we fixed it overnight" responses.
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
So what should I do, as a new user? Go with bleeding edge 2.4.whatever, or go with 2.2.whatever and do without things like !USB!? I'm looking to build a box to play around with as a desktop workstation but mostly experiment with setting it up as a server.
I guess I more understand why Debian stable is still at 2.2. And I'll probably go with Debian as I can't trust Mandrake, it screwed with my machine too much on an install, and was completely unstable; Slackware seems to be dying a long slow death, not even maintaining a support forum; and Redhat just seems too corporate/business-oriented for a lil' guy like me.
Looking forward to suggestions on how to proceed and inevitable flames on not being h4CK3R 31it3 enough.
evanchik.net
...is about as reliable as the 2.4 version. ;p
"Adequacy.org: Where congenital stupidity is not an option, but a requirement."
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
Just tonight I had a production box go tits-up with a panic. Mandrake 8.0 2.4.3-20MDKSMP.
I've been using it in production on high-load servers since the late 2.3 series, and no major problems came from the kernel itself (more issues with crappy hardware never designed to handle the load). So for intensive (>100 million hits a day) services, it is OK, as far as I'm concerned.
-- javaDragon is an instance of JavaDragon.
Our Oracle server 2xcpu + 1g ram running on Rh 6.1 its running kernel 2.4.3. It near the Year, we havent got any problem.
But both my Mail server and Firewall running on RH 6.2 and RH 7.1. Both of them upgraded Rh 7.2.
Then? Two of them blown. Firewall get random kernel panick. Mail server fcks up RPM.
So I do clean install MDK 8.1 both system. After more than mount. Everything going fine.
Check your doings. Before the blame GNU/Linux.
[My english is better than most other people's Turkish, so please point out mistakes politely. Thank you.]
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.
while i dont want to bash linux even one little bit here, i think its great. Prehaps the author should consider an operating system with a larger focus on stability? FreeBSD and others have a much more stability consious approach, and freebsd really cleans up on netcrafts longest uptimes stats.
not only that but it includes linux binary compatability for those things which dont compile nativley (not much)
cept that would be too short to post. isnt the minimum 20?
and, on topic... Ive never had a stable linux box, and 2.4 hasnt been any more unstable than im used to.
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!
I have been using the 2.4 kernel on my home system since the beginning. The early releases were quite stable, but there were issues that required an upgrade.
But then, each new release seemed to deteriorate. System lock ups, broken drivers, you name it. Some kernels even refused to boot. I was lucky I never lost any data.
Around 2.4.13, things had become so bad that I decided to skip a few releases. And after the next crash, I reverted to 2.4.9 (which still had problems, but it was bearable - I was lucky I still had it: I bumped into random errors while compiling a new kernel).
In 2.4.16 and 17, things finally became stable. At last. I hope Marcelo Tosatti keeps stability as the main priority of his job as kernel maintainer.
The 2.4 series has had more than its share of brown-paper-bag bugs. Up to the point that 2 releases didn't even compile properly.
Switching VM implementations in a stable kernel series has been one of Linus' greatest mistakes. I hope people learn from this, and that some kind of QA will be installed.
WWTTD?
Is 2.4.x really as bad as this author makes it sound? I mean you'd think that the stuff he's complaining about -- it sounds kind of common -- you'd figure that people would have run into it during 2.3.x?
Been running a 2.4 kernel since 2.4.5 (shipped with Slackware 8.0), and have had zero problems on the few machines I use as servers. MySQL, Apache, Tomcat, PHP 4, and tons of hits a day from outside people using message boards. I'm also running ReiserFS on all of my machines.
Could this be an issue with compilers on certian platforms? I know I've had some weirdness trying to compile 2.4 kernels under Red Hat 7.2 at work, and the kernels claim to be compiled with GCC 2.96. What compilers do Mandrake 8.0 and SuSE use?
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.
I don't read this site for slanderous whining about Linux being bad.
Get back to Micro$oft bashing or I'll quit!
238 days of uptime on 2.4.3 since sometime in May, it's been quite stable for me. It IS a personal box so I don't have to worry about those local exploits with symlinks.. and the other thing.
:)
I can't complain
-stu.
yesterday, I went from 2.4.5 to 2.4.17, and never had so many problems. As soon as I started doing something, everything would start to segfault. I could not reboot because disk could not be unounted while errors flowed over the screen too fast to read. Off/On switch was the only thing that helped.
Is this the new VM systems biting me?
I'm using 2.4.17 for both my desktop at work and my server at home (web sites for friends and family, message boards for car clubs, etc), and I've had no problems.
I've been using a 2.4 kernel since 2.4.5, which came with Slackware 8.0. I also use ReiserFS on all of my machines that run 2.4 kernels, and so far so good.
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
Does anyone know when the official kernels from kernel.org will come with pre-emptive multitasking? The foundations of Linux are mature, so why do we have to go to another site and download source code with this feature? From a newbie's point of view, this can be daunting. I want RPMs!!! lol
So the latest stable version is 2.4.17... and 2.4 has been in development for a year. As someone with not much knowledge on the history and progress of Linux, I sure would be interested in seing a cartesian graph of kernel version vs. date of release.
I haven't had any problems running 2.4.14, but
admittedly I only run it to play quake3 for a while,
then boot back to windows to do my part in spreading
virii.
;-)
b
What f*ing box!?!?
Slackware 8.0 also gives you the option of running 2.2.19 or 2.4.5 when you do the install.
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 got bitten by the 2.4.5 included in slackware 8. Got it working on a p60 mb, but wouldn't boot on a 486. I thought it was my falut at first because I thought that a problem as basic as booting shouldn't have made it all the way up to .5. Either not many people are running 486's anymore or no one's complaining.
2.4.17 at least boots fine now.
wrong
Slackware's not dying off, there's just less people directly involved after the fiasco with Wind River. Patrick V. is only one man, and he doesn't feel like playing with trolls on message boards. That's why the forums are down.
Development of Slackware continues.
For those of you who are looking for people who used to frequent those Slackware forums, subscribe to the alt.os.linux.slackware newsgroup. Some of the regulars from the forums are there, as well as people who were never on the forums.
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).
I've had a dual CPU computer for some years now; I ran 2.0.x all the way till 2.4.x on it with great success.
I must say that the difference (apparent response time you get while at the console) between 2.2.x and 2.4.x is huge for SMP machines. I'm not going back to 2.2.x
On a totally unrelated matter, fishy hardware makes sometimes people believe that `Linux' hangs. Hardware issues are hard to troubleshoot. My 4-years old PC can take 2 attempts before cold-booting up in the morning (the first time it typically hangs after POST and keep the floppy drive LED active). This morning again, I suddenly heard the fans drop in rpm and the PC hung shortly after... this is when I decided it was about time to leave the house and go to work :)
My point : for average users, the 2.4.x series is just fine; when it's not there are other issues at stake.
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...
.....use FreeBSD
Mac OS X and Windows XP working side by side to fight back the night.
I have had some issues with 2.4 but overall it has been stable enough. What bugged me most were all the big changes the guys introduced in what was supposed to be a "stable" release series.
;)
But since none of my machines running 2.4 went down in flames, I don't REALLY mind. ie, 2.4 is a brown bag series, but the developers are allowed to cut holes into it for air & view.
I use it mostly for code and writing latex with emacs. So for that is great, of course you ..., its been great for that for years. But with the machine I hack I have several problemas with my usb modem, I gave up on that, my tv card, burn cds on it has been a nightmare.... A part from that is been great.
------I can please only one person per day. Today is not your day. Tomorrow isn't looking good either.------
One of our machines (server, not desktop) has been running with kernel 2.4.0 (SuSE 7.2) absolutely painlessly and without any noteworthy problems for month now.
Sorry you'll have to find another cop out to use. Mandrake is a perfectly fine distro for running a server on.
The problem is with the 2.4.x kernel, not the distros.
Mac OS X and Windows XP working side by side to fight back the night.
First of all, there is no code difference between "server" and "desktop" distributions of Linux. That's right, none. A desktop system can be tuned for server operation by enabling SMP and increasing things like file descriptors as necessary. Perhaps you are confusing this with Microsoft's Windows 2000, which places restrictions on the desktop versions such as limiting incoming connections and removing soft raid.
Your other two points prove you to be an apologist for atrocious development practices. Linux 2.4 is (and was always) advertised as a stable kernel series resulting from development in the 2.3 series. The linux developers seriously need to look at the FreeBSD model of development -> stable -> release rather than this orgy of code rewrites and new features. You want to add new features? Fine, put them in 2.5. Just don't fuck with 2.4 unless it is a bug or security fix.
- 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.
Then update and upgrade your Macs.
If someone was whining about a Linux system built on a 1.x kernel from the stone age, everyone here would be bitching. Yet, insult Apple's obsolete OS, and it's informative.
I guess your Windows labs (heaven forbid) run Windows 95 as well?
Honestly, if you want stability, use a stable OS. Windows NT/2000, OS X, Linux, whatever. Just don't whine about antique OSs sucking - Upgrade them!
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!
I'm a Linux kernel novice, but to me it seems like the Linux kernel is too big and contains too many modules. 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.
Maybe it would be better if they concentrated on creating a stable, small kernel which contains stuff like memory and processor management, and everything else is external drivers or modules not included in the kernel. Linux distributions could then put together the modules they like and create a complete system.
i think you should get a new computer if all your programs are crashing
2.1, 2.2, never be screwed
2.3, 2.4, you'll be whored.
2.5, 2.6, VM schtick
2.7, 2.8, out too late.
Linus T is falling down,
falling down,
falling down.
Linus T is falling down
Bee-eSs-Dee!
Oh God, I need to listen to less Korn.
Btw, if there's anyone who can do better, please respond. Actually, I'm just hoping that I'm not the only person to embarass myself like this.
/^[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,4}$/i
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.
# uname -a
:(
Linux judge-zorro 2.4.0 #1 Sat Jan 27 23:41:59 CET 2001 i686 unknown
# uptime
10:46am up 336 days, 23:40, 6 users, load average: 0.82, 1.05, 0.98
But it has been less fun on my desktop system..
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!
If Linux had a kernel debugger, bugs would have to be fixed before new features were added. In other words, Linux would fall 20 years behind Windows instead of the current 10.
I thought Nader was half towelhead.
1st 2.4.x install was on a laptop with a 1394 PCMCIA cardbus card + device I had to get running. As in *had* *to* -- not to be fancy, it was a requirement. No dice under 2.2.x. 2.4.x Has been running great for over 6 months.
2nd 2.4 install on a server, had to get a USB ATM device running on it -- so again, 2.4 was the only choice. No problems whatsoever, and am driving it pretty hard. Upgraded from source after applying some ATM specific patches written for a different patch-level. Had to add them one by one, mostly because the stuff the patches added was...already in there. The only thing I don't really get about it is, with all the ATM kernel support and the plethora of ATM device drivers available in it, why do we have to scrounge around for a PPPoA that works? I hear it's in 2.5...wow, *that* helps.
On the desktop, StarOffice 5.2 has no problem with .doc stuff, but freezes up on occasion when trying to draw simple diagrams---well, lots -- under 2.4.x. This is just about the worst thing it can do if you're trying to convince WinDoze users to switch to Linux. But Python, wxPython, gcc and SWIG all work great, so who cares?
It Works For Me
The trouble began when I tried to upgrade to SuSE 7.2 (Kernel 2.4.6 IIRC). The installation always hanged because of SCSI lockups (I don't use IDE, I have all SCSI in that machine). I could get around of it by disabling ACPI in the BIOS and so the lockups were very rarely then. Another Update to Kernel 2.4.10 (SuSE 7.3) solved this issue completely.
But I'm not angry about that. It gave me a wonderful opportunity to learn new things and I also found answers on the Kernel mailing lists. So it was just a bug, that could be fixed, I didn't lose any data from it and it didn't take me ages to solve the problem.
And BTW: The parallel installation of Windows 95 didn't work on the updated PC at all. And upgrading to a real running Windows 98 installation took me much more time (with all the reboots) than solving my little SCSI lockups under Linux.
Only complain I've had about the 2.4 series is that really early versions 2.4. Other than that, I think its pretty good.
-- Eric
It's worse than it sounds: Personally, it raped me in the ass and sucked my soul out. Then it ate my dog and pissed on my wife. So, no, it is pretty bad.
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.
I keep noticing that most of the major players
in the Beowulf arena still use 2.2.x kernels
(Scyld, Myricom come to mind). Only
a few completely custom system have upgraded
to 2.4.x , for claimed superior TCP/IP
performance. There must be something there...
Google passes Turing test : see my journal
and I look forward to FreeBSD 4.5.
/dork would not have to be posting 'the kernel of pain'.
If real software engineering went on with the Linux kernel de jour (oh, simple things like CVS) perhaps the Linux mutual appreation society that is
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
[root@ns root]# uptime
10:00am up 246 days, 23:57, 1 user, load average: 0.00, 0.00, 0.00
[root@ns root]# uname -r
2.4.5-pre1
this was the first critical server i ever installed a 2.4 kernel on. (it does dns).
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
Linux isnt ready for the -
Server?
Wait a minute...
I started using 2.4.16 on the desktop.
The ones before panicked for me.
I'm fine with this though. I didn't trust 2.0 until 2.0.32,
2.2 until 2.2.14 and 2.4 after 2.4.16.
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?
The number of people overlooking this one very important fact amaze me. .0 this or bleeding edge that. Here is a clue stick for
Everyone is
all of you. It maybe unstable, but it isn't supposed to be. It isn't
supposed to bleeding edge either. That stuff should be for the 2.5
series. The fact is by releasing an unstable kernel, and then ripping
out the _entire_ VM system midstream they have made a mess of things
this go around. A mess that all you people defending the Linux
would be boiling M$ alive for. Linux is supposed to be about stability.
I guess I will have to go to *BSD for that now.
--wyn
It was the 2.4 kernel that made me look at, and eventually switch to OpenBSD. After reading several articles in the press about why Linus was releasing 2.4.0 (some mentioned being tired of everyone asking when), and subsequently having serious problems with early kernels, I decided to move my data to OpenBSD.
Linux seems to seek desktop user mass, and that goal seems to be more important than code quality and stability. All I really want is a secure and stable OS. Linux 2.2 kernels were pretty much that, but 2.2 is getting old.
So I decided it was time for me to go back to my roots, and install BSD, which was the first UNIX OS I used (on an old pyramid). I used unix since 1991, linux since late 1993. Too bad Linux is going the wrong way (for me) nowadays...
I am so glad about this article since my bad conscience was already haunting me that we did not upgrade to 2.4.
Having read that article I have to say that I'm not surprised. If there is a good general rule of thumb, its that the kernel isn't stable until the fork for the next kernel has happened.
That said, I have 2 production boxes up and running with 2.4.x (one is 2.4.9 and the other is 2.4.12). If I remember the timeline for the big VM switch right, one is pre and one is post.
2.4.12: up 69 days, 43 min
2.4.9: up 53 days, 17:00
So far, none of these boxes has had any problem. We generally don't upgrade kernels on a production box, prefering to rebuild the entire system. This may explain why these boxes are so reliable. They were setup with distributions that used the 2.4 kernel.
I've been running 2.4.x kernels since 2.4.0 on my desktop machine. I tried every one except 2.4.11. Never had any problems, even considering I have an all-reisefs box.
On my company's server, however, I'm still running 2.2.19. The servers have been running along nicely, so there is no reason to upgrade. If it ain't broken, don't fix it.
Running mission-critical servers on cutting edge kernels is just silly, and if the servers crash and lose all the data it's the sysadmin's fault, not Linux's.
Just my 2 eurocents.
FreeBSD has a rock-solid VM system. A GPL'd fork of this code can be created as long as we acknowledge the original authors. Why don't we do that instead of constantly trying to reinvent the wheel?
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.
I switched a production server to 2.4.x very early on (I think it was one of the pre's, even) for the improved software raid support.
The server would become unresponsive as memory utilization crept up near 100%. The OOM killer would axe the ssh processes - and often even getty - to "free up" memory.
Hard lockups on a colocated, headless server are *not* acceptable. After about 6 kernel upgrades, we gave up and switched to FreeBSD.
A year later and they finally anounce the new VMM. Great. Glad I don't have to live with that anymore.
~mindlace
2.4.17 is the first really adequate release IMO for a machine that is going to be important. It has ext3 built in, and the rest of the kernel is refined to a point that is not present in previous kernels. 2.4.16 was probably okay, too.
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)
;)
Man, i thought the point of open source operating systems were to avoid endless and buggy upgrade cycles.
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
Its stabler than the 2.5 series, but you don't learn as much.
Through experience and monitoring of the lkml, it became apparent that the major reason why 2.2.x and 2.4.x kernels failed so frequently for us was down to the implementation of VM by Rick van Riel. Once the decision was made to use Andrea's VM, we found a significant improvement. In both kernels, this decision was made after approx. 1 year of initial release.
Our servers running 2.2.19 and 2.4.16/17 still lock up from time to time, usually every 30-60 days, but compared to using Rick's VM we'd only get about 16 days uptime.
We were forced to upgrade to the 2.4.x kernels because 2.2.x no does not support the chipsets that our servers use.
i was running a 2.4 on mandrake 8.0 and had nothing but problems. my logs were filled with write errors from startup until shutdown. everyone told me that it was a bad drive. the older mandrake that had the 2.2 had used this drive fine. when i made the jump to debian/potato with it's 2.2 kernel all the wirte problems disappeared. I'm sticking with 2.2 for a while.
I have to say that the guy who wrote this article and the other consultants seem to be a bunch of idiots. First of all, who would used Mandrake for a server. We are talking about an installation that is meant for a laptop environment, with all the bells and stuff. Also, I thought that it was a normal understanding that you should not used a brand new kernel for anything major, since it by default will lack some stability. But here is this guy installing it and then complaning about stability. What a surprise!
I personally haven't had any problems with 2.4.x. This puppy works 24/7 without any problem whatsoever. Although I definitely feel that the new VM is better than the old one by far. Definitely, Linus made the right decision by yanking the old one off.
With regards to new kernels and distros, my recommendation for people that like to bitch about things is not to install bleeding edge on production systems. This should be more than obvious, in particular for consultants. I would say that the norm is or should be to wait until the kernel is on the teen numbers (i.e. X.14.X) before its used for any major installation. Again, this should be more than obvious, but it seems that people are brain-dead with regards to something so lame. And then they go around writing "Kernel of Pain" bitching articles.
When I try using 2.4 and mount cdrom kernel freezes. Good not? So I kept 2.2 and I'm happy with it even it gaing slower. Yesterday I just made a downgrade of Xfree back to version 3.3.6 because Trident 3D Image 975 isn't well suported on Xfree 4.1. So I think those guys should stop a bit and make SURE the hardware that worked with older versions still works on newer versions. I am really angry that there is already a 2.5 kernel before my problem was fixed (at least not at 2.4.14).
nowhere does he mention why he needed a 2.4 kernel in the first place
The article is generally short on details but that doesn't mean he didn't have a valid reason for wanting to use 2.4, a supposedly stable kernel.
Besides all of the new functionality -- reiserfs, drivers, etc -- 2.4 was supposed to have a lot of BETTER functionality. The VFS subsystem was supposed to much improved, the networking layer was completely rewritten to be much better, etc.
If someone told you that 2.4 was the stable kernel release fork and that 2.4 included lots of major rewrites that improved the efficiency and scalability of subsystems wouldn't you think it appropriate to try to use it?
Or do you purposely run the most inefficient OS you can find for your application?
I agree that he doesn't make a very good argument for his case, but just because the system was currently working doesn't mean it didn't need to be changed. Maybe it was working but overloaded and slow to respond and due to profiling of the problem he determined that an improved network and VFS subsystem would help remedy the situation.
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 had serious issues with ethernet cards on 2.4 kernels. Several diffrent card with diffrent drivers have just died after some time of use, requring a reboot to ressurect. This has never happend with the same cards on 2.2 kernels.
Why not go directly to 4.4-STABLE or chance 4.5-PRERELEASE? It's definitely nice and stable. Much better than 2.2 or 2.4.
# uptime
7:39AM up 31 days, 7:46, 8 users, load averages: 1.00, 1.00, 1.00
#uname -a
FreeBSD somewhere 4.4-STABLE FreeBSD 4.4-STABLE #10: Sat Dec 1 13:37:45 EST 2001 root@gw.smnolde.com:/usr/obj/usr/src/sys/FIREWALL i386
Well, maybe I am trolling, but you linux d00ds still don't get it.
engineering of the Linux kernel is producing
an unmaintainable, fragile product. The
amount of work to fix the lack of systematic
engineering will be enormous, and likely
beyond Linus' capacity since he seems to avow
rational design whenever possible.
The BSDs work great. Go use 'em.
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.
Before 2.4.10, I had serveral issues with my own little server box. It would always randomly crash. The error always told me about 'swapper'. Needless to say I had known about the rough edges in the kernel's VM, but maybe with my hardware and software , I was an extreme case. Since Linus incoporated Andrea's VM patches in 2.4.10 and higher, everything has been smooth.
The problem I had with 2.4 was just that, it crashed for me. I managed roughly 6 linux servers for an ISP all running 2.2. Would I even consider sticking 2.4 on those after what I witnessed with my personal machine? No. But now things are much different now. My box is flawless, and I've since upgraded those boxes that had 2.2 to 2.4.
-reid
My hardware is: ASUS P3B - PIII-550 (slot 1), 2 x 256mb Hitachi RAM, Nvidia TNT2, Maxtor HDs.
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
bob@tree:~$ uname -a
Linux tree 2.4.6 #1 Thu Jul 5 16:34:16 EST 2001 i686 unknown
bob@tree:~$ uptime
12:00am up 196 days, 5:28, 42 users, load average: 1.16, 2.52, 2.46
bob@tree:~$
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 put 2.4.7 on our site's production (ok, productive) web server last August. I did one recompile to add in supposr for a new SCSI CDRW. That server (a rack system we designed and built) has been humming along very nicely...
Now, I won't ever get to sleep again after reading that article...dammit!
Joe Dougherty, Florida, USA
The words I thought I brought, I left behind. So, never mind.
With all of the MS bashing going on lately, please allow me to say that my quad processor
(overkill, but the budget was there) Win2k server has been rock solid for since I set it up last August.
A few patches here and there, but other than that, not one BSOD, no lockups, nothing.
No, it's not sitting in a closet; it's a database server that gets hit about 17,000 a day.
s'cuse me, not last August, but August of 2000.
So if your mail program crashes then choose another one! Doh!
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.
The title of this comment says it all.
I reject the notion that stability is something reserved for high end systems. Curse Microsoft if you will, but perception is reality as far as desktops are concerned. If people THINK something is stable, it'll succeed on the desktop. People seem to think XP is stable (why, is beyond me) and so it succeeds.
Every time I see the phrase "stable enough" with regards to Linux, I just have to cringe. I understand completely that high end systems require a different level of reliability, but when you accept something as "stable enough" then you've admitted to accepting bugs as reality. And isn't that just what Microsoft does? (as an example, Microsoft rarely classifies "bugs" and calls most bugs "issues")
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
--
Red Hat now ships with grub as the default bootloader, which is smart enough to boot without rerunning the stub installer after every kernel upgrade.
Just the facts:
$ uptime
8:26am up 158 days, 6:39, 7 users, load average: 0.23, 0.05, 0.02
$ uname -a
Linux XXXXXXXXX 2.4.7 #13 SMP Sun Aug 12 03:11:03 EDT 2001 i686 unknown
I haven't had time to update the kernel or reboot the box...
The only problem I had with 2.4.x was with the DAC960 drivers. After that its been running flawlessly for months.
[%- PROCESS life -%]
>:)
Just my (22/7)x10^-1 cents.
-=fshalor
Then you're doing something wrong.
That poor fellow ought to move his machines to FreeBSD4.5
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.
I have to agree with this post... people forget
that large machines are completely different beasts than your desktop. Your x86 based machine is going to behave quite differently than say a 2, 4, 8 or more cpu machine with gigs and gigs of ram and 100s maybee 1000s of gigs of drive space. I am a linux advocate myself, but I would not put it on the IBM F50 I used to work on. This is where the community needs to pay attention. We are on what, near 0% of the dekstop, so are we pushing for this? Linux used to be making inroads into the server community, lets keep it that way and fix these issues...
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!
It would be interesting to have a standard method of reporting crashes that anyone could put into their programs.
:)
Then have a few servers on the internet that collects that information and allow people to read the results. All personally identifying information would be stripped out.
Plus, the reporting procedure could immediately report back if there is a fix for know crashes in specific places.
It would be cool for a program to crash, and up come a dialog that says, "Program XYZ has a know crash bug that has been fixed in version 2.3.x, upgrade now?"
Been running 2.4.5 on my webserver since the week it was released... no problems whatsoever.. Tried installing it on a other webserver Im responsible for the same week... kept having probs mounting root partition eventually gave up on it.. still running a 2.2.x kernel on it. (maybe I should try installing 2.4.16 on it now)
~~~~~~~~~~~~~~~~
Jon Adams
Don't go to 2.5 until 2.6 is out. :)
Kevin
----- Refactoring is the reason why man does not mistake himself for a god.
Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.2-2 on an i686
No problems with stability here, company mail server 200+ accounts.
I have machines that have stability problems with 2.2 and not with 2.4, I haven't had the vice-versa yet but I wouldn't rule it out.
agua:~# uname -a ; uptime
Linux agua 2.4.12 #1 Fri Oct 19 10:26:27 CST 2001 i686 unknown
07:54:22 up 85 days, 20:18, 2 users, load average: 0.00, 0.00, 0.00
prime:~# uname -a ; uptime
Linux prime 2.2.19 #1 Fri Oct 19 18:24:43 PDT 2001 i586 unknown
05:53:54 up 89 days, 12:19, 2 users, load average: 0.00, 0.00, 0.00
polleo:~# uname -a ; uptime
Linux polleo 2.4.17 #1 Sat Dec 29 22:11:39 PST 2001 i686 unknown
05:56:12 up 18 days, 7:02, 1 user, load average: 0.01, 0.02, 0.00
reverse:~# uname -a ; uptime
Linux reverse 2.4.16 #1 Fri Dec 7 19:10:14 PST 2001 i686 unknown
06:01:26 up 33 days, 10:40, 2 users, load average: 0.08, 0.02, 0.01
As far as the 2.4 stream is concerned, it only works for a typical PC. There are tons of VM problems that set in as soon as you use large memory, SMP hiccups, and both Linus and Alan are ignoring them. Lot's of device drivers are minimally tested, and break from minor release to minor release. If you're a serious linux site, stick with 2.2.19 as it works, as opposed to the 2.4 stream.
I was a big linux promoter in my fortune 100 company, but I'm looking at *BSD for production nowadays.
fact : the 2.4 kernel has not been stable on high end machines (with exceptions)
...
...
fact : in a lot of instances the person installing the kernel gets blamed for the instability
fact : generally people who do get it working are very happy and are proud of themselves, even though that was a lucky strike, and had nothing to do with any abilities they may have or lack
this puzzles me as this is very illogical. Those people getting blamed didn't do anything stupid, and people who did get it working don't realize that that is a chance event (from their perspective). People feel proud because someone ELSE accomplished a working kernel on their system. strange
I remember getting blamed for not getting windows installed properly on this very system I'm typing this text on. The problem was faulty video drivers which crashed the system during the installation. Now I'd like to know how I could possibly replace them
2.4 is so much better than 2.2. Sure, it has warts, but the benefits far outweigh the problems. Its ability to boot so well on unknown hardware is enough of a feature for me. Everything else is icing on the cake.
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.
RedHat HURD baby! Can't beat that with a fistfull of dough...
I installed Mandrake 8.1 on my Toshiba Satellite and have had no problems. Most importantly, my USB wireless Logitech mouse works. It's almost as if...this laptop was made for this disto/kernal combo.
-- A cat is no trade for integrity!
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...
At least with Linux we have a choice! Looking beyond the arguments/discussion of which kernel version is better, I see the bigger picture: Linux is about freedom. The freedom to choose, modify, extend.
because I wanted to play DiVX and games, both of which demand more than a K6-266
I accept that a 266 MHz K6 processor probably doesn't have enough oomph for real-time MPEG-4 decoding, but games should work. Heck, Tetris and Tunneler run even on an 8 MHz 286, and a Tetris clone that uses mode 7 is (barely) playable on a 25 MHz 486.
More recent first-person shooters, on the other hand...
Will I retire or break 10K?
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.
if you have enough RAM so it doesn't swap.
"much better" is not needed if current system works fine. not until server takes such a big load that'll slow it down enough to affect users' work, anything other than security patches are not needed.
Preserve old classics: copy your collection onto all hard drives.
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.
"And we have seen and do testify that the Father sent the Son to be the Savior of the World"
1 John 4:14
2.4.1 -> 2.4.5 sucked (8139too broken)
2.4.10 -> 2.4.13 sucked (vm sucked)
eh, I guess it wasn't that good. I liked 2.4.9 and I am liking 2.4.16. I hope 2.6.x or whatever it's going to be called is going to be better...
I'm still running two production Linux servers (SuSE 7.1), one with the the original SuSE-supplied 2.4.0 kernel, the other with 2.4.16.
Both are running SQUID proxy and the one running 2.4.16 has memory leaks like crazy. The amount of swap consumed grows and grows and never comes down and every couple weeks I have to reboot it. The one running the 2.4.0 has been up for about 90 days now. I'm debating on whether to go back to a 2.2 kernel or just hose Linux altogether and switch to FreeBSD on this machine. These are all Compaq Proliant 5000 boxes with multiple PPro 200MHz processors and SMART2 raid arrays in them. I've got three of them and have already changed over to FreeBSD 4.4 on the one that is my sendmail and apache server. FreeBSD is performing fantastic on that machine.
I have had 0 problems with my systems running kernel version 4.5-RC #0
As a server and a desktop system the performance and stability has been outstanding from this "pre-release" version.
Well, as you must know by now, I am talking about FreeBSD. For servers this is the way to go. When you want V4L features, or joysticks etc..., then get out your Linux dist.
I have no problems with 2.4.17 on an UltraAXi based machine running heavily modified Redhat 6.2. Its under moderate load as an NFS server, and runs some other menial tasks. My only complaint is that pcmcia-cs doesn't work under sparc, which forces me to use my w2k box as my 802.11 gateway. Damn lack of floppy drive slots for the cardreader. 2.4.17 hasn't given me any problems under Redhat 7.2 in my jukebox machine either.
Linux sparcstor 2.4.17 #3 SMP Thu Jan 10 06:12:38 EST 2002 sparc64 unknown
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.
http://www.apple.com/macosx could be a nice move.
I run 2.4.X on my production servers. The first move we made was around 2.4.9(?), and we had quite a bit of problems with it. Lockups, crashes, services going crazy. But we upgraded to 2.4.12(?), and everything seemed to settle down. Other than the initial streak of bad luck, I've been pretty happy with it. Hell, my desktop is even pulling a 50+day uptime with 2.4.13. So it can't be all that bad =)
Can all fish swim?
Debian, Debain, Debian... When I first started using Linux I used RedHat which was ok until rpm madness! When I found Debian it was like waking up to a new world. apt-get is the best package manager and is worth the little extra time learning debian. Use the 2.4.x kernel it will be more than fine. My database server runs for about 90 days at which time I usaully have added a new hard drive or upgraded the kernel. My laptop running 2.4.x I develop in Java, C++ and PHP and it had no problems with 2.4.x and ext3. Good luck.
Forgetting to run lilo is only one problem. As I said, I had one RedHat errata kernel that wouldn't boot on one machine. Even lilo issues aside, I would have been in trouble had I done a '-U' that time.
Is it grub that's smart, or does the RedHat postinstall add some grub configuration? If the latter, why don't they add a stanza and rerun lilo on lilo boxen?
The living have better things to do than to continue hating the dead.
... 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
... X fonts are a pain in the back. Look into your system , youll find hundreds if not thousands of fonts that nobody uses, but those three or four that every app needs are UGLY UGLY UGLY. cant help it but universal truetype is way more elegant.
that he was using Mandrake, and that his installation of Red Hat with the same kernel on his desktop was more stable. The only problem with that is that Mandrake takes the Red Hat Distro and repackages it with different software and some other minor changes. So there is no way for this guy to have had the same kernel on two seperate system and not had any problem on one, he must have done something wrong when he installed the server, I have several SuSE installs with uptimes in the 6-9 month range that run 2.4.x and they have no problems.
"Really, I'm not out to destroy Microsoft. That will just be a completely unintentional side effect." Linus Torvalds
The only problem I've seen with the 2.4 kernel (this seems to happen only on 2.4.7) is that it won't recognize some IDE cdrom drives as valid block devices. It's nothing that a little 'insmod cdrom' or 'modprobe ide-cdrom' won't fix, but it was a major oversite.
On the plus side, it's amazing how flawlessly 2.4 handles USB toys. Overall, I'd take 2.4 ove the past kernels any day.
Transistors and Beer!!
"Say what you like about microsoft outlook but it rarely just crashes. "
:)
OK - I'll bite
Last year I read a report on how most sysadmins spend their time. Guess which application took #1 spot?
And oh yeah - I agreed wholeheartedly....
I've found the 2.4.* quite stable, no problems at all (managed to avoid the really ugly releases). Until yesterday when ext3 decided to go ballistic. A fsck solved it though.
Our boxen all run 2.4.6 and it runs fine (at least for our web and database use). I don't run X or any of that other crap -- it's a production system and I can't see why people are talking about "how fast my window renders" on a prod box. 2.4.* is certainly a whole lot better than 2.2.* (on our SMP systems) so I think it is worth the upgrade to those who haven't done it yet. What is the accepted, 'stable as it is going to get' 2.4 kernel?
Thanks,
--
Matt
If your 4 friends worked in the Pentagon the surely were NOT innocent. Besides while Clinton was in powere the middleeast was calm, it was directly after Dubya that everything fucked up when USA went back to an introvert "we don't give a shit about the outside world" policy. One could have hoped that you'd have leared a lesson after Perl harbour, but nope...
Um, that is what he is doing. Linus is working on 2.4.x anymore.
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.
Recent RH kernels do in fact create a new initrd and add a new kernel config to the appropriate boot loader. lilo isn't rerun, AFAIK, but then, running lilo with a bad config is a good way to break a machine.
d o.
Linux is an interesting contradiction. On the one hand, the GNU philosophy is that everything should be extended and made easier to use, unlike the purist, spartan BSD tools; on the other hand, we put up with crap like lilo for years and years. FreeBSD's boot system kicks ass all over lilo-who-can't-read-fstab-and-figure-out-what-to-
The 2.4 problems loom very large in that scenario, and make it very easy for those opposed to open source in companies to say, "See? I told you they cou;dn't be trusted."
Yes, MS and other big closed source companies screw up all the time, but in those cases the screwups are usually contained, and the customers have someone to yell at, if not sue. But in the open source case, what do they do? Go bitch on /. or in a newsgroup, only to be told, "You get what you pay for. Learn to program, Windoze newbie."
Until Linux has a much longer track record in the mainstream world it has to walk a straighter and narrower path than other projects. This isn't fair, but that's the way it is.
That's right, blame the end user. Heaven knows it wouldn't make sense for the open source programmers to take responsibility for the crashes and fix their buggy code.
I swear, every time a comment like the one I quoted above it seen in public, it delays the mainstream acceptance of Linux by a week. At this rate, Linux will go mainstream sometime around the year 2100.
8 2.4 loaded 2/4-way web/database servers
2.4.5
up 219 days, load average: 2.23, 3.26, 1.27
2.4.3
up 245 days, load average: 1.43, 1.56, 0.46
2.4.16 (2.2 Stablity forced an upgrade)
up 34 days, load average: 2.08, 2.71, 2.71
up 34 days, load average: 1.28, 1.99, 2.01
Still swaps a bit much for my liking though
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 upgraded my two lintel machines to the 2.4 kernal quite some time ago.
One of them, my fileserver, got a new IDE controller and I decided to upgrade it to a 2.4 kernel for better support of the IDE controller. Luckily, this machine only serves files, and it does it over a 10mbps network, so even when it is saturating the network, in no way is it being stressed or strained. Still, I want to move to NetBSD for the file server. This machine is only linux for historical reasons (NetBSD has come a long ways in the past 5 years, and I didn't care for FreeBSD). But I probably won't do that until I actually replace the file server which could be several years yet.
My other lintel machine is my main workstation. It probably will always be a linux box. I upgraded it for hardware support reasons. Since upgrading it, it has been horribly unstable. I usually have it crash at least once a week. I've upgraded the kernel several times (now running 2.4.16), and I update XFree everytime. The main cause of instability seems to be the NVidea drivers, although some times I get crashs that aren't as easy to blame on those drivers.
Frankly, on my workstation, I'm extremely appalled by the problems I've been having. If things don't improve soon (and going back to 2.2 isn't an option on this machine), I'm likely to switch to an SGI for all my development work, then just backport to linux.
I'm a loser baby, so why don't you kill me.
You don't have a rescue CD? Now that is gutsy.
STOP . AMERICA . NOW
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.The fact is, if a kernel is marked as stable it should be stable. If the 2.4 kernel came from Microsoft you would all be bashing the hell out of them. Maybe Linus needs to slow down, and look over his code before he releases it.
Slipping Away...
The Linux kernel is a piece of shit.
2.4.1[15] were badly broken. Many of the ones in between wouldn't even compile, and it's not like I'm running something exotic like a PPC-based Amiga.
2.2.16-22 with Red Hat 7.0 doesn't even compile under the compiler that's supposed to work (kgcc).
I don't know, crashes within 24 hours and user processes monopolizing the machine, doesn't sound much better than Mac OS 9 to me.
Except Mac OS 9 actually has a decent user interface.
Lies about crimes
Well of the 2.4 I was hoping to get USB for one and DEVFS for two. Did I get them? - well not really.
Devfs was a bust for now. Until I have the time to rename all my devices and recode/reconfigure all the programs that use them. Futhermore; it did not play well with software raid. So in the end I had to back off of this.
USB: had more luck with this but noticed something very odd. I have a USB mouse hooked up to it now but forget any autodetect. Still too beta for configuration. I also found that you could remove a module that the mouse required to run while GPM was running. I thought you could never remove a modules if a program had it in use.
AMD Athon support: No go. I had to finally step back to PIII because it could not handle my BIOS right. (K166 chipset.) Furthermore; any support for my Raedeon card was a no go. Still not sure if it was related to the MB or not.
But my biggest beef was this. All of the programs I had created and compiled under 2.2.19 would not run with the new 2.4 kernel. They would all fail mysteriously without any errors. I would have to recompile them all before they would work. I thought it was supposed to be binary compatable.
In the end I have a stable 2.4.12 kernel (I hope), but it was was too hard to get it there.I'm still not sure which kernel _is_ stable considering the problems some of the kernel builds had (eg. 2.4.15)
make Linux, not Microsoft. sin(beast) = -0.809016994374947424102293417182819
Ok, so I want to jump on the band wagon here and remind everyone that ".. its designed around user preference, and development will always have a different feel for each person or user."
To give you an idea, here is my machine:
850mhz celeron (clocked to 1.5ghz),1.5 gb ram, 180 gig raid 10 HD, Ati rage pro 16m, 3comm nic, MDK8.1 with 2.4.17, Logitech wireless keyboard/mouse combo on usb, sidewinder usb joystick, epson 880 usb printer, lexmark color laser usb, sony 21" monitor. I have yet to notice any problems or "lags" in my system. I play kohan and my box also is the head unit for BigBrother monitoring system (28 oracle servers). I also have a qmail server running for my company, and ftp, and file server, and print server, and web sphere, and oracle, and tomcat. Even with 45 users pounding my system, I can still get in a quick game of kohan or quake and no one notices. I love the new 2.4 kernel. But it may not be for everyone but its only my opinion.
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.
Perhaps Linus needs to make a new kernel designation of "Server Stable." 2.4 has been stable for a long while now, but evidently it's not good enough for servers. I haven't had a problem with it on my desktop, but that's not mission critical. Perhaps Linus needs to designate server-stable so that people running servers will know which kernels will hit 5 9's reliability (99.999% uptime)... whereas desktop users like me could get all the nice USB/Firewire features and test out the VM as well, on the "stable" kernel release.
-=Lothsahn=-
Its been discussed on slashdot before, too. Don't you guys worry about these kinds of things? It's one thing to avoid upgrading, but it's another to brag about it in a public forum.
-Mike
After a decent way of intalling them, you need consumer apps compatible with the dominant file formats. Think Office and iMovie.
Lies about crimes
and it was stable?
Guess not!
I find that it's just barely approaching the level of stability needed for desktop use. It still has lots of bugs. If you configure a kernel, it should compile. If you compile a kernel and modules, the modules shouldn't give you errors on inserting about missing symbols. I've had both in the 2.4 series. Lots of little things (like GPL-only symbols) ought to have been held off for the early part of an unstable version, so groups like ALSA could catch up, and have stable utilities to go with the 2.4 kernel. Lots of things still aren't compatible, mostly because of changes made far too late in the 2.3 series. I use it because I need a few of the features, but I find the stability level unacceptable.
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.
That's why I use FreeBSD!
Common sense is not so common.
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
I've been using 2.4 since the initial release and haven't had any problems with it. I never used the 'problem' versions of 2.4, but I have used most of the releases without a hitch.
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.
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.
Pearl, not Perl, and since it's a part of the US, it would be harbor.
The sun rises and sets on the British Empire every what, 12 hours now?
Writers imply. Readers infer.
Even single-server microkernels like Windows NT and Apple Darwin haven't much to offer, being bloated, slow and not flexible at all.
Do you have any facts to support this, or are you just parroting Linux conventional "wisdom"?
You don't think Darwin's microkernel has anything to offer, but you hold Linux's hope in Hurd?!
Lies about crimes
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.
Correct me if I'm wrong; but wasn't GWB also a part of the Savings & Loan scandal that most modern americans refuse to talk about? Or was that Jeb? Or both?
Actually if you take the muslim view, it started when Dubya I put and keep tanks in Musilm terrority. All Clinton did was to continue that policy. I do not blame clinton for the actions of 9/11 I blame 1200 years of misunderstanding how and why the musilm world works vs Western
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.
I had a problem with Mandrake 8.1 not being able to identify my ZIP250 USB drive. On Redhat 7.1 and 7.2, it auto-mounted the ZIP drive with no problems as /dev/sda4 (/mnt/zip250). Maybe that problem lies with the distribution rather than the kernel? Perhaps Iomega USB drivers were omitted from the Mandrake release. This seems logical since under mandrake I could see the device, but not use it. Or, I could just be an idiot! I'm still kind of new to Linux, but a big fan nonetheless.
Transistors and Beer!!
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.
myself, i've had little problem with 2.4 on either the performance OR stability front... my problems have been with those stupid X drivers Nvidia has been releasing, with they're terrible adherence to the 2.4's "way of doing things" and almost complete lack of integrity when it comes to performance and stability.
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 need to experience the true joy of fsck-less reiserfs!
Same thing here, BTW - the only time I ever have to reboot is where X hangs.
Im Mostly a slackware user but I use SUSE and Mandrake as well as debian very frequently. I dont run any servers so I have no idea how good 2.4 is at that, but for the desktop 2.4 had been terrible. Its just not stable under Mandrake I cant install new rpms if Im using 2.4. Kde runs like garbage. Under slackware its noticabley slower and less stable (it screwed up lilo a half a dozen times, im sure it was the kernel because when I switched back to 2.2.12 the problem went away) Under SUSE its okay, but it makes debian far less stable. My fav kernel is 2.2.19 since it does almost everything 4 can do and far more stabely. Maybe its just me. Maybe im the only person who has noticed this. Maybe the kernel hates me but after all the crap its put me through i think ill stick with 2.2 at least until 2.6 comes out.
My experiences with 2.4.x kernels have been very good. I am long-time Linux user (since -94) and Linux has just got better year by year.
;)
Keep the good stuff coming!
btw: Could someone (who actually knows) tell us if the new VM stuff (which is ok IMHO) is going to ship with next RedHat release?
Before 2.4 there was all this thalk about "When is 2.4 going to come out?" Whine Whine Whine. So maybe that addes a little extra pressure to release 2.4 a little early. SO now you have it and you are not happy.
I think everyone should use the hell out of 2.4 so all the bugs are found and then the world will be a happier place.
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...
Ive had a few issues with DMA. I have 10 & 8 gig HDs. Both of which are trying to 'write over the end of the drive'. Which is fairly odd. The 10gig has been the most trouble. Has caused 1 lockup, and 3 reboots. :\
--------------------------
Is this a sig?
--------------------------
Well. I've had a few problems with the 2.4 series. But im just running a desktop. I'm running 2.4.16 right now and I get lockups occasionally, but I'm not acctually sure that the kernel is the problem. previous 2.4 was worse. I am not a particularly experienced linux user and I do have this to say about unstable kernels. They make it alot harder for newbie users to track down a problem. Ther are enough problems between the keyboard and the chair, I dont need problems with the kernel too. I'd like to be able to say, hey my kernel is totally stable so if my machine locks up it must be X, or program blah. Usually when my system locks up i can still ssh in, so its probably not kernel. but sometimes it locks up and it cant even be sshed into. That could be kernel... I'd like to know that its not.
I noticed a huge amount of instability from revision to revision - I do have some 2.4.x kernels running on certian sparc machines (where ip filters is needed), but there are certian annoyances present that I could go into great detail with.
Like for instance - hmm the dhcp server isn't responding - well its pinging okay, still not responding. Restarting the dhcp server doesn't help - the only thing that does is restarting the interface - really really wierd.
Majority of my problems are X related. Specifically, Nvidia related.
/proc/kcore > /dev/dsp
Check all your packages. I will sneak a peek at what the latest Redhat runs from time to time. X 4.1.0 is a good choice. I don't use the preemptive patch just yet but I may give it a try.
Has anyone experienced problems with Quake3 Arena and Glibc 2.2.4 ? DGA support seems screwed period. I'm using the Alsa drivers on a Awe64 gold so the sound is fantastic.
cat
Why not build a Micro GUI as QNX, when there are so many embedded application platforms comming?
The whole compile your own kernel and use lilo is a disaster from a user standpoint. People should simply not have to deal with this. I can tell you if the windows kernel required this, I would buy a mac. Its no fun when you pick one wrong item to add or not add to the kernel and now part of your system does not work. Even worse you mess up lilo and get LI or something similar on boot. Lilo should die, and so should have to compile your own kernel, replace systemmap, edit and run lilo,etc etc.
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
Since NetBSD doesn't run on i286 but DOS does this is a quite a matching analogy...
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
let's go back to pre America, 1776. i'll bet you were the one running around in town saying, 'Why not drink English tea?'.
looser.
If you need a 2.4 (I need for my hardware), use 2.4.9. The last kernel before the new VM. It may not be the fastest kernel out there, but it is quite stable. But definitely do not anything between 2.4.10 and 2.4.17.
Huh ... interesting. What hardware are you running on? Just curious, since I read a report on LKML (the thread is the flamefest-titled "Rik spreading bullshit about VM" ^^; ) where someone was hypothesizing that that very range of kernels might be kind of a "sweet spot" for the AA VM ... at least on their hardware, I guess.
Personally, I haven't really had any problems with 2.4 ... the only bad thing I've had happen is an odd oops using 2.4.13-ac8 which I still haven't looked at the screen for that much. Of course, there might be other issues at play on my system since I did a Very Stupid Thing with the kernel headers ... An interesting thing though, I couldn't run a self-compiled X under 2.4.14 (IIRC), the binaries kept segfaulting until I did that VST and changed what was in /usr/include/linux and /usr/include/asm (I know ... ^^; now I know better). However, that change is probably going to have me go and recompile a lot of software on my system now after I change the headers back to what I had on the system at the time. (Or just rebuild my entire system :3 ) (Yes, I'm one of those linux from scratch weirdos ... )
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
Model XL300 I picked up for $300 and about $200 in parts. Was running 2.4.2 on Slackware 7.x fine for about 7 months until trying to upgrade the kernel. Tried 2.4.10 - 2.4.17 and none of them would even build. There's some discussion about CONFIG_HOTPLUG on 2.4.16. Although this issue deals with 2.2.20 the asm/pci.h hack was necessary to get 2.4.9 to build. But, that one wouldn't boot...
I finally found the 2.4.9-ac1 (an Alan Cox) kernel builds and appears stable. This isn't a complaint, but there were some concerning points made in discussions about kernel branches in researching how to get this kernel in place; one in particular a couple weeks on Slashdot.
Again, this is not a complaint: the XL300 was originally targeted for the NT 4.0 market. Guess what....
Linux tempe 2.4.9-ac1 #1 Tue Jan 15 11:04:17 MST 2002 alpha unknown
www.dedserius.com
VB != VisualBasic
couldn't you somehow enable the talkback feature for kernels that are running on top of another linux kernel? that way, they can dump their contents to the base kernel and it can handle the talkback..
check out my comic: Essential Tremors
I've installed Mandrake 8.0 on my new Compaq 7000
/home is located on the trusty maxtor drive (No badblocks either).
(1.3GHZ AMD w/256MB DDR Memory and a BIOS that sucks! you can't overclock with this bios) anyway
I've got IDE and SCSI devices. 1 60GB IDE (Maxtor), 1 60GB Wstern Digital (Sucks!, I had to reformat and ceck for badblocks for all operating
system on this drive). DVD Drive, CDROM burner,
1394 Firewire (works great with kernel 2.4) 4 USB ports (Keyspan USB to 4 port adapter, Belken 4 port USB hub, Lexmark Z52 printer) All USB devices
work flawlessly, Nvidia Gforce 2 Video card works great!, Sound Blaster Live (works great!) Adaptec
2940 SCSI adapter (works great!) HP Scanjet II (works great!). HaughPauge WinTV Theatre Card
Works great! I'm using V4L and Zapping! I've also
been playing around with creating family video CDROMs. I might buy Main Actor, for now I am
using the vcd tools to create the vide CDs.
Because the box is a Compaq this box is dual boot.
It's much more stable when running Linux. I only
use windows to attempt to reverse engineer drivers. I've got one of those Polaroid printers that print to polaroid Spectra film, it's pretty cool. I'm still working on the code that logs the
dialog between the PC and the printer. Once I get the dialog recorded I can possibly start writing my own driver.
The only time my box running 2.4.x locked up was
when the bad blocks on the shitty Western Digital Drive upchucked on a badblock, so I had a previous backup on my Ecrix drive, I reformatted and checked for bad blocks, reloaded the OS, all set.
I haven't had a problem since, but I still don't trust the Western digital drive so my
The tweeked 2.4.x kernel that shipped with Mandrake 8.0 seems to be very stable.
I upgraded from my trusty PPRO 200 because I am
teaching myself Oracle 9ias on my new box.
Oracle on Linux, it's pretty fast, bat man does
oracle eat resources!
*thinking out loud* maybe, just maybe, Microsoft has planted code trashers somewhere among the Linux kernel development chain? because we know that they've AT LEAST hired them away from it.
*thinking out loud* maybe, just maybe, Microsoft has planted code trashers somewhere among the people who contribute to Linux kernel code?
How hard is it to poll XFS for fonts? KDE and StarOffice (5.2) don't seem to poll for the fonts - I can't use any of my lots of fonts! I want TTF on my desktop! (I don't know enough right now to go code hacking ...)
Not being a smart arse/troll or whatever... I presume you have looked up the info on XFS.. There is a TrueType font howto at linux.org.
I found that when I cut over my Windows TTF fonts, there were a few duds and this (when creating mkfontdir etc...) that stopped the WHOLE directory from working... Try cutting your fonts over in small chunks... (Alphabetize in seperate dirs if need be)... should work ok..
KDE & Star Offfice are fine with TTF's
KOffice works with em ok.... And my desktop uses TTF's
Burma?
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.
So what's your point? Here's what I did: I got an old Word 97 CD that nobody uses anymore and stole all the fonts from it. Add that directory to X's font path and BINGO. Universal anitaliased bliss ^_^ Then, if you're so inclined, remove the old bitmapped fonts' directories from the font path and you never have to worry about them again. I didn't have to patch the X server or anything special. (Well, I did have to run a program to generate scaling information in lieu of running xfontdir, but since you'd have to do xfontdir anyway ... ) Of course, it's probably good out of principle to keep "fixed" around ...Mind you, I haven't tried the version of this story involving "kill all the old X fonts" yet :) However, there's nothing wrong with Truetype support under XFree86 4.1.0, certainly. I haven't looked at a poorly rendered font since I did this ... and it's not like it would be terribly difficult for distributions to do out of the box. The only question is where do we get the free TT fonts :) And I'm not even sure if that would be a problem.
As far as I know pre-emptive multitasking is a basic feature in ANY Unix. EVERY linux kernel (and BSD kernel, and Mach kernel ... ) does pre-emptive multitasking.
"But what about the pre-emptive patch?"
That makes it so that a process in kernel context can be pre-empted. See, Unix processes generally run in two modes: user mode (userland) for your general computation and boring stuff like that, and system/kernel mode for stuff like requesting hardware access. Normally when the system is in a kernel context a task switch isn't allowed, so the kernel can't be interrupted (pre-empted). Robert Love's patch changes this so that a process can be pre-empted at any time, even when it's context-switched to be in kernel mode (assuming it's not in a spinlock, etc.)
Graphing kernel releases vs. time is always interesting :) (Especially with that 2.4.15/2.4.16 snafu ... hey, 24 hours between point releases. Oh well, no Universal PnP bugs ^_^; ) Especially if you track every "official" release, including -preX releases.
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.
Always nice to see people booting INTO linux for gaming :)
I have been using Linux since July of 1998. My first install was Slackware 3.5. I fell in love with it almost immediately. I watch closely for new kernel releases and was always happy to install and compile the newest kernels, until 2.4 came out. Kernel 2.4 has been a disaster on my laptop, one problem after another. Most of the problems have been about power management. I tried many times to help diagnose the problems but it seems that the people working on the kernel are to busy to deal with my problems for now. Each minor release of the kernel fixes a few things and 2.4.17 is almost as reliable as 2.2 was on my laptop. Some day it will work good but until then I will keep hoping.
Many of the problems I had with the kernel relate to the radical changing of features in the kernel between minor releases. Example, between kernel 2.4.8 and 2.4.10 the modules for PCMCIA where renamed, that is very poor project management. These kind of problems would not have happened if there was a better form of project coordination between the kernel developers. I would like to see a set of rules for the development of the kernel that clearly define what changes are allowed and what must be reserved for different branch of the kernel version. I would also like to see a better effort on the part of the distribution makers to insure flexibility when installing a kernel from source that is not part of the distribution. I run Mandrake on my laptop, I can not use the Mandrake kernel RPM's because they brake more then they fix. I consider Mandrake inflexible as to the kernel because for me to download the kernel source (not from Mandrake) then compile it and use it I have to change a lot of scripts that Mandrake adds to my system.
I run 2.4.17 on my new server and it works great, so far. It started with 2.4.7 and I upgraded it. I found that it now runs about 50% faster and uses about 60 MB less RAM, just from changing the kernel.
Linux has problems, nothing that can't be solved. It is light years ahead of that other OS, what ever the hell it is called this week.
Linux wins again!
Off-topic? Stating the ironic quirkiness of 2.4 in a thread about problems people have been having in 2.4 is off-topic? C'mon. The 2.4 series has had a few problems. I haven't had them. I don't want it to be true, and I fervently wish it weren't. But 2.4 wasn't a joy-ride for everyone. While this post was a little too cynical for my tastes, it wasn't off-topic. Hell, it wasn't necessarily too wrong, either.Moderation Totals: Offtopic=1, Insightful=1, Total=2. (Score 2: Offtopic)Why was this modded as such?
I blame a bunch of fucks with knives and a bunch of other fucks cheering them on.
Not being a smart arse/troll or whatever... I presume you have looked up the info on XFS.. There is a TrueType font howto at linux.org.
X knows about my fonts: I eventually figured out that X wants permission on boot (that does *not* include ~/fonts...), but read on:
KDE & Star Offfice are fine with TTF's KOffice works with em ok.... And my desktop uses TTF's
Apparently, my problem is isolated: I cannot figure out how to get KDE to notice the fonts in the look&feel-->fonts section (kword does the same thing: no Sherwood etc.). Anyone know how to make this work? (plz. email me --mike@nospam.igs.net
Much annoyed since I went to all that trouble for X...
MIKE
Beware the JabberOrk.
Mostly 2.4 has worked nicely for me, but a few things have been a bit annoying - the VM was at some point quite painful. Lately it's been quite OK and now (2.4.17) it actually feels like it's working the way it should be.
Also, I encountered twice an annoying bug that caused some process to end in state that made it unkillable. That was not particulary bad, but when I noticed that trying to read process information with eg. ps or top caused the reading process also to enter similar state, I was quite stunned. I haven't seen the bug around since 2.4.15pre7 (which didn't supposedly have the filesystem corruption bug yet); both 2.4.16 and 2.4.17 have been working nicely. (Yes, I reported the bug. ;)
But all in all, the good features (like stateful firewalling etc.) have been nice and balanced those trobles I have had. For someone else, the same may not apply.
Everyone who makes generalizations should be shot.
Most of "US" make dep ; make bzImage ; make modules ; make modules_install && depmod -a ; mv $src_dir/bzImage /boot/newkern_$ver && mv $sys_dir/
/System.map$ver && do_lilo_change /boot/
System.map
newkern_$ver
But pussies will be pussies.
> Is 2.4.x really as bad as this author makes it sound? I mean you'd think that the stuff he's complaining about -- it sounds kind of common -- you'd figure that people would have run into it during 2.3.x?
There was no 2.5 development tree until just recently, so the kernel hackers had only the 2.4 tree to test new stuff over the past year. The problems relate to post-2.3 material, stuff that didn't get shaken out until *much* later. And, between 2.4.9 and 2.4.15 there was a new VM subsystem with its attendant shakeouts.
So no, 2.4 'til now has *not* been a purely stable kernel series as one would expect from its number. It will be much better from now on, though. FINALLY.
If you worked for the government you weren't suppose to disclose the details of your projects. Hasn't security become tighter especially at the moment. Hell you probably just let Osamma know your runing 2.4.2 which probably has some choice exploits within 7.1 Redhat.
Graitious man!!!
hahahahahah
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.
God, what a bunch of shit Linux is. If I had had anything near this amount of problems with, say, a Microsoft OS release, I would be on the phone getting them to support the hell out of me, and if they couldn't do it I would be able to sue them for the lost time I had experienced (read those corporate license agreements, idiot OSS FID boys).
No such luck with Linux, dimwits.
An article by Michael J. DeMaria over at networkcomputing.com.
The problem with getting your own kernel is that you then have to be intelligent and responsible about picking a good release, especially with 2.0 and 2.4 series. (Wasn't 2.2 generally better more stable than either of the before and after releases?) Then you have to choose which, if any, patches you want or need.
Then comes the simple stuff you mention. That's the easy part. Selecting the kernel and patches to build is the hard part.
Or, if you don't feel like putting the time and energy into it at the moment, have a little trust in your distribution. At that point, there's usually little difference between 'rpm -i' (or -U) and walking through the build steps yourself, except that you build a bunch of unneeded modules.
The living have better things to do than to continue hating the dead.
Honestly, the Linux developers will probably learn from their mistakes and recover well enough to keep those releases coming. For those of you who like using Linux, that's what counts. Everything else is fluff.
The comments I've recieved from my above words has ranged from total flames to actual good advice (thanks). Perhaps I was over reacting. I actually (as of yet) have not noticed ANY major problems with the various 2.4.x kernels I am running. I'm assuming this is based on pure luck, or I'm just not doing a whole lot with them. I am an end user of Linux, meaning I don't actually participate in the development of any major open source projects (except the occassional one written in Perl). I am learning C though in hopes of one day being able to get involved in the process. Until I can, it makes me kringe everytime I hear a 'beware' story about a certain asspect of Linux. Guess that just comes with the territory.
... it should be "distro of pain" referring to Mandrake.
I have been running numerous Red Hat versions on small-time servers while I had a VB Programmer friend (forgive him for he does not know) dorking around with a Mandrake distro that has been given him tons of problems.
In all of my 6 young years of SysAdmining (is that a verb?), I have never fathom running Mandrake for a server. Never been told otherwise but I was under the impression that Mandrake is more of a desktop distro rather than server distro.
Slackware or Debian for the servers? Definitely. Maybe SuSE or even Red Hat if I am desparate enough but Mandrake. eeek.
ChozSun
ChozSun.com
Apple has increased support for mounting shared drives. You can now connect to servers via AFP (AppleTalk File Protocol), SMB (Server Message Block), NFS (Network File System) or Samba servers. I was able to connect to my Microsoft Windows NT box by typing smb:// Borgcube/share me and supplying my Windows NT user name and password. You cannot yet browse the Windows network, so you must know the server's name and shared directory before you can connect.
That is funny, I setup a Linux server running Samba and Atalk and MacOS 9.x and 10.1 people can see the server in the list of servers and double-click in order to connect just fine.
Why are people running NT for file serving?
ChozSun
ChozSun.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
"Then you're doing something wrong."
yeah, right. install, boot, run program that came with the distro, hang. repeat. what exactly could i be doing wrong in that scenario?
There are a lot of very educated Linux users and developers who post to /., and this seemed like the most appropriate thread to ask this. I sincerely hope this is not construed as flamebait.
I'm currently running Win2k on a Pentium 350 with about 384 megs of RAM. Besides the RAM, the system is fairly standard. For the past two years, I have really, really been interested in using Linux (or *BSD), but it is precisely the nature of these posts that is scaring me off. Win2k runs fast on my system. By fast I mean that the windows manager is quick in responsiveness, that windows can be dragged around quickly and programs load in a "generally" snappy manner, even with all the background tasks and open windows.
My question is, how does this current release compare with Windows on a "basic" system in terms of general application usage? It was mentioned that there were WM problems in 2D display; is that a problem with the WM or with the kernel itself?
I have a hundred other questions but don't want to be any more off-topic. Perhaps I can post it to an Ask Slashdot... anyway, thank you in advance.
don't reboot just because x hangs !!
try using ctl-alt-backspace
it stops the X server and xdm will reinit for you
and give you a fresh login screen
or try using the pseudo ttys by pressing ctl-alt-f2
and you will get a login prompt where you can
log in and kill the stuck x session
When I upgraded to 2.4.17, my machine has since begun experiencing random (and quite violent) crashes.
The kernel OOPS is different every time, but it almost always ends on talking about how the interrupt handler has died.
I'm running on a VIA motherboard with an K7 - but it worked fine under 2.2 so I believe it's the kernel.
Quite depresssing. I started using ext3 because I could reboot quicker after the crash. I need to run v2.4 for the improved driver support.
Scott.
# uname -a
SunOS crystalite 5.8 Generic_108529-07 i86pc i386 i86pc
# uptime
7:57pm up 126 day(s), 4:44, 5 users, load average: 3.5, 2.87, 1.11
#
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...
A new Slashdot article has cleared up my misconceptions and provided this link:
3 4. html
http://www.linuxdevices.com/articles/AT82672987
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.
You still seem confused, although some of your facts are correct.
You say Darwin is bloated, yes. It needs 96MB to perform, and it's pretty monolithic. Sorry, Darwin is not monolithic, it is based on a microkernel. Linux OTOH is monolithic.
Yes, everyone has read the exchange between Tannenbaum and a rather immature Torvalds. And everyone with a brain realises that Linus' opinions are just that, opinions. This may come as a surprise to you, but he is not a god, and he gets it wrong quite a bit.
I still can't tell if you are supporting microkernels or monolithic kernels. And I still don't understand why you think Hurd will be this wonderful thing but Darwin is not. They are both based on Mach, you know?
Lies about crimes
As for Free Software Licenses, neither BSD style Licenses nor the GPL do much to protect the interests of the individual coder. The point is that the GPL is trying to protect (your) community of individuals, and the freedoms of human society in general againt private interests - advancing civilization without repressing individuals. With BSD styles, you reserve the right to privatize your code at a later date.
As for the harsh realities of today's corporate environment, there may be a good reason to Free Software license your useful code, even without humanitarian intentions. In a hiring situation, having publicly released useful code can be as good as a reference, and differentiate you from somebody who is similarly qualified. If you used a BSD style license, then there is a greater chance that they might even be using your code. If you are looking for a job, then what better contact could you have then a company that is already using your code! Just point at your name on their product's Copyright Statement, and you become very valuable. Then they brib- er, pay you generously, and your valueable software can potentially become a competitive advantage of their company, especially if it hasn't been widely distributed yet.
Of course, maybe you don't need such leverages. But don't discount the practical value of public recognition.
If you as a corporate entity are realeasing Open Sourced code, then the implicit assumption is that you don't have the talent or resources available to make some valuable enhancements to your code base. If you did, then you would keep the code proprietary, and the resources spent would be the investment in a competitive advantage.
.sig says "Information wants to be anthropomorphized." The GPL and the BSDL are tools, they are not friendly. The clever corporation will find an entepreneurial use for them.
As an Open Source proponent, you suspect that there are external parties capable and willing to enhance your code - but with a BSD license, you are betting on the fact that none of those parties comprise a competetor, or else you just gave SerpentCorp a competitive advantage. They can make those enhancements, and give you lip service while usurping your profitable prey using their "empraced and extended" EvilViper Plus, with new tighter constriction libraries!
No, you know full well that there are no corporate pretenders to your ViperSuite crown, just foolish mice who will improve your SerpentSoft for free, while you reap the profits. Unless some self-righteous bull... yak?.. no, a GNU comes along and GPLs a the highly valuable Venom function you were counting on, and before you know it the GPLed fork of your program has integrated "Antidote" to the weaker "poison" you included in the original BSD release.
But then again, the GPLed version of ViperSuite is shaping up as a powerful implementation, and even SerpentSoft couldn't outpace the Free Developers, as your original idea was a really good one. Now FreeViper has all of the functionality you need, it is just missing some of your proprietary features. So you still have to release your code with a GPL compatible license, and then work to integrate it into a poorly maintained and undocumented mess of FreeViper. At least you don't have to worry about SerpentSoft eating your lunch, everyone can use your code. Too bad you are playing catchup at this point.
If you had released as GPL in the first place, then you could have maintainted the coherence of the codebase, you project would be available, but you would have the recognized "Official" code base. Linus can take Linux where he wants it to go, and in general, he will be followed. You have the advantages of a deeper insight into the program than any competitors, and you will have meticulous documentation, which only those who pay for "premium" support will have access to.
When you Open Source your valueable but limited program, the important components will be filled in, making your proprietary but "more complete" version less valuable. Unless you are a modern day software superwizard, your code is probably not as valuable as the comprehensive support of it that you can provide once it is deployed.
As a subscriber to the benefits of Open Source, you probably see the value in avoiding unneccesary forks in you code. This is especially true if your talented competition has improved your project. As a BSD licensed Open Source product, your competition has no incentive to release their improvements, just a reduced cost of entry in becoming your competetor, and the abaility to hit the ground running. As GPLed code, your creative competetors' code, if ever distributed, will be available to enrich your product. I have read anecdotes where A company has released code under the GPL by necessity, while their lawyers restricted similar contributions under BSD style licensed products. The bottom line is that there is no justification for contributing code back to BSD licensed projects, only potential liabilities, and they must answer to their shareholders. On the other hand, GPL code can provide a better platform then starting from scratch, at the acceptable cost of contributing enhancements back to the source. It makes good business sense, and helps the Free Software community.
To focus on your two points,
1) Under GPL, their value added features get sent back to you. Under BSD they can usurp your code with a significantly enhaced version.
2)If you publicly release your code, the public one may match or even surpass your proprietary one. A free competetor is not a non-issue, your intention is to keep it a trivial contender. The oversight is that you only control half the equation at this point. With a full GPL release you remain within a maintinable delta of any OTHER version, and simultaneously decimate the value of any pre-existing competition. You then have the leverage of controlling the "official" public product.
A very clever Slashdot
-castlan
It offends my senisbilities when your karma bonus gives You a (Score:2) while an earlier post by mosch is down-modded, despite being the same content presented in a clever format.
So I choose to pick your nits, as your post is obviously more valuable. (I am kidding about this, though you might be more deliberate with your bonus next time.)
It seems fairly evident that faster has a specific meaning in the above statement, which is likely not the interpretation you used. The BeOS is fairly well known as a very responsive system, especially the GUI, which helped support its hype about being the "Media OS". It also used the BeFS, as highly performant file system comparable to XFS, as some former SGI engineers were involved in Be's creation. Also, it could conceivably refer to the efficiency when scaled across multiple CPUs. The claim is that BeOS is highly performant with SMP architectures, as it was designed to maximize performance with multiple sub-par CPUs for cost effective power (when 4x500MHz is cheaper than 1x2GHz of the same core CPU.)
For the most likely comparison, GUI responsiveness, The BeOS GUI is such that a text mode display is considered superfluous. The full system with GUI will boot far before any similarly useful installation of "Linux" or FreeBSD on the same machine, even without waiting on XFree86. Be GUI apps will launch in stingy fractions of the time of GNOME or KDE apps, and the managed window will have an independant thread (process) running before the app is launched. Whether it is the toolkit, environment or the implementaion of X11 itself, acting on an X controlled app will tend to lock the interface for other X apps, even niceing Xfree to -10 will only help the responsiveness of the app you control at the time, blocking the other apps. If you have ever tried the BeOS then you will find the quality of the interface smooth when compared to most other systems. with sufficient hardware Windows will also feel smooth, but not as crisply responsive. And don't even try to "outrun" your dragged window... the mouse can tend to get ahead of the window with XFree. The only objection to "faster" is that hardware 3D support was never as widespread, so OpenGL performance was CPU bound.
As for the File System, is FreeBSD's FFS faster then Linux's EXT2? I don't think so. Even using EXT2 on FreeBSD isn't as performanct, even if there is a good reason (Linux writes asynchronously in a haphazard manner). BeFS performance felt rather good, I'd need to see some benchmarks to believe that Linux, much less FreeBSD was "faster" with disk access. Is is likely that with SoftUpdates enabled FreeBSD files can be deleted faster than with Linux or maybe even BeOS, but that is of much less value than BeOS's innovative use of metadata to perform neraly instant file queries, and the metadata journal which allows for trivial boot times, despite unsafe shutdowns. It would be interesting to devise a benchmark for filesystem journal performance. It would likely involve huge disk volumes, which reminds me, BeFS has XFS like 64 bit theoretical volume capacity. While BeFS hasn't been stress tested quite as fully as XFS on IRIX, it is more than likely capable of scaling beyond FFS, and XFS on Linux (which is limited by Linux VFS interface).
As for SMP scalability, BeOS beats Linux 2.2 and FreeBSD hands down. I know of no benchmark comparing BeOS to Linux 2.4.x, but to even consider FreeBSD's SMPng would compromise most of the other advantages FreeBSD would have over Linux or BeOS. For this category I have to assume that BeOS beats Linux which beats FreeBSD (so far).
You may refer to my previous post concerning "free", which supports that "FreeBSD may be freer" as opposed to "easily beating" the GPL version 2 which covers Linux. BeOS is less free than both, though there is the freely available FreeBeOS. There is also an OpenBeOS reimplementation project in the works, which is addressing this issue.
Easier is subjective at best here, though there are some distributions of Linux which have a simplified installation which is far easier than FreeBSD. Administration is another matter altogether, FreeBSD tends to be better in this dept., and in a more universally applicable manner than most Linux Distros, though some may find some Distro specific tools "easier" than raw text files. Ease for the end user is not inherently different between Linux or FreeBSD, both are dependant on administration within the UNIX framework. BeOS, on the other hand, is trivial to operate compared to Unix systems in general.
If you are considering SMP workstation systems, then perhaps BeOS fits better then both Linux and FreeBSD! Of course for single proc or multiuser systems FreeBSD tends to be better then Linux, but since Linux 2.4 it is not an easy win by any means. Perhaps SMPng will outerperform Linux 2.4, maybe even BeOS. But by then, OpenBeOS may well be useable, bringing it back into the running! (Okay, not bloody likely, but that would sure be snazzy!)
You are right, in that those reasons you responded to all apply to Windows over Linux. In the very first paragraph I said "there is primarily one family of reasons why a Linux based operating system would be preferred, followed by a gaggle of reasons that I personally value less at the moment. The family of reasons I refer to have less to do with the Linux kernel, and more with the GNU system that provided a useful place for Linux to nest, gain functionality and eventually popularity superceding the original GNU project. "
The paragraph that you chose to repond to is the very group that I "value less", which is why they were so briefly stated. They are rather unimportant, as technology is always changing. I spent so much time on the long winded part because it is the more important part - in my opionion, that is the answer to your question. The first sentence of the Rant sums it up: Linux is popular for political reasons over technical reasons. Over time, any technical shortcomings can be addressed. the GPL, even if it isn't in all the headlines, is the root of what has unfortunately become the "Linux buzz", as it represents a major shift in the politics of computing. I do apologize for the length... it wasn't strictly necessary. Everything after the first few paragraphs is merely an attempt to support the earlier assertions.
Another way of looking at this: Linux is not technically superior to any other Unix. That does not mean that it isn't more valuable To society. OpenBSD, for example, is a specific tool for people who have a defined set on needs, as is Irix. Linux represents more than just an expedient technical solution.
-castlan
Not to suggest that Linux or its hype inspires greater longevity than any other GPLed OS... I just wan't aware that there were dozens of other GPLed OSes that failed. Linux was the first kernel available that enabled the GNU OS AFAIK. Aboritive previous attempts that were never completed didn't cross my mind when I made that statement, so maybe you can disprove me. Can you name some failed GPLed OSes that are no longer available? (I won't even ask you to name "dozens".)
If you are willing to further humor me, back into the post-apocalyptic future we go, where all surviving corporations are Free Software hostile. Those depending on FreeBSD derivatives are not contributing back to the lone FreeBSD maintainer. He dies of Radiation poisoning, the the existing Stable version is the last useable OS which is recognizable as FreeBSD. Derivatives just "contain code from" the late, great FreeBSD.
At the same time, The dying Linux maintainer competes his automated Revision Control System, which makes it trivial for those Corps who are still saddled with a Linux foundation to fulfill their duty of resubmitting changes. Various companies are all in sync with the Offical Latest Stable Linux, which by this time is fairly stable and experiences very little feature creep. The few obscure bug fixes made by the remaining corporations are trivial diffs which are automatically applied to a newer, still stable working kernel. The last Linux maintainer dies a horrible death in peace, as existing governments still require that pre-apocalyptic licensing requirements be kept. Companies are careful, thier changes can't be harmful because their continued existence depends of their copy of Linux functioning, which translates in to the official repository functioning. The system is not infallible, as a malicious contributor could make a malicious patch, which would be analagous to a murder-suicide. Except that the next company isn't interested in dying too, so they spend to effort to fix the evil patch purely out of self interest.
I would think that logically, companies would want to avoid the restrictions of the GPL in favor of a less restrictive license - until I realize that the GPL is very permissive compared to many of the proprietary licensing agreements that many companies are still subjecting themselves to every passing day. If I were a company, I would think that I would want absolute control over my product, and avoid ALL licensing that isn't Public Domain, or at least BSD style. I suppose there are non-obvious considerations in-practice.
Section 9 of the GPL states
This means that the worst case scenario is that the GPL is no longer a strict Copyleft, $10,000 can buy freedom from the GPL restrictions. Even if this new Proprietary GPL disallowed any redistribution whatsoever, then the GPL v2 would still apply, at your option.
Despite it's potential problems, you may Interested to know that Linux specifies Version 2 of the GPL, so that even if your proprietary GPL became a reality, it wouldn't have any effect on Linux.
Cheers!
-castlan
Lets go back a step then. I assumed that you were a Proponent of Open Source - are you? Why should you release your code to the public at all? Is there any reason not to just keep all of your code proprietary? If not, then you really should have represented yourself as against Open Source much earlier, so that I wouldn't have wasted my time on the obscure, finer points of discussion.
-castlan
I would not consider FFS definitively faster than Ext2, because softupdates aren't yet considered standard. Softupdates are still be considered less stable than vanilla FFS, though I won't claim that Softupdates make FFS less stable than Ext2. I'd only argue that FFS + softupdates should be considered distinct, much like Ext2 + journaling is considered a distinct Ext3. I do believe that it should have been called Ext2j, as it really isn't different enough to warrant a new number, but that's my unqualified offtopic opinion. Right, Linux does tend to favor performance over stability, which while a negative tradeoff, does pronpt my doubt of any "solid hands down" judgement when it comes to performance.
/bin/su wasn't.
You are also correct in that the performance of the BeOS is independant of its boot time, but not for the reasons you state. Personally, I don't find that Windows 95/98 boots noticeably faster than NT/2000. Without Citrix, it's hard to consider NT multiuser, and completing BeOS multiuser would take much less work then NT did. BeOS is more like Windows NT then Windows 95, in more ways than one, from memory protection to kernel architecture. While it was released as a single user OS, it had multiuser foundations that Be never prioritized enough to activate, much like the GUI was designed to be network aware (like X), even though it wasn't utilized. It had full file and memory protection, but the standard user was always root. You must not have been paying very much attention to say that the BeOS didn't have multitasking _anything_. I have read complaints from BeOS developers that the BeOS was forcibly "too pervasively" multithreaded" (multitasking) in just about every aspect, from the Gui to the filesystem. "Threads" had to be grouped into "teams" just to make applications manageable (pain in the ass killing 6 threads individually if your word processor hangs). You needed to get a Slay utility because kill -9 was too thread specific. A significant difference (that severely fouled my attempts to compile BASH from source) was the completely non-standard (read: non-POSIX) threading and process priority system.
One positive thing about Be's multitasking and memory protection, was that when it choked on a website (Net+ was a fairly weak browser) it would pop up a dialog box asking what I wanted to do about it. I would push the Dialog to the side, and continue browsing as if nothing had happened until I was finished, sometimes a few hours and a handfull of links later. BeOS never cared, it was much more polite than the Unix standard "kill 'em first, ask questions later" way of killing the app you're using (then Netscape lock file yadda yadda...). Trust me, multiuser/multitasking file and memory protection was in place, even if
Just let me point out that even if you tweaked FreeBSD to run everything near real-time priority, it wouldn't do much good... you would fairly well cancel out any "near real-time" bonus, as that strategy only works considering the delta between process priorities. Actually, AFAI remember, BeOS priorities ran along a scale around 0-95, with >85 considered "near real-time", and the Idle thread at 0. The GUI ran at "standard priority" of 35, media players ran I think at 45, and Distributed-Net's client ran at 1. Pushing e.g. the desktop thread up too high (near real-time) would reduce performance, as eventually the keyboard task wouldn't get enough cycles to be tolerable, or something else. GUI performance was purely enhanced by the superior multitasking. The main reason that BeOS booted so quickly, was that unlike Windows and most Unices, there was very little in the way of legacy/backwards compatibility. To tweak FreeBSD to match BeOS, forget about priority settings. Even making X really not-"nice" wouldn't match the BeOS' UI qualities. But an especially optimized, low latency Pico-BSD would be a good start, and XFree86 has made major improvements in the multithreading department as well. The biggest limitation at the moment is probably finding a very modular and well threaded WindowManager and GUI environment to run atop it.
Just in case you might care, The OpenBeOS project is using a BSD style license, so perhaps some of their UI might someday come in handy for improving BSD user experience.
-castlan
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