Microsoft Security Essentials. Real-time antivirus protection (i.e. install and forget). Free.
Malware Bytes. Trojan/BotNet scanner (i.e. only runs when you launch it). Free. (And broadly considered the best secondary protection tool)
Note: Malware Bytes use CNet as a mirror which is unfortunate, because CNet is replete with adverts that contain – or are nothing more – than big “DOWNLOAD!” buttons. Watch where you click, please?
Another day, another friend I had to batter for using Avast. Ugh. Malware Bytes found 17 infections with a quick scan, removed ~200 infections with a full scan from safe mode.
He’d just renewed his Avast license too.
If nothing else, download a copy of Malware Bytes to someplace safe – a USB stick or a CD. Truly nasty infections can actually prevent you being able to update your AV scanner or download/install a new one.
Whatever AV you’re going to go with, please, pretty please, download a copy of Malware Bytes onto a USB stick or a CD and file it away for safe keeping.
For some time now, you’ve seen me turning into a Ubuntu loverboy. Mark this post as my officially running for the exit with only a brief stop to grab an industrial strength barf bag.
Ubuntu 11.0, “Natty Narwhal”, is in Alpha. I’ve given it a short spin, done a little reading to check on my initial conclusions.
Don’t misunderstand: It’s perhaps the best Ubuntu yet. But you come near one of my workstations with it and I’m not going to think twice about smashing you in the head with my monitor.
I think that, for many people, the big Ubuntu win was it’s ability to deliver a better-than-tolerable desktop experience. Their success has enabled them to leverage the same smarts to delivering a fantastic netbook experience. Then they did too many drugs and now they’re trying to deliver the netbook experience in the desktop version…
I’ve been plowing ahead with my grid system redo. Yesterday I got the last vestiges of the old system unplugged from the code and, since this is officially our holiday week, taking the opportunity to clean up some of the peripheral code.
The old code combined the packing of data into the output stream with the actual assembly of the data. Result: spaghetti code mixed with massive blocks of #ifdefs that was utterly unreadable.
What the old code has going for it, perhaps, was efficiency. Hard to judge though. Even giving it the benefit of the doubt, the new code will lend itself to parallelization.
Right now my brain is stewing over how I am going to elegantly/efficiently track (and communicate) changes in such large and complex structures, and in a language that doesn’t have reflection.
Two of the core components of our game server systems are the poorly named “World Grid” and “Update System” (the names reflect what the systems do, but not their overall role in the game server cluster). The combination of these two is alternately called “The Grid” and “The Update System”.
In short: they divide the world up into small parcels of virtual space, track the players moving around in those spaces, and generate data packets describing movements between one player and another.
Written by coders not happy to co-operate together, hodged and podged over 10 years, sprinkled with genuine pixie dust(*); neither component lends itself to maintenance, study or peace of mind.
They were developed for 1999 hardware and lovingly hand-optimized to running with magnificent efficiency on an old Pentium III 800. But you would really have to go out of your way to make them less hostile to a modern CPU like the Dual Xeon Quad-Core 3ghzs our servers currently run on.
For 7 years+, they have been the bane of my existence.
(This is not a hate-on-Python by a Python-hater, this is a smirk-at-Python by a recent Python convert)
I’d mentioned yesterday that Python comes with a hefty cost for function calls.
In my foot-wetting with Python, it has seemed that “Pure Python” modules are often highly prized. But glancing at the Python 3.1 What’s New notes, it seems that writing Python in Python isn’t the best way:
The new I/O library [...] was mostly written in Python and quickly proved to be a problematic bottleneck [...] the I/O library has been entirely rewritten in C and is 2 to 20 times faster depending on the task at hand.
Note: This post is tounge-in-cheek; I’m well aware the real reason Pure Python modules are valued is an extra level of flexibility they deliver through the propagation of various Python language facilities.