Date: Wed, 3 Jul 2002 11:58:03 -0700 From: "Helmut Hissen" <helmut@zeebar.com> To: <freebsd-small@FreeBSD.ORG> Subject: more on reducing FreeBSD Message-ID: <001401c222c3$8fc05970$6601a8c0@BOBO> References: <38E3A09A-8E42-11D6-BBF1-0030657B5F1E@bellsouth.net> <3D229963.EF2B40B3@pantherdragon.org>
next in thread | previous in thread | raw e-mail | index | archive | help
its nice to have dynamic libs in case you want to upload executables to your
system. if
not, all-static and crunching is probably the way to go soz its smaller and
faster (at
load/run time, too) and simpler and for the most part -like Gerald said-
harder to break).
I have also been working on putting together a small distribution. Seems
like I am
not the only one. Good to know that and kind of a bummer at the same time.
Started out putting together a special purpose DOF x86 firewall and then I
started
looking at why I was installing 100's of MB and I was appalled by what I
found when
I did the math.
<rant> TALK ABOUT BLOATWARE! I though FreeBSD was all lean and mean,
but I gotta say we put some commercial bloatware products to shame. Its
almost like we are trying to fill some imaginary cardboard product box.
</rant>
I also started out with PicoBSD, but nothing there ever seems to work (or at
least
not as expected) so I figured if I have to understand the code, I might as
well do it
myself. Now I have a ~4MB rootmfs kernel with everything I need (ssh2,
dhclient,
ipf, shell utils, tcsh, vi etc) and I set up a framework which now allows me
to build
kernels+mfs containing arbitrary subsets of that functionality ... and
nothing else. Surprisingly little patching was required in /usr/src, but
there was some pretty
sad looking stuff in openssh for instance which needed patching (as some of
you have found out :-).
The real fun starts with the miscellaneous stuff, like the rc.* and those
little
/etc/*{tab,.conf} files you never even know you had or needed. Many of
those
are highly subset-specific. Ideally, I would like to see some subset-aware
"unified unix configuration" thingy to address all that. I know there are
some efforts in that area, but they all seem to be either in dream-land or
vendor-proprietary.
and whats up with IP6? some of the code assumes it to be there and some
Makefiles turn it on whether or not you ask for it, whether or not its
necessary,
wanted, or desirable.
from where I am standing, to me its as important what IS NOT in a software
system as what IS.
anyhow - will post results when I get closer.
Helmut Hissen <helmut@zeebar.com>
Zeebar Technology Services, Inc.
----- Original Message -----
From: "Darren Pilgrim" <dmp@pantherdragon.org>
To: "W Gerald Hicks" <gehixz@bellsouth.net>
Cc: <freebsd-small@FreeBSD.ORG>
Sent: Tuesday, July 02, 2002 11:27 PM
Subject: Re: Guide to reducing FreeBSD (a.k.a miniBSD :)
> W Gerald Hicks wrote:
> >
> > On Wednesday, July 3, 2002, at 12:10 AM, Darren Pilgrim wrote:
> > [snips]
> > > As long as you realize that if a /bin or /sbin program can't run due
> > > to missing/corrupt libraries that you may or may not be able to even
> > > boot single-user. At the very least, /bin/sh, /sbin/mount,
/sbin/init,
> > > and /sbin/fsck should be static builds.
> > >
> >
> > Libraries residing in a linked-in MD_ROOT_IMAGE are available whenever
> > the kernel is
> > but it still seems more space efficient for that small handful of
> > critical files to be crunch-linked.
>
> Those libraries can still get corrupted. Using dynamic binaries adds
> a point of failure. It's not much more space taken for just those few
> programs, so why increase the risk?
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-small" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-small" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?001401c222c3$8fc05970$6601a8c0>