And from the same press release, the reason Apple aren't taking up the "offer" to distribute NBC's content is because they want the price to rise from $2 to $5!
Which planet are these people (NBC, not Apple) from ?
Company tries to do something new and doesn't deliver on time. The sky *is* falling, yes ? I mean, it looks like it's still up there, but that's an illusion, right ?
The games will come. I doubt they intended to say one thing and do another, even if it is EA...
And choice of carrier has *what* exactly to do with choice of billing method ?
Apple choose their carrier. Great. You expect them to then dictate to the carrier how that carrier ought to do business ?
Assuming...
- you're employed, I guess you chose to work wherever you do - so you have a contract with your employer.
- that you have a bedroom
Does your employer tell you what colour to paint your bedroom ? Or is that nothing to do with your employer (it being your life to live and choices to make), and therefore a complete non-sequiteur vis-a-vis your working life ?
Not sure why it's anything to do with *Apple* at all.
There are apparently some ancient (ie regarding POTS calls) laws about what has to be reported to the customer. AT&T is just obeying the law. If you think it's a stupid law (hint: for datacomms, it is), then sign up for e-billing and save a forest or two...
Who knows, in some other reality, AT&T might even pass on some savings to you if you do... No postage, no paper costs...
You've almost certainly not set the application file within the Terminal.app bundle to be executable once it's been transferred. Just like FTP, iphoneinterface always sets permissions to rw-r--r--
Companies are generally considered to be plural entities in "real" English [grin]. I suppose we put a higher value on a collection of humans compared to a collection of metal parts...
If you prefer, consider mentally replacing "Apple" with "the people who work at Apple"...
Apple find a vulnerability (before the worm is announced, according to TFA), and remove that vulnerability in their next security update.
I'm guessing there's a regular scheduled security update process in Apple. If you can't fix it in time for the next patch-release, isn't is *better* to temporarily disable it ? I really doubt it's a permanent removal of the feature - they're just being responsible.
I'm guessing the bit they're worried about is the indefinite storage of the GPS-location of every licence-plate ever seen by the system. I'm not really sure you can liken that to an officer saying "I think I saw that guy 3 months ago". Effectively, the police are keeping tabs on cars (and by extension, people driving those cars), in an automated and later-searchable manner.
If the idea is "innocent until guilty", then the innocent ought to be given the *rights* of an innocent man, not just have lip-service paid to it. One of those rights is not to be constantly under surveillance by police - in that respect it's very similar to having to produce "papers" at checkpoints, and having the checkpoint-cop record your movement for later use. The 4th amendment may be what they're thinking is being infringed - is it reasonable for the cops to be constantly checking your details, or should there be some level of expected result before they are allowed to do so ?
So, as I *stated* in the post, I was responding to the points raised by the poster. If you want to raise your own, go right ahead - pulling "all the bad things" out as a catch-all isn't a good argument though.
As for "... didn't even bother putting any UI components in to help you diagnose what the problem is", again I don't really see your point. It's UNIX. It has logs. Use them. If you want pretty UI-based logs, then open up the console application, and you can see all the logs in a nice pretty format. Personally I prefer grep.
Not to mention all the pretty UI-based help available using the 'help' key; or the drop-down 'help' menu available on all apps...
I'm not sure I understand your comment. I think you don't get the usual Mac workflow.
(a) The dock (which sort of doubles as a taskbar) is hideable. No screen real-estate need be sacrificed.
(b) The mouse-movement that the menu costs you is a lot easier than the mouse movement for menus attached to windows - that's the point of putting the menus at the top of the screen.
(c) If I'm using multiple applications on the same screen (and I'm not using a virtual-desktop, which to be fair I usually do), then I use Exposé to switch between them. It's bound to my 5th mouse button so it works anywhere and it's very quick.
(d) There are other ways the Mac tries to speed workflow, but to be fair, other systems have extras too, so I'll stick to what you identified...
You don't have to like the Mac way of doing things, but you ought to try it with a fair mind before criticising it...
I'm in the process of svn-downloading the source (which takes forever [grin]) but there's no mention anywhere of what this "--with-heavenly=/path/to/Heavenly1A543a.UserBundl e" option refers to, when compiling the toolchain... I can't see it on the Apple-DMG -download either (according to the files-list on the wiki).
... and the theory behind what I was doing is up at my blog. Or at least most of it is (all of it modulo time constraints. It'll all get there eventually).
Back in the day (almost 2 decades ago), I was using video rather than still images (which allowed me temporal information as well as spatial information) but I recently wrote a simple application to just use the spatial information to find me images "most-like" a source one. The original goal was to train the system and then try to leverage a semantic processor from the trained system. It worked reasonably well (sometimes astoundingly well) on the database I had (some 300,000 images downloaded from keyed-searches on google images).
As Hitachi said, the key is to develop a matching system within a higher numerical dimension. One of the missing pages on the blog (I'll get there!) is how to evaluate the usefulness of any given feature (=dimension) of a region of an image. With this, one can approximate a numerical value for the information being relayed to the recognition-system using that feature, and therefore establish its worth as a feature.
When you know what you're looking for (your feature set) *and* the value of each of those features to your recognition system targets {man,boat,grass,house,...} you can create reasonably useful discriminators and rule-systems based on those discriminators. Note that the discriminators and the rule-system can be given to the system as a-priori information, but most of them are created and destroyed automatically *by* the recognition system as it evolves. It sounds complex, but really it's a bunch of simple ideas applied one after the other.
Um, OS X apps don't use the/tmp directory in the way most unix machines do. It's manly there as a compatibility thing for BSD apps...
My Mac has been up for 21 days, used every day for a variety of things (none of them illegal, but hey...) and there is precisely one "file" in/tmp, the X11 socket under my user-id directory:
[mac:~] simon% ls -laR/tmp/ total 0 drwxrwxrwt 4 root wheel 136 Jul 14 03:24 . drwxr-xr-x 6 root wheel 204 Jun 22 17:40.. drwxrwxrwt 3 simon wheel 102 Jun 22 20:27.X11-unix drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 501/tmp//.X11-unix: total 0 drwxrwxrwt 3 simon wheel 102 Jun 22 20:27 . drwxrwxrwt 4 root wheel 136 Jul 14 03:24.. srwxrwxrwx 1 simon wheel 0 Jun 22 20:27 X0/tmp//501: total 0 drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 . drwxrwxrwt 4 root wheel 136 Jul 14 03:24.. [mac:~] simon% uptime 10:09 up 21 days, 16:48, 1 user, load averages: 0.20 0.08 0.02
[the extra slashes are there because/tmp is a link to/private/tmp, and you only get the contents when you append the/]... and I have darwinports installed, use X rather than Terminal, use X editors etc. I'm far more unix-like than your average Mac user...
Oh yeah, and "all" you have to do is brute-force the DMG encryption ? *ALL* !!!? The NIST seem to think it would take 149 thousand billion years to crack the key, *if* you used specialised hardware...
Re "Robin Hood and Friar Tuck" - that was the first I'd heard of it, but I have a similar tale, though in my case it could be more accurately described as "Robin Hood and the Sheriff of Nottingham":-)
The thing about pretty much all the discussion over 'security through obscurity' is that it compares a 'secure-because-obscure' to a 'secure-without-being-obscure' mechanism. I'm not saying that the use of a secure-through-obscure mechanism is a good thing, and if you read my post, you'll see that.
My point was that if I'm using a hard-encryption mechanism, then I can additionally do things that would render a "cracked" result difficult to determine. If you know what you're looking for (ie: the algorithm is open source), I can't do that. I wasn't trying to say "just use secure-through-obscure' methods, I was saying that they can have some value when also combined with hard encryption.
I also disagreed with FCC (at the end of the post). It was sort of amusing to watch the moderations (up to 5, down to 2, up to 5, down to 3, up to 5). I'm left wondering whether those that moderated me down actually read what I wrote (and thought I was wrong), or just read the title of my post, and gave a knee-jerk response...
Oh for [insert deity]'s sake, please don't tell them that... If they actually start thinking through every possible way someone could do harm on a plane, they'll shut down the airlines "for your safety and convenience"...
At the end of the day, the most dangerous thing is an intelligent mind with the goal of doing harm. There is little-to-no way to protect against that, but it's not a politically acceptable truth, so they just make life difficult for everyone and hope for the best [sigh]. The *only* reason for all this is to protect *themselves* from a "you didn't do anything" accusation after the fact.
If people would just accept that life == risk, we'd be a lot better off.
If I'm trying to break into some code, and I can read the source code to determine how the author protected it, I'll have an easier job (note: "easier", not "easy") because I can home in on the algorithm the author used. I know whether it's Blowfish, DES, AES, IDEA, or a simple XOR or substitution cipher. I know what pre-encrpytion steps were taken, and what post-encryption algorithms were used.
Let's say that in a moment of insanity, I decided to use a basic XOR encryption routine (create each byte in the encrypted stream by XOR-ing the corresponding source byte with every byte in the password save one, rotating that one as I iterate over the source). This is completely and utterly trivial to crack if you have the source code and *know* the routine I used. It's a repetitive cypher, so it's reasonably obvious unless the password is of significant (a sizeable fraction of the source's length) as well. Note the difference - it's easier with the source code.
Now that's a contrived example - no-one in their right minds would use an XOR cypher, but the same principle applies to harder encryption techniques. If you *know* what system was used to protect the source, you have an advantage over not knowing... Did they gzip the source before encrypting it ? Did they use ZIP, RAR, or 'compress' instead ? Did they XOR to hide the obvious compression header ? Is it inverted (last byte first) or was any other transformation done *before* the encryption stage to try and make it non-obvious that a successful crack had taken place ? These are all "knowns" if you have the source code...
So, yes, it is easier when you have the source code. Security through obscurity is rightly derided, but not because it has no value. It is derided because it leads to the use of insecure encryption methods (small keys, using XOR/whatever instead of proper hard encyption, etc) and the fact that once the obscurity is cleared up, there's no more security. The idea is that if you are sufficiently confident that your encryption is unbreakable, you *can* document how you did it in public. That doesn't mean you *should*.
The point though, and why I disagree with the regulators, is that if you're using hard encryption, it really doesn't matter whether it's *easier*, it's not *easy*. It is in fact still so damn hard, that we're talking "impossible in our lifetime(*)" - the relative comparison makes no sense. It's akin to measuring the height of Mount Everest at 6-month intervals - it's always pretty darn high, though you might find some variance due to snowfall.
So, yes, they're right. But by not considering the (tiny) impact of their conclusion, they have made the wrong ruling.
(*) Modulo the discovery of an easy way to crack the encryption technology, of course.
DMG's are encrypted with AES (at least I'm reasonably sure that's the case). The options on 'Disk Utility' when you select encryption are 'none', '128-bit', and '256-bit'. Given that they opted for an encrypted DMG in the first place, and that mounting this (and copying to flash) is not a common operation, I'd guess they went for the 256-bit key.
If so, that's going to take a while to break [grin]. On Leopard (and I'm guessing Apple engineers will be using Leopard:-) there's an indication of how good the chosen password is for a DMG as you create it. I'm guessing they chose a good one, because of that warning...
If Apple consider it important (ie: if there actually *is* a use for this, rather than just a false trail, or if they want to make people think that), all they need to do is update the values and/or system libraries in the next software update. They could even change the encryption *mechanism* to make it pretty-much un-brute-forceable if they wanted to. I doubt they need to do that though, just change it to a 31-character string with punctuation/digits etc.
Whereas this *is* news (hell, I'd submit it!), I think a lot of people criticising the iPhone at the moment still haven't made the leap from "this is a phone. It does X,Y,Z" to "this is a fully-fledged computer, masquerading as a phone" - with all that that implies.
Apple have said they intend to provide updates, changes, additions, etc. to the iPhone over time. They have a policy of supporting older computers with new OS releases, and I don't see why they wouldn't migrate this approach to their new market. It only *benefits* them if there are more used phones in circulation running OSX - even if it was a hand-me-down from the big-brother/sister who went and bought the new one...
If this truly is the "third leg" of Apple's business, someone will get yelled at internally, and the next update will fix it. End of story.
Slashdot Mirror
And from the same press release, the reason Apple aren't taking up the "offer" to distribute NBC's content is because they want the price to rise from $2 to $5!
Which planet are these people (NBC, not Apple) from ?
Simon
Company tries to do something new and doesn't deliver on time. The sky *is* falling, yes ? I mean, it looks like it's still up there, but that's an illusion, right ?
The games will come. I doubt they intended to say one thing and do another, even if it is EA...
Simon.
And choice of carrier has *what* exactly to do with choice of billing method ?
...
Apple choose their carrier. Great. You expect them to then dictate to the carrier how that carrier ought to do business ?
Assuming
- you're employed, I guess you chose to work wherever you do - so you have a contract with your employer.
- that you have a bedroom
Does your employer tell you what colour to paint your bedroom ? Or is that nothing to do with your employer (it being your life to live and choices to make), and therefore a complete non-sequiteur vis-a-vis your working life ?
Jeez.
Simon
Not sure why it's anything to do with *Apple* at all.
There are apparently some ancient (ie regarding POTS calls) laws about what has to be reported to the customer. AT&T is just obeying the law. If you think it's a stupid law (hint: for datacomms, it is), then sign up for e-billing and save a forest or two...
Who knows, in some other reality, AT&T might even pass on some savings to you if you do... No postage, no paper costs...
Simon
You've almost certainly not set the application file within the Terminal.app bundle to be executable once it's been transferred. Just like FTP, iphoneinterface always sets permissions to rw-r--r--
Simon
Companies are generally considered to be plural entities in "real" English [grin]. I suppose we put a higher value on a collection of humans compared to a collection of metal parts...
If you prefer, consider mentally replacing "Apple" with "the people who work at Apple"...
Simon
Apple find a vulnerability (before the worm is announced, according to TFA), and remove that vulnerability in their next security update.
I'm guessing there's a regular scheduled security update process in Apple. If you can't fix it in time for the next patch-release, isn't is *better* to temporarily disable it ? I really doubt it's a permanent removal of the feature - they're just being responsible.
Simon.
... because (s)he is indeed whiney, but certainly no mac-fanboy.
Simon
Dvorak is crying that the sky is falling; so, based on his track record, everything must be just peachy then.
Good.
Simon.
*real* masters of the dark arts use 'ed'.
Nothing else comes close. Or wants to.
Simon
I'm guessing the bit they're worried about is the indefinite storage of the GPS-location of every licence-plate ever seen by the system. I'm not really sure you can liken that to an officer saying "I think I saw that guy 3 months ago". Effectively, the police are keeping tabs on cars (and by extension, people driving those cars), in an automated and later-searchable manner.
If the idea is "innocent until guilty", then the innocent ought to be given the *rights* of an innocent man, not just have lip-service paid to it. One of those rights is not to be constantly under surveillance by police - in that respect it's very similar to having to produce "papers" at checkpoints, and having the checkpoint-cop record your movement for later use. The 4th amendment may be what they're thinking is being infringed - is it reasonable for the cops to be constantly checking your details, or should there be some level of expected result before they are allowed to do so ?
Simon.
So, as I *stated* in the post, I was responding to the points raised by the poster. If you want to raise your own, go right ahead - pulling "all the bad things" out as a catch-all isn't a good argument though.
As for "... didn't even bother putting any UI components in to help you diagnose what the problem is", again I don't really see your point. It's UNIX. It has logs. Use them. If you want pretty UI-based logs, then open up the console application, and you can see all the logs in a nice pretty format. Personally I prefer grep.
Not to mention all the pretty UI-based help available using the 'help' key; or the drop-down 'help' menu available on all apps...
Simon.
I'm not sure I understand your comment. I think you don't get the usual Mac workflow.
(a) The dock (which sort of doubles as a taskbar) is hideable. No screen real-estate need be sacrificed.
(b) The mouse-movement that the menu costs you is a lot easier than the mouse movement for menus attached to windows - that's the point of putting the menus at the top of the screen.
(c) If I'm using multiple applications on the same screen (and I'm not using a virtual-desktop, which to be fair I usually do), then I use Exposé to switch between them. It's bound to my 5th mouse button so it works anywhere and it's very quick.
(d) There are other ways the Mac tries to speed workflow, but to be fair, other systems have extras too, so I'll stick to what you identified...
You don't have to like the Mac way of doing things, but you ought to try it with a fair mind before criticising it...
Simon.
"It's an established fact that version 1 of anything Apple produce is pretty shoddy"
Of course, it's no such thing.
Simon. (Presenting as much argument for my case as the original poster did for his/hers)
You know, I did a
... to see if it was anywhere else. I guess I missed that it was -specs, not .specs.... [sigh]
find . -name '*.specs'
Cheers,
Simon
Got it. Thanks :-)
... will be an issue ...
Now all I have to do is figure out whether the fact I don't have the file 'arm-cc-specs' for:
cp Csu-71/arm-cc-specs ~/.arm-cc-specs
Simon
I'm in the process of svn-downloading the source (which takes forever [grin]) but there's no mention anywhere of what this "--with-heavenly=/path/to/Heavenly1A543a.UserBundl e" option refers to, when compiling the toolchain... I can't see it on the Apple-DMG -download either (according to the files-list on the wiki).
Anyone any idea ?
... and the theory behind what I was doing is up at my blog. Or at least most of it is (all of it modulo time constraints. It'll all get there eventually).
Back in the day (almost 2 decades ago), I was using video rather than still images (which allowed me temporal information as well as spatial information) but I recently wrote a simple application to just use the spatial information to find me images "most-like" a source one. The original goal was to train the system and then try to leverage a semantic processor from the trained system. It worked reasonably well (sometimes astoundingly well) on the database I had (some 300,000 images downloaded from keyed-searches on google images).
As Hitachi said, the key is to develop a matching system within a higher numerical dimension. One of the missing pages on the blog (I'll get there!) is how to evaluate the usefulness of any given feature (=dimension) of a region of an image. With this, one can approximate a numerical value for the information being relayed to the recognition-system using that feature, and therefore establish its worth as a feature.
When you know what you're looking for (your feature set) *and* the value of each of those features to your recognition system targets {man,boat,grass,house,...} you can create reasonably useful discriminators and rule-systems based on those discriminators. Note that the discriminators and the rule-system can be given to the system as a-priori information, but most of them are created and destroyed automatically *by* the recognition system as it evolves. It sounds complex, but really it's a bunch of simple ideas applied one after the other.
Simon.
Um, OS X apps don't use the /tmp directory in the way most unix machines do. It's manly there as a compatibility thing for BSD apps...
/tmp, the X11 socket under my user-id directory:
/tmp/ .. .X11-unix /tmp//.X11-unix: .. /tmp//501: ..
/tmp is a link to /private/tmp, and you only get the contents when you append the /] ... and I have darwinports installed, use X rather than Terminal, use X editors etc. I'm far more unix-like than your average Mac user...
My Mac has been up for 21 days, used every day for a variety of things (none of them illegal, but hey...) and there is precisely one "file" in
[mac:~] simon% ls -laR
total 0
drwxrwxrwt 4 root wheel 136 Jul 14 03:24 .
drwxr-xr-x 6 root wheel 204 Jun 22 17:40
drwxrwxrwt 3 simon wheel 102 Jun 22 20:27
drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 501
total 0
drwxrwxrwt 3 simon wheel 102 Jun 22 20:27 .
drwxrwxrwt 4 root wheel 136 Jul 14 03:24
srwxrwxrwx 1 simon wheel 0 Jun 22 20:27 X0
total 0
drwxr-xr-x 2 simon wheel 68 Jul 12 18:57 .
drwxrwxrwt 4 root wheel 136 Jul 14 03:24
[mac:~] simon% uptime
10:09 up 21 days, 16:48, 1 user, load averages: 0.20 0.08 0.02
[the extra slashes are there because
Oh yeah, and "all" you have to do is brute-force the DMG encryption ? *ALL* !!!? The NIST seem to think it would take 149 thousand billion years to crack the key, *if* you used specialised hardware...
Simon
Re "Robin Hood and Friar Tuck" - that was the first I'd heard of it, but I have a similar tale, though in my case it could be more accurately described as "Robin Hood and the Sheriff of Nottingham" :-)
Simon
The thing about pretty much all the discussion over 'security through obscurity' is that it compares a 'secure-because-obscure' to a 'secure-without-being-obscure' mechanism. I'm not saying that the use of a secure-through-obscure mechanism is a good thing, and if you read my post, you'll see that.
My point was that if I'm using a hard-encryption mechanism, then I can additionally do things that would render a "cracked" result difficult to determine. If you know what you're looking for (ie: the algorithm is open source), I can't do that. I wasn't trying to say "just use secure-through-obscure' methods, I was saying that they can have some value when also combined with hard encryption.
I also disagreed with FCC (at the end of the post). It was sort of amusing to watch the moderations (up to 5, down to 2, up to 5, down to 3, up to 5). I'm left wondering whether those that moderated me down actually read what I wrote (and thought I was wrong), or just read the title of my post, and gave a knee-jerk response...
Simon
Oh for [insert deity]'s sake, please don't tell them that... If they actually start thinking through every possible way someone could do harm on a plane, they'll shut down the airlines "for your safety and convenience"...
At the end of the day, the most dangerous thing is an intelligent mind with the goal of doing harm. There is little-to-no way to protect against that, but it's not a politically acceptable truth, so they just make life difficult for everyone and hope for the best [sigh]. The *only* reason for all this is to protect *themselves* from a "you didn't do anything" accusation after the fact.
If people would just accept that life == risk, we'd be a lot better off.
Simon.
If I'm trying to break into some code, and I can read the source code to determine how the author protected it, I'll have an easier job (note: "easier", not "easy") because I can home in on the algorithm the author used. I know whether it's Blowfish, DES, AES, IDEA, or a simple XOR or substitution cipher. I know what pre-encrpytion steps were taken, and what post-encryption algorithms were used.
Let's say that in a moment of insanity, I decided to use a basic XOR encryption routine (create each byte in the encrypted stream by XOR-ing the corresponding source byte with every byte in the password save one, rotating that one as I iterate over the source). This is completely and utterly trivial to crack if you have the source code and *know* the routine I used. It's a repetitive cypher, so it's reasonably obvious unless the password is of significant (a sizeable fraction of the source's length) as well. Note the difference - it's easier with the source code.
Now that's a contrived example - no-one in their right minds would use an XOR cypher, but the same principle applies to harder encryption techniques. If you *know* what system was used to protect the source, you have an advantage over not knowing... Did they gzip the source before encrypting it ? Did they use ZIP, RAR, or 'compress' instead ? Did they XOR to hide the obvious compression header ? Is it inverted (last byte first) or was any other transformation done *before* the encryption stage to try and make it non-obvious that a successful crack had taken place ? These are all "knowns" if you have the source code...
So, yes, it is easier when you have the source code. Security through obscurity is rightly derided, but not because it has no value. It is derided because it leads to the use of insecure encryption methods (small keys, using XOR/whatever instead of proper hard encyption, etc) and the fact that once the obscurity is cleared up, there's no more security. The idea is that if you are sufficiently confident that your encryption is unbreakable, you *can* document how you did it in public. That doesn't mean you *should*.
The point though, and why I disagree with the regulators, is that if you're using hard encryption, it really doesn't matter whether it's *easier*, it's not *easy*. It is in fact still so damn hard, that we're talking "impossible in our lifetime(*)" - the relative comparison makes no sense. It's akin to measuring the height of Mount Everest at 6-month intervals - it's always pretty darn high, though you might find some variance due to snowfall.
So, yes, they're right. But by not considering the (tiny) impact of their conclusion, they have made the wrong ruling.
(*) Modulo the discovery of an easy way to crack the encryption technology, of course.
Simon.
DMG's are encrypted with AES (at least I'm reasonably sure that's the case). The options on 'Disk Utility' when you select encryption are 'none', '128-bit', and '256-bit'. Given that they opted for an encrypted DMG in the first place, and that mounting this (and copying to flash) is not a common operation, I'd guess they went for the 256-bit key.
:-) there's an indication of how good the chosen password is for a DMG as you create it. I'm guessing they chose a good one, because of that warning...
If so, that's going to take a while to break [grin]. On Leopard (and I'm guessing Apple engineers will be using Leopard
Simon
If Apple consider it important (ie: if there actually *is* a use for this, rather than just a false trail, or if they want to make people think that), all they need to do is update the values and/or system libraries in the next software update. They could even change the encryption *mechanism* to make it pretty-much un-brute-forceable if they wanted to. I doubt they need to do that though, just change it to a 31-character string with punctuation/digits etc.
Whereas this *is* news (hell, I'd submit it!), I think a lot of people criticising the iPhone at the moment still haven't made the leap from "this is a phone. It does X,Y,Z" to "this is a fully-fledged computer, masquerading as a phone" - with all that that implies.
Apple have said they intend to provide updates, changes, additions, etc. to the iPhone over time. They have a policy of supporting older computers with new OS releases, and I don't see why they wouldn't migrate this approach to their new market. It only *benefits* them if there are more used phones in circulation running OSX - even if it was a hand-me-down from the big-brother/sister who went and bought the new one...
If this truly is the "third leg" of Apple's business, someone will get yelled at internally, and the next update will fix it. End of story.
Simon.