Best FreeBSD version for NanoBSD on an old SBC

[M. Warner Losh]

In message: <495AA9B0.9050104 at smiffytech.com>
            Matthew Smith <matt at smiffytech.com> writes:
: Thanks for your reply, Bruce.
: 
: Quoth Bruce M. Simpson at 2008-12-31 03:31...
: ...
: >     The key thing is to be able to leave enough in the base install for 
: > what you need -- it doesn't strip absolutely everything, and whilst the 
: > XORP LiveCD is now considerably smaller, and thus quicker to download, 
: > than it was (thanks to NanoBSD), it is quite a generic place to start:
: >     http://cvsweb.xorp.org/cgi-bin/cvsweb.cgi/other/LiveCD/
: Ta.  I'll have a look at that.
: 
: >     Of course NanoBSD would work just fine w/o the patches for making 
: > ATA drive images. You would probably do much better with CompactFlash in 
: > your rig. For DRAM, 16MB may be seriously pushing it now, 32MB is really 
: > a realistic minimum for FreeBSD on x86 these days on any platform.
: Not sure if CF would be totally suitable for this as I believe that ntpd 
: needs to do a lot of logging - don't know if CF still has the issue with 
:   a finite number of writes.  (Also trying to do this on virtually zero 
: budget and with what I've got so don't really want to start forking out 
: for extra bits.)

CF is fine for this application.  Most CF cards can cope with the
limited traffic of an NTP server.

: I'm surprised about the RAM though seeing as how my first Unix box (IBM 
: 6150), which ran the whole company, started off with only 8Mb!  (And 
: that was a card about the size of a keyboard.)  I've run minimal Linux 
: distributions on this hardware (the x86 SBC, not the 6150) so wonder 
: what in FreeBSD is gobbling up the resources - and whether it can be 
: pruned out.  I'm sure that there is a load of stuff in the kernel that 
: is unnecessary for simple, old, hardware on a headless machine - but 
: then maybe this is already removed on NanoBSD.

You can run FreeBSD on a 16MB box, but you have to do some careful
tricks to change the current bias in optimization of the kernel from
speed to size.  And you have to carefully prune your kernel to the
bone.  And you have to trim the applications that are run as well,
since that's where the bulk of the memory usage comes from.

Linux has these same issues, the knobs to optimize for them are better
labeled and documented.

Warner