> On one hand I agree with you - OTOH: why not run an older version of the> kernel?

Security issues. That applies for userspace as well. Not upgrading,or at least disabling the functionality with the security issue isirresponsible.

Actually, this is one thing we could do to make Linux systems moreusable on low spec hardware - fix all the security issues in ancientversions of the kernel and popular userspace applications.

> Are kernel versions 2.2 or even 2.0 really not sufficient for such> a situation? It should be noted that newer kernels are adding a whole lot> of drivers which aren't much use with old hardware anyway and only a> little actual non-driver related stuff (sure it's an oversimplification,> but...). Just like you don't expect to run the latest> games/X/mozilla/kde/gnome on old hardware perhaps you shouldn't run the> latest kernel... perhaps you should...

No, 2.6 should run on a 4MB 386 with no significant performancepenalty against 2.0, in my opinion.

> Sure I would really like to be able to compile a 2.6 for my > firewall (486DX33+40MB-2MB badram) - but is this the way to go?

Why not?

> As for making the kernel smaller - perhaps a solution would be to code all > strings as error codes and return ERROR#42345 or something instead of the > full messages - there seem to be quite a lot of them. I don't mean to > suggest this solution for all compilations but perhaps a switch to remove > strings and replace them with ints and then a seperately generated file of > errnum->string. I'd expect that between 10-15% of the uncompressed kernel > is currently pure text.

I agree, error codes would be nice, but this discussion has come upbefore and I doubt they will ever get in to mainline.

> Perhaps int->string conversion could be done by a loadable module or a > userspace program?

Not really going to help much, in my opinion, it'll just add overhead.