Date: Tue, 25 Jan 2000 08:56:41 +1000 From: "Andrew Hannam" <famzon@bigfoot.com> To: "Greg Lehey" <grog@lemis.com> Cc: <small@FreeBSD.ORG> Subject: Re: One disk vs Two Disk (was Re: New approach to picobsd) Message-ID: <005d01bf66be$68384200$0104010a@famzon.com.au> References: <005001bf6588$09fb8760$0104010a@famzon.com.au> <20000124120109.B2643@mojave.worldwide.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Greg Lehey" <grog@lemis.com> Subject: Re: One disk vs Two Disk (was Re: New approach to picobsd) > 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. Correct - still the issue remains - named is a memory hog. > > (PS. Does anyone have a tiny version of named or dialog ?) > > It would still use a lot of cache. Named could be built to have a fixed core size with the available cache being replaced in LRU fashion. Has anyone done something like this ? Also, Named and Dialog are both large programs when added to the crunch anyway. > Feel like merging this stuff with the /custom config in -CURRENT? As a task coming up parts will be merged back. I built on 3.3 release because it was what I had easy access to and having the latest and greatest wasn't the most important thing to me. It sounds like much of the stuff I did for myself had already been done in current. One of things I did was significantly alter the build system. This now makes it more difficult to merge back (a real mistake on my part). As my custom config was considerably different from the standard tree, it became a real nuisance that the 3.3 release build used a common mfs.tree and then just described differences. The most major change I made to remove the reliance on that common mfs.tree so that all files other than the crunch, the kernel, and the boot files came from the custom versions mfs.tree and dsk.tree (with obvious meanings). > > 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. I agree ! In my particular situation I was after a "end-user" type product where a Web front end is ideal and a command line interface could be seen as a disadvantage. Still, I could not bring myself to completely remove the command line interface, justifying it on the basis of being an "advanced user diagnostic tool". Still the principal applies. What can be done with a web server and shell script based cgi's can be done even more easily with shell scripts and a command line interface. 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?005d01bf66be$68384200$0104010a>