On Thursday 11 October 2007 22:00, David Boyes wrote: > > It is a little hard to answer this email since I don't remember the > > details of > > each email thread. It would help in the future to leave a bit > > additional > > > info, like who sent the last message. > > I thought your threaded mail reader with the fancy colors did this for > you...8-)?
Yes, I suppose it could, but I cannot work with a gigantic inbox, so I read email then file it. > > > On Tuesday 09 October 2007 16:10, David Boyes wrote: > > Not me. That was Kenny Dail. > > > In the first baby step, there is probably no need for a database > > change. > > > However, the key to understanding the difficulties, and something that > > is > > > not > > going to change is that Bacula is Job based, not file based. > > Since you're writing the code, you get to implement it any way you want. > I think you're coming to the point of where that assertion may need to > change, but not my call. You got my input and ideas. Go forth and have > fun. Well, it may change someday, but certainly not any time soon without essentially rewriting most of Bacula. > > > IMO inetd is a bad way to go. It will unnecessarily consume an extra > > port, > > > and > > is a solution that worked well many years ago on small memory systems. > > Now > > > that Microsoft has made 2GB the minimum working RAM for Vista, there > > is no > > > disadvantage of having daemons or more code in the SD (in a DSO if > > necessary > > at some point). Doing it with a continuously running daemon avoids > > problems > > of security, additional ports, the expense of initialization (reading > > the > > > conf file, ...), and persistence (i.e. knowing what the current state > > of > > > everything is). > > Except that it's not a good approach for shared-resource systems, like > the coming spate of virtual machine-based deployments, eg z/VM and > VMware where increased memory footprint in one virtual machine impacts > the behavior of other images on the same box. A permanently larger > working set size for a feature that isn't needed for your > commonly-referenced simple case seems like a not-so-hot idea in the long > term. I don't know much about your systems, but mine swaps if it needs more memory, which causes no problem for daemons that are dormant such as Bacula most of the time. They simply go out of memory when not used, and come back when needed, or if there is enough memory, they remain in. The only problem is a large working size, but that was not the issue we are discussing about xinetd. > > Again, you're writing it, but that's how I'd evaluate it. OK -- I'm just trying to keep it as simple as possible. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
