Now many of these things are configurable. If it is the amount of
messages that the boot of the kernel makes or even the "motivation" and
actions that the VM takes. It seems possible to configure the kernel so
that it would work optimally for each of the groups. The problem is that
the code in these sections is having to work in too different of
situations. Example : The VM is now somewhat more tweaked for servers
than it was previously. Many people were concerned about the
"interactivity" of it. Now it seems that it would be possible to change
the vm code so that it worked better for desktop users, but the
maintainers are not eager to do that because it would slow linux down in
the server market.
This all stems from one problem, which is a really great problem to have
if you must have a problem. Linux is spreading to largely different
kinds of machines with many different purposes. Microsoft solved this
problem by having several different kernels (NT code base for servers, 9x
code base for desktops, CE code base for handhelds), and this is somewhat
like what the "forking is a good thing" messge recommended for linux. I
disagree with that concept though. It is easy to see the trouble
microsoft is having with that and now they are trying to slowly merge the
two (NT,9x) together.
Instead of forking the kernel or catering only to one group, instead why
not try this: Using the new CML2 tools and rulesets, make it possible to
have the kernel configured for the type of job it will be doing? Just
like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
and configures options for that, have it ask people "Is your machine a
server, workstation, embedded/handheld?" and configure things in the
kernel like the VM, bootup and others to optimize it for that job type?
Brent Norris
Executive Advisor -- WKU-Linux
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/