As was foretold, we've added advertisements to the forums! If you have questions, or if you encounter any bugs, please visit this thread: https://forums.penny-arcade.com/discussion/240191/forum-advertisement-faq-and-reports-thread/
Options
Free Antivirus
meeker
Registered User regular
Registered User regular
So it looks like today is the last day that AVG will be free. I have used it for years after I got sick of paying a yearly fee to Norton.
So what is the best free AV software out there now? I have heard about Avast, but that is the only one I know of.
So what is the best free AV software out there now? I have heard about Avast, but that is the only one I know of.
meeker on
0
Posts
Comcast. No way in hell am I putting Comcast software on my PC...
http://free.grisoft.com/ww.download-avg-anti-virus-free-edition
Just did it on my PC and my wife's, works pretty much the same, although the interface has been candy-fied a little more as far as the skin goes.
Errr...I've heard good things about NOD32 as well, but the fact that it was written in assembly makes me instantly question the competence of their developers. Not to mention their sanity. Is that really true?
I brought it up because it was interesting. While it could be due to the fact that the developers didn't have the resources to program with a high-level language, it doesn't work against them. The fact that it was written in assembly means it's fast and resource efficient.
Source, comprehensive review
It's fast and efficient and wins crazy awards, from what I hear.
(it's not free though, I'm seeing. there's a 30 day trial on Eset's site.)
I've done some searching, and apparently they do claim that NOD32 is written primarily in assembly, and therefore it's fast and efficient. To me, it doesn't follow - yes, it may be written in assembly, and yes, it may be fast and efficient. This argument that assembly implies fast and efficient is based on the fact that old compilers weren't very good at optimizing. We're talking in like the 1980s. There was a big hullabaloo when people started writing operating systems in C, because it was believed that C could never be as efficient as hand-tuned assembly. It turns out that indeed, you can write performant operating systems in C and other high-level languages.
The difficulties with writing large programs in assembly these days are numerous. First, once an assembly program gets to a certain size (that is not very big) you begin to lose intellectual control over it. It becomes hard to understand and maintain. Witness the Geoworks vs. Windows CE situation: GeoWorks was a full graphical operating system written for 8-bit microcomputers (like Commodores and stuff). It was written completely in assembly. When writing GUIs in assembly was no longer a good idea (i.e., when powerful computers like the 80286 came out), they thought they had found a renaissance in embedded devices - things like PocketPCs, where the severe resource constraints would favor an all-assembly OS. What they found after porting their code to these pocket platforms was that Windows CE was a lot more responsive. How could this be? It turned out that Geoworks was redrawing stuff dozens of times, executing similar sections of code mulitple times, etc. It was doing this because the developers had lost intellectual control - they had lost the ability to understand and debug the program.
With modern processors, assembly coding perhaps makes even less sense. First, each new generation of processor has a smattering of new instructions that can vastly speed up certain operations. What do the NOD32 guys do when the new Core 2 processors add a few registers or a couple new SSE instructions? Do they go recode everything? Do they really do multithreaded code at the assembly level to take advantage of multicore processors? If they had written things in C, they could just recompile with ICC and pass a different flag to target the new instruction set, then look at the vectorization profile reports and rearrange things or insert some intrinsics to deal with things that aren't vectorizing.
Things are only going to get worse in the next few years, as JIT and dynamic compilers will use runtime profiling information to dynamically transform and tune code beyond what hand-tuned assembly can do.
If I had to guess, I'd say that NOD32 was faster than, oh, say, Symantec AV not because it was written in assembly, but because the NOD32 guys understand how to write efficient code (it's a shame they do it in such a stupid way, though). It helps them greatly that the Symantec developers appear to have all the coding skill of a tribe of retarded monkeys.