Medical and military sounds like mostly Windows shops, with maybe a bit of Linux thrown in. Qt apps on OS X tend to be garbage - you can spot them within a few seconds of launch, because they look vaguely like OS X but don't behave at all like it (e.g. modal dialog boxes, incorrect shortcut keys for text field navigation, preferences that need buttons hitting to take effect, and so on).

Only one of those is really true. You can implement a stack-based ISA in hardware, but there's a reason that most of the companies that tried it went out of business in the '80s: stack-based ISAs are really hard to get any ILP from and so once pipelining became common they started to be noticeably slower and were completely killed by superscalar register-based architectures.

Wow, that's a pretty old article. ARM9 was introduced in 1997 and pretty much dead for a good 5 or so years. The Jazelle extensions (no, they're not called 'Java extensions', they're called Jazelle DBX) added a decoder alongside the ARM decoder that would execute simple Java instructions natively and trap to the JVM for more complex ones. They were pretty nice for their target (i.e. machines with 2MB or so of RAM) but were surpassed quite a while ago by JIT compilers, for several reasons:

• The JVM is stack-based, so it's hard to get any ILP out of a superscalar core and it's even hard to identify hazard-free pairs for a simple in-order pipelined core, so you don't end up packing the pipeline very well.
• The javac output is not very well optimised, because it's intended to be consumed by something else that will optimise and doing the optimisation in the front end can hide opportunities later.
• Run-time optimisations (trace-based adaptive recompilation) techniques improved a lot

Once ARM devices wanting to run Java had 32-64MB of RAM, you could get better performance with an optimising JIT compiler than with Jazelle and it died. More recent chips have Jazelle RCT (also known as Thumb-2EE) which has some extra instructions for fast bounds checking and so on, but even that isn't used much.

Are you really that dense? You may be buying gifts for one of your friends half of the time, but you're not buying gifts for one specific friend half of the time. Recommending things that one friend likes when you're shopping for things for a different friend may coincidentally be useful, but probably isn't unless you have a very homogeneous set of friends.

You're missing the point. You buy stuff like that occasionally and on specific occasions. If I have, say, 10 friends for whom I buy birthday presents, and buy 20 things for myself, from Amazon each year, then if you want to recommend things to me then there is absolutely no point in recommending things that one of my friends likes, because there's a very small chance that this will be the time when I'll be buying something for that person. The same applies to seasonal goods, but those patterns are easier to spot because they apply to everyone.

The problem is, if half of the stuff that you buy on Amazon is intended for gifts, then it's very difficult for the algorithm to determine the difference between a pattern with 50% of inputs being false positives, and a completely different pattern. It's quite easy to train a machine learning algorithm to discover that, given these 100 things that you've bought for either yourself or your friends, either you or one of your friends would like something from this other set of items. It's much harder for it to then determine that, at this instant, you're shopping for yourself or a specific friend and that it should narrow the search down to things that person will be interested in.

The point that the grandparent is trying to make is that you don't need to prevent cancer, you need to prevent cancerous cells from having a serious adverse effect on the organism. There are a number of benign growths that have cancer-like properties that people can live with and that don't spread over the body. Being able to differentiate the benign versions from the malignant and kill off the malignant cells would not require eradicating the cancer mechanism, but would (from the perspective of humans outside of the medical profession) count as curing cancer.

I wonder if this will change, given all of the reports about web advertising being a bubble. Advertisers are starting to notice that, for most of them, the ROI is tiny and that's eventually going to trickle up the supply chain. If Microsoft were smart, they'd sell off their ad business while it's still at an overinflated price and then work to kill the market.

No, because if they did then they'd be able to track all of your browsing. They don't wish to do this...

The self-destructing cookies plugin for Firefox has the cookie management policy that I want. Sites can leave whatever cookies they want, but they are silently removed when I navigate away from the page (there's also an undo feature, so if I realise after navigating away that I actually wanted the site to store something persistent, I can retrieve it). It also does the same for HTML5 local storage and will aggressively delete tracking cookies from ad networks. It needed basically no configuration other than to whitelist a few sites as I go.

I'd love to see Microsoft and Apple integrate this kind of functionality into IE and Safari. I doubt Google would do the same for Chrome, as they rely too heavily on aggressive tracking for making money. I don't really understand why Apple and Microsoft don't aggressively push privacy features in their browsers: they'd get good PR and hurt one of their competitors at the same time...

They don't use tracking cookies (their preferences cookies are not identifying, they're just a string of your options, if you've set them), so the most data that they can have for identifying you is the IP address. They've been SSL by default (redirecting from http to https and defaulting to https in search results where available, for example on Wikipedia) for a long time, so you don't suddenly jump into an unencrypted connection as soon as you leave.

One word: Zoning. If you've played SimCity, you have a good idea of the structure of a lot of US cities. For some reason, they decided that places where people live, places where people shop, and places where people work should all be separate and so you need to drive to get between them. In most of the rest of the world, cities formed where villages grew until they were overlapping, so contain a mixture of homes, shops, offices, and so on. In the UK, it's hard to live in a city (or town) and be more than 5 minutes walk from a grocery store and usually a load of other small shops. A big supermarket may be a bit further away, but most deliver so you don't usually need to physically visit them.

We proposed it to WG14, not WG21. It's pretty trivial to add wrapping and trapping integer templates in C++.

Clang has some builtins that allow you to get the carry bit, so you can cheaply write code that branches on carry. We (mostly CERT, I helped a bit) had a proposal for inclusion in C11 that would have added qualifiers on integers explicitly defining their overflow behaviour as trapping or wrapping, along with a model that let this be implemented cheaply (e.g. allowing a set of side-effect-free code to propagate temporary results and only trap if one of them along the way overflowed). Sadly, it didn't make it into the standard.

Integer overflow has been in the top five causes of CVEs for several years running. Buffer overflows, sadly, are still at the top.