From: tabris <tabris@tabris.net>
To: Maciej Zenczykowski <maze@cela.pl>, jlnance@unity.ncsu.edu
Cc: linux-kernel@vger.kernel.org
Subject: Re: Unbloating the kernel, was: :mem=16MB laptop testing
Date: Tue, 14 Oct 2003 14:35:52 -0400 [thread overview]
Message-ID: <200310141435.52571.tabris@tabris.net> (raw)
In-Reply-To: <Pine.LNX.4.44.0310141813320.1776-100000@gaia.cela.pl>
On Tuesday 14 October 2003 12:27 pm, Maciej Zenczykowski wrote:
> > 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?
>
Well... So far, 2.4 is enough for my routers. BUT, I also cannot put more
than 32-40MB into them (i just don't have the budget to go buy 16MB FP or
EDO DIMMs when I already have a bunch of 8MB DIMMs.
I started my project running 2.2, but that wasn't enough for what I
needed. It might have been fine for the most part, but iproute2 doesn't
work completely on 2.2, and there's no IPTABLES. sure, ipchains is
simpler to config by hand, but I still want to use iptables when I can
for the increased flexibility.
Simple fact. not everything can, or will, be backported. And not everybody
can just make their own raw distribution. (tho it might have helped if i
had used debian instead of RedHat on my router). and many modern distro
installers don't like 32MB RAM... that's what i ran into.
> 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.
>
Considered already. Was tied into i18n. was considered impractical, esp
w/o a realtime LANANA services or equiv for error numbers.
> 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.
>
--
tabris
-
Coward, n.:
One who in a perilous emergency thinks with his legs.
-- Ambrose Bierce, "The Devil's Dictionary"
next prev parent reply other threads:[~2003-10-14 18:36 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-10-14 11:44 Unbloating the kernel, was: :mem=16MB laptop testing Marco Fioretti
2003-10-14 12:02 ` William Lee Irwin III
2003-10-14 13:24 ` Rik van Riel
2003-10-14 14:30 ` jlnance
2003-10-14 14:54 ` Richard B. Johnson
2003-10-14 16:27 ` Maciej Zenczykowski
2003-10-14 17:33 ` John Bradford
2003-10-14 17:51 ` Richard B. Johnson
2003-10-15 12:43 ` Jan-Benedict Glaw
2003-10-15 13:06 ` William Lee Irwin III
2003-10-15 16:52 ` H. Peter Anvin
2003-10-15 13:08 ` Nick Piggin
2003-10-17 11:50 ` Jan-Benedict Glaw
2003-10-17 23:21 ` Nick Piggin
2003-10-14 18:35 ` tabris [this message]
2003-10-14 21:11 ` Roger Larsson
2003-10-15 11:45 ` Jan-Benedict Glaw
2003-10-15 13:06 ` William Lee Irwin III
2003-10-15 13:22 ` Jan-Benedict Glaw
2003-10-24 15:47 ` bill davidsen
2003-10-15 6:06 ` Sandy Harris
2003-10-24 15:59 ` bill davidsen
2003-10-24 16:55 ` M. Fioretti
2003-10-24 17:14 ` bill davidsen
2003-10-25 17:42 ` Geert Uytterhoeven
2003-10-28 9:12 ` Rob Landley
2003-10-14 21:43 ` Unbloating the kernel, action list M. Fioretti
2003-10-14 22:30 ` Martin J. Bligh
2003-10-14 22:56 ` cliff white
2003-10-15 12:48 ` Jan-Benedict Glaw
2003-10-15 13:10 ` William Lee Irwin III
2003-10-15 15:05 ` Jan-Benedict Glaw
2003-10-19 11:21 ` Adrian Bunk
2003-10-21 8:04 ` Jan-Benedict Glaw
2003-10-15 18:16 ` Gabriel Paubert
2003-10-16 5:19 ` Jan-Benedict Glaw
2003-10-16 8:16 ` Gabriel Paubert
2003-10-16 16:16 ` Jan-Benedict Glaw
2003-10-17 20:26 ` M. Fioretti
2003-10-17 20:10 ` M. Fioretti
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200310141435.52571.tabris@tabris.net \
--to=tabris@tabris.net \
--cc=jlnance@unity.ncsu.edu \
--cc=linux-kernel@vger.kernel.org \
--cc=maze@cela.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).