A newbie's view

["Thomas Womack" <thomas.womack@merton.oxford.ac.uk>]

This list seems to have lots and lots of members, but I haven't yet seen content
on it.

I'm not sure how much this counts as content; if you require experience with
Linux since 0.99pre16, I'm not worth listening to, and I'm writing this in
Outlook Express on Win98. But I read linux.dev.kernel, I ran Linux as a desktop
system for a month, and I feel I'd like to say *something*.

The real question is, *is* there anything obvious - aside from drivers, and new
drivers will always be needed - missing from the kernel? I can't think of
anything, but all this means is that 2.0.35 was adequate to run a desktop system
doing really not very much.

On the other hand, making yourself a new kernel is scary. You have to use a
compiler, there are umpteen million and six options to set, with no wizards
floating around to tell you what hardware you have, tell you the IRQs for your
sound card, and set a 'typical' set of options which will work with your
hardware.

Is there anything in the current kernel architecture that makes it impossible to
distribute vmlinux and a directory full of precompiled modules; when support for
new hardware comes out, you download new modules to put in the directory, when a
new version of the kernel comes out, you download a new vmlinux file, replace
the old one and reboot?

I'd be prepared to accept a longer boot sequence and a larger vmlinux file, if
it meant that the same vmlinux file would run on a wild variety of different
hardware.

I must have something obvious wrong, since this isn't an idea I've even seen
waved around before - would the scripts to generate the new vmlinux and the new
modules be an intolerable burden to run once per release? Would efficiency
require the kernel to modify its own code substantially at bootup (which I agree
is unpleasant to do in C)?

Tom

-
Linux-future: thinking about the future of the Linux kernel
http://humbolt.nl.linux.org/lists/