Sigh
America's central bank HAS dumped $ over the last 3 years. That was to stop what these other nations were doing. Had they not been manipulating, then when we dumped our $, and if they kept theirs at a set amount, then the foreign money to the $ would have dropped (i.e. more $ to the ruppe/won/yuen/etc). That was NOT the case. Instead, it continued rising relative to the $.

Now, as to other moneys, NZ's dollar dropped because the one-way trade with US increased, combined with US$ dumping $ to stop these other nations from trying to sink America. And our central bank has HELPED NZ with that.

Uh, no. America is not manipulating others. The central banks do some manipulation, but only to a degree. And actually, all of those nations mentioned are dropping their money relative to the $, even though one-way trade has massively increased.

When it is considered the main money of the world, no, you can NOT manipulate it easily. To throw China and others off, we DID dump $ on the market, but we also helped allies to overcome the issues with it. OTOH, China, India, Vietnam, etc are suffering massive inflation due to their manipulation.

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.

The real problem is that other nations continue to manipulate their money relative to the $.
China,
Indonesia,
India,
vietnam,
etc. are but a few.

As long as this is ignored, then manufacturing will continue to stay with those nations that manipulate the most.

What is really helping move this back is NOT so much costs, but the fact that the younger generation are saying no to this and working hard to bring it back. Look at how Target, and Walmart are doing. These are basically front companies for these other locations. They are having no choice but to start bring back North American products.

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++.

Of course, that comes with its own headaches and negates some of the benefits of a VM architecture. Paravirtualized networking is however pretty adequate for most workloads.

It's not like you have to do VM *or* baremetal across the board anyway. Use what makes sense for the circumstance.

In my experience, KSM hasn't helped as much as it promised. It depends heavily upon the workloads. It also impacts memory performance. If things are such that KSM can be highly effective, then a container solution would probably be more prudent.

CPU throughput impact is nearly undetectable nowadays. Memory *capacity* can suffer (you have overhead of the hypervisor footprint), though memory *performance* can also be pretty much on par with bare metal memory.

On hard disks and networking, things get a bit more complicated. In the most naive way, what you describe is true, a huge loss for emulating devices. However paravirtualized network and disk is pretty common which brings it in the same ballpark as not being in a VM. But that ballpark is relatively large, you still suffer significantly in the IO department in x86 virtualization despite a lot of work to make that less the case.

Of course, VM doesn't always make sense. I have seen people make a hypervisor that ran a single VM that pretty much required all the resources of the hypervisor and no other VM could run. It was architected such that live migration was impossible. This sort of stupidity makes no sense, pissing away efficiency for no gains.

So to the extent this conversation does make sense (it is pretty nonsensical in a lot of areas), it refers to a phenomenon I find annoying as hell: application vendors bundle all their OS bits.

Before, if you wanted to run vendor X's software stack, you might have to mate it with a supported OS, but at least vendor X was *only* responsible for the code they produced. Now increasingly vendor X *only* releases an 'appliance and are in practice responsible for the full OS stack despite having no competency to be in that position'. Let's see the anatomy of a recent example of critical update, OpenSSL.

For the systems where the OS has applications installed on top, patches were ready to deploy pretty much immediately, within days of the problem. It was a relatively no-muss affair. Certificate regeneration was an unfortunate hoop to go through, but it's about as painless as it could have been given the circumstances.

For the 'appliances', some *still* do not even have an update for *Heartbleed* (and many more didn't bother with the other OpenSSL updates). Some have updates, but only in versions that also have functional changes in the application that are not desired, and the vendor refuses to backport the relatively simple library change. In many cases, applying an 'update' actually resembles a reinstall. Having to download a full copy of the new image and doing some 'migration' work to have data continuity.

Vendors have traded generally low amounts of effort in initial deployment for unmaintainable messes with respect to updates.

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.

If you can't call native code, you probably don't have a working JVM. The Oracle JDK and OpenJDK each include around a million lines of C in their standard libraries. That doesn't mean that you won't find it easier to write secure code in Java, it just means that you probably don't have much less C code in your TCB for a Java program than you do for a C one.