On Mon, 1 Oct 2001, Karl J. Runge wrote: > Do we mean "rocks" or simply "does not suck"?
Or even "sucks less" or "sucks in a different fashion"? > I have not followed the kernel development mailing list for a very long > time... Does anyone know why the linux kernel often seems to lurch back > and forth with respect to VM/memory management? Here is my take.... (DISCLAIMER: Every I say here could be a TOTAL LIE.) The memory manager (VM, as the kernel people call it) was largely rewritten for the 2.3 series. Which is fine. Development on the kernel proceeded. New drivers were added, functionality improved, bugs fixed. Things started to get to the point where people wanted a feature freeze for release (2.4). Things started to do just that. Soon, developers were chomping at the bit to release 2.4 so they could start hacking away on new ideas again. Just one problem: The VM was still broken. The VM developers knew it was broken, and kept trying to change it to fix it. Because it was changing so often, it was largely untested. Because it was untested and still changing (i.e., "not done"), not as many "beta testers" were testing it out. They wanted to wait for the dust to settle before trying to submit bug reports on it. So the VM started to settle down -- not because it was fixed, but because there were no bug reports. No one really accepted the VM as "tried and true", but no one had any clear ideas on what to do to fix it, either. Meanwhile, the rest of the world continued to want to move forward. Eventually, the pressure relief value blew, and 2.4 was released. Many people tried it. Many people found 2.4.0 was one of the more unstable "stable" releases of Linux in quite some time. Now we have a new set of problems: First, the VM in 2.4, the supposedly "stable" release, is broken. Second, we're not supposed to have large changes in a "stable" series. The second item precludes fixing the first, but the first negates the concept of 2.4 as "stable" in the first place. Ugh. Frankly, I think Linus did the right thing be accepting the big change. It was broken and needed to be fixed. Yes, it meant 2.4 was not as "stable" as previously thought. Oh well, shit happens. However, he should have made that more clear. We have a minor note, buried in the changelog for 2.4.10-pre11, as "major VM merge". He should have just come out and said, in glow-in-the-dark ASCII, that 2.4.10 was "2.4.0 take two". > I remember a terrible sequence of kernels late in 2.1.x development > where VM/MM got really bad ... Well, "It's baaaack...". :-/ > That was the last time I ran the current linux kernel on any of my > machines... We're holding at 2.2.x right now. Frankly, on most servers, we would be content to hold there more-or-less indefinitely. However, 2.4 has some nice features for firewalling, which would be nice to try. Plus, many of the good "desktop" distros (Red Hat, Mandrake) have started using 2.4.x exclusively. We're working around that in-house by booting a custom-compiled 2.2 kernel with them, but that is rather kludgey. I still think there has to be a happy medium somewhere between Red Hat's "So what if it doesn't even have a version number yet?" and Debian's "We release once every three years, whether we need to or not". :-/ Anyway, as far as 2.4.10 goes: I think I'll wait and see how the rest of the world does with it. Maybe I'll try it at home. Or maybe some brave soul here in our office will try it on their workstation. <evil grin> "Hey, Mike, wanna make a buck?" -- Ben Scott <[EMAIL PROTECTED]> | The opinions expressed in this message are those of the author and do not | | necessarily represent the views or policy of any other person, entity or | | organization. All information is provided without warranty of any kind. | ********************************************************** To unsubscribe from this list, send mail to [EMAIL PROTECTED] with the following text in the *body* (*not* the subject line) of the letter: unsubscribe gnhlug **********************************************************
