If withholding sex is something that only punishes one member of a couple, then at least one of you is doing it wrong...

Amazon launched their app store long before they launched the Kindle Fire. It's not tightly integrated with the Kindle line, and you can download it as an apk. There's nothing stopping other manufacturers from building their own custom Android version and shipping the Amazon store by default. There's also F-Droid, which maintains a large repository of open source Android apps, and also makes available the infrastructure that they use to build it, so creating a vendor-specific app store with a moderate set of applications as a bootstrap would be quite easy.

I was quite impressed with the Kindle Fire. My stepfather got one for Christmas, and is now using it as his primary computer. It was very easy to set up and use. I did find the pervasive adverts somewhat annoying, but from a UI perspective Amazon has done a pretty good job at implementing something that is easy for non-technical users to set up and run. The walled garden aspect is quite troubling though, and more so given that it's quite an appealing garden: no one would care about walled gardens if they didn't contain things people wanted.

I had a look, and all of the proprietary Android apps that I'm currently running are available on the Amazon store, which you can download as an apk. I'd love to have a phone with the Amazon store and F-Droid installed by default, but without any of the Google things. If the device manufacturer would guarantee OTA security updates for 4-5 years, I'd buy one today.

The bold part looks like something that is almost certainly illegal, as it indicates that Google is controlling a cartel. If they put that in a public license agreement, then they need to fire their entire corporate legal team.

The big advantage that the tablet has over an eInk device of the same size is that you can scroll quickly. I found having an eBook reader that could only display half of an A4 page quite annoying, but on a tablet it's far less of a problem because you can slide the page up as you read it.

JavaScript is quite different in its use from most languages that live in VMs. Java or .NET applications, for example, tend to be quite long-lived and often CPU dependent, so spending a couple of seconds at the start optimising them can be a big win. The VM will then build some profiling data and recompile things based on that, and may do some other tricks.

With JavaScript, in most cases, the thing that users care the most about is load time. It's often better to use a simple AST interpreter for JavaScript than a clever compiler, because you can start executing the interpreter as soon as you've got the text. If you spend more than a few ms getting the JS ready to run, users notice even if the resulting code is faster.

The 'often' is the important bit here, because some pages use JavaScript extensively for animations, games, and so on. In this case, users will notice if it's slow. They'll also notice if it's eating all of the CPU on their mobile device and flattening the battery. It's better in this case to switch to an optimised compiled representation as soon as possible, because you can get away with running the game slowly for a few second (while it's typically loading assets and displaying splash screens anyway), but after that people notice.

In both cases, after a while you've got some useful profiling data and so you want to recompile and generate more optimised code (unless it's just doing menu animations and the JavaScript is using 1% of your CPU, in which case the compiler is likely to consume more CPU time than the compiled code will save). Ideally, you want to do this in the background, on another core (or, at least, on a lower-priority thread on the same core), because otherwise you're interrupting the thing that the user cares about to run the compiler.

Especially if they've set the thread priorities correctly. The compilation thread should have a lower priority than the interpreter thread, so it will run in the gaps where the interpreter is waiting for input (and a little bit anyway). The interpreted code will be slower than compiled, and may remain interpreted[1] for longer, but the compiler won't be preempting the real work, as happens when they do it synchronously.

[1] 'Interpreted' in V8 really means compiled with no optimisations.

I tried Google Maps a bit, and then switched to OSMAnd. It was about the only Google app I used, although I don't know if the Android Browser is developed anymore now that Google has shifted all of their focus to Chrome. I would love to be able to get a reasonable Android phone with F-Droid installed as the default market and no Google stuff.

Apple has 7.68% of the desktop market and 15.42% of the mobile market. They can pull a lot of stuff without getting into trouble because they don't have anything like the market share required to exert undue influence on the market. When they have larger shares, for example in the online music distribution market a few years ago, they do get investigated.

Your comment makes as much sense as complaining that your corner shop doesn't get into trouble for doing things that would be the target of antitrust investigations if Walmart did them. Apple is a highly profitable niche player, but still a niche player. They can't use their dominant position in one market to gain prominence in another because they don't have a dominant position in any market and haven't since the iPod.

Intel does the former quite successfully, but it does cause problems internally. Promotions and so on are often linked to project success, yet projects can be cancelled simply because Intel had 5 guesses about what the market would want a few years down the line and your group was given one of the ones that didn't turn out to be accurate to work on. This leads to resentment and competent engineers realising that they have more prospects for advancement if they go and work for competitors. It's hard to get right: you often do want multiple teams working on different solutions to the same problem, because it gives you a fallback, but no one wants to be working on the one that gets cancelled (this is increasingly a problem at Google too).

Actually, it is. Google is charging between $0.5 and $2 for manufacturers to bundle their apps, depending on what they bundle, and also restricting what else they're allowed to ship. They're trying very hard to do to the mobile phone market what Microsoft did to the PC market: make the hardware a cheap, interchangeable, commodity and their software the bit that customers are willing to pay for. Oh, and on the subject of Microsoft, don't forget that they're charging around $15/device for the patents of theirs that probably (i.e. might, but it would cost too much to have a court find out) infringes. Even if you don't do any customisation, Android is likely to end up costing the manufacturer around $20/device.

From what I've heard from ex-Nokia people, it wasn't just senior management that lacked direction. They had internal teams all developing complete stacks in isolation and competing for resources. Elop wasn't completely wrong: making them all focus on a single platform was probably the only thing that could have saved Nokia, and Windows Phone wasn't a completely ludicrous choice, as they did want something to differentiate themselves from the competition and there weren't any other significant Windows Phone vendors to compete with.

Pushing ahead with Linux + Qt might have worked, but only if they'd fired about 90% of middle management and reorganised the teams. Even then, there would likely have been a lot of resentment from the various teams that had their work discarded in favour of another's. Remember that Nokia didn't have a Linux + Qt platform, they had several, all with mutually incompatible frameworks built atop Qt, none of which was compellingly better than the others.

It's a shame that the Qt on EKA2 project was killed. The EKA2 kernel was a much better fit for mobile devices than Linux (it still amazes me after all of Google's investment how few of its features Android has), and Qt would have given them the base of a modern development environment that would have competed well with other platforms.

Was Maemo ever Qt? I thought they changed the name when they switched it from GTK to Qt. And there you see the real problem with Nokia: a complete lack of direction. They had, in EKA2, a beautifully designed kernel for mobile applications, tied to a userland and userspace APIs that were designed when 1MB of RAM was an insane quantity reserved for the most expensive of phones. So, the first thing they did was try to shoehorn Linux into a phone. Then, having replaced the one good bit of their stack with Linux, they had a load of competing projects to provide a replacement UI, leading to a plethora of short-lived APIs, just as everyone else was realising that third-party developers are the key to a successful platform.

Not really. How many people do you think can deliver tons of salt and grit (in quantities of a factor of ten more than they normally sell you) at a few days notice, in unusually bad weather? And if you find someone, then you have to distribute it (something that's usually done in the summer, when the roads are clear and you can put it in strategic locations where the gritting trucks can easily collect it.