lkml.org 
[lkml]   [2003]   [Oct]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Unbloating the kernel, was: :mem=16MB laptop testing
    > Let me concur with the sentiments on this thread.
    >
    > When I started using Linux, it was on a 40 MHz 386 with 8Megs of ram and
    > a 200 Meg HD. This was a reasonably typical machine for the time (1993).
    > I ran X on this machine, and it was fine running several Xterms and you
    > could play the X version of Tetris or gnuchess. I used this machine to
    > write the program I was working on for my Masters degree.
    >
    > Today, a machine with specs like I quoted above seems hopelessly slow.
    > However, I was able to do useful work on it in 1993, and the same sort
    > of work would still be useful today. You of course are not going to be
    > able to run mozilla and KDE on it, but lynx, slrn, mutt, and fvwm will
    > work fine. There are many people who will never be able to afford
    > to buy a computer but could find someone to give them one of these
    > "hopelessy outdated" machines for nothing. If we can ensure that
    > Linux keeps working on these machines, it will be a good thing.

    On one hand I agree with you - OTOH: why not run an older version of the
    kernel? 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...

    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?

    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.

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

    Just my 3c and some ideas.

    Of course part of the problem is that by designing the kernel for high mem
    situations we're using more memory hogging algorithms. It's a simple
    matter of features vs mem footprint.

    I'm not convinced either way - and I'm just posting this
    as a voice in this discussion...

    Cheers,
    MaZe.

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

    \
     
     \ /
      Last update: 2005-03-22 13:49    [W:3.654 / U:0.376 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site