On Saturday 22 December 2007 07:29:04 pm Linda Walsh wrote: > >>> The Saturday 2007-12-22 at 16:06 +0100, Anders Johansson wrote: > >>>> The real solution here is to find and fix the bug that causes beagle > >>>> to allocate so much memory. It doesn't happen on all systems. > > ---. > Without question, this is the best solution. > > > Anders Johansson wrote: > >> I wouldn't say "probably". It shouldn't be par for the course for an > >> application to not check return values from memory allocation functions > > Aaron Kulkis wrote: > > As I said earlier... the whole thing is poorly written. > > --- > And you say this based on??? Do you have _any_ expertise > in the source? (if you do, sorry, but your attitude is not > productive). It _appears_ you know nothing about how it is > written but are basing your opinion on its behavior in certain > configurations. > > This is why I made a comment about *not* using "swap" > on a system -- if you are using swap on any regular basis (my > threshhold is using swap, *anytime*, during 'normal' day-to-day > usage), you are running applications that are "too big" for for > your machine. Now whether this is due to poor application memory > usage OR is due to poor-planning on the part of the system owner > depends, in large part, on promises or expectations set by the > developer or owner of the program. > > Certainly, if I am running on a system with 128M of memory > with a 650MHz mobile CPU, and load a full "suse 10.x" desktop with > full features, I am asking that I be "shot in the foot". If > a release (like suse10.2, or windows 98) says it will run best with > 1GB-mem + a 1GHz processor and my machine has 2GB+a 2GHz processor > and the release runs like a "dog" -- then I'd say it is the fault > of the release packager (they made the choice of what packages to > include 'by default'). > > Certainly if the *end user* chooses to run more applications > than their computer can comfortably fit in memory, how can the > application developer account for this. > > > Beagle should be scrapped and started over from the > > ground up, starting with the design assumption that it > > is to behave as an unobtrusive background process, not > > the current one which can take over the whole system > > with a "feed me" attitude as if the whole purpose for > > a computer and its data to even exist is to provide > > something for a beagle process to index. > > ----- > Do you have documentation or direct knowledge > of what the "design goals" were? If not, how do you know it > wasn't designed that way? > > Something the beagle developers cannot know is how > their application will be installed by release packagers. One > example of an outstanding 'bug' (or feature depending on > interpretation) that can affect beagle performance > is how it is run by 'cron.daily'. From my own experience, > under 9.3, the default is to run cron.daily 24 hours after it last > ran -- but if something delays it running "overnight" (like the > machine being off or suspended) it will run within 15 minutes > of the machine becoming active. IT WON'T WAIT until the > 'middle of the night', as you might want. This has nothing > to do with beagle or its developers. > > Ideally, the beagle indexing process would run once > (either at night, or immediately if needed), and then be able > to monitor the filesystems and directories for changes using > the "fam" (famd) package. > > The "fam" function (and as extended for directories > and/or devices) monitors when any change is done to its monitored > file-system objects, then calls "listening" programs to process > the new or changed objects as they are changed on disk. Ideally, > you would then need no 'batch' updating, but such would be done > in "bits" throughout the day as monitored files are changed. > > That being said, if a system doesn't have the OS support > or resources needed to run 'famd' without without degradation, the > system will still be painful to use (shorthand: "be unusable"). > > Be careful about "global generalization" about a product > being bad, though, though, just because it doesn't run well in > a particular situation. > > Linda
thanks, i think that about covers a broad spectrum of possible perceived problems... Howard -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
