...is this: suppose that we make contact with some alien species, and it just happens that they are overwhelmingly superior to us - a civilization that's thousands of years more advanced and kicks our ass in technology, morals, arts, everything.
Now suppose that this civilization is completely atheist. They are angel-like beings but with no God; they consider religion a trait of pre-historic (in their POV) civilizations. Just like, say, our modern opinion about cannibalism. Their scientists and philosophers have long demolished all pro-religion arguments, finishing this debate in such clear terms that any educated human would understand and find impossible to not agree.
*If* this happens (notice I'm just supposing), religion is in major trouble and the only option for resistance is fanatism.
It was once believed that the sun revolved around the earth. This is still a good approximation, for most purposes here on the ground. It is only when we begin to consider the motion of other planets that it becomes important which is which.
Actually, saying that the Sun orbits Earth is not really wrong even today. The universe doesn't have a fixed reference frame so no body has an absolute position, all 'positions' are just relative to other bodies (including time positions). We still tend to put the Sun in the "center", in coordinate (0,0,0) of the solar system, because that's very useful for local purposes, but it's just as arbitrary as having Earth in the center centuries ago. So, we could very well define as a convention that Earth is permanently fixed in the center of the entire Universe as a convention, and adjust all our calculations for that, and everything would be just fine... some equations could become more complex (a microscopic perturbation in Earth's orbit would translate, due to angular distance, in galaxies billions of years away being "shaked" in faster-than-light speed - still not violating any physics laws) but that would be just complex and ugly, not wrong.
...formed one billion years ago, but originally much more distant from the star. But its orbit was not stable, approaching quickly (in astronomical time) to the star; and we're just lucky to have found it in the final stage of the death spiral. If this is the case, it may even be possible to watch the final spectacle in a timeframe reasonable for human scale (a few thousand years, perhaps centuries, or even less).
Wild speculation of course... but just to be safe, I'm immediately canceling all my plans of space vacations near the Wasp18 system. I never liked wasps anyway.
...as the latest JVMs have a "compressed pointers" option that allows the 64-bit VM to be as memory-efficient as 32-bit. This option limits max heap size to 32Gb, but this should be plenty for even most huge applications, for many years to come.
BTW this optimization is a great advantage of all "managed" languages/VMs; it's just impossible for langs like C/C++. Of course, you've got to actually implement it in a JIT compiler like Java's. But I think even an interpreter could do it. Notice that there is no tradeoff to code speed; although the code needs a couple extra instructions to compress/uncompress pointers at every usage of heap objects, this overhead is greatly reduced/hidden by JIT optimizations. (And for an interpreter, it's certainly just noise in the performance map.) Not to mention that the gains in reduced paging, cache misses and TLB misses will more than compensate for any remaining overheads.
L4 is a microkernel, so it DOES mean that buggy device drivers cannot crash, corrupt, DoS or own the system; because drivers would all run in userland.
Of course, if bugs prevents that some essential driver works at all, the system may becomes unusable anyway. But the kernel is still in control and it can resort to techniques like restarting the driver or, if the driver keeps failing, replacing it by a much simpler, "safe mode" driver so you can use the system even with some reduced functionality or performance.
Who in his right mind starts mixing a binary and a decimal system. 2^10 bytes?
Very likely, a hardware engineer or a programmer who had to deal with low-level system realities like memory block sizes being always powers of two. You must manipulate memory (and other HW things) in blocks which sizes match physical packaging, to avoid inefficiencies from alignment, memory hierarchies, etc.
And this is reality up to current day. Please come back whining for decimal system when you're using, say, a monitor with 1500x1000 resolution, or a net connection of 10.000.000 bps.
I for one, will continue using Kb = 1024 etc., these politically correct labels like KiB are for idiots.
Here, I fixed that for you. And this one is NOT a myth: http://en.wikipedia.org/wiki/AARD_code, http://www.ddj.com/windows/184409070?pgno=4
...from TFA: "That documentation must be kept "in confidence" and "under non-disclosure" by PFIF and Samba. "
Not what I'd consider openness yet; not by a LONG shot.
Some drivers to make Linux work better inside MS's Windows Server Hyper-V virtualization platform? How altruistic...
I'll be more impressed when MS, for example, helps with the SAMBA project. Or at least, doesn't actively screw up with such interop projects from the FOSS community. No GPL code required, just give people decent, up-to-date, open specs; and no patents bullshit.
Or at very least, when MS stops enforcing such patents (see TomTom / FAT32, or again SMB in MS/Novell "agreement").
Check this, 240 languages and counting: http://www.is-research.de/info/vmlanguages/. Now just die of shame.
Of course not all these "languages" are highly relevant. There are abandoned or not well maintained projects, academic stuff, and several extremely niche languages/tools. But I suppose this can be said at least for a few of the
Wikipedia's articles have very different quality. You'd think that the articles used some criteria like only including languages which are current / well maintained, but the JVM article it misses such entries like JESS and Drools, both very "alive" and popular for logic/IA and rule-based programming.
(If both steps are sufficiently efficient and the host platform is also x86, the compiled code may even be very similar to the original code.)
Why don't they just do away with the inefficient step of compiling it twice?
Because of the big "if" in my comment. Notice that even when emulating a PC on a PC you don't always get identical ISAs; you may be emulating code compiled for 80386 inside a Core2 Quad CPU, so this recompilation may even improve the code because it's possible to use 64 bit-opcodes, SSE, prefetching, etc. (This is not theoretical; modern JVMs like HotSpot are well known to exploit the very latest ISA features.)
The second reason is that the original code may not be safe, but the emulated/recompiled code is. Any kind of emulation has a side effect of sandboxing. So, JPC allows you to run arbitrary x86 code inside a browser's applet without any stability or security risk.
I don' think Applet deployment is the target for that project; if they are offering this option it's certainly just for quick demo sake. Notice also that the applet would need some serious time to download because (1) the emulator itself is reasonably big, (2) you need a virtual disk image containing the whole OS and apps; even a small FreeDOS distro with a couple of tiny DOS games will weight in a few hundred Kb, although the problem is mostly for first run as the Java PlugIn can cache everything.
As I see it, JPC's main goal is showing off some amazing virtualization technology that they have developed - the emulated x86 code is JIT-compiled by JPC's engine into Java bytecodes, which are in turn JIT-compiled by the JVM to native code, so the net result is full native-to-native translation. (If both steps are sufficiently efficient and the host platform is also x86, the compiled code may even be very similar to the original code.) This remembers of similar systems like Transmeta's Crusoe.
As a secondary goal,. JPC is becoming a pretty nice general-purpose PC emulator, so it's potentially just as useful as other PC emulators like Bochs. If JPC reaches sufficiently close to native performance (I tested it ~1yr ago and it's slashdotted now), and includes sufficient hardware compatibility, it's obviously an advantage to be a Java program, fully portable including UI.
...that insists pushing bigger clock speeds. I fully expect IBM to promote liquid Nitrogen cooling in another couple years.
..but I am also old enough so have seen it in the big screen, back in 1982. And I'm not trekkie enough (read, fanatic) so have seen it again and again so I'd remember such trivia.
Remember to say hello to your bank teller.
