You can develop for all of those platforms with the toolkit that is native to Jolla, Qt.

You'll still have issues with app stores though.

In South Africa, if you claim for a stolen phone, the insurance company will request the IMEI as part of their claim processing, and they will have the IMEI blacklisted on a database shared by all the local mobile operators.

Are you saying that it is impossible for anyone to use the information in your fb and gmail account to compromise your bank website account?

By the same token, I shouldn't be expected to use non-company resources (ADSL line for remote standby support, personal smartphone reading company mail) for business purposes.

Or we can come to a compromise, and all be adults.

But it got nowhere near the kind of marketing Lumia has had. Not even the N9 had anything close to what Lumia is getting (and it wasn't even sold in most first world countries), yet it made similar sales numbers.

/me raises hand ... I still can't settle on anything that would suit me better than my N900.

Or, if you lived in a different country, where Apple does not have rights to distribute it

Note that in most other countries (outside North America, and possibly the UK), there is *no* legal way to download TV shows. No TV shows on iTunes. No Netflix, no Hulu, no content available on Amazon.

You would think the production houses would have figured out that the same technology which allows a few people to distribute large content to millions of people around the world for very low costs would allow them to reach their customers directly, without many different 'distribution' companies, license agreements, thousands of lawyers (or the Apple 30% tax), and allow them to both serve the customers better, understand what the customers are prepared to pay for, all allowing them to make more money.

Why don't they just run private trackers and RSS feeds with subscriptions available per-season, in the $1 to $3 per show range?

Or rsnapshot

pageant(from PuTTY) works adequately. But, the combination of an ssh-agent and bash-completion is still difficult to achieve without actually having bash (e.g. from mingw32), and using plink (to run commands remotely once-off) and pscp are less convenient, and you lose out on all the programs that use ssh as a transport.

if the third party is your own Root CA, then it does make sense. For example, I can issue a new cert on the mail server (for whatever reason), without the users all needing to accept a self-signed cert and cultivate bad security habits.

Maybe you need to think about the 'Trusted 3rd party' a bit more, specifically comparing SSL/PKI with Kerberos. Without a trusted third party, how are you supposed to do the initial authentication you speak of? Do all your users actually check SSL certificate fingerprints every time you point them at a service using 'first party public keys' (SSL certificates are public/private, and the SSL client gets the public key during negotiation)?

And the old cert that someone stole is still valid, if they manage to redirect users to a system they control that has the old cert, your users will think it is the valid one, and the real one is the fake one, and you've just compromised all your users credentials.

I hope you don't store any personal data.

You know there's a difference between using self-signed certs, and an internal CA, right?

(of course, all root CA certs are self-signed, intermediary CA certs are not, but the distinction being, you usually don't use the self-signed cert itself for anything but signing other certs).

Using your own internal CA (which you can either do by getting a commercial CA cert signed by a commercial root CA cert, or by creating your own self-signed CA cert) to authenticate/certify your internal services is good. Using self-signed certs to secure your services usually does nothing to authenticate the service to the end user, if they aren't verifying the cert fingerprints via some other method.

Well, in actual fact, nothing prevents software from allowing the user more control of validation of certificates. For example, nothing is stopping software from storing the fingerprints, and notifying the user when the fingerprint has changed, even for certificates signed by a trusted CA. It would be useful to be able to assign a trust level to an individual CA certificate.

But, you understood that all, right? A self-signed cert has less about it that you can validate automatically than a commercially signed cert. Everything you can validate about the self-signed cert can be validated on a commercial cert.

(In our environment, where we are responsible for 200 servers with about 50 internal users, > 5000 users inside the company, plus customers, we use an internal self-signed CA cert for all internal services such as VPNs, most internal web admin interfaces, and commercial certs for customer-facing interfaces).

Nokia specifically made provision for this, there is 'open mode', you can flash kernels onto the device, they need some patches to disable the security framework if you want to boot Harmattan (and you may lose some functionality that is protected by Aegis), and while you have a non-Nokia kernel running, you will see a nasty warning when you boot the phone.

But, you can easily install (multi-boot) other distributions.

Really, how do you think mer / Nemo and Nitdroid (Android 4.0.3) run on the N9 ? Since Nokia did things right with the N9 (upstreaming as much as possible), the Nitdroid team has almost full functionality available (calls, 3G, USSD, bluetooth, wifi etc.), where on the N900 years of work by the same team and they didn't manage to get calls or 3G working (though I think mer on the N900 does).

Just make sure you have the same system running in QA, and your QA people can log a defect against the developer from dirtcheapistan.

In certain environments it is useful having a tool like this, just so you have a contractual means of penalising the outsourced development house.

But, if RH takes all of MSs market share in areas they compete in, RH will still have lower revenues/profit in that area than MS.

Because the customer is saving.

Revenue comparison is irrelevant here, revenue loss (including potential) by MS and market share are more relevant.

By their actions (adopting open source, when 5 years ago they were attacking it) shows they are worried enough to try and fight it now.

Uh, no, not virtually every carrier, just the two US CDMA carriers. But, they are virtually the entire CDMA smartphone market, and since they don't want phone portability, the rest of the CDMA operators don't get it either.

And, this will be the death of CDMA (where I refer to cdma2000 and cdmaOne as CDMA).