Date: Mon, 24 Jan 2000 12:01:10 +0800 From: Greg Lehey <grog@lemis.com> To: Andrew Hannam <famzon@bigfoot.com> Cc: small@FreeBSD.ORG Subject: Re: One disk vs Two Disk (was Re: New approach to picobsd) Message-ID: <20000124120109.B2643@mojave.worldwide.lemis.com> In-Reply-To: <005001bf6588$09fb8760$0104010a@famzon.com.au>; from famzon@bigfoot.com on Sun, Jan 23, 2000 at 07:53:14PM %2B1000 References: <005001bf6588$09fb8760$0104010a@famzon.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
[Format recovered--see http://www.lemis.com/email/email-format.html] On Sunday, 23 January 2000 at 19:53:14 +1000, Andrew Hannam wrote: >> 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. Now that's a very good idea. > 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. This is already an option. In combination with (1) it might make for a reasonable one-disk solution and a more feature-packed two-disk solution. > 3/ Get rid of some of the other junk in there currently. I've done that already :-) I had to. > 7/ "Tune" the kernel by removing some hardware support and thus create more > specific versions for different hardware sets. That too. > 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. I don't believe that the named problems relate to the code. What you're thinking of is the size that the process image can assume, and that depends on how much work it does. > (PS. Does anyone have a tiny version of named or dialog ?) It would still use a lot of cache. > A lot can still be done ! Feel like merging this stuff with the /custom config in -CURRENT? > 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. You need to describe this in more detail. I've never seen a web approach credited with reducing bloat. > 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. Hmm. That approach would certainly meet with a lot of resistance, from me amongst other people. Sure, I got rid of ee (I found space for vi :-), but I would hate to have to use a web browser for normal functionality. Greg -- When replying to this message, please take care not to mutilate the original text. For more information, see http://www.lemis.com/email.html Finger grog@lemis.com for PGP public key See complete headers for address and phone numbers 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?20000124120109.B2643>