From owner-freebsd-small Wed Jul 3 12: 0:30 2002 Delivered-To: freebsd-small@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6D7C737B405 for ; Wed, 3 Jul 2002 12:00:15 -0700 (PDT) Received: from mail2.boxitllc.com (mail2.boxitllc.com [209.209.45.33]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0087B43E09 for ; Wed, 3 Jul 2002 12:00:15 -0700 (PDT) (envelope-from helmut@zeebar.com) Received: (qmail 16298 invoked from network); 3 Jul 2002 12:07:14 -0700 Received: from h24-65-174-160.gv.shawcable.net (HELO BOBO) (helmut@zeebar.com@[24.65.174.160]) (envelope-sender ) by 0 (qmail-ldap-1.03) with RC4-MD5 encrypted SMTP for ; 3 Jul 2002 12:07:14 -0700 Message-ID: <001401c222c3$8fc05970$6601a8c0@BOBO> From: "Helmut Hissen" To: References: <38E3A09A-8E42-11D6-BBF1-0030657B5F1E@bellsouth.net> <3D229963.EF2B40B3@pantherdragon.org> Subject: more on reducing FreeBSD Date: Wed, 3 Jul 2002 11:58:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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. 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. 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 Zeebar Technology Services, Inc. ----- Original Message ----- From: "Darren Pilgrim" To: "W Gerald Hicks" Cc: 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