That was my point; the lack of permission to play stuff from the iTunes library doesn't matter, because anything you probably want to play couldn't go through there anyhow.
I believe it was added for the iPad, since it wouldn't be a very useful word processor if you didn't have some way of getting files onto and off of the device. The same thing was added to the iPhone.
This Apple document has some pictures of the process:
The iPad has a pretty capable processor. It can probably handle pretty much anything SD entirely in software, possibly even some 720p content with a very well written decoder.
Regardless, the hardware support doesn't care about the container format, so there's nothing stopping VLC from playing an MKV file with hardware acceleration (for video, at least), so long as the h.264 stream in the MKV container is compliant with the decoding restrictions. I imagine that it could then use overlays to display subtitles...
This would finally enable easy fansub playback on the iPhone.
iTunes allows you to copy arbitrary data to your iDevice for a specific application. I believe this is how some eBook readers get their content from PCs.
Besides, this doesn't really matter anyhow; the primary reason to use VLC is to play media that the existing iPod software won't play. If the iPod software won't play it, then iTunes won't let you upload it to the iDevice in the first place.
In other words, I couldn't put an MKV file in my media library even if Apple didn't have this restriction, for technical reasons.
Anyhow, the MediaPlayer framework lets you pass in raw data; there's no particular reason why VLC couldn't pass an h.264 video stream extracted from an MKV file to the MediaPlayer framework. The only issue would be playing content that doesn't adhere to the standards supported by the hardware.
VLC can *display* Flash videos, it can't *run* Flash videos. That's still handled by Adobe software, much in the same way that Media Player Classic (the original, anyhow) doesn't decode XviD videos; it extracts the video data from the file, passes it on to the codec, lets the codec decode it, and then displays the result.
Rogers/Fido doesn't offer TV or wired internet service in Quebec. Internet remains a duopoly between Bell and Videotron, TV has a third competitor (Star Choice/Shaw Direct), but it has a relatively small market share (less customers over the whole country than Videotron has in Quebec alone).
Only the telephony market sees a fair amount of competition, with a variety of options (POTS/VoIP/cell) and providers (Bell, Videotron, Rogers, all the VoIP carriers, Public Mobile, etc).
Internet access infrastructure largely remains a duopoly.
the CLEC comes in there undercutting the ILEC and the ILEC is forced to let the CLEC use the equipment below cost.
In Canada, the CLECs often undercut the ILEC (by running tighter ships and accepting slimmer margins), and the tariffs the ILEC charges the CLEC for use of equipment is far from below cost (indeed, for the new usage-based-billing aspect of the tariffs, it's most likely a markup of 5000-10000% of cost).
Google Voice was originally GrandCentral, which supported Canada. Google bought out GrandCentral, and removed support for Canada as part of their transition. They kept support for one area code in Alberta, however, for reasons no-one is quite sure.
You seem to be missing the point. It used to be possible to GET numbers where you live in Canada, as far as I know. Google removed the pre-existing support for this.
There is little work required to get Google Voice to work in Canada. It *DID* work in Canada before Google *removed* support. In fact, it does still work in one area code in Alberta.
And since Canada and the US use the same country code (1), and support was already there, it shouldn't be particularly difficult to support Canada...
The iPhone and iPod have had physical FM functionality (receive/transmit) for some time. Apple just chooses not to expose it in software on most of their devices.
RAM is modified a lot more often than data on the hard disk, and it has to be fast too. Let's assume that, in order to match current high-end RAM speeds (GDDR5 is over 20GB/s, so I'll just use 20 for simplicity), we keep the current number of channels in an Intel SSD (10) and bump up the per-chip flash speed to reach that 20GB/s, which gives us 2GB/s (which is about a hundred times faster than what's on the market today)
To hit the 10,000 write limit of a MLC on a 2 gigabit flash/RAM chip (2gbit seems to be about the limit of current RAM chips) with theoretically perfect wear leveling would require just over 20 minutes. SLC would bump that up to 200 minutes, still not practical.
Flash for RAM isn't going to happen any time soon. The speed just isn't there, and the rewrite cycle count would probably need to be three or four orders of magnitude higher than the best we have today.
The fastest RAM available today operates at roughly a thousand times faster than flash (SSDs are only fast because they tend to have many channels (Intel uses 10) in order to improve performance), and RAM speeds continue to increase by moore's law. It's unlikely that flash will ever catch up, and the limitations of flash (wear) would make it completely unsuitable, even with large improvements in number of usable cycles.
What it could be useful for is as a shadow to RAM for fast hibernation support. Imagine a computer with 4GB of RAM and 4GB of flash (with a suitable degree of parallelism for speed purposes). If you do a decent job of keeping that flash relatively up to date with the contents of system RAM such that there is a relatively minor difference between system RAM and flash at any given time, hibernations could be done in under a second, and restoring from hibernation could be done at better than SSD speeds even if the computer is using a cheaper magnetic disk.
If you were smart about it, you could even resume execution almost immediately after you copied a bare minimum of data, and allow the user to interact with the system while the rest of memory is copied from flash to RAM, handling any uncopied data the user requests on the fly.
From what they've said, it appears to be language-independent. It's more to do about interpreting why you touched the screen in a certain place, so what language you're trying to type... it's just a different dictionary to match against.
From all information that has been posted so far, there isn't any learning going on, except for custom words. The demonstrations they've given in person don't seem to have involved any prep either. So it would seem that it would work fine for your use case.
As has been pointed out elsewhere, many of those costs (staff and support contracts) don't scale linearly with the amount of storage. Using larger disks increases hardware costs, but it does't increase staff/support/UPS/etc costs. I could easily scale up and say, instead of building your storage array with 146GB 15K SAS disks, you're building them with 600GB 15K SAS disks. Now your 1TB becomes 4TB, your $1.08 MM becomes $4.32 MM, but your staff/support/UPS/etc costs should be identical. Backups are more expensive, but they're just part of the equation. So that's an extra ~$3 MM.
If you're not spending it on the staff/support/UPS (since they don't change), and you're not spending it on the hardware/redundancy (since that's a small fraction of the cost), where are you spending it? Are your backups going to cost $3 MM more because you've got 4x the data? Tapes aren't THAT expensive.
How many IOPS do you need? With that kind of budget, you can sprinkle enterprise SSDs all over the place. One terabyte of storage with enterprise Intel SSDs (16x) goes for $8,384. You can have triple redundancy on the drive level and triple redundancy on the server/city level and still have spent a fraction of the $360k. You can do daily non-incremental tape backups, thinning out your backup frequency as they get older (keep daily backups for the first week, then weekly for the first month, then monthlies for the rest of the time, re-using carts as they are thinned out), and still barely scratch the surface of $360k (LTO tapes are cheap). You can keep tons of spare parts on-site. I mean, at some point, your degree of overbuild is so insane that it's excessive. Disks are cheap. Everything else about your data isn't cheap, but it's not exorbitant either.
To answer your first question (about IOPS), the theoretical performance of each 16-drive array would be about 192512 IOPS (8KB random writes). Times three per array, times three per server, and the total theoretical IOPS of the system that I described (assuming the rest of the hardware can deliver it) is 1.7 million IOPS.
Enterprise level SATA disks only cost 2x-3x as much as consumer disks. SAS goes beyond that. But to get to 600x that, even including all the related expenses (supporting staff and hardware) is quite a stretch.
Slashdot Mirror
That was my point; the lack of permission to play stuff from the iTunes library doesn't matter, because anything you probably want to play couldn't go through there anyhow.
It would seem so. I must have missed VLC merging in an opensource Flash solution.
Keep in mind that Broadcom wireless chipsets are used in a staggering number of linux-based embedded devices, such as the venerable WRT54G.
I believe it was added for the iPad, since it wouldn't be a very useful word processor if you didn't have some way of getting files onto and off of the device. The same thing was added to the iPhone.
This Apple document has some pictures of the process:
http://support.apple.com/kb/HT4088
For one thing, they have segregated app stores, so an iPad app won't show up for download on your iPod unless it's a hybrid app.
The iPad has a pretty capable processor. It can probably handle pretty much anything SD entirely in software, possibly even some 720p content with a very well written decoder.
Regardless, the hardware support doesn't care about the container format, so there's nothing stopping VLC from playing an MKV file with hardware acceleration (for video, at least), so long as the h.264 stream in the MKV container is compliant with the decoding restrictions. I imagine that it could then use overlays to display subtitles...
This would finally enable easy fansub playback on the iPhone.
iTunes allows you to copy arbitrary data to your iDevice for a specific application. I believe this is how some eBook readers get their content from PCs.
Besides, this doesn't really matter anyhow; the primary reason to use VLC is to play media that the existing iPod software won't play. If the iPod software won't play it, then iTunes won't let you upload it to the iDevice in the first place.
In other words, I couldn't put an MKV file in my media library even if Apple didn't have this restriction, for technical reasons.
Anyhow, the MediaPlayer framework lets you pass in raw data; there's no particular reason why VLC couldn't pass an h.264 video stream extracted from an MKV file to the MediaPlayer framework. The only issue would be playing content that doesn't adhere to the standards supported by the hardware.
VLC can *display* Flash videos, it can't *run* Flash videos. That's still handled by Adobe software, much in the same way that Media Player Classic (the original, anyhow) doesn't decode XviD videos; it extracts the video data from the file, passes it on to the codec, lets the codec decode it, and then displays the result.
Rogers/Fido doesn't offer TV or wired internet service in Quebec. Internet remains a duopoly between Bell and Videotron, TV has a third competitor (Star Choice/Shaw Direct), but it has a relatively small market share (less customers over the whole country than Videotron has in Quebec alone).
Only the telephony market sees a fair amount of competition, with a variety of options (POTS/VoIP/cell) and providers (Bell, Videotron, Rogers, all the VoIP carriers, Public Mobile, etc).
Internet access infrastructure largely remains a duopoly.
the CLEC comes in there undercutting the ILEC and the ILEC is forced to let the CLEC use the equipment below cost.
In Canada, the CLECs often undercut the ILEC (by running tighter ships and accepting slimmer margins), and the tariffs the ILEC charges the CLEC for use of equipment is far from below cost (indeed, for the new usage-based-billing aspect of the tariffs, it's most likely a markup of 5000-10000% of cost).
25/7 is VDSL2 (not VDSL), the rest of the "Fibe" speeds are all ADSL2+, and below 7Mbps are ADSL.
Google Voice went public in late June.
Google Voice was originally GrandCentral, which supported Canada. Google bought out GrandCentral, and removed support for Canada as part of their transition. They kept support for one area code in Alberta, however, for reasons no-one is quite sure.
You seem to be missing the point. It used to be possible to GET numbers where you live in Canada, as far as I know. Google removed the pre-existing support for this.
There is little work required to get Google Voice to work in Canada. It *DID* work in Canada before Google *removed* support. In fact, it does still work in one area code in Alberta.
And since Canada and the US use the same country code (1), and support was already there, it shouldn't be particularly difficult to support Canada...
The iPhone and iPod have had physical FM functionality (receive/transmit) for some time. Apple just chooses not to expose it in software on most of their devices.
You should do the math some time.
RAM is modified a lot more often than data on the hard disk, and it has to be fast too. Let's assume that, in order to match current high-end RAM speeds (GDDR5 is over 20GB/s, so I'll just use 20 for simplicity), we keep the current number of channels in an Intel SSD (10) and bump up the per-chip flash speed to reach that 20GB/s, which gives us 2GB/s (which is about a hundred times faster than what's on the market today)
To hit the 10,000 write limit of a MLC on a 2 gigabit flash/RAM chip (2gbit seems to be about the limit of current RAM chips) with theoretically perfect wear leveling would require just over 20 minutes. SLC would bump that up to 200 minutes, still not practical.
Flash for RAM isn't going to happen any time soon. The speed just isn't there, and the rewrite cycle count would probably need to be three or four orders of magnitude higher than the best we have today.
The fastest RAM available today operates at roughly a thousand times faster than flash (SSDs are only fast because they tend to have many channels (Intel uses 10) in order to improve performance), and RAM speeds continue to increase by moore's law. It's unlikely that flash will ever catch up, and the limitations of flash (wear) would make it completely unsuitable, even with large improvements in number of usable cycles.
What it could be useful for is as a shadow to RAM for fast hibernation support. Imagine a computer with 4GB of RAM and 4GB of flash (with a suitable degree of parallelism for speed purposes). If you do a decent job of keeping that flash relatively up to date with the contents of system RAM such that there is a relatively minor difference between system RAM and flash at any given time, hibernations could be done in under a second, and restoring from hibernation could be done at better than SSD speeds even if the computer is using a cheaper magnetic disk.
If you were smart about it, you could even resume execution almost immediately after you copied a bare minimum of data, and allow the user to interact with the system while the rest of memory is copied from flash to RAM, handling any uncopied data the user requests on the fly.
Writing code is not a common use case on a telephone.
Death by a thousand disruptions could be just as effective
What disruption? The service continued to work fine. It was only the status page that reported it was down, which doesn't actually impact the service.
From what they've said, it appears to be language-independent. It's more to do about interpreting why you touched the screen in a certain place, so what language you're trying to type... it's just a different dictionary to match against.
From all information that has been posted so far, there isn't any learning going on, except for custom words. The demonstrations they've given in person don't seem to have involved any prep either. So it would seem that it would work fine for your use case.
Why? You'd shortly have added all your shorthand and abbreviations to the custom dictionary, and then it'd be perfectly happy with informal use.
As has been pointed out elsewhere, many of those costs (staff and support contracts) don't scale linearly with the amount of storage. Using larger disks increases hardware costs, but it does't increase staff/support/UPS/etc costs. I could easily scale up and say, instead of building your storage array with 146GB 15K SAS disks, you're building them with 600GB 15K SAS disks. Now your 1TB becomes 4TB, your $1.08 MM becomes $4.32 MM, but your staff/support/UPS/etc costs should be identical. Backups are more expensive, but they're just part of the equation. So that's an extra ~$3 MM.
If you're not spending it on the staff/support/UPS (since they don't change), and you're not spending it on the hardware/redundancy (since that's a small fraction of the cost), where are you spending it? Are your backups going to cost $3 MM more because you've got 4x the data? Tapes aren't THAT expensive.
How many IOPS do you need? With that kind of budget, you can sprinkle enterprise SSDs all over the place. One terabyte of storage with enterprise Intel SSDs (16x) goes for $8,384. You can have triple redundancy on the drive level and triple redundancy on the server/city level and still have spent a fraction of the $360k. You can do daily non-incremental tape backups, thinning out your backup frequency as they get older (keep daily backups for the first week, then weekly for the first month, then monthlies for the rest of the time, re-using carts as they are thinned out), and still barely scratch the surface of $360k (LTO tapes are cheap). You can keep tons of spare parts on-site. I mean, at some point, your degree of overbuild is so insane that it's excessive. Disks are cheap. Everything else about your data isn't cheap, but it's not exorbitant either.
To answer your first question (about IOPS), the theoretical performance of each 16-drive array would be about 192512 IOPS (8KB random writes). Times three per array, times three per server, and the total theoretical IOPS of the system that I described (assuming the rest of the hardware can deliver it) is 1.7 million IOPS.
Enterprise level SATA disks only cost 2x-3x as much as consumer disks. SAS goes beyond that. But to get to 600x that, even including all the related expenses (supporting staff and hardware) is quite a stretch.