> I think what you're really looking for is lower priority. If the >system has nothing else to do, might as well use it to make the AV get >done quicker. But if the system has anything else to do, put >resources towards that, and make the AV wait.
Sure, All of this debate point blank surrounds software failing at an earlier process and we neglect trying to fix it there? Reminds me a demo I had last year online: The guy shared his screen and didn't release Visual Studio was running, the module he was working on was "crash protection". It worked by zipping the project LITERALLY every minute or so and restarting and reopening when it shit the bed. I thought you have got to be kidding me, "next". To avoid being inflammatory I have neglected to chime in and state I have NEVER had an FP or a machine overwhelmed by ForeFront and MS has not released a bad dat that frankly simply failed QA. Whether or not a fan boy from another product can argue on any other premise of that software, its proof it *can* be done right without treating the fallout instead of the root cause. If you told me "Vendor A" who has continued to release poorly written updates that wreak havoc on my network can be mitigated by controlling the severity of their wreckage, do you *really* think I am interested? Uhm, no. I'd rather they learn how to get it right. jlc ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
