Pr0n! Anywhere! Anytime!

The J2ME security model did this. You would start a photo-manager midlet and you would have to authorize access in a nagging pop-up form for each single directory in the path to the photo you were going to see and then for the photo file itself. This was totally horrendous, and I prefer the security model in Android to that.

Moreover, it's difficult to make any automated system *understand* what a program is actually doing. If you just give permission to an app for connecting to a specific server for downloading the weather forecast, it could be using that same connection to funnel any data (for which it has access) away.

The more interesting approach to actually controlling access in a useful way is the way in which intents work in Android, actually. See Locale, for instance, for which you can get plugins downloaded as independent apps. The main program and the plugins communicate via a well-defined intent-based protocol. Each plugin will get different (and thus limited) permissions, as they need. The location plugin will access the GPS, a messaging one might need SMS or account access. You can enable/disable/install/uninstall them as needed, providing fine and sensible control.

To some extent, the same thing happens with the share menu, at a much more coarse level.

If you have rooted the device, you can intercept any communications through any of the operating system provided services, either by using the monitoring facilities it provides or by modifying it. You don't need to sniff the packets 'on air', and thus you can pick the traffic for bluetooth too.

If you are worried that sensitive data is transmitted over a network link... uhm... then the software should be encrypting the data.

I don't get what's your worry, anyway, other than people reverse-engineering Microsoft's protocols and creating alternative SmartGlass clients.

A 16 bit session id should be enough for everyone...

Most of the time Android activity screens just "stack" as they are being opened. An example with the GMail client would be InBox -> Display specific message -> Reply.

Usually, when you press the back button, you just cancel the top activity screen, popping it out of the stack. For instance, you could cancel replying to a message by pressing the back button, so that you get back to having the display specific message activity on top.

When backing/popping the last activity, the application is not needed anymore and usually its execution ends, taking you back to either the home screen or the "other" application that launched it (for instance, by choosing to share a photo via GMail from the Gallery application, you got a Gallery stack starting a nested GMail stack). This is different from pressing the home button, that just puts the activity stack aside (it's still open in the background while memory allows), so that you can "start another stack", and then switching back to the previous stack afterwards by holding home and then selecting the previous stack from the list of "currently active" stacks.

See this blog post to understand why the notification icon is needed:

Services can further negotiate this behavior by requesting they be considered "foreground." This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running. This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar. Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.

So if you want it to keep running as a background service to be able to receive incoming calls, this is the standard procedure. And I seriously think Android notifications are one of the best thought parts of the system.

Another thing is the inability to leave the application screen by pressing the back button (you can use the home button though, but that's so un-androidy...) You can force the application to quit completely via a menu option in one of the screens.

Android applications are left running in the background by the operating system until the memory they use is needed, and the application process is killed in order to reclaim it. For services running in the background (as required for receiving incoming calls), displaying a notification icon will flag the process as "less killable".

See this blog entry:

Services can further negotiate this behavior by requesting they be considered "foreground." This places the service in a "please don't kill" state, but requires that it include a notification to the user about it actively running. This is useful for services such as background music playback or car navigation, which the user is actively aware of; when you're playing music and using the browser, you can always see the music-playing glyph in the status bar. Android won't try to kill these services, but as a trade-off, ensures the user knows about them and is able to explicitly stop them when desired.

There's a menu option to totally kill the program in one of the screens. But the thing about not being able of exiting the Skype screen to the Home screen by using the back button (you can use the Home button) is another, very different thing. It's so un-androidy... :-(

You've betrayed yourself as yet another Apple Fanboy :-) I don't EXPECT anything from Apple. Even in the case I actually expected anything from them, then they would have failed to meet those expectatives.

I was just pointing at the fact that Apple competitors do already sell devices with both better hardware and better software than the ones the iPhone 4 has. Yes, the screen has more resolution than any other device, but its size is still 3.5", and I honestly think so many pixels in that size are way overkill to be of any use.

Regarding the gyroscopes, yes, I knew about them. More orientation sensors, then too.

What I mean is they have no more a significantly better product in the smartphone space. They definitely aren't in a position to keep making new enemies, even if what they're doing is squeezing the cow dry for their shareholders.

Not a way, but the way when you're forced to play by Apple's rules. I mean, they amended the developer agreement to a point that would exclude any real competitors to their own newcomer ad service. Of course using an ad-based model or not is the software developer's choice. Users just can vote with their feet.

In the case of iPhone app developers, voting with their feet about iAd just requires them abandoning the whole Apple platform. Sooner or later, Apple will find that they can't get away with anything. I know most users who buy an iThing don't give a hoot about these issues... yet. But Apple are really walking by the line, testing the antitrust limits, patent-battling everyone else at the mobile space, alienating their developer base, and (as of today here in Spain) alienating their users by their exclusive deals with specific carriers.

I think that what goes around does indeed come around. It's to be seen how long can they keep their market share by being fashionable only. iPhone 4 came with no new ideas and only more of the same (more pixels, more cameras, more hype, more limitations by contract). Don't know about the iPad, but they should be worried in the mobile phone space.

He already made an investment in learning the iPhone SDK, an iPhone developer subscription ($99 a year), and at least one Mac computer.

It's easier to rationalize out the Android ecosystem without actually providing any specific reasons than to reckon that perhaps you invested so much time and resources into what happened to be a bad choice.

The actual problem comes to the input data to these models. As TFA says, they measured the correlation value that would predict the observed market prices of CDS's.

This is kind of common in the financial business; you assume that "the market" is already taking into account all facts when deciding those prices, so that you can calibrate a single parameter (the correlation in this case) that will make up for all that assumed knowledge. If your model doesn't explain all data, you simply add more parameters.

I see two problems with this.

The first one is that many times "the market" actually doesn't know about the future, making your calibrated parameters reflect a collective subjective opinion instead of a tangible reality.

The second one is that, as markets mature, many players end up using the same models. This not only leads to a single failure mode for the whole market, but may end up producing a free-floating (unstable) fed back system if no tangible (real world) inputs are at hand; you price things with model M given parameters that were deduced from prices via the same model M. When everyone is doing the same without looking at their surrounding reality at all, there's no more of that "collective market knowledge" left, but a bunch of lemmings running towards the cliff edge.

At my work, we maintain several Windows clusters for financial derivatives valuation.

We can't really move all of them to Linux (no matter how much we would like to do it), because some of the calculations have been implemented using MS only technologies, like ActiveX (yes, you read that well) and .NET (the last time we checked it the Mono runtime was ~5-6 times slower than MS implementation of .NET for our code).

When we needed to upgrade the Windows clusters recently, we had to move from 2-cpu-1-core to 2-cpu-4-core machines, since it was what was being sold. What we've observed is that Windows (Server 2003) is unable to fairly share the CPU time when there are more active threads than available cores. We get a lot of variance on the overall calculation time when the clusters are very loaded because of this.

The same tests done on SLES-9 (yes, 9) based Linux clusters with similar hardware did not suffer from this problem. CPU time was divided equally among all threads. And we are using a 4-year old kernel, that doesn't even sport the newest completely-fair-scheduler.