First, "programs reliant on STL" can be as fast as anything on plain C. And very often they can be faster (for example, because dwarf-style exception handling is faster than return result checks).
Second, JITs are NOT "very far along". HotSpot is _already_ faster than C/C++ on some benchmarks. And it's only going to get better, because HotSpot can use real runtime statistics to guide optimizations (C/C++ can also use Profile Guided Optimizations but it relies on static data).
"It wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish."
For example, in Java HotSpot it _already_ works this way. A special thread compiles the code while other thread(s) work in interpreted mode. When compilation is finished, other thread(s) switch to this new fast compiled code.
Also, there are optimizations in Java HotSpot which are _impossible_ to do using static analysis.
To summarize it, C++ now moves toward design which allows to catch more and more errors during compilation. But at the same time C++ provides tools which allow to write generic code.
Homemade fusors are not likely to have really dangerous levels of neutron radiation.
The principal danger in fusors is X-Ray radiation. It's produced in generous amounts and can kill you just as good as another types of penetrating radiation.
Isolation of applications in OSGi containers is leaky, one bad-behaving application can bring down the whole containers.
Lightweight containers (OpenVZ, Virtuozzo) have almost no overhead and allow cool features like load-balancing of ALL applications between cluster nodes. However, all lightweight containers use the same kernel, and one kernel bug can bring down all virtual nodes.
XEN/KVM have a bit more overhead but with even more isolation (each node has its own kernel).
A PIN is a weaker form of password. It also relies on hardware (to lock you out if you enter PIN incorrectly several times). It's useful to make simple attacks (like stealing your token) harder.
A written-down password is less secure than a hardware token. Because you can simply copy the written password (and use it later) but you need to have a physical token to use it. Of course, assuming tokens are not easy to clone.
Slashdot Mirror
So? Just fire up your browser, navigate to http://en.wikipedia.org/ and check the facts.
I actually liked it in Baroque cycle.
In "The Moon Is A Harsh Mistress" Heinlein just uses straightforward Russian. I always wondered why that's such a big deal.
PS: maybe because I'm speaking Russian.
What a bunch of stupidity...
First, "programs reliant on STL" can be as fast as anything on plain C. And very often they can be faster (for example, because dwarf-style exception handling is faster than return result checks).
Second, JITs are NOT "very far along". HotSpot is _already_ faster than C/C++ on some benchmarks. And it's only going to get better, because HotSpot can use real runtime statistics to guide optimizations (C/C++ can also use Profile Guided Optimizations but it relies on static data).
"It wouldn't be JIT then, it'd have to be 'before the code is executed', because you wouldn't want the compiler to spring into action, run on core 2 whilst core 1 twiddles its thumbs waiting for the compilation to finish."
For example, in Java HotSpot it _already_ works this way. A special thread compiles the code while other thread(s) work in interpreted mode. When compilation is finished, other thread(s) switch to this new fast compiled code.
Also, there are optimizations in Java HotSpot which are _impossible_ to do using static analysis.
MD5 is already completely broken: http://en.wikipedia.org/wiki/MD5#History_and_cryptanalysis
To summarize it, C++ now moves toward design which allows to catch more and more errors during compilation. But at the same time C++ provides tools which allow to write generic code.
Read: http://www.amazon.co.uk/Modern-Design-Applied-Generic-Patterns/dp/0201704315
It's a good introduction to modern C++. While the book itself is not really helpful, it gives you a nice overview of "modern" development techniques.
Homemade fusors are not likely to have really dangerous levels of neutron radiation.
The principal danger in fusors is X-Ray radiation. It's produced in generous amounts and can kill you just as good as another types of penetrating radiation.
You might notice, that since the days of floppies copy protection IS NOT STOPPING PIRACY.
To break 256-bit encryption you need about the same energy as is generated in supernova explosions.
Bullshit. D3D can be used for CAD programs just fine.
A lot of CAD developers simply have mountains of _legacy_ OpenGL code back from times when OpenGL was the _only_ working 3D API.
Well, that tells a lot about Putin too.
Yeah, that stuff is dangerous! We need to stop it RIGHT NOW!
Think of the children! They might get EXPOSED to these vile chemicals.
Call your congressman!
How about load balancing then? It's fairly easy to move container applications between nodes.
Also, some applications may take a long time to restart.
Isolation and easy management.
Isolation of applications in OSGi containers is leaky, one bad-behaving application can bring down the whole containers.
Lightweight containers (OpenVZ, Virtuozzo) have almost no overhead and allow cool features like load-balancing of ALL applications between cluster nodes. However, all lightweight containers use the same kernel, and one kernel bug can bring down all virtual nodes.
XEN/KVM have a bit more overhead but with even more isolation (each node has its own kernel).
LARGE corporations usually just buy site licenses. It's easier for them this way.
It's NOT in Ossetia. It's a bit south of Ossetian border.
Well, I hope they debugged their image-recognition code.
In any case, I wouldn't like to be a scuba-diver near this vehicle.
Yes, it's a weakness. We really need to speed up DNSSEC adoption.
In fact, I'm going to install it on my DNS servers ASAP.
In theory, hardware tokens can also authenticate that the OpenID server is the real one.
No, it's more like RSA tokens used in Internet-banking.
TPM ensures that no 'untrusted' code is running, hardware tokens are used to ensure your identity.
A PIN is a weaker form of password. It also relies on hardware (to lock you out if you enter PIN incorrectly several times). It's useful to make simple attacks (like stealing your token) harder.
A written-down password is less secure than a hardware token. Because you can simply copy the written password (and use it later) but you need to have a physical token to use it. Of course, assuming tokens are not easy to clone.
There's no real reason for it.
They are expensive because demand for them is low and economy of scale doesn't have a chance to kick in.
Combine it with a lot of conflicting proprietary implementations.
So? Of course you can screw up anything.
For most applications "something held" (maybe with a simple PIN-protection) is perfectly fine. Like your keys, for example.
Good key revocation system is essential in this scenario, however.
Passwords are much overrated, anyway. Most users inevitably either choose weak passwords or just write them down somewhere.