Not sure if trolling, stupid or doing some particularly bad drugs - but I'll bite anyway.
I'll take a larger L2 over more cores any day, You're a F0k1ng idiot if you judge processors solely bases on Hz and core-count.
I'll personally take what quantified, repeatable benchmarks for my particular needs indicate is best - but whatever floats your boat:-). Also, let's see...
1) The PS2 launched in 2000, not 2004.
2) In 2000, we had the GeForce 2 series GPUs for the x86 platform - definitely not up to today's GPGPU standards, but definitely hardware-accelerated 3D graphics. I'll leave any further comparison to somebody more qualified, it's beyond my main point anyway.
3) So, my main point wrt. Sony: their architecture has been somewhat whacky compared to x86. With x86, we have symmetrical multiprocessing - the x86 cores are programmed equally. PS2 and PS3 are anything but homogenous. Original XBOX was pretty much a Pentium3, and while XBOX360 isn't x86, it's a homogenous tricore+SMT CPU.
Shouldn't things like collision detection be running server-side to avoid client-side exploits? And since when has sound mixing been particularly CPU intensive? (yeah, it was hardware accelerated for a few years with EAX, then everybody seemed to move it back to software processing, without anybody taking much of a hit.)
I'm not saying that More Cores will never be important, btw - just that parallelizing is hard (in general - and for games in particular) and that with the current crop of games I've seen, fewer-but-faster cores are the better deal. I thought that was pretty clear, with the emphasis and all, from paragraph 3 of the post you responded to:-)
Don't confuse an exploit with a specific piece of malware. This invalidates all your above points.
Also, keep in mind that there's (public-and-patched as well as private-0day) privilege escalation exploits available for all major operating systems. This directly invalidates your point #4, and indirectly #3. #2 and #5 are relatively trivial to overcome... but the funny/sad thing is that you don't need any of this trickery in order to be effective. You can get a zillion zombie bots all running in user-mode without much anti-malware tricks, simply because the majority of users are computer illiterate and will click on anything in order to see Olsen Twins Hot Lesbian Sex.
They don't need the browser plugin, though, only the JRE - so while they'll fall prey to clicking "Olsen Twins Hot Steaming Lesbian Sex.MPG.jar", they won't get browser drive-by malware.
Keep away from the browser plugin and install just the JRE. You'll still be 0wned by clicking on "Olsen twins hot lesbian session.mpg .jar", but you'll be safe from browser drive-by attacks.
Sorry, but Java has a really nasty track record of exploits - especially considering that client code runs not just in a sandbox, but a sandboxed virtual machine - and that the platform has had a lot of emphasis on security from day one.
I don't have a Java plugin in my browser, I consider that pretty much security suicide. Because I live in.dk, I have to use a browser with Java plugin from time to time, but I handle that in a locked down virtual machine that I use solely for that purpose.
Also: I kinda like Java as a language (even if it's verbose and the platform has a boatload of flaws), the JVM has a few nifty things here and there, and my day job involves Java coding. That doesn't mean I'm going to close my eyes and pretend it's a good thing to have installed on client systems, though.
For us people living in Denmark, there's pretty much no way to avoid Java. The nation-wide "digital signature" (that's what they call it - in fact it's really just a glorified single-signon) NemID ("Easy ID") requires Java. It's a big fscking mess, it's run by the banking industry but being shoved down our troaths for interfacing with the government, and there's already successful MITM attacks for it.
Oh yeah, and the signed Java applet is just a bootstrap that fetches unsigned applets from "whatever location", and it includes JNI binaries as well that snoops system info for "fingerprinting reasons"... perfect vector for the PET, the Danish version of NSA. Goodtimes.
Ah, nice to hear - your redacted summary just gave another impression.
Been through both sides myself, depending on what made most sense at the time - first box I owned was a 486dx4-100, obviously AMD. Current rig is third intel generation in a row, though - AMD haven't really been able to keep up (except for the budget segment) since Intel launched Core2, imho. Which is kinda sad - while I kinda would have liked to see x86 die and "something better" emerge rather than getting x86-64, at least AMD obliterated the P4 with AMD64. Would be nice seeing that kind of competition again:-)
Just one thing: whether disk speed matters or not depends a lot on the game, and whether it's the "we have a fixed memory profile, and load all assets to memory while loading a level" or "we stream stuff as necessary" type. For instance, for Far Cry 2, it made pretty much no difference whether I had the game files on a 2x74gig Raptor RAID-0 or on a ramdisk. For a lot of engines, there's all sorts of things going on... Disk I/O, some CPU crunching, some sysmem->gpumem transfers, some gpu crunching... and enough wait-states that nothing ever runs at 100% speed.
PunkBuster spiking to 20-30% CPU is, as you mentioned, a bug - it is not the norm. And while people won't be shutting down every background process to play a game, they don't tend to run anything heavy while gaming. And all the regular stuff (web browser with a zillion tabs loaded, email client, IM client, torrent client,...) is pretty negligible CPU-wise.
I personally haven't run into games that can utilize more than two cores (please let me know if they're out there!), and even then there's usually been synchronization issues that has kept the game from reaching 100% core utilization, even on the slower cores. Parallelizing stuff is hard, and outside of the core graphics pipeline (which runs mostly on the GPU), there's so much stuff that needs to run in strict order in a game engine. I sure do hope clever programmers will think of improvements in the future, though, since we'll hit the GHz sooner or later - and then we need to scale on number of cores.
As things are right now, I'd still say a faster dualcore is more bang for the buck than a slower quadcore, gamewise - but that might change before long. And considering that the current crop of CPUs can turbo-boost a couple of cores when the other cores are inactive, it's obviously better to shop for a quadcore than a dualcore - but with the current crop of games, you'd effectively be using the CPU as a faster dualcore when not running intensive background stuff:-)
You can't really compare the consoles directly to x86 CPUs, btw, the architecture is radically different - moreso on the playstation side than the xbox (and let's ignore the original xbox here, for obvious reasons:)). I wonder if Sony is going to keep up their "OK, this is pretty whacky compared to the commodity multicore stuff you're used to, but it's really cool!" approach, or if they'll settle for something "saner".
I've been running a Q6600 for several years, and only replaced it last month. That's a July 2006 CPU. It didn't really seem strained until the very most recent crop of games... and yes, sure, it's a quadcore, but game CPU logic hasn't been heavily parallelized yet, so a fast dualcore will still be better for most gamers than a quadcore - and the Q6600 is pretty slow by today's standard (2.4GHz, and with a less efficient microarchitecture than the current breed of core2 CPUs).
Sure, CPUs matter, but it's not even near a case of "you need the latest generation of CPU to run the latest generation of games!" anymore. Upgrading to a i7-3770 did smooth out a few games somewhat, but I'm seeing far larger improvements when transcoding FLAC albums to MP3 for my portable MP3 player, or compiling large codebases:)
The days where people wrote malware for fun & fame are long gone - today it's serious business with big money involved. You don't add features for shit & giggles, and for "let's build ourselves a botnet" or "let's harvest as many CC numbers and login credentials", you don't spend time adding code that will only affect a (relatively) few users.
Other trojans, though, start by exploiting a bug in Java, Flash or AdobePdf... then they're either content with running with normal user privileges (with which you can still do a lot of harm), or they use a privilege escalation exploit (present in all common desktop OSes - some just not known widely because it's more profitable to keep them private for very targeted attacks) - and b00m, you're owned.
It's hard to write bugfree software, sure, but the unholy trio above is appalling.
Breaking out of a VM could be useful for getting at a researcher's interesting files (and there's been a few windows of opportunity where at least vmware has been vulnerable), but breaking into a VM? Why on earth would you want to do that? I can think of one reason that kinda makes sense, and that's getting access to an image that's going to be spread into the cloud, but that seems like such an insanely specialized usecase that I don't grok why it's included in a generic piece of malware.
I never had a problem with direct 8042 access, as long as the IRQ1 handler was properly written - this includes running a TSR that had direct keyboard handling (to detect it's hotkey) as well as direct textmode access through segment 0xB800. I don't think EMM386 (the EMS memory manager) had anything to do with keyboard access (though it did use the 8042 to reprogram Gate A20 in order to access >1meg memory addresses), you might be thinking of DesqView? (DOS multitasking environment - I only used it very briefly, but didn't have trouble with direct keyboard access or text mode memory access there, either).
The worst that could happen from accessing 0xB800 directly was not being able to redirect text output to files, possibly garbled text because other programs were also writing to text memory, or nothing happening because the system was running in a mode where 0xB800 wasn't used (like, graphics modes, or monochrome 0xB000 output, or a virtualized environment where you didn't have access to physical address 0xB8000) - but it certainly couldn't mess up stuff, as long as you weren't adding other things to the mix, like changing video modes or setting a different cursor position.
You're right - the default textmode when booting an x86 system "since pretty much forever" is 80x25, BIOS video mode 3.. A lot of distros are evil and change to other textmodes, or framebuffer modes, without asking you, though.
"wasn't exactly being a good neighbor"? That's the way you did stuff under DOS, and it was just fine in those days. It was a single-tasking environment, and writing directly to the 0xB800 segment when you needed fast textmode operations was just fine. ANSI.SYS was slow as hell compared to handling ANSI escape sequences yourself - even if you resorted to BIOS character output routines and not doing direct 0xB800 access... But since redirecting ANSI escape codes to files often didn't make sense, it made more sense doing direct access. Not everybody had the luxury of affording one of those insanely fast 80386 processors;)
...at very limited resolutions (yes, there's the extended VGA text modes, but those are still limited and look horrible), with limited character sets, and either display cloned across all connected monitors, or limited to a single monitor output.
80x50 textmode is perfectly fine for me, but other people might have different needs... and the unaccelerated framebuffer modes are definitely horribly slow.
If you've been hit by something that's able to modify your hosts file (requiring administrative privileges), worrying about facebook or doubleclick being redirected seems kind of futile.
OTOH, not being able to retrieve Windows Updates, download MSE and other anti-malware software? That can definitely make a difference. It's dubious, at best, that facebook and doubleclick entries are being removed.
Umm, would you use the hosts file if setting up a Windows box for firewall purposes? I think not.
I actually think not allowing critical things like *.microsoft.com (especially windows update and MSE) being redirected is a good thing - but there should be a Big Fat Popup warning that this is being done, and extending the hosts-removal for things like facebook and doubleclick? That's dubious, to put it mildly.
Slashdot Mirror
Not sure if trolling, stupid or doing some particularly bad drugs - but I'll bite anyway.
I'll take a larger L2 over more cores any day, You're a F0k1ng idiot if you judge processors solely bases on Hz and core-count.
I'll personally take what quantified, repeatable benchmarks for my particular needs indicate is best - but whatever floats your boat :-). Also, let's see...
1) The PS2 launched in 2000, not 2004.
2) In 2000, we had the GeForce 2 series GPUs for the x86 platform - definitely not up to today's GPGPU standards, but definitely hardware-accelerated 3D graphics. I'll leave any further comparison to somebody more qualified, it's beyond my main point anyway.
3) So, my main point wrt. Sony: their architecture has been somewhat whacky compared to x86. With x86, we have symmetrical multiprocessing - the x86 cores are programmed equally. PS2 and PS3 are anything but homogenous. Original XBOX was pretty much a Pentium3, and while XBOX360 isn't x86, it's a homogenous tricore+SMT CPU.
Shouldn't things like collision detection be running server-side to avoid client-side exploits? And since when has sound mixing been particularly CPU intensive? (yeah, it was hardware accelerated for a few years with EAX, then everybody seemed to move it back to software processing, without anybody taking much of a hit.)
I'm not saying that More Cores will never be important, btw - just that parallelizing is hard (in general - and for games in particular) and that with the current crop of games I've seen, fewer-but-faster cores are the better deal. I thought that was pretty clear, with the emphasis and all, from paragraph 3 of the post you responded to :-)
Don't confuse an exploit with a specific piece of malware. This invalidates all your above points.
Also, keep in mind that there's (public-and-patched as well as private-0day) privilege escalation exploits available for all major operating systems. This directly invalidates your point #4, and indirectly #3. #2 and #5 are relatively trivial to overcome... but the funny/sad thing is that you don't need any of this trickery in order to be effective. You can get a zillion zombie bots all running in user-mode without much anti-malware tricks, simply because the majority of users are computer illiterate and will click on anything in order to see Olsen Twins Hot Lesbian Sex.
Larry Ellison glances at his screwdriver...
...then laughs manically, and screws everybody over. Again.
*cough* version control software + branches *cough* - hardly rocket science.
They don't need the browser plugin, though, only the JRE - so while they'll fall prey to clicking "Olsen Twins Hot Steaming Lesbian Sex.MPG .jar", they won't get browser drive-by malware.
Seems legit.
Keep away from the browser plugin and install just the JRE. You'll still be 0wned by clicking on "Olsen twins hot lesbian session.mpg .jar", but you'll be safe from browser drive-by attacks.
Sorry, but Java has a really nasty track record of exploits - especially considering that client code runs not just in a sandbox, but a sandboxed virtual machine - and that the platform has had a lot of emphasis on security from day one.
I don't have a Java plugin in my browser, I consider that pretty much security suicide. Because I live in .dk, I have to use a browser with Java plugin from time to time, but I handle that in a locked down virtual machine that I use solely for that purpose.
Also: I kinda like Java as a language (even if it's verbose and the platform has a boatload of flaws), the JVM has a few nifty things here and there, and my day job involves Java coding. That doesn't mean I'm going to close my eyes and pretend it's a good thing to have installed on client systems, though.
For us people living in Denmark, there's pretty much no way to avoid Java. The nation-wide "digital signature" (that's what they call it - in fact it's really just a glorified single-signon) NemID ("Easy ID") requires Java. It's a big fscking mess, it's run by the banking industry but being shoved down our troaths for interfacing with the government, and there's already successful MITM attacks for it.
Oh yeah, and the signed Java applet is just a bootstrap that fetches unsigned applets from "whatever location", and it includes JNI binaries as well that snoops system info for "fingerprinting reasons"... perfect vector for the PET, the Danish version of NSA. Goodtimes.
Ah, nice to hear - your redacted summary just gave another impression.
Been through both sides myself, depending on what made most sense at the time - first box I owned was a 486dx4-100, obviously AMD. Current rig is third intel generation in a row, though - AMD haven't really been able to keep up (except for the budget segment) since Intel launched Core2, imho. Which is kinda sad - while I kinda would have liked to see x86 die and "something better" emerge rather than getting x86-64, at least AMD obliterated the P4 with AMD64. Would be nice seeing that kind of competition again :-)
Wise words.
Just one thing: whether disk speed matters or not depends a lot on the game, and whether it's the "we have a fixed memory profile, and load all assets to memory while loading a level" or "we stream stuff as necessary" type. For instance, for Far Cry 2, it made pretty much no difference whether I had the game files on a 2x74gig Raptor RAID-0 or on a ramdisk. For a lot of engines, there's all sorts of things going on... Disk I/O, some CPU crunching, some sysmem->gpumem transfers, some gpu crunching... and enough wait-states that nothing ever runs at 100% speed.
PunkBuster spiking to 20-30% CPU is, as you mentioned, a bug - it is not the norm. And while people won't be shutting down every background process to play a game, they don't tend to run anything heavy while gaming. And all the regular stuff (web browser with a zillion tabs loaded, email client, IM client, torrent client, ...) is pretty negligible CPU-wise.
I personally haven't run into games that can utilize more than two cores (please let me know if they're out there!), and even then there's usually been synchronization issues that has kept the game from reaching 100% core utilization, even on the slower cores. Parallelizing stuff is hard, and outside of the core graphics pipeline (which runs mostly on the GPU), there's so much stuff that needs to run in strict order in a game engine. I sure do hope clever programmers will think of improvements in the future, though, since we'll hit the GHz sooner or later - and then we need to scale on number of cores.
As things are right now, I'd still say a faster dualcore is more bang for the buck than a slower quadcore, gamewise - but that might change before long. And considering that the current crop of CPUs can turbo-boost a couple of cores when the other cores are inactive, it's obviously better to shop for a quadcore than a dualcore - but with the current crop of games, you'd effectively be using the CPU as a faster dualcore when not running intensive background stuff :-)
You can't really compare the consoles directly to x86 CPUs, btw, the architecture is radically different - moreso on the playstation side than the xbox (and let's ignore the original xbox here, for obvious reasons :)). I wonder if Sony is going to keep up their "OK, this is pretty whacky compared to the commodity multicore stuff you're used to, but it's really cool!" approach, or if they'll settle for something "saner".
You're an AMD fanboi, eh? :-)
*shrug*
I've been running a Q6600 for several years, and only replaced it last month. That's a July 2006 CPU. It didn't really seem strained until the very most recent crop of games... and yes, sure, it's a quadcore, but game CPU logic hasn't been heavily parallelized yet, so a fast dualcore will still be better for most gamers than a quadcore - and the Q6600 is pretty slow by today's standard (2.4GHz, and with a less efficient microarchitecture than the current breed of core2 CPUs).
Sure, CPUs matter, but it's not even near a case of "you need the latest generation of CPU to run the latest generation of games!" anymore. Upgrading to a i7-3770 did smooth out a few games somewhat, but I'm seeing far larger improvements when transcoding FLAC albums to MP3 for my portable MP3 player, or compiling large codebases :)
The days where people wrote malware for fun & fame are long gone - today it's serious business with big money involved. You don't add features for shit & giggles, and for "let's build ourselves a botnet" or "let's harvest as many CC numbers and login credentials", you don't spend time adding code that will only affect a (relatively) few users.
Other trojans, though, start by exploiting a bug in Java, Flash or AdobePdf... then they're either content with running with normal user privileges (with which you can still do a lot of harm), or they use a privilege escalation exploit (present in all common desktop OSes - some just not known widely because it's more profitable to keep them private for very targeted attacks) - and b00m, you're owned.
It's hard to write bugfree software, sure, but the unholy trio above is appalling.
That seems plain stupid.
Breaking out of a VM could be useful for getting at a researcher's interesting files (and there's been a few windows of opportunity where at least vmware has been vulnerable), but breaking into a VM? Why on earth would you want to do that? I can think of one reason that kinda makes sense, and that's getting access to an image that's going to be spread into the cloud, but that seems like such an insanely specialized usecase that I don't grok why it's included in a generic piece of malware.
I never had a problem with direct 8042 access, as long as the IRQ1 handler was properly written - this includes running a TSR that had direct keyboard handling (to detect it's hotkey) as well as direct textmode access through segment 0xB800. I don't think EMM386 (the EMS memory manager) had anything to do with keyboard access (though it did use the 8042 to reprogram Gate A20 in order to access >1meg memory addresses), you might be thinking of DesqView? (DOS multitasking environment - I only used it very briefly, but didn't have trouble with direct keyboard access or text mode memory access there, either).
The worst that could happen from accessing 0xB800 directly was not being able to redirect text output to files, possibly garbled text because other programs were also writing to text memory, or nothing happening because the system was running in a mode where 0xB800 wasn't used (like, graphics modes, or monochrome 0xB000 output, or a virtualized environment where you didn't have access to physical address 0xB8000) - but it certainly couldn't mess up stuff, as long as you weren't adding other things to the mix, like changing video modes or setting a different cursor position.
You're right - the default textmode when booting an x86 system "since pretty much forever" is 80x25, BIOS video mode 3.. A lot of distros are evil and change to other textmodes, or framebuffer modes, without asking you, though.
Ah yes, a serial console is superior to supporting an external monitor. Definietely a lot faster and easier to hook up as well ;)
"wasn't exactly being a good neighbor"? That's the way you did stuff under DOS, and it was just fine in those days. It was a single-tasking environment, and writing directly to the 0xB800 segment when you needed fast textmode operations was just fine. ANSI.SYS was slow as hell compared to handling ANSI escape sequences yourself - even if you resorted to BIOS character output routines and not doing direct 0xB800 access... But since redirecting ANSI escape codes to files often didn't make sense, it made more sense doing direct access. Not everybody had the luxury of affording one of those insanely fast 80386 processors ;)
...at very limited resolutions (yes, there's the extended VGA text modes, but those are still limited and look horrible), with limited character sets, and either display cloned across all connected monitors, or limited to a single monitor output.
80x50 textmode is perfectly fine for me, but other people might have different needs... and the unaccelerated framebuffer modes are definitely horribly slow.
If you've been hit by something that's able to modify your hosts file (requiring administrative privileges), worrying about facebook or doubleclick being redirected seems kind of futile.
OTOH, not being able to retrieve Windows Updates, download MSE and other anti-malware software? That can definitely make a difference. It's dubious, at best, that facebook and doubleclick entries are being removed.
Umm, would you use the hosts file if setting up a Windows box for firewall purposes? I think not.
I actually think not allowing critical things like *.microsoft.com (especially windows update and MSE) being redirected is a good thing - but there should be a Big Fat Popup warning that this is being done, and extending the hosts-removal for things like facebook and doubleclick? That's dubious, to put it mildly.