> > were used.
> 
> Well that's not really true, at least not unless you're running a very
> very very stripped down kernel.  Once upon a time Unix ran in 256k.
> These days you can't even boot a GENERIC kernel in less than 6MB or so.
generic_tiny boots on 4MB fine
> Notice the orders of magnitude jumps that sort of match the similar
> orders of magnitude jump in CPU speeds.  However it still all boils down
> to I/O throughput and having a decent ratio between that and CPU speed.
> If you've ever worked on a VAX 11/780 running 4.1BSD with 63 other users
> then you'll know what I mean!  :-)
no i don't. i must be VERY slow :)
> I've been testing the INSTALL_TINY kernel on my 486 laptop with 4MB RAM,
> and it's still really too big for that machine -- once I get the "sm"
> driver working on it (or replace my 3com MHz card if it's broken) then
> I'll have to build a true custom kernel that's not unnecessarily
> bloated.  Maybe I can even get rid of some of the remaining real bloat
> too...  :-)

it's difficult to build kernel less than 800-900kB :(

my have 1.1MB with some features more. 
> > but let's stop talking about what crap of hardware it is, start talking
> > about how to make system work faster on ANY hardware and especially
> > low-memory and slow-disk one.
> 
> Yes, of course, but that's always easier to say than do when you're
> talking about something as widely portable as NetBSD.
> 
> You *CAN* run NetBSD very successfully today on a 486 laptop provided
> that you don't try to use it as a general purpose multi-user server
> system.  :-)

i'm using this as personal laptop, not multi-user server!
 
> I find dynamic linked libraries to be a royal pain on any open-source
> system, so I personally would be very interested in working on true
> shared libraries (like those of AT&T UNIX) for NetBSD, but I still

IMHO something like /lib/standard-library.image mmapped for every
processes to one address would be nice. it should have most used libs in
/usr/lib.

> wouldn't be wanting them used for things in /bin or /sbin.  At least
> there there's a guaranteed savings, especially if the now well known
> guidlines for knowing what and when to make shared libraries are
> followed.
> 
> -- 
> 							Greg A. Woods
> 
> +1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
> Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
>