At those costs, one terabyte of data stored for three years would cost roughly $1.1 million. I find it hard to believe that you could legitimately build a SAN that stored 1 TB for that amount of money and not have hit some sort of performance wall that made the expense superfluous. I mean, at some point, you're maxing out multiple 10GigE fibre channels from your SAN and thinking "How can I spend the rest of this money?"
That's not the point, the point is that you can buy a consumer grade hard disk for $0.05/GB.
A 1TB consumer-grade HDD costs $50. $1/GB per month would mean $12,000 per year to store that. His employer is spending $360,000 to store that same amount of information. This is clearly far beyond the "consumer pricing has no bearing on enterprise pricing" argument.
I don't think that more than one third of a million dollars can be justified to store one terabyte of data, no matter what the infrastructure involved. At that price, you can afford to colocate one hundred servers in one hundred different datacenters and replicate your data to all of them, including the staff to manage them all. $360k per year to store 1TB is insanity.
Unfortunately, these things are useless for most use cases. Anything use case that cares about size or weight will favour higher density batteries.
These things provide up to 67Wh/kg (the smaller cells provide 10.08Wh in 150g cells). Lithium ion batteries can provide up to 250Wh/kg (I'll admit I'm grabbing the upper limit of what's possible from Wikipedia).
An electric car that has 100kWh of capacity would require 1492kg of SCiB batteries, or as little as 400Kg of Li-ion batteries. That pretty much rules them out for electric cars, and those kind of recharge speeds in electric cars are useless anyhow since you can't get enough power to the battery to charge them anywhere close to that fast (charging a 100kWh battery to 90% in 5 minutes would require 1.08 megawatts of power).
The only thing that I can think of where these things might be useful are UPS. These already use lead acid batteries, which don't go over 40Wh/kg to begin with. I don't believe that lead acid batteries can be charged very quickly. Providing 500kW to a consumer UPS (on top of load) for charging is not unreasonable, and a consumer UPS providing 100Wh is also not unreasonable, so being able to charge that UPS in 12 minutes is probably a big step up over what we have now.
They certainly wouldn't use TCP for something so latency sensitive, and it seems logical that they'd have designed their system to tolerate packetloss.
In terms of QoS queues, they're already making peering arrangements with major ISPs (BT seems first) in order to get preferential treatment.
I'm not sure why everybody thinks the latency EuroGamer is reporting is so high; it's not much different from LOCAL latency that EuroGamer reported for console games:
Hardware T&L "just works", but so does trying to play Crysis on a GMA950; if the game is assuming that certain components are performing to certain levels, and they don't, then the game isn't going to be playable.
I know that's an extreme example, but the point remains; games started assuming that you'd have the extra oomph available, and the Kyro II didn't.
Nor did the PowerVR Kyro II (which offered GeForce 2 GTS class performance at a much lower cost), and it was quite popular. Although it was also the lack of hardware T&L that eventually killed it, once the critical mass of games taking advantage of it was surpassed.
The Voodoo 5 5500, which also featured multiple identical GPUs, did make it to market. It had two, the 6000 had four.
While the 6000 didn't make it to market, there are examples of them in the wild. I remember a few years back, it was reported that somebody had gotten hold of one and sold it on eBay, and the buyer posted benchmarks so that people could see what might have been.
Well, alkalines don't last long in a digital camera because their capacity is far smaller on big loads. On small loads, they'll destroy any NiMH battery.
Is it not possible to shove a small voltage regulator and a li-ion battery into a AA-sized container such that it produces 1.5v of output voltage? Or would the heat produced be too great?
And yet here we are, 21 years later, and NiMH rechargeable cells are still the best available rechargeable technology for standardized form factors such as AA.
Canadians can't sign up, despite the fact that about a quarter of our population is within the 1000 mile range of the DC OnLive location. For example, Montreal is about 590 miles away, well under the 1000 mile limit.
I'm not sure. VP3 is pretty old. I don't know enough about it (I'm not an expert). I'm not sure if VP3 is particularly useful or relevant. As far as I can tell, the only reason you might actually want to use it is because it is theoretically patent-free, but there's no guarantee of that. It's a pretty horrible codec. Compare these samples, which I've placed in order of quality:
B-frames, adaptive quantization, adaptive arithmetic coding, adaptive strength block loop filter... These are all things that VP8 is missing, that will together cause rather large penalties in efficiency. In reality, VP8 performs a bit better than XVID, but not as well as VC1.
Apparently speaking the truth is trolling if it doesn't paint an open project in a good light. VP8 is not a terribly good codec, and it's likely to be patent encumbered. I hope that it's not, since it's a big improvement over VP3 (Theora), but if it does become patent encumbered, it loses its only real advantage.
I don't know, their successor, the SBLive, was pretty nice. It still did MIDI synthesis in hardware with the EMU10K1 chip, but it could stream the data out of system RAM rather than relying on onboard RAM. The advantage there was that suddenly you could have massive soundfonts that weren't restricted to the limited memory space of the AWE32/64. Polyphony also shot up.
And the big kicker was, hardware reverb, which made MIDI sound pretty awesome.
Almost certainly not, since many parts of it are very similar (or identical) to h.264 (and yet it still manages to come up significantly inferior by lacking some of the most important bits).
Opera Mini is not just a glorified JPEG viewer as many slashdotters keep repeating. That's simply false.
Unfortunately, Opera Mini's poor rendering, while a problem, isn't the biggest problem. The lack of working zooming support probably is.
As has been pointed out, Mini has two zoom modes; 100%, and all-the-way-out. Text is unreadable in all-the-way-out (and the page layout looks a bit odd, indicating that it isn't trying to render the page as standards dictate), and you can't fit enough content in the screen at 100%. The lack of in-between is a huge issue, for me anyway. I like to zoom out to what is probably somewhere a bit more than 50%, where I find a comfortable balance between amount of content and readability.
More damning? Zooming is disabled in landscape mode, which I suspect is how most people browse the web on the iPhone. This one seems to be a simple bug, as you can trick Mini into being in one zoom mode by doing your zooming in portrait mode and then rotating the phone.
Another major issue is the touch detection. While Safari does a pretty decent job figuring out what you want to click on (particularly useful clicking on page numbers on DSLReports), Opera Mini's attempts at this are much more crude. Most of the time, it just doesn't try to figure it out at all and attempts to click on a small object (and even sometimes large UI elements like the browsers' own buttons) result in no action being taken. Safari tries to fix this by saying "Well the user tapped, and the center of the tap was pretty close to this link, so I'm going to click it."
I used the J2ME version of Opera Mini extensively on my old featurephone, and loved it. It was an enormous improvement over the built-in WAP browser. However, it's just painful to use on the iPhone. I do see a lot of potential, as issues like zooming, click detection, strange feeling scrolling, and even rendering issues are certainly fixable. But Opera is going to have to commit to making these improvements, and some of them (such as how scrolling doesn't feel the same as other iPhone apps) is going to have to be platform-specific.
Funny you should say that, since Iron Man didn't have a script; they had an outline, and improvised most of it (or came up with it right before the scene): http://incontention.com/?p=18384
Jeff Bridges described it as a $200 million student film.
Not really. The iPhone version looks like it's pretty much a platform-customized version of Opera Mobile with client-side support removed; the interface of Opera Mini on the iPhone and Opera Mobile on other platforms looks nearly identical.
Consider also that Opera Mini is a Java app, which the iPhone does't support. It's more likely that they ported Opera Mobile to the iPhone. In order to meet the App Store requirements, they were likely forced to remove client-side support, and decided that the name "Opera Mini" was more appropriate; while the iPhone version looks to be more "Mobile" than "Mini", the "Mini" name does imply the server-only featureset that we get.
So, it seems like it really was done to meet the App Store requirements.
It does have limited support for chapters and subtitles, but not in a terribly useful manner. There are two methods of specifying chapters; QuickTime's and Nero's. I have no idea if either of them is standardized, or what players support them. Since encoder support for chapters is virtually non-existent, I'd answer "Does MP4 support chapters" as "No, not really".
As for subtitles, it supports ttxt (MPEG-4 part 17) and vobsubs (image-based subs, like DVDs). I'm not terribly familiar with timed text subs, but I do believe they're rather limited. Certainly, you'd lose the more advanced manipulations and custom fonts possible with other containers/sub engines.
In short, MP4 just isn't practical for use unless you don't need subs or chapters.
Realize that they made a big sacrifice to make it happen... In order to meet the App Store requirements, there is no local JavasScript execution. It's entirely server-side. While this is nice from a performance perspective (everything is downloaded/processed server-side and then sent over the slow cell network in one compressed chunk), it's severely limiting from a functionality perspective.
Opera Mobile could never make it through the app store with the current terms of service in place; the JS engine makes it ineligible.
Rendering both posts moot is the fact that the 12-core Opteron performs like a 6-core Xeon, meaning that licensing would be the same per-socket anyhow since you wouldn't be able to reduce the number of servers/processors any more than you already can.
Opera Mini on the iPhone will not have any local JavaScript support because it's forbidden by the App Store ToS. This is why Opera has to rely entirely on server-side JavaScript execution for the iPhone version.
Slashdot Mirror
At those costs, one terabyte of data stored for three years would cost roughly $1.1 million. I find it hard to believe that you could legitimately build a SAN that stored 1 TB for that amount of money and not have hit some sort of performance wall that made the expense superfluous. I mean, at some point, you're maxing out multiple 10GigE fibre channels from your SAN and thinking "How can I spend the rest of this money?"
That's not the point, the point is that you can buy a consumer grade hard disk for $0.05/GB.
A 1TB consumer-grade HDD costs $50. $1/GB per month would mean $12,000 per year to store that. His employer is spending $360,000 to store that same amount of information. This is clearly far beyond the "consumer pricing has no bearing on enterprise pricing" argument.
I don't think that more than one third of a million dollars can be justified to store one terabyte of data, no matter what the infrastructure involved. At that price, you can afford to colocate one hundred servers in one hundred different datacenters and replicate your data to all of them, including the staff to manage them all. $360k per year to store 1TB is insanity.
Unfortunately, these things are useless for most use cases. Anything use case that cares about size or weight will favour higher density batteries.
These things provide up to 67Wh/kg (the smaller cells provide 10.08Wh in 150g cells). Lithium ion batteries can provide up to 250Wh/kg (I'll admit I'm grabbing the upper limit of what's possible from Wikipedia).
An electric car that has 100kWh of capacity would require 1492kg of SCiB batteries, or as little as 400Kg of Li-ion batteries. That pretty much rules them out for electric cars, and those kind of recharge speeds in electric cars are useless anyhow since you can't get enough power to the battery to charge them anywhere close to that fast (charging a 100kWh battery to 90% in 5 minutes would require 1.08 megawatts of power).
The only thing that I can think of where these things might be useful are UPS. These already use lead acid batteries, which don't go over 40Wh/kg to begin with. I don't believe that lead acid batteries can be charged very quickly. Providing 500kW to a consumer UPS (on top of load) for charging is not unreasonable, and a consumer UPS providing 100Wh is also not unreasonable, so being able to charge that UPS in 12 minutes is probably a big step up over what we have now.
They certainly wouldn't use TCP for something so latency sensitive, and it seems logical that they'd have designed their system to tolerate packetloss.
In terms of QoS queues, they're already making peering arrangements with major ISPs (BT seems first) in order to get preferential treatment.
I'm not sure why everybody thinks the latency EuroGamer is reporting is so high; it's not much different from LOCAL latency that EuroGamer reported for console games:
http://www.eurogamer.net/articles/digitalfoundry-lag-factor-article
http://www.eurogamer.net/articles/digitalfoundry-vs-console-lag-round-two-article
If 150ms of latency is acceptable for an FPS on a console, how come it's not acceptable for an FPS on OnLive?
ntpd also corrects for clock drift if the kernel supports it.
Hardware T&L "just works", but so does trying to play Crysis on a GMA950; if the game is assuming that certain components are performing to certain levels, and they don't, then the game isn't going to be playable.
I know that's an extreme example, but the point remains; games started assuming that you'd have the extra oomph available, and the Kyro II didn't.
Nor did the PowerVR Kyro II (which offered GeForce 2 GTS class performance at a much lower cost), and it was quite popular. Although it was also the lack of hardware T&L that eventually killed it, once the critical mass of games taking advantage of it was surpassed.
The Voodoo 5 5500, which also featured multiple identical GPUs, did make it to market. It had two, the 6000 had four.
While the 6000 didn't make it to market, there are examples of them in the wild. I remember a few years back, it was reported that somebody had gotten hold of one and sold it on eBay, and the buyer posted benchmarks so that people could see what might have been.
Well, alkalines don't last long in a digital camera because their capacity is far smaller on big loads. On small loads, they'll destroy any NiMH battery.
Is it not possible to shove a small voltage regulator and a li-ion battery into a AA-sized container such that it produces 1.5v of output voltage? Or would the heat produced be too great?
And yet here we are, 21 years later, and NiMH rechargeable cells are still the best available rechargeable technology for standardized form factors such as AA.
Canadians can't sign up, despite the fact that about a quarter of our population is within the 1000 mile range of the DC OnLive location. For example, Montreal is about 590 miles away, well under the 1000 mile limit.
Extra ECC data and fancy controller trickery can't get around the fact that the write limit is a limit of the underlying flash, not the controller...
I'm not sure. VP3 is pretty old. I don't know enough about it (I'm not an expert). I'm not sure if VP3 is particularly useful or relevant. As far as I can tell, the only reason you might actually want to use it is because it is theoretically patent-free, but there's no guarantee of that. It's a pretty horrible codec. Compare these samples, which I've placed in order of quality:
Theora/VP3: http://doom10.org/compare/ptalabvorm.png
VP8: http://doom10.org/compare/vp8.png
MPEG-4 ASP/XviD: http://doom10.org/compare/xvid.png
H.264/x264: http://doom10.org/compare/x264.png
Unfortunately, Theora/VP3 can't even keep up with XviD. That people wanted browsers to adopt this for HTML5 instead of h.264 boggles my mind.
Ironically, shortly after being branded a troll for suggesting that VP8 was patent-encumbered, MPEG-LA has begun forming a patent-pool for VP8:
http://yro.slashdot.org/article.pl?sid=10/05/21/133249
B-frames, adaptive quantization, adaptive arithmetic coding, adaptive strength block loop filter... These are all things that VP8 is missing, that will together cause rather large penalties in efficiency. In reality, VP8 performs a bit better than XVID, but not as well as VC1.
Apparently speaking the truth is trolling if it doesn't paint an open project in a good light. VP8 is not a terribly good codec, and it's likely to be patent encumbered. I hope that it's not, since it's a big improvement over VP3 (Theora), but if it does become patent encumbered, it loses its only real advantage.
I don't know, their successor, the SBLive, was pretty nice. It still did MIDI synthesis in hardware with the EMU10K1 chip, but it could stream the data out of system RAM rather than relying on onboard RAM. The advantage there was that suddenly you could have massive soundfonts that weren't restricted to the limited memory space of the AWE32/64. Polyphony also shot up.
And the big kicker was, hardware reverb, which made MIDI sound pretty awesome.
But is it really patent free?
Almost certainly not, since many parts of it are very similar (or identical) to h.264 (and yet it still manages to come up significantly inferior by lacking some of the most important bits).
My iPhone 3GS supported tethering from day one, you insensitive clod. Virtually all carriers support iPhone tethering.
Opera Mini is not just a glorified JPEG viewer as many slashdotters keep repeating. That's simply false.
Unfortunately, Opera Mini's poor rendering, while a problem, isn't the biggest problem. The lack of working zooming support probably is.
As has been pointed out, Mini has two zoom modes; 100%, and all-the-way-out. Text is unreadable in all-the-way-out (and the page layout looks a bit odd, indicating that it isn't trying to render the page as standards dictate), and you can't fit enough content in the screen at 100%. The lack of in-between is a huge issue, for me anyway. I like to zoom out to what is probably somewhere a bit more than 50%, where I find a comfortable balance between amount of content and readability.
More damning? Zooming is disabled in landscape mode, which I suspect is how most people browse the web on the iPhone. This one seems to be a simple bug, as you can trick Mini into being in one zoom mode by doing your zooming in portrait mode and then rotating the phone.
Another major issue is the touch detection. While Safari does a pretty decent job figuring out what you want to click on (particularly useful clicking on page numbers on DSLReports), Opera Mini's attempts at this are much more crude. Most of the time, it just doesn't try to figure it out at all and attempts to click on a small object (and even sometimes large UI elements like the browsers' own buttons) result in no action being taken. Safari tries to fix this by saying "Well the user tapped, and the center of the tap was pretty close to this link, so I'm going to click it."
I used the J2ME version of Opera Mini extensively on my old featurephone, and loved it. It was an enormous improvement over the built-in WAP browser. However, it's just painful to use on the iPhone. I do see a lot of potential, as issues like zooming, click detection, strange feeling scrolling, and even rendering issues are certainly fixable. But Opera is going to have to commit to making these improvements, and some of them (such as how scrolling doesn't feel the same as other iPhone apps) is going to have to be platform-specific.
Funny you should say that, since Iron Man didn't have a script; they had an outline, and improvised most of it (or came up with it right before the scene): http://incontention.com/?p=18384
Jeff Bridges described it as a $200 million student film.
Not really. The iPhone version looks like it's pretty much a platform-customized version of Opera Mobile with client-side support removed; the interface of Opera Mini on the iPhone and Opera Mobile on other platforms looks nearly identical.
Consider also that Opera Mini is a Java app, which the iPhone does't support. It's more likely that they ported Opera Mobile to the iPhone. In order to meet the App Store requirements, they were likely forced to remove client-side support, and decided that the name "Opera Mini" was more appropriate; while the iPhone version looks to be more "Mobile" than "Mini", the "Mini" name does imply the server-only featureset that we get.
So, it seems like it really was done to meet the App Store requirements.
It does have limited support for chapters and subtitles, but not in a terribly useful manner. There are two methods of specifying chapters; QuickTime's and Nero's. I have no idea if either of them is standardized, or what players support them. Since encoder support for chapters is virtually non-existent, I'd answer "Does MP4 support chapters" as "No, not really".
As for subtitles, it supports ttxt (MPEG-4 part 17) and vobsubs (image-based subs, like DVDs). I'm not terribly familiar with timed text subs, but I do believe they're rather limited. Certainly, you'd lose the more advanced manipulations and custom fonts possible with other containers/sub engines.
In short, MP4 just isn't practical for use unless you don't need subs or chapters.
Realize that they made a big sacrifice to make it happen... In order to meet the App Store requirements, there is no local JavasScript execution. It's entirely server-side. While this is nice from a performance perspective (everything is downloaded/processed server-side and then sent over the slow cell network in one compressed chunk), it's severely limiting from a functionality perspective.
Opera Mobile could never make it through the app store with the current terms of service in place; the JS engine makes it ineligible.
Actually, it looks more like Transport Tycoon Deluxe.
Rendering both posts moot is the fact that the 12-core Opteron performs like a 6-core Xeon, meaning that licensing would be the same per-socket anyhow since you wouldn't be able to reduce the number of servers/processors any more than you already can.
Opera Mini on the iPhone will not have any local JavaScript support because it's forbidden by the App Store ToS. This is why Opera has to rely entirely on server-side JavaScript execution for the iPhone version.