.NET doesn't handle leap seconds because Windows doesn't. Its NTP client will ignore seconds values greater than 59, and then fix the time during the next update. This means that Windows can knowingly be up to a second off from UTC time between the introduction of a leap second and its next NTP update. This is important to know if you attempt a fully synchronous distributed system that relies on NTP for synchronization.

I believe that some of the details in jni.h changed from 1.3 to 1.4. Perhaps a change to how JNIEnv was defined? A quick Google shows that the JNI version did in fact change then, but every page describes launching a JVM from within C/C++ code (which does use the JNI version information).

It is possible that my memory could be faulty (it was a long time ago after all) and that the problem was with launching a JVM from native code. Either way, my point stands. It is possible (however unlikely) to upgrade the JVM and have running JNI code break.

You can get the version of the compiler used to compile a class file (which contains the bytecode) using "javap -verbose MyClass.class". A major and minor version will be at the top. For what it is worth, Java 7 uses major version 51.

This is mostly true, but it is worth expanding as there are a lot of misconceptions about this. Java bytecode contains the JVM version it was compiled against, and later JVMs will run it just fine, even if it will no longer compile. I remember when Java added the enum keyword, and all our applications ran fine on the new JVM, even though it wouldn't compile without changes (one of our programmers used enum as the standard variable name for Enumerators). Overall, I've been very impressed with Java's cross platform and version compatibility, but I have found three causes of compatibility problems that are worth knowing about.

First, you cannot rely on non-standard libraries such as the com.sun packages. These aren't guaranteed to exist from one version of Java to the next. They aren't even guaranteed to work the same between minor Java versions. If you limit yourself to the standard libraries, you are safe. Be advised that deprecated methods may be removed in the future, though none have been removed so far.

Second, some programmers explicitly version check the JVM. This is usually for compliance issues, as some organizations feel that code should never run against a JVM that it hasn't been formally verified against. I have also seen this done because code was written to a known bug and some idiot thought it would be better to ensure that the underlying JVM always had the bug rather than work with both bugged and unbugged JVMs. Whatever your reasons, I consider this to be a bad practice, as you won't get security fixes from updated JVMs.

Third, while bytecode should always be forward compatible (barring bugs in the Java library), if you use native code you should be aware that JNI libraries are not guaranteed to work across major JVM versions. JNI libraries must be recompiled to work on newer JVMs.

There may be other sources of compatibility problems, but these are the only that I've run across them in my 15 years maintaining several million lines of Java code.

Stupid Slashdot doesn't have a way to undo a moderation other than posting. I meant to select Funny, and hit Overrated instead.

Your theory would work if the agents that were pulled out were American, but British agents are unlikely to have an SF-86.

I get the same page both with and without AdBlock for Chrome. And I agree, this site isn't a good example of tricky download links.

Robot Santa lives on Neptune.

Maxim 43: If it's stupid and it works, it's still stupid and you're lucky.

Credit goes to Schlock Mercenary.

Only if you are considering desktop PC's. If you consider all computing devices, Linux wins easily. It is run on the largest of supercomputers and the smallest of embedded systems. All Android devices run Linux. Many (most?) home routers run Linux. Even my LG Blu-ray player has some sort of Linux somewhere inside it. Linux is literally everywhere.

This demonstrates the importance of not being seen.

Why stop there? The days of the week are named after the gods associated with the seven celestial bodies (only Saturday wasn't converted from a Roman deity to a German one, as there was no equivalent of Saturn in the Norse pantheon). And the first 6 months of the calendar are all named after Roman gods or religious festivals, so we should rename those as well. Even how we divide time into hours, minutes, and seconds is associated with Babylonian numerology and astrology, which has deep religious significance.

If we are going to start changing names to remove religious connotations, we have a lot of work to do. Or is it just the Christian origin of the name you object to, and not religion in general?

It's been doing okay. NVIDIA is making money, but it is only up 4.5% over the last year. Compare this to 6.6% for Intel, 13% for the Dow Jones, and 16% for the S&P 500. It's only doing well when compared with smaller chipmakers like ARM (up only 4.2% in the last year), Qualcomm (down over 12% in the last year), and AMD (which has lost over 26% in the last year).

I haven't read Linux's rant against C++ for a while, but he is correct that C++ isn't a good choice for an OS kernel. The only major kernel written in C++ that I know of is Windows NT, and it uses only a subset of C++ language features. In particular, it disables exceptions, disables RTTI, removes new/delete, and it doesn't have the standard library. Microsoft wrote their C++ compiler with this in mind, and there is a compiler flag to disable kernel unfriendly features (documented here). For everyone else, it's easier to just say that the C++ subset for kernel development is C (minus the standard library).

For non kernel use, C++ is superior to C in the hands of an expert programmer, but mediocre programmers who don't understand the language tend to write absolutely horrible code. And you can't take an expert C or Java programmer and expect them to write expert C++ code with just a few weeks practice. C++ is one of those languages that you have to dedicate a lot of time to, but it can be worth it if you require highly optimized code, have low latency requirements, or have low space requirements (areas where higher level languages like Java don't do well).

The Soviet Union adopted with the AK-74 in 1974, and most Eastern European and former Soviet Republics use it today. It has many advantages over the old AK-47, including accuracy, penetration, and muzzle velocity. With proper maintenance it is as reliable as the AK-47, and it costs less than other modern assault rifles.

The only nation states I know of that still use the old AK-47 are in the Middle East, Africa, and Southeast Asia (including, I think, India). The big advantage of the AK-47 is that it is cheap enough to hand out like candy to guerrilla fighters, and it's reliable enough to still work after years of little to no maintenance (though it's effectiveness drops quite a lot when doing so).