Slashdot Mirror

Out of interest, did you actually read any of those articles you cited?

Yes.

The first, for example, is using Java to develop a distributed computation network.

Indeed. I have written such stuff myself. There are tools for it in C,C++ and Fortran. I don't believe Java's facilities in this area are not sufficient for a move to the language if it were significantly slower than the alternatives.

I don't see how that supports your argument; on the contrary, it's the classic "hardware is cheap" approach necessarily employed by those using inefficient programming tools.

This is a very condescending attitude to those doing the development - you honestly think that they are deliberately doing work with inefficient programming tools? Do you really think they would use a language for general purpose simulation if there was a significant speed penalty? (Having been through the process myself, I can just imagine the comments from review bodies when the applied for grants if this were true).

How about finding some real, production applications (not recent, unfinished developments or academic experiments) that use Java for the same sort of job that things like C++

Here is a well-known molecule CAD system in Java:

http://willware.net:8080/ncad.html

Here is a high-performance simulation system:

http://jist.ece.cornell.edu/

Here is a Java Numerics Library:

http://www.vni.com/products/imsl/jmsl/jmsl.html

There aren't many of these, because until recently (a few years ago), Java performance was just not good enough for this sort of thing (even the strongest Java supporters will admit this), and the numerics/simulation industry is one of the slowest about accepting new technologies (as shown by the huge amount of Fortran still being written).

However, this may interest you - some numerical benchmarks commonly used with C and Fortran - Java is right there close to the top in many of them:

http://www.vni.com/products/imsl/jmsl/jmsl.html

On the other hand, your choice of a random data source might not matter much at all. Although I'm sure none of this is proven in the formal sense of the word, I strongly suspect that any source of entropy that has some original indeturminability (due to true randomness in the physical world*, complexity of the data's origin, or lack of a human means to measure the source of the data's origin**) is as good a source as any other. Computers can extract entropy from a mix of ordered and disordered data. The data compression WinZIP and bzip2 do is a good example of this. Therefore, I suspect that the security of an RNG rests less or the inherent entropy of the source then on the quality of the algorithm used to amass usable random numbers from the source data.
*if that exists at all
**think Heisenberg uncertainty principle

Wired has an article on Drew Endy and Tom Knight: Life Reinvented (Issue 13.01 - January 2005). For those interested the article also illustrates how the parts can be assembled as bio bricks.

Anybody have experience with building and integrating a hardware random number generator?

Yes. But I can also tell you, a hardware RNG is overkill for these purposes. There is easily enough randomness available through /dev/random based on disk timings and such to make strong 152-bit keys. Alternatively, you can roll a bunch of dice.

If you really, really want a hardware RNG, go for a Soekris card or a C3 processor, or make your own RNG (integrating that would be tougher, though).

I've gotten curious enough about this stuff that I've started learning a little bit about orbital mechanics. I've written some Python code to do the calculations for this stuff. Here's the asteroid's orbit:

from units import *
from orbit import *

rmin = earthRadius + 200 * mile
vmin = 10000 * m / sec

o = Orbit(rmin, vmin)
for v in [ o.perigee, o.apogee ]:
- # Slashdot's ecode tag does not preserve leading whitespace!
- print v
- print (v[0] - earthRadius) / mile, "miles"
- print (v[0] - earthRadius) / km, "km"

(<6.69997e+06 m>, <10000 m sec^-1>)
200.0 miles
321.8688 km
(<3.52573e+07 m>, <1900.31 m sec^-1>)
17944.7223304 miles
28879.2312141 km

I've gotten curious enough about this stuff that I've started learning a little bit about orbital mechanics. I've written some Python code to do the calculations for this stuff. Here's the asteroid's orbit:

from units import *
from orbit import *

rmin = earthRadius + 200 * mile
vmin = 10000 * m / sec

o = Orbit(rmin, vmin)
for v in [ o.perigee, o.apogee ]:
- # Slashdot's ecode tag does not preserve leading whitespace!
- print v
- print (v[0] - earthRadius) / mile, "miles"
- print (v[0] - earthRadius) / km, "km"

(<6.69997e+06 m>, <10000 m sec^-1>)
200.0 miles
321.8688 km
(<3.52573e+07 m>, <1900.31 m sec^-1>)
17944.7223304 miles
28879.2312141 km

$100? You're being charged for convenience.

Here's a hardware RNG that you can build with some spare parts: a couple of caps, couple of transistors, a few resistors, and a quad inverter.

Carlin Vieri at MIT designed and fabricated a reversible processor, described in his PhD thesis defense. It was really a fascinating gadget. It was very interesting how far-reaching the implications of reversibility were -- he needed to be able to reverse all the conditional jumps in the code, so it influenced compiler design as well as hardware design.

If by "vaporware" you mean "I can't buy one today at CompUSA", then you're correct. If you mean "it has never been built and it never will be built" then you are misinformed.

Java limited people to one language, a language that many coders didn't like.

Which language would that be, then? Would it be BASIC, or COBOL or ADA or Python or FORTH or PASCAL or C or PERL or FORTRAN or LISP or Scheme or Smalltalk or one of these?

In fact, surprise, surprise, there are over 200 different programming languages you can use to write Java VM programs in.

There's no machine I've ever heard of nor seen that could generate a truely random number

It's true that no computational algorithm can generate truly random numbers, without input from some random physical process. The real test would be whether you could look at the history of numbers generated and predict the next number. This would mean inferring the state bits of the algorithm and deducing its inputs, if any. Cryptographic hashes are algorithms specifically designed to make that difficult.

In physics, you don't get real randomness without quantum effects, but statistical processes can give you highly unpredictable numbers, unless you're prepared to do faster-than-real-time molecular dynamics on 10^23 particles.

Here's a random bit generator suitable for use with a crypto hash algorithm to make good random bits: http://willware.net:8080/hw-rng.html