Gonna chime in here as well.

Webroot SecureAnywhere. The old stuff was junk, but SecureAnywhere is pretty much Prevx 4. The total install file for the AV-Only version is under a mebibyte, the working memory stays under 5 meg while idle (usually under three), under 30 meg generally while scanning, and scans take a few minutes at most on most machines, even old old ones. I do enough computer work that I take people who were told that something else is fast/light (usually ESET or Vipre), remove malware for them a few times in a few months, then swap them to Webroot SecureAnywhere. Then I never have to remove malware from their systems again (year and a half and going strong on a few hundred systems) and several asked if I upgraded their hardware for them all sneakily.

So no, it's not free, but you can get the enterprise version if you really want to manage things and have completely internet-based management, and honestly the darn thing has saved me thousands of dollars in work and given me hundreds of happy customers. So I'll advocate it anytime.

Append "with no technology knowledge who met salespeople." and you're set.

Generally triggers between 3-30Hz with some rare cases up to 60Hz (who can't do much under indoor lighting). 100Hz for a backlight is not an issue and if it is, make a few thousand bucks selling yourself to science.

Based on the very limited view we are given of this thing, I start to seriously wonder why a real-time Linux system was used. It looks like it is just actuating legs blindly. Real-time systems are tremendously useful for responding to physics in... (wait for it)... real time. "I'm starting to fall! Let me adjust this this way to prevent it. Can't wait 30ms for a response! Need to respond now, otherwise the response will be wrong." Sure, it's actuating its legs in a manner that is fault-tolerant (It can travel down breaks in the terrain up to 20% the length of its legs), but that is entirely based on the springs absorbing the extra unexpected impact and then losing it after the leg leaves the ground again, not a real-time adjustment.

This depresses me a little because, like others, it feels misleading. Mention real-time linux! Does it help or hinder? No, not really. Mention that it's cat like! How is it cat-like? Um... It has four legs and springy bits! Oh, and it goes faster stably than any other quadrupedal robot in its size bracket. How fast? That's not very fast really... But focus on the fast-ER part! It runs like the wind! A very slow, calm wind...

Rookie error #3: Point the radio transmission directly at the star.

Unless the target is moving directly toward or away from us relatively speaking, pointing it at the star will target where the star was 36 light years before the transmission will arrive. If it -is- moving directly toward or away, are they accounting for Doppler?

"To qualify in the US, you must have a minimum of 10 years' experience with Windows Server 2008, 30 years of experience with Windows as a whole; You must know C, C++, C#, Java, PHP, ASP, .NET, JavaScript, Python, Perl, ASM, Objective C, HTML, CSS, and at least five other languages of your choice, all at a guru level and never -ever- need to use any reference material; You must be able to code a full working 100,000 lines of code with no bugs within 40 work hours; You must be able to QA test the whole thing in another 40 work hours; You must be able to take every single feature request coming from marketing and implement it within that week of coding - even the features that are requested the day after the week ends; You must have a doctorate in Computer Sciences; And you must be willing to work for no more than $41K/year."

Not an AC - or the above AC - but I cleaned up about 1500 tabs recently when I moved from Firefox to Waterfox 64 (due to the memory use needs). Firefox was hitting 32-bit memory issues and Waterfox was hitting a CPU load issue. I'll explain the logic (or lack thereof) behind Way Too Many Tabs when I get home from work, as today is expected to be VERY busy. (Running just over 200 tabs now, if you must know)

Previous Story: "Show me the money"

This story: "Here's the snowflakes! And the money."

Just in case this page gets updated and the penny gets bumped off, hopefully the direct link to the beautiful high-speed photo of a falling penny will persist in the records and the annals of time forever.

Well, besides the fact that you would need to block TCP as well as UDP (RFC calls for support on both and longer messages, such as zone transfers, require TCP due to UDP's content length limits), you also have the benefit of the fact that this would block exploits that make use of port 53 for communication on the strong likelihood that it is completely unfiltered.

The AS article asks where is the best place to filter though. This gets tricky. The request doesn't indicate whether this is enterprise equipment or consumer. The mention of router-based filtering implies consumer though, so I'll focus on that.

First off, a good number of consumer routers do not have the processing power to handle full filtering at high speed. Even enterprise appliances such as iPrism require heftier units when the pipeline speed exceeds a certain threshold. As a good example, a Linksys 625 Wireless Router can handle filtering with no rulesets up to about 50-60Mb/s. Rules are relatively efficient, but there is no way in many cases to automate rule implementation, and when the ruleset increases in size the capability of the router to handle it drops to around 20-30 Mb/s. Fine if the WAN uplink is perhaps a 15Mb/s line, but catastrophic if you're trying to get full use from a 105Mb/s cable or fiber line.

The end answer really comes down to a balance. Implement filtering at the furthest end that you carry absolute sovereignty over, balanced by duplication of effort and complexity of implementation. Replicating rules over thousands of endpoints is complex enough and lacks enough control that performing the filtering at the trunk is more efficient and effective. By comparison, the ability to control one or a few computers in a home is substantially more likely and will take the burden off the limited processing power of a consumer router. Walking a rule manually to five endpoints is trivial compared to dozens, hundreds, or thousands.

If the uplink is small enough to allow filtering at the router and the eventual change and replacement of equipment will allow easy transfer of rulesets and administration, work from the router or a similar trunk location to globalize and centralize effort. If the endpoints are spread enough or there is sufficient lack of control over them to warrant such, again, work from the trunk. If enough trust exists in the endpoints to offload the work onto their substantially-stronger processors, and administration of rules to and of the endpoints is trivial, filter at the endpoints.

I know that NSIS Installers at the very least base the default progress bar internally* on the line number through the length of the entire set of installation process code. This makes it quite fun when you have long position jumps in the code or repeating loops that have enough code to cover a good chunk of progress. I would expect that several other installers may use the same base internal calculation of the progress bar.

*The progress bar can also be controlled manually within the code for the coder to be nice or exceptionally evil as they see fit.

Maybe I'm missing something here, but....

Group 1 makes a third-party add-on that works with Company A's and Company B's product. Neither company controls Group 1.
Company A is not using anything at all from Company B, but makes use of Group 1's items.
Company B is telling Company A to remove the feature of using Group 1's items because it violates ToS.

So either Company B's person somehow thinks that the Company A product violates B's ToS (which is not in effect, since B is not in use at all and the interaction is with a third party), or B thinks that A's implementation violates Group 1's ToS and is giving a "courtesy" alert. If the former, then a simple response pointing out that A's product and feature does not utilize anything under the control of Company B and thus Company A is not subject to B's Terms of Service since B is not providing any services to A would suffice. If the latter, then check the ToS of Group 1 and remedy if the allegations are correct.

I suspect that somebody (Louise) saw the words "CCleaner's Winapp2.ini files" in the ghacks article that implies (apparently incorrectly) that the files are created by and owned by Piriform, so assumed that her company owns them and nobody else is allowed to use them. Instead the case looks to be that "Group 1" creates and owns them and her company USES them, so her company's ToS does not apply to the use of a third party item they don't own or control.

So what happens when the "copyright enforcement agencies" decide that somebody on that NAT IP has downloaded a movie and three strikes or something similar gets kicked in for the IP? (I know it's perfectly possible given port, IP, and Time to back-track a connection through a properly-logged NAT.Just an amusing side effect if somebody is dumb, and dumb happens a lot these days.)

Boot away from the hard drive (Linux live CD for example). Replace the MBR with a known-good copy. Check that the primary partition of the drive is Active, not the dinky space area. The TDL4 stuff primarily hits the MBR to bootstrap a malign active partition that it boots from. Wiping the MBR alone leaves the partition active but unable to boot. Wiping the partition alone leaves the MBR corrupted and unable to boot.

Self-Recompiling Polymorphic threats are effectively intelligently-designed evolution, then. You can't ignore either factor in their operation without looking odd.