From owner-freebsd-small Sun Jan 23 1:56: 2 2000 Delivered-To: freebsd-small@freebsd.org Received: from mail02.syd.optusnet.com.au (mail02.syd.optusnet.com.au [203.2.75.105]) by hub.freebsd.org (Postfix) with ESMTP id 0341F1507B for ; Sun, 23 Jan 2000 01:55:58 -0800 (PST) (envelope-from famzon@bigfoot.com) Received: from w95 (wdcax4-201.dialup.optusnet.com.au [198.142.149.201]) by mail02.syd.optusnet.com.au (8.9.3/8.9.3) with SMTP id UAA10306 for ; Sun, 23 Jan 2000 20:55:49 +1100 Message-ID: <005001bf6588$09fb8760$0104010a@famzon.com.au> Reply-To: "Andrew Hannam" From: "Andrew Hannam" To: Subject: One disk vs Two Disk (was Re: New approach to picobsd) Date: Sun, 23 Jan 2000 19:53:14 +1000 Organization: FamZon Systems MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 Disposition-Notification-To: "Andrew Hannam" X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-small@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Do we need to do it in one disk? The answer is a resounding "YES" for as long as possible. COMMENTS BELOW ... There are some major disadvantages to two disks. Besides the floppy swapping task - the most major is that you can't put the floppy in the machine and then just leave it there and have it handle power outages. That is, it loses its advantage of being able to be used in unattended situations. A two disk system is not a bad idea though (for absolutely feature packed systems). Some suggestions that may help ... 1/ Use some of the larger floppy formats - for example a 1.72M format of the standard 1.44M floppy disk. 2/ Have the one disk/two disk question an option in the build with the one disk version leaving out less important stuff such as all the README's and command help. 3/ Get rid of some of the other junk in there currently. 4/ Some space can be saved by doing a strip --remove-section .note --remove-section .comment on the crunch (as is done on the kernel). 5/ Clean up the booting system and the rc files. (I believe some of this has been done in -current) 6/ Define a kernel option (such as ALLQUIET) that allows you to compile the kernel without lots of its current text (and other less important code). This also has advantages for other reasons in a commercial situation. 7/ "Tune" the kernel by removing some hardware support and thus create more specific versions for different hardware sets. As an example of what can be done with a little cleanup, I have created a custom version (based on V3.3 stable admittedly) with ... named ppp with nat support web server complete set of HTML configuration pages and cgi's for named, ppp, nat, and general network setup complete with graphical backgrounds and buttons. These pages control every aspect of the system except for the initial hardware setup. A custom graphical hardware configuration system added in the kernel Support for EVERY ethernet card supported by FreeBSD Standard shell (ash) All the standard networking tools such as ifconfig, route, vm, ns etc etc etc A number of shell scripts that use dialog (full screen text boxes, menus etc) I have used only tricks 3, 4 and 5 from above to achieve this. I have some space left on the system and hope to add a DHCP server as well. If I run out of space I may need to try some of the other tricks listed above. All this still runs in 8M RAM on a 386SX running at 16MHz. I don't think it will run in less than 8M (although I haven't tried) as named is such a memory hog. (PS. Does anyone have a tiny version of named or dialog ?) A lot can still be done ! From my investigations it has become apparent to me that the major cause of bloat has been the lack of a good system configurator (which I have solved for my floppy using a web server and shell script based cgi's). I believe the unified configuration project could be the long term solution to this problem. With this problem solved I was able to remove such things as ee and more. The command line then becomes purely an "advanced" user fixit system. Some of these changes I have made I believe could be quite useful to the larger PICOBSD community and so I will be posting back some of my changes soon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-small" in the body of the message