HTML5's local storage feature means that this app, if written correctly (which I suspect is the case), can be used offline without a data connection at all.
For example, see Neven Mrgan's GlyphBoard; this is a web app which you can add to your home screen and use offline. The iPhone's new online user manual is another example of a fully offline web app.
iPhone gives you the option of using Yahoo as the default search engine, too. If Apple makes a deal with Bing, it's likely that the option to use Google will still be there, but it won't be the default for new devices.
There's a "Get Album Artwork" option built-in to iTunes, and there are also 3rd party plugins that will update tags on your music from pretty much any music service.
The "Get Album Artwork" has never worked well for me, but that's probably because 95% of my library isn't available through the iTunes store.
ID3 is horribly broken in its current state: for starters, there are four (common) incompatible versions: 1.1, 2.2, 2.3, 2.4. On top of that, some programs (*cough* iTunes *cough*) can't even agree on the tagging spec (in iTunes' case, it produces ID3 v2.4 streams that are incompatible with other players, resulting in much anguish).
The idea of putting metadata into an MPEG stream, then altering it to remove MPEG sync bits speaks to the fact that MP3 was never intended to hold metadata; a better solution is really needed.
I'm a big fan of extensible formats like MKA, Ogg and MP4 (m4a), since these allow metadata to be stored much more effectively and in a properly interoperable fashion. Any of these three container formats really deserves to unseat MP3 as the format of choice, if only because the metadata situation is far better.
The app by itself is not illegal -- it uses publicly available information to "parse" a credit card number, and the algorithms which determine the validity of a set of 16 credit card digits are pretty well-known by now. What the app probably cannot tell you is whether the card actually belongs to someone.
The description also doesn't outwardly suggest that the app was "marketed to Romanian hackers". Basically, there's nothing in the app description or screenshots to suggest that the application, which uses only publicly available knowledge, violates any of the terms of Apple's app policy.
Or, they might have seen the grenade, searched his luggage, swabbed it for explosives and found it was harmless. Of course, this assumes that the luggage was checked baggage and not carry-on, because your friend would probably have noticed if they searched his carry-on bag at airport security.
Nokia demanded that Apple cross-license several of its patents in return for licensing the key GSM patents, something it has not asked other manufacturers to do. Nokia therefore singled out Apple for licensing terms despite promising the GSM Alliance that it would license these patents under fair and non-discriminatory terms; singling out Apple and trying to force a cross-licensing deal is not non-discriminatory.
I use MinTTY, which comes with Cygwin. It also supports Unicode, and I have a keyboard shortcut to launch MinTTY from any open Windows Explorer window, which makes a lot of command-line use easier.
I got the 3.1 upgrade for my first-gen iPod Touch, and I have to say it's faster and more responsive than the 1.1 firmware. For me, it was worth it for the apps: I have nearly 100 applications, all obtained for free, and their total utility easily beats out the $10 I spent on the upgrade.
While I don't necessarily buy the "subscription accounting" argument Apple uses to charge for the upgrade (it really should be free, like upgrades for their other iPods, or upgrades for Zunes), I really can't argue with the increased utility.
I will agree on iTunes, though; it is quite a bloated piece of software, which is why foobar2000 plays my music, and iTunes syncs the iPod.
Sync issues: First link: Hardware problem with the computer, has absolutely nothing to do with the iPhone Second link: iPhoto database corruption, only marginally related Third link: See comment for first link Fourth link: Not a reputable news source: this is only one instance Fifth link: That's certainly an issue, but it doesn't have to do with syncing specifically. This should belong in the second category.
I thus dispute that any of your links point to a widespread synch issue due to iTunes or iPhone, on any platform.
Random shutdowns/decreased battery life: I don't doubt that this happens, and your links back this up. I would be interested in seeing if the recent update (3.1.2) has fixed this.
Overheating/burning/asploding: Less than half of the first 10 results are actually about iPhone-on-fire incidents, so I'm not sure how useful your statistic really is. For the stories which are about actual fires, they make great sensational stories and so are likely to be highly linked to. The number of results does not therefore say anything about the actual incidence rate.
For the record, I own a first-generation iPod touch which has been upgraded from 1.1 all the way up to 3.1, and I have experienced none of the above-mentioned problems from the official firmware.
Wikipedia explains it fairly well, though it is still a bit technical. The Huffman coding details are not important to the main idea; what is important is the concept of using the Discrete Cosine Transform (DCT) and a subsequent quantization step to reduce the precision, and therefore size, of the high-frequency components.
At extreme compression levels, only a few of the patterns in this image will end up with non-zero coefficients: specifically, those which are low-frequency (in the top left corner). You'll notice that these also happen to resemble gradients, which is what I meant when I said that the 8x8 blocks devolve into simple gradients.
If we still assume rectangular layouts, this is still not too hard to do. We simply sum d(n)*(4^n)*(n!)/2 for each n from 1 to 300, where d(n) is the number of divisors of n.
Dividing by 2 eliminates the upside-down variant of each image, since we don't care about the orientation of the whole image (however, we do distinguish the horizontal and vertical orientations).
The result of the full summation, again according to Python, is 1.1432*10^796, which, comparing with the previous result of 1.14299*10^796, is really not too far off (the main reason is that removing just one piece causes the number of permutations to shrink by a large factor, e.g. 300! is 300 times bigger than 299!).
We are still, however, assuming a rectangular layout. If we allow arbitrary edge-connected layouts, the difficulty of the enumeration problem increases substantially (if we remove the edge-connected constraint then the number of layouts is effectively infinite).
I'm not sure what Cygwin does, exactly, but it manages to correctly spew out the first few sectors of my boot drive (including what looks like the MBR) when I do "dd if=/dev/sda", despite the fact that "ls/dev/" shows only fd, stdin, stdout and stderr.
So, with Cygwin installed, I can pwn myself with that command! Hurray!
JPEG chunks an image into 8x8 blocks. An overcompressed JPEG contains so little information per block that the blocks devolve into simple gradient patterns (try this yourself with a grayscale image: save it with a quality near "0" and you will see the individual blocks clearly). If you think about it a bit, this makes sense: the block is being approximated by a combination of a small number of cosine waves (in the limit, it's a single wave along each image dimension), so the result is a gradient, because most of the coefficients have been thrown out by compression.
In this sense, the puzzle pieces can be thought of as representing these simple block patterns. With a 15x20 rectangle of pieces, by JPEG standards, this is essentially an overcompressed 120x160 image. You'll note that if you take your overcompressed JPEG and scale it down to around 25% (30x40), then, provided the original image shows only a single subject, it should still be reasonably recognizable, because the human visual system patches together the pieces to produce a coherent image, even if it is highly distorted.
I'm not sure where you are getting 1200! from. It should be 300!*(4^300), because the piece rotation is independent of their ordering, and that works out to 1.27*10^795.
Assuming all pieces are used, and that none of the pieces are symmetric or identical (that is, all pieces are different, and each rotation is different), then the actual number of possible images comes out to:
9*(4^300)*(300!)
where 9 is for the number of possible rectangles (1x300 up to 15x20), 4^300 accounts for the rotations of each piece, and 300! accounts for their arrangement.
The result, according to Python, works out to around 1.143*10^796, which is large, but not infinite.
I've looked over this archive (before Slashdot posted it), and I found several articles which were very interesting to me.
Leeuwenhoek's description of the "little animals" he saw with his early microscope (1677) -- this one is quite long and many entries are repetitive, but it is a detailed account of Leeuwenhoek's regular experiments and observations with microscopic life forms.
Surviving in a room heated to 260 degrees Fahrenheit (1775) -- this paper strikes me as absolutely incredulous in its claims; I did not know that people could survive such heat (I have not yet found any modern information supporting or disproving this claim, so information about this from a modern science perspective would be nice!).
I have a large backlog of papers which I would like to read, but which I cannot right now due to time constraints. I certainly would like to read more of these if I had the time to do so.
Bravo to the Royal Society for making these publicly accessible and easily explored. I now have an urge to read some of the early Philosophical Transaction papers not highlighted in Trailblazing.
And all those devices will be different in some way: screen resolutions, communications (bluetooth/WiFi or not), storage, computing power (CPU), etc. etc. Sure, they'll sell tons of units, but will a developer be able to write an application that is expected to work on every released device, all at once, without any fuss? (hint: look at the Windows Mobile application situation: it's not so hot).
So Android might be able to move units, but if they keep fragmenting the devices like they are currently, I think they can expect developers to be rather irritated that they need to push out multiple versions of an app (one for each device or device class), or work very hard to make their app work on all those devices (probably harder than they need to work to overturn an Apple App Store rejection).
The situation on the iPhone is rather different in this regard. Every device running iPhone OS (iPod touch (3 generations), iPhone (3 generations)) released so far has the exact same screen resolution, general form factor and similar hardware (e.g. all have accelerometers and WiFi); the main differentiating factor is that newer devices have more storage, computing power and possibly additional sensors (cameras in the iPhones, compass in the iPhone 3GS, etc.). Fundamentally, however, these devices are not so different from an application programmer's standpoint; in this regard, iPhone development is easier.
Except that this scenario is next-to-impossible on stock iPhones, because of the aforementioned code-signing restrictions, sandboxed applications and other mechanisms which prevent this from being a general problem.
Jailbreaking your phone makes all these safety nets go away: the kernel is patched so that it will run anything and applications are permitted to roam free across all of the device. At that point, you are on your own as far as security goes. If you, as a user, willfully ignore the instructions saying "Use 'passwd' to change the default password!!", then the resulting compromise of your iPhone is *entirely* your fault, and Apple doesn't even have to do "damage control". A rooted Android phone would suffer the same problems.
Slashdot Mirror
At the very least, Flash prompts for permission before accessing them (well, usually).
HTML5's local storage feature means that this app, if written correctly (which I suspect is the case), can be used offline without a data connection at all.
For example, see Neven Mrgan's GlyphBoard; this is a web app which you can add to your home screen and use offline. The iPhone's new online user manual is another example of a fully offline web app.
iPhone gives you the option of using Yahoo as the default search engine, too. If Apple makes a deal with Bing, it's likely that the option to use Google will still be there, but it won't be the default for new devices.
There's a "Get Album Artwork" option built-in to iTunes, and there are also 3rd party plugins that will update tags on your music from pretty much any music service.
The "Get Album Artwork" has never worked well for me, but that's probably because 95% of my library isn't available through the iTunes store.
ID3 is horribly broken in its current state: for starters, there are four (common) incompatible versions: 1.1, 2.2, 2.3, 2.4. On top of that, some programs (*cough* iTunes *cough*) can't even agree on the tagging spec (in iTunes' case, it produces ID3 v2.4 streams that are incompatible with other players, resulting in much anguish).
The idea of putting metadata into an MPEG stream, then altering it to remove MPEG sync bits speaks to the fact that MP3 was never intended to hold metadata; a better solution is really needed.
I'm a big fan of extensible formats like MKA, Ogg and MP4 (m4a), since these allow metadata to be stored much more effectively and in a properly interoperable fashion. Any of these three container formats really deserves to unseat MP3 as the format of choice, if only because the metadata situation is far better.
...to be quickly crushed by downloadable music. Oh, the irony...
The app by itself is not illegal -- it uses publicly available information to "parse" a credit card number, and the algorithms which determine the validity of a set of 16 credit card digits are pretty well-known by now. What the app probably cannot tell you is whether the card actually belongs to someone.
The description also doesn't outwardly suggest that the app was "marketed to Romanian hackers". Basically, there's nothing in the app description or screenshots to suggest that the application, which uses only publicly available knowledge, violates any of the terms of Apple's app policy.
Or, they might have seen the grenade, searched his luggage, swabbed it for explosives and found it was harmless. Of course, this assumes that the luggage was checked baggage and not carry-on, because your friend would probably have noticed if they searched his carry-on bag at airport security.
I read this as "across the English channel", with "frogs" meaning "Frenchmen". The Atlantic isn't really a "channel".
Nokia demanded that Apple cross-license several of its patents in return for licensing the key GSM patents, something it has not asked other manufacturers to do. Nokia therefore singled out Apple for licensing terms despite promising the GSM Alliance that it would license these patents under fair and non-discriminatory terms; singling out Apple and trying to force a cross-licensing deal is not non-discriminatory.
I use MinTTY, which comes with Cygwin. It also supports Unicode, and I have a keyboard shortcut to launch MinTTY from any open Windows Explorer window, which makes a lot of command-line use easier.
The cygpath utility converts paths back and forth between Windows and POSIX formats.
$ cygpath -w /bin/ls
C:\cygwin\bin\ls
$ cygpath "C:\WINDOWS\System32"
/cygdrive/c/WINDOWS/System32
I got the 3.1 upgrade for my first-gen iPod Touch, and I have to say it's faster and more responsive than the 1.1 firmware. For me, it was worth it for the apps: I have nearly 100 applications, all obtained for free, and their total utility easily beats out the $10 I spent on the upgrade.
While I don't necessarily buy the "subscription accounting" argument Apple uses to charge for the upgrade (it really should be free, like upgrades for their other iPods, or upgrades for Zunes), I really can't argue with the increased utility.
I will agree on iTunes, though; it is quite a bloated piece of software, which is why foobar2000 plays my music, and iTunes syncs the iPod.
Sync issues:
First link: Hardware problem with the computer, has absolutely nothing to do with the iPhone
Second link: iPhoto database corruption, only marginally related
Third link: See comment for first link
Fourth link: Not a reputable news source: this is only one instance
Fifth link: That's certainly an issue, but it doesn't have to do with syncing specifically. This should belong in the second category.
I thus dispute that any of your links point to a widespread synch issue due to iTunes or iPhone, on any platform.
Random shutdowns/decreased battery life:
I don't doubt that this happens, and your links back this up. I would be interested in seeing if the recent update (3.1.2) has fixed this.
Overheating/burning/asploding:
Less than half of the first 10 results are actually about iPhone-on-fire incidents, so I'm not sure how useful your statistic really is. For the stories which are about actual fires, they make great sensational stories and so are likely to be highly linked to. The number of results does not therefore say anything about the actual incidence rate.
For the record, I own a first-generation iPod touch which has been upgraded from 1.1 all the way up to 3.1, and I have experienced none of the above-mentioned problems from the official firmware.
Have you tried the "apply to all files of this type" in the Get Info window? AFAIK this is how you re-associate a file extension to a new program.
As for Quicktime's formats, try Perian: it is a codec pack for QuickTime (a la Directshow) which integrates ffmpeg, MKV, and a few other formats.
Wikipedia explains it fairly well, though it is still a bit technical. The Huffman coding details are not important to the main idea; what is important is the concept of using the Discrete Cosine Transform (DCT) and a subsequent quantization step to reduce the precision, and therefore size, of the high-frequency components.
At extreme compression levels, only a few of the patterns in this image will end up with non-zero coefficients: specifically, those which are low-frequency (in the top left corner). You'll notice that these also happen to resemble gradients, which is what I meant when I said that the 8x8 blocks devolve into simple gradients.
If we still assume rectangular layouts, this is still not too hard to do. We simply sum d(n)*(4^n)*(n!)/2 for each n from 1 to 300, where d(n) is the number of divisors of n.
Dividing by 2 eliminates the upside-down variant of each image, since we don't care about the orientation of the whole image (however, we do distinguish the horizontal and vertical orientations).
The result of the full summation, again according to Python, is 1.1432*10^796, which, comparing with the previous result of 1.14299*10^796, is really not too far off (the main reason is that removing just one piece causes the number of permutations to shrink by a large factor, e.g. 300! is 300 times bigger than 299!).
We are still, however, assuming a rectangular layout. If we allow arbitrary edge-connected layouts, the difficulty of the enumeration problem increases substantially (if we remove the edge-connected constraint then the number of layouts is effectively infinite).
I'm not sure what Cygwin does, exactly, but it manages to correctly spew out the first few sectors of my boot drive (including what looks like the MBR) when I do "dd if=/dev/sda", despite the fact that "ls /dev/" shows only fd, stdin, stdout and stderr.
So, with Cygwin installed, I can pwn myself with that command! Hurray!
JPEG chunks an image into 8x8 blocks. An overcompressed JPEG contains so little information per block that the blocks devolve into simple gradient patterns (try this yourself with a grayscale image: save it with a quality near "0" and you will see the individual blocks clearly). If you think about it a bit, this makes sense: the block is being approximated by a combination of a small number of cosine waves (in the limit, it's a single wave along each image dimension), so the result is a gradient, because most of the coefficients have been thrown out by compression.
In this sense, the puzzle pieces can be thought of as representing these simple block patterns. With a 15x20 rectangle of pieces, by JPEG standards, this is essentially an overcompressed 120x160 image. You'll note that if you take your overcompressed JPEG and scale it down to around 25% (30x40), then, provided the original image shows only a single subject, it should still be reasonably recognizable, because the human visual system patches together the pieces to produce a coherent image, even if it is highly distorted.
I'm not sure where you are getting 1200! from. It should be 300!*(4^300), because the piece rotation is independent of their ordering, and that works out to 1.27*10^795.
Assuming all pieces are used, and that none of the pieces are symmetric or identical (that is, all pieces are different, and each rotation is different), then the actual number of possible images comes out to:
9*(4^300)*(300!)
where 9 is for the number of possible rectangles (1x300 up to 15x20), 4^300 accounts for the rotations of each piece, and 300! accounts for their arrangement.
The result, according to Python, works out to around 1.143*10^796, which is large, but not infinite.
You just tried to infect my computer with a virus, didn't you?
Note to self: don't go about executing Slashdot comments on a vulnerable Windows box.
I've looked over this archive (before Slashdot posted it), and I found several articles which were very interesting to me.
Leeuwenhoek's description of the "little animals" he saw with his early microscope (1677) -- this one is quite long and many entries are repetitive, but it is a detailed account of Leeuwenhoek's regular experiments and observations with microscopic life forms.
Surviving in a room heated to 260 degrees Fahrenheit (1775) -- this paper strikes me as absolutely incredulous in its claims; I did not know that people could survive such heat (I have not yet found any modern information supporting or disproving this claim, so information about this from a modern science perspective would be nice!).
I have a large backlog of papers which I would like to read, but which I cannot right now due to time constraints. I certainly would like to read more of these if I had the time to do so.
Bravo to the Royal Society for making these publicly accessible and easily explored. I now have an urge to read some of the early Philosophical Transaction papers not highlighted in Trailblazing.
And all those devices will be different in some way: screen resolutions, communications (bluetooth/WiFi or not), storage, computing power (CPU), etc. etc. Sure, they'll sell tons of units, but will a developer be able to write an application that is expected to work on every released device, all at once, without any fuss? (hint: look at the Windows Mobile application situation: it's not so hot).
So Android might be able to move units, but if they keep fragmenting the devices like they are currently, I think they can expect developers to be rather irritated that they need to push out multiple versions of an app (one for each device or device class), or work very hard to make their app work on all those devices (probably harder than they need to work to overturn an Apple App Store rejection).
The situation on the iPhone is rather different in this regard. Every device running iPhone OS (iPod touch (3 generations), iPhone (3 generations)) released so far has the exact same screen resolution, general form factor and similar hardware (e.g. all have accelerometers and WiFi); the main differentiating factor is that newer devices have more storage, computing power and possibly additional sensors (cameras in the iPhones, compass in the iPhone 3GS, etc.). Fundamentally, however, these devices are not so different from an application programmer's standpoint; in this regard, iPhone development is easier.
Except that this scenario is next-to-impossible on stock iPhones, because of the aforementioned code-signing restrictions, sandboxed applications and other mechanisms which prevent this from being a general problem.
Jailbreaking your phone makes all these safety nets go away: the kernel is patched so that it will run anything and applications are permitted to roam free across all of the device. At that point, you are on your own as far as security goes. If you, as a user, willfully ignore the instructions saying "Use 'passwd' to change the default password!!", then the resulting compromise of your iPhone is *entirely* your fault, and Apple doesn't even have to do "damage control". A rooted Android phone would suffer the same problems.