Messages in this thread | | | Date | Wed, 16 Jul 1997 10:11:18 -0400 (EDT) | From | Dale Scheetz <> | Subject | Re: 2.0.31 : please! |
| |
It was my intent to stay out of this discussion. But since almost everyone in the Linux Community has had something to say on this subject, and some points have still not been made, I feel obliged to take my share of the bandwidth to make a few that I think are important.
First, to the developers:
THANK YOU!!!! Without your valiant efforts no one would have anything to complain about, but more important none of us would have this wonderful OS to kick around! The Linux Development Community has created an "economic" paradym that could change the way the world looks at work and wealth. These ideas have a potential that goes far beyond the software environment.
Second, to the developers:
Success has its penalties. The phenomenal growth of the Linux User Community over just the last year is a tribute to the wonderful usefulness of this product. A side effect of this rapid growth is that the population of ignorant newbees has grown as well. The problem of expectations among this group will not go away and the developers are just going to have to come to terms with that aspect of the world. (Some people aren't either kind or considerate when it comes to what they want from you, and there isn't much any of us can do about that) Learn to seperate the chaff from the wheat and just let the chaff go...it is far less painful that way.
Third, an explanation of frustrations:
The last stable kernel for many of us was 2.0.27 and since that kernel the memory management has gotten progressivly worse, culminating in the 2.0.30 kernel being one that dies under what have always been "low load" circumstances in the past. The fact that this problem has progressed in stead of regressed, coupled with the fact that the .30 kernel has been around for quite a while (by historical Linux development schedules) exibiting these flaws, has been a cause of frustration for many of us in the user community.
Forth, the bug report:
Myself, and several others have reported this in the past, but here it is again just for the record.
On a 486 machine with 8 meg of memory (a very adequate piece of hardware in the past) with the 2.0.30 kernel, the machine can be caused to lock up tight from the "can't get free page" error if you try to create a file system on an 850 meg partition (or larger).
I hope we can all agree that mke2fs should not be able to crash the kernel while doing a "simple" job like that discribed above. I, for one, am unwilling to call such a kernel "stable" (even though I use it myself).
The only explanation that I have seen for the cause of this problem came from a fellow user, who suggested that, because of buffer allocation priorities, processes that allocate a large number of buffers in a short period of time can fragment memory to the point that no full pages of memory are available for paging. This makes sense since increasing the paging thresholds in /proc pushes the threshold for failure to a higher level. This "work around" doesn't really fix the problem, although for some it pushes it beyond the horizon for their operating environment.
Conclusions...finally ;-)
Telling users to get off their fat behinds and help with the coding efforts is no more productive than users demanding that developers do the same.
I would like to suggest that this development group set up a "formal" bug tracking system (possibly modeled after the system used by the Debian Development Team) that would allow users (and others) to "log" a bug report that is visible to all who wish to look at the tracking system. These bugs could then be used by developers to "prioritize" their efforts, and, when the problem has been addressed, the bug report can be closed. This provides a means for users to "vent" their frustrations without attacking any particular developer (or the developers in general), but more important, this give the developers a "concrete" list of problems, as perceived by the community at large.
To All:
Thanks for your patience,
Dwarf -- _-_-_-_-_-_- _-_-_-_-_-_-_-
aka Dale Scheetz Phone: 1 (904) 656-9769 Flexible Software 11000 McCrackin Road e-mail: dwarf@polaris.net Tallahassee, FL 32308
_-_-_-_-_-_- If you don't see what you want, just ask _-_-_-_-_-_-_-
| |