Subject: Re: why /bin and /sbin static
To: NetBSD User's Discussion List <email@example.com>
From: None <firstname.lastname@example.org>
Date: 03/18/2001 21:18:25
> > 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
> 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
> Greg A. Woods
> +1 416 218-0098 VE3TCP <email@example.com> <robohack!woods>
> Planix, Inc. <firstname.lastname@example.org>; Secrets of the Weird <email@example.com>