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 _-_-_-_-_-_-_-