Gunvalkyrie: Good review scores, unavailable on any other platform. Spikeout: Battlestreet: Poor reviews, low sales, limited market for emulation Metal Wolf Chaos: Never released outside Japan, famous only for how bad it is (in a so-bad-its-good way) Outrun 2: Also runs on arcade and 360 Otogi 1 & 2: Good review scores, unavailable on any other platform. ToeJam & Earl III: Mixed review scores, potentially a small market does exist Steel Battalion: Mandatory monstrous controller would prevent effective emulation anyhow, but a 360 port is underway Tao Feng: OK reviews, possible market
So, of all of these games, I see three of them (counting Otogi 1 & 2 as separate games, since they are) having potential interest, but the rest, not as much. And for some of them, they either do run on other platforms (like Outrun 2) or have ports in development (Steel Battalion). Some of these games, good or not, didn't sell all that well, which also limits the interest in emulating them.
That seems like the wrong approach. How about emulating the hardware, and running the Xbox OS from a hard disk image (or real xbox hard drive)?
Well, the current maintainer of Cxbx is taking that approach, and he's started a low-level emulation project. But the original author of Cxbx (and most other people who started XBox emulators) had the same thought: "Wait a minute, we don't need to emulate, we can just do high-level emulation and it'll run super fast!" This was relevant, because computers weren't as fast 8+ years ago (when Cxbx was first released) as they are today. But a large part of it is, as I said, lack of interest. Can you name a single game for the XBox that doesn't run on some other platform (be it PC or 360 or PS2 or GameCube)? I'm sure there are a few, but all of the popular ones are probably covered, so there's really a lack of need for a good XBox emulator.
I've had the opposite experience (as I said, crisp output from classic consoles looks odd to me, and I just don't get the same feeling as a real console), but it should be noted that some games actually rely on the behaviour of RF or composite video output. If you know that pixels are going to blur together, you can exploit that to produce colours that the console can't natively produce, for example. Other games, while not specifically relying on such trickery, probably made certain assumptions about colour gradients in low-bitdepth textures, so what looked like a smooth high-colour texture on-screen might not look nearly as good if you strip away that expected blur.
Driving a Ferarri at about the same speed as a bicycle isn't all that hard. Driving the Ferarri behind a bicycle at *exactly* the same speed such that the front bumper of the Ferarri is always exactly 1mm away from touching the spinning rear wheel of the bicycle, that's a lot harder. Now add a motorcycle behind your Ferarri trying to do the same thing, and a segway behind the motorcycle, and a battle tank behind the segway, and a skateboard behind the battle tank, and you might start to appreciate how hard synchronization can be.
An Atom CPU, the kind of CPU likely to be found in a nettop PC that might be hooked up to a large monitor, does about the same amount of work per cycle as a P4 did.
That's not really a fair example, since Intel hasn't touched the Atom's microarchitecture since 2008 when it first came out, and the architecture itself is a throwback to processor designs from the late 80s to early 90s (i486/i586). It's reportedly half the performance of a Pentium-M, and that's about how much faster the Pentium-M was compared to the Pentium 4, so it makes sense that the performance of Atom would be about on-par with with P4 clock-for-clock. Of course, the Pentium-M is much less performant clock-for-clock than a modern Sandy Bridge i7...
Not to spout "RTFA", but the author addressed this exact point. He points to DICE, the Discrete Integrated Circuit Emulator, which simulates classic games on the transistor level (including propagation). So, this is pretty much as accurate as you can possibly get, unless you want to emulate on the atomic level.
How is performance? Well, one of the primary games it emulates (on the physical circuitry level, of course) is Pong. The original. Modern computers aren't quite fast enough to run it at full speed, although it's getting there, and the latest version is reportedly playable on high-end hardware. Pong didn't even have a CPU, so imagine how hard emulating an NES's 6502 in real-time... The author actually mentions this as well, he mentions Visual6502, an emulator that emulates on the transistor level but doesn't bother simulating propagation delay. So it cheats a lot for performance. How fast does it run? They report the Python version runs at 27Hz. To emulate an NES, ignoring the rest of the hardware, the 6502 needs to run at 1790000 Hz. That's quite the gap to bridge. If we assume the Python version is a tenth the speed of a C++ implementation, and then go by a Moore's law doubling of performance every 18 months, it will be about 20 years before a modern computer is fast enough to emulate *JUST* the NES CPU on the transistor level, and even then an incomplete emulation that ignores the propagation delay of electricity.
There are a few xbox emulators. The most famous of which is Cxbx, which is still semi-actively maintained (in a fork after the original author abandoned it):
It's not the only one. There was another one that came out early on that emulated Halo (and only Halo). Like Cxbx, it was also a high-level emulator. I don't remember the name of that one. Another is DxBx, which has a handful of playable games. There might be some others.
Overall, the reason why XBox emulation is so primitive compared to other consoles in the same generation is lack of interest and need. The XBox wasn't all that successful (It was Microsoft buying their way into the market, which *was* a smart move, but they knew going in that the first XBox would lose a ton of money), and most of the games that were popular on it were also available on other platforms that do have decent emulators (GameCube, PS2) or don't need emulators (PC). Even then, most of the popular games *are* supported by the XBox emulator that comes with the XBox 360, so even if the game isn't available on a different platform, and you can't emulate it on a PC, you can probably emulate it on a 360.
Just because the 360 ran x86 doesn't mean emulation is trivial. Even if you treat it like a PC to be virtualized rather than a console to be emulated, you've got the unenviable task of writing the simulation of an entire operating system (which, while not based on Windows, does use a similar API, plus DirectX), and since there's very little hardware abstraction going on, you *do* need to emulate (or at least translate for) all the other components like the GPU.
Look at projects that try to accomplish similar things, like WINE. WINE doesn't even have to do nearly as much, since it just has to simulate the API and not any of the hardware, but even WINE is still woefully incomplete after 18 years of development by a large team. Admittedly, part of that is because they're working towards a moving target, but it gives you an idea of how it's really not so simple. Another more specific example might be Direct3D virtualization in software like VMWare. They spent years working on it, and it's still not perfect, and it still has a bunch of limitations. Considering that VMWare has only become more popular on the consumer-level over the years (not least because MacOS switched to x86, leading to a whole lot of Mac users who want to run Windows apps without rebooting into bootcamp), I'm sure they'd had a perfect Direct3D virtualization subsystem years ago if it were that easy.
I'd love to know how you got crisp blocky pixels from your NES in the 1980s, because I certainly didn't. I got a wonderfully softened image from the 1980s TV tubes, and "crisp blocky pixels" are the opposite of fidelity.
True fidelity would also simulate the display presentation. The simple TV filters provided with most emulators do an OK job, although they normally just do horizontal linear interpolation and then simulate a scanline effect for the vertical. But some people out there go farther than that and try to emulate all the strangeness of the NTSC signal, and sometimes even try to emulate CRT subpixels. Which isn't as silly as it sounds, when you consider that my $750 LCD monitor's resolution (2560x1440, or 1920x1440 for 4:3), which cost less than a decent TV back then, has a high enough pixel density to do that.
Playing NES and SNES games with nearest-neighbour filtering always felt off to me, because it never looked anything like that on a real NES/SNES and TV back in the day. Something about how sharp it was just felt fake. A simple bilinear interpolating filter, while not authentic, looks a lot closer to a real NES/SNES than nearest-neighbour ever did.
The GameBoy might be a good counter-example, since it was an LCD, but few emulators bother to simulate the super low contrast ratio of those impossible to see screens:)
The 3DS virtual console's classic GB emulator is actually pretty faithful. It gives you the choice between 1:1 pixels and bilinear interpolation, and between greyscale display (as most emulators show) and a low-contrast colour pallet that simulates the green shades of a real GB. It's nice that they give you the option to go for fidelity if you want, or just play scaled up with high-contrast greyscale if you don't want.
While I'd generally agree with some of that (SW ships definitely have the speed advantage), most of the figures cited there are silly. They have the heavy laser gun on a troop transport (a shuttle, basically) putting out enough energy to wipe out all life on the planet in a single shot... Makes the death star kind of redundant, don't it? Their scales are so far off that a single hit from any SW laser or turbolaser should completely incinerates whatever ship it hits if the shields are down, when there's tons and tons of canonical evidence to the contrary (damage is caused, but not as much as the numbers you link to indicate).
I suspect the reason for this is because when Rick Sternbach and Michael Okuda were coming up with these figures, they probably consulted real-life figures and theory and extrapolated, while the author of Star Wars Episode II Incredible Cross-Sections probably just made up stuff that sounded good.
That's not a knock against Star Wars, it reflects a different focus. Star Wars was never about the tech.
That might be true if Amazon didn't have multiple AZs in single datacenters.
The fault isn't necessarily Amazon's for stuff like this. The whole point of cloud infrastructure is that you use many cheaper instances to scale load and provide high availability caused by the failure of any one (or group of) node. Take Netflix, for example. While they do have their share of outages, they were completely unaffected by Amazon's big EC2 failure a few months ago, despite the fact that a significant portion of Netflix' infrastructure was hosted out of the affected region. Why? Because they built failure into their system, to the extent where they have a process that goes around killing random instances to keep them on their toes. They've planned for and built their system around the possibility that large chunks of the system might just up and vanish without warning.
If you're building a large-scale cloud system, *geographic* diversity should obviously be a part of any high availability plan. I'd also say that having provider diversity isn't a bad idea, but it seems like a lot of big cloud customers just stick with one provider.
It's hard to list one thing when it's the whole package of hundreds of tiny things that make up a modern web mail interface. Plus lots of tiny little things that you hardly notice until they're not there.
I use SquirrelMail maybe 6-7 years ago, and it was a painful experience compared to even other web interfaces at the time. I've use it recently too, and as far as I can tell, it hasn't really improved, while every other web mail UI has dramatically evolved.
Modern webmail clients are on par with the features and usability of offline clients, squirrelmail isn't.
That's a specific bug with certain consumer-grade OCZ drives. I have had the exact same problem happen to me with regular HDDs due to a bug in the filesystem driver. Admittedly, it was a different cause, but the same effect. As far as I know, Intel has never suffered from that issue with their drives, nor have any other enterprise-grade drives.
Intel has had a few issues with their drives, but they've thankfully been all of the immediate-failure type that works best with RAID.
Lots of first person shooters are written in C#/.NET. Any FPS for Windows Phone 7, since WP7 requires third party apps be written with XNA or Silverlight. Any FPS XBox Live Indie Games are too. There's no particular reason you can't make an FPS with.NET. Are you going to make the next Crysis? No, but the performance is good enough that it won't be the platform holding you back from producing fun and engaging content, it'll be your abilities. But really, why design an FPS-oriented 3D engine from the ground up for.NET/XNA when there are many existing engines out there that are cheap or free? Unreal Engine, for example. The UDK is free.
If you absolutely need it, you can also call native code in a.NET app, although you lose most of the portability (or the ability to run on the 360 or WP7). Is this cheating? Well, is it cheating to write performance critical sections of a c++ app in assembly?
$10,000 per terabyte. Ok, then. Sure, it's faster, if you are willing and able to pay 10x the cost of *current* HDD-based systems...
I guess you missed the part where they said that the Nimbus pricing of $10,000 was "on par" with the HDD-based storage arrays they had from NetApp and HP before? Fibre-channel HDD pricing is in the same ballparks as enterprise SSDs.
The thing is, the cost-per-gig will eventually not matter, because the cost-for-enough-gigs will be sufficiently low. The point will come where people can get an SSD that's "big enough" at a price that's low enough. It won't matter that you'll be able to buy a 5TB drive for the price of your 1TB SSD, because the 1TB SSD will be big enough for the average person.
Even for home use, I figure nearly everybody scoffing at SSDs, thinking they're not needed, has never *USED* an SSD for their day-to-day computing. It's the kind of thing where you think "Nobody needs that", and then you try it, and it turns out the be the single biggest performance upgrade you can make to your computer. And then you get used to it, and think "It's not that big a deal, HDDs weren't so bad", and then if somebody takes away your SSD, your computer feels like molasses.
A while ago, I built a new computer for a friend of mine. Got a great deal on a consumer SSD for him too. Later, he got a new laptop, and was complaining to me about how slow it was. After some prodding about what was slow about it, I realized that it wasn't the CPU, or the GPU, it was that he was now used to his desktop's SSD and going back to a notebook HDD was too big of a performance hit for him.
I'd rather a drive fail suddenly without warning if the alternative is "slowly and silently corrupting data until somebody notices it because it tripped a SMART threshold". Because I've had that happen, and all sorts of other nasty gradual failures.
Any enterprise setup is going to have redundancy built-in. If a drive up and fails suddenly and without warning, you swap it out, boom, done. If you've got hot or cold standby drives already in the array, icing on the cake. But if a drive starts a slow march towards failure, it can be a while before you or monitoring tools notice the issue, and even once you do, there's that temptation to say "Oh, it's still working well enough, we don't need to replace it quite yet."
And a 3.5" 15K SAS drive will do 120MB/s to 200 MB/s with an average of 170 MB/s, which is only very slightly slower than an SSD on a 3Gbps SAS or SATA2 connection will do. A very large 7200RPM drive comes pretty close too. Sequential read and write speeds is not a major factor in SSD performance advantages. That's not even a typical use case. It's when IOPS get involved that SSDs completely destroy HDDs.
1989? So you haven't tried a version of Windows since Windows 2?
I'm not sure System 6 would compare all that well to Windows 7, just like Windows 2 wouldn't compare all that well to OS X. I remember the days of System 6 and 7. Compared to what was available at the time, they were leaps and bounds ahead of the competition, (Windows was a joke at the time) but compared to anything modern, they were horrible. System 6 didn't support multitasking without multifinder (which was a hack), and both of them were terribly unstable (no protected memory and co-operative multitasking).
I saw it last year at Fantasia. It was cheesetastic, but it had the audience hooting, hollering, and cheering along. It's the kind of B-movie where if you embrace the cheese and insanity, you have a great time. The director was at the screening to talk a bit, it was a blast.
Slashdot Mirror
Gunvalkyrie: Good review scores, unavailable on any other platform.
Spikeout: Battlestreet: Poor reviews, low sales, limited market for emulation
Metal Wolf Chaos: Never released outside Japan, famous only for how bad it is (in a so-bad-its-good way)
Outrun 2: Also runs on arcade and 360
Otogi 1 & 2: Good review scores, unavailable on any other platform.
ToeJam & Earl III: Mixed review scores, potentially a small market does exist
Steel Battalion: Mandatory monstrous controller would prevent effective emulation anyhow, but a 360 port is underway
Tao Feng: OK reviews, possible market
So, of all of these games, I see three of them (counting Otogi 1 & 2 as separate games, since they are) having potential interest, but the rest, not as much. And for some of them, they either do run on other platforms (like Outrun 2) or have ports in development (Steel Battalion). Some of these games, good or not, didn't sell all that well, which also limits the interest in emulating them.
That seems like the wrong approach. How about emulating the hardware, and running the Xbox OS from a hard disk image (or real xbox hard drive)?
Well, the current maintainer of Cxbx is taking that approach, and he's started a low-level emulation project. But the original author of Cxbx (and most other people who started XBox emulators) had the same thought: "Wait a minute, we don't need to emulate, we can just do high-level emulation and it'll run super fast!" This was relevant, because computers weren't as fast 8+ years ago (when Cxbx was first released) as they are today. But a large part of it is, as I said, lack of interest. Can you name a single game for the XBox that doesn't run on some other platform (be it PC or 360 or PS2 or GameCube)? I'm sure there are a few, but all of the popular ones are probably covered, so there's really a lack of need for a good XBox emulator.
I've had the opposite experience (as I said, crisp output from classic consoles looks odd to me, and I just don't get the same feeling as a real console), but it should be noted that some games actually rely on the behaviour of RF or composite video output. If you know that pixels are going to blur together, you can exploit that to produce colours that the console can't natively produce, for example. Other games, while not specifically relying on such trickery, probably made certain assumptions about colour gradients in low-bitdepth textures, so what looked like a smooth high-colour texture on-screen might not look nearly as good if you strip away that expected blur.
Driving a Ferarri at about the same speed as a bicycle isn't all that hard. Driving the Ferarri behind a bicycle at *exactly* the same speed such that the front bumper of the Ferarri is always exactly 1mm away from touching the spinning rear wheel of the bicycle, that's a lot harder. Now add a motorcycle behind your Ferarri trying to do the same thing, and a segway behind the motorcycle, and a battle tank behind the segway, and a skateboard behind the battle tank, and you might start to appreciate how hard synchronization can be.
An Atom CPU, the kind of CPU likely to be found in a nettop PC that might be hooked up to a large monitor, does about the same amount of work per cycle as a P4 did.
That's not really a fair example, since Intel hasn't touched the Atom's microarchitecture since 2008 when it first came out, and the architecture itself is a throwback to processor designs from the late 80s to early 90s (i486/i586). It's reportedly half the performance of a Pentium-M, and that's about how much faster the Pentium-M was compared to the Pentium 4, so it makes sense that the performance of Atom would be about on-par with with P4 clock-for-clock. Of course, the Pentium-M is much less performant clock-for-clock than a modern Sandy Bridge i7...
Not to spout "RTFA", but the author addressed this exact point. He points to DICE, the Discrete Integrated Circuit Emulator, which simulates classic games on the transistor level (including propagation). So, this is pretty much as accurate as you can possibly get, unless you want to emulate on the atomic level.
How is performance? Well, one of the primary games it emulates (on the physical circuitry level, of course) is Pong. The original. Modern computers aren't quite fast enough to run it at full speed, although it's getting there, and the latest version is reportedly playable on high-end hardware. Pong didn't even have a CPU, so imagine how hard emulating an NES's 6502 in real-time... The author actually mentions this as well, he mentions Visual6502, an emulator that emulates on the transistor level but doesn't bother simulating propagation delay. So it cheats a lot for performance. How fast does it run? They report the Python version runs at 27Hz. To emulate an NES, ignoring the rest of the hardware, the 6502 needs to run at 1790000 Hz. That's quite the gap to bridge. If we assume the Python version is a tenth the speed of a C++ implementation, and then go by a Moore's law doubling of performance every 18 months, it will be about 20 years before a modern computer is fast enough to emulate *JUST* the NES CPU on the transistor level, and even then an incomplete emulation that ignores the propagation delay of electricity.
There are a few xbox emulators. The most famous of which is Cxbx, which is still semi-actively maintained (in a fork after the original author abandoned it):
http://shogun3d-cxbx.blogspot.com/
It's not the only one. There was another one that came out early on that emulated Halo (and only Halo). Like Cxbx, it was also a high-level emulator. I don't remember the name of that one. Another is DxBx, which has a handful of playable games. There might be some others.
Overall, the reason why XBox emulation is so primitive compared to other consoles in the same generation is lack of interest and need. The XBox wasn't all that successful (It was Microsoft buying their way into the market, which *was* a smart move, but they knew going in that the first XBox would lose a ton of money), and most of the games that were popular on it were also available on other platforms that do have decent emulators (GameCube, PS2) or don't need emulators (PC). Even then, most of the popular games *are* supported by the XBox emulator that comes with the XBox 360, so even if the game isn't available on a different platform, and you can't emulate it on a PC, you can probably emulate it on a 360.
Just because the 360 ran x86 doesn't mean emulation is trivial. Even if you treat it like a PC to be virtualized rather than a console to be emulated, you've got the unenviable task of writing the simulation of an entire operating system (which, while not based on Windows, does use a similar API, plus DirectX), and since there's very little hardware abstraction going on, you *do* need to emulate (or at least translate for) all the other components like the GPU.
Look at projects that try to accomplish similar things, like WINE. WINE doesn't even have to do nearly as much, since it just has to simulate the API and not any of the hardware, but even WINE is still woefully incomplete after 18 years of development by a large team. Admittedly, part of that is because they're working towards a moving target, but it gives you an idea of how it's really not so simple. Another more specific example might be Direct3D virtualization in software like VMWare. They spent years working on it, and it's still not perfect, and it still has a bunch of limitations. Considering that VMWare has only become more popular on the consumer-level over the years (not least because MacOS switched to x86, leading to a whole lot of Mac users who want to run Windows apps without rebooting into bootcamp), I'm sure they'd had a perfect Direct3D virtualization subsystem years ago if it were that easy.
I'd love to know how you got crisp blocky pixels from your NES in the 1980s, because I certainly didn't. I got a wonderfully softened image from the 1980s TV tubes, and "crisp blocky pixels" are the opposite of fidelity.
True fidelity would also simulate the display presentation. The simple TV filters provided with most emulators do an OK job, although they normally just do horizontal linear interpolation and then simulate a scanline effect for the vertical. But some people out there go farther than that and try to emulate all the strangeness of the NTSC signal, and sometimes even try to emulate CRT subpixels. Which isn't as silly as it sounds, when you consider that my $750 LCD monitor's resolution (2560x1440, or 1920x1440 for 4:3), which cost less than a decent TV back then, has a high enough pixel density to do that.
Playing NES and SNES games with nearest-neighbour filtering always felt off to me, because it never looked anything like that on a real NES/SNES and TV back in the day. Something about how sharp it was just felt fake. A simple bilinear interpolating filter, while not authentic, looks a lot closer to a real NES/SNES than nearest-neighbour ever did.
The GameBoy might be a good counter-example, since it was an LCD, but few emulators bother to simulate the super low contrast ratio of those impossible to see screens :)
The 3DS virtual console's classic GB emulator is actually pretty faithful. It gives you the choice between 1:1 pixels and bilinear interpolation, and between greyscale display (as most emulators show) and a low-contrast colour pallet that simulates the green shades of a real GB. It's nice that they give you the option to go for fidelity if you want, or just play scaled up with high-contrast greyscale if you don't want.
While I'd generally agree with some of that (SW ships definitely have the speed advantage), most of the figures cited there are silly. They have the heavy laser gun on a troop transport (a shuttle, basically) putting out enough energy to wipe out all life on the planet in a single shot... Makes the death star kind of redundant, don't it? Their scales are so far off that a single hit from any SW laser or turbolaser should completely incinerates whatever ship it hits if the shields are down, when there's tons and tons of canonical evidence to the contrary (damage is caused, but not as much as the numbers you link to indicate).
I suspect the reason for this is because when Rick Sternbach and Michael Okuda were coming up with these figures, they probably consulted real-life figures and theory and extrapolated, while the author of Star Wars Episode II Incredible Cross-Sections probably just made up stuff that sounded good.
That's not a knock against Star Wars, it reflects a different focus. Star Wars was never about the tech.
That might be true if Amazon didn't have multiple AZs in single datacenters.
The fault isn't necessarily Amazon's for stuff like this. The whole point of cloud infrastructure is that you use many cheaper instances to scale load and provide high availability caused by the failure of any one (or group of) node. Take Netflix, for example. While they do have their share of outages, they were completely unaffected by Amazon's big EC2 failure a few months ago, despite the fact that a significant portion of Netflix' infrastructure was hosted out of the affected region. Why? Because they built failure into their system, to the extent where they have a process that goes around killing random instances to keep them on their toes. They've planned for and built their system around the possibility that large chunks of the system might just up and vanish without warning.
If you're building a large-scale cloud system, *geographic* diversity should obviously be a part of any high availability plan. I'd also say that having provider diversity isn't a bad idea, but it seems like a lot of big cloud customers just stick with one provider.
Well - that's what maintaining an XBMC box is for :) Till Google does that...
http://www.google.com/tv/
Of course, it turned out to be a horrible failure, but that's beside the point.
It's hard to list one thing when it's the whole package of hundreds of tiny things that make up a modern web mail interface. Plus lots of tiny little things that you hardly notice until they're not there.
I use SquirrelMail maybe 6-7 years ago, and it was a painful experience compared to even other web interfaces at the time. I've use it recently too, and as far as I can tell, it hasn't really improved, while every other web mail UI has dramatically evolved.
Modern webmail clients are on par with the features and usability of offline clients, squirrelmail isn't.
I think you're reversing the two. 802.11a is strictly 5GHz, while 802.11n is either 2.4 GHz or 5GHz.
Most 802.11n hardware that has 5GHz support should also do 802.11a, but it's not a hard rule.
That's a specific bug with certain consumer-grade OCZ drives. I have had the exact same problem happen to me with regular HDDs due to a bug in the filesystem driver. Admittedly, it was a different cause, but the same effect. As far as I know, Intel has never suffered from that issue with their drives, nor have any other enterprise-grade drives.
Intel has had a few issues with their drives, but they've thankfully been all of the immediate-failure type that works best with RAID.
Lots of first person shooters are written in C#/.NET. Any FPS for Windows Phone 7, since WP7 requires third party apps be written with XNA or Silverlight. Any FPS XBox Live Indie Games are too. There's no particular reason you can't make an FPS with .NET. Are you going to make the next Crysis? No, but the performance is good enough that it won't be the platform holding you back from producing fun and engaging content, it'll be your abilities. But really, why design an FPS-oriented 3D engine from the ground up for .NET/XNA when there are many existing engines out there that are cheap or free? Unreal Engine, for example. The UDK is free.
If you absolutely need it, you can also call native code in a .NET app, although you lose most of the portability (or the ability to run on the 360 or WP7). Is this cheating? Well, is it cheating to write performance critical sections of a c++ app in assembly?
$10,000 per terabyte. Ok, then. Sure, it's faster, if you are willing and able to pay 10x the cost of *current* HDD-based systems...
I guess you missed the part where they said that the Nimbus pricing of $10,000 was "on par" with the HDD-based storage arrays they had from NetApp and HP before? Fibre-channel HDD pricing is in the same ballparks as enterprise SSDs.
The thing is, the cost-per-gig will eventually not matter, because the cost-for-enough-gigs will be sufficiently low. The point will come where people can get an SSD that's "big enough" at a price that's low enough. It won't matter that you'll be able to buy a 5TB drive for the price of your 1TB SSD, because the 1TB SSD will be big enough for the average person.
Even for home use, I figure nearly everybody scoffing at SSDs, thinking they're not needed, has never *USED* an SSD for their day-to-day computing. It's the kind of thing where you think "Nobody needs that", and then you try it, and it turns out the be the single biggest performance upgrade you can make to your computer. And then you get used to it, and think "It's not that big a deal, HDDs weren't so bad", and then if somebody takes away your SSD, your computer feels like molasses.
A while ago, I built a new computer for a friend of mine. Got a great deal on a consumer SSD for him too. Later, he got a new laptop, and was complaining to me about how slow it was. After some prodding about what was slow about it, I realized that it wasn't the CPU, or the GPU, it was that he was now used to his desktop's SSD and going back to a notebook HDD was too big of a performance hit for him.
I'd rather a drive fail suddenly without warning if the alternative is "slowly and silently corrupting data until somebody notices it because it tripped a SMART threshold". Because I've had that happen, and all sorts of other nasty gradual failures.
Any enterprise setup is going to have redundancy built-in. If a drive up and fails suddenly and without warning, you swap it out, boom, done. If you've got hot or cold standby drives already in the array, icing on the cake. But if a drive starts a slow march towards failure, it can be a while before you or monitoring tools notice the issue, and even once you do, there's that temptation to say "Oh, it's still working well enough, we don't need to replace it quite yet."
For SLC, which is what you'd find in enterprise, the number of erase operations (which is what has a lifespan, not writes) is a non-concern.
And a 3.5" 15K SAS drive will do 120MB/s to 200 MB/s with an average of 170 MB/s, which is only very slightly slower than an SSD on a 3Gbps SAS or SATA2 connection will do. A very large 7200RPM drive comes pretty close too. Sequential read and write speeds is not a major factor in SSD performance advantages. That's not even a typical use case. It's when IOPS get involved that SSDs completely destroy HDDs.
1989? So you haven't tried a version of Windows since Windows 2?
I'm not sure System 6 would compare all that well to Windows 7, just like Windows 2 wouldn't compare all that well to OS X. I remember the days of System 6 and 7. Compared to what was available at the time, they were leaps and bounds ahead of the competition, (Windows was a joke at the time) but compared to anything modern, they were horrible. System 6 didn't support multitasking without multifinder (which was a hack), and both of them were terribly unstable (no protected memory and co-operative multitasking).
Yes, WinXP has dropped below 50% of the total market. But according to TFA, WinXP still has a 57% share of Windows installations.
I saw it last year at Fantasia. It was cheesetastic, but it had the audience hooting, hollering, and cheering along. It's the kind of B-movie where if you embrace the cheese and insanity, you have a great time. The director was at the screening to talk a bit, it was a blast.
So, breaking copyright law isn't breaking the law? A tort and a crime are both breaking the law.