Slashdot Mirror

This is what the biggest USAF compute cluster uses (RH, PBS)

No, the largest USAF system (AFRL's Raptor, which is actually the largest DoD system) is a Cray XE6 and uses a custom built Linux environment, CLE.

Well.. I'd say that the DREN are. This appears to be a DoD usa-wide engineering research network. By their own admission, DREN is the "official DoD long-haul network for computational scientific research, engineering, and testing" -- doesn't sound like they're the military operations type people though.

So... yeah. Given that DREN explictly say they support ipv4 and ipv6, they're almost certainly insisting on ipv6 support on equipment they buy and want a show of good faith from vendors that their ipv6 solutions are good enough that the people selling them actually use them themselves. Makes sense - everyone knows that ipv6 is coming; and a research network can afford to be an early adopter. They're probably big enough to have some clout.

Broade, for example, met the demands by putting some of their own gear in front if its website

Brocade put a pair of its ADX load balancers in front of its Web site to allow incoming IPv6 users to access its IPv4-based content. This pair of load balancers – which would cost around $26,000 -- allowed Brocade to IPv6-enable its Web site, DNS services and mail server.

For them, not a huge cost to land what is probably a fairly decent contract.

However, this does appear a way off from being a US DoD-wide mandate.

I heard through the grapevine that a cable at ARL was cut. I can't find anything to substantiate this other than a slightly related "unscheduled network maintenance" notice here

You gotta communicate with 'em SOMEHOW. Are you proposing the banking system, the hospitals, and the military all SEPARATELY .. dig up the country and run their own private network?

You are talking technological nonsense. All it would take is secured encrypted VPN nodes running on embedded devices.

"(And harden it against manhole-divers with bolt cutters while they're at it?)"

And having more then the one redundant path, so as to protect from when someone accidentally or otherwise digs up the cable.

[quote]
As of 15 January 1999, the DoD High Performance Computing Modernization Program (HPCMP) has required MHPCC to restrict access to our computers to valid users who:

1. Are running Kerberos or Secure Shell software on their local computer, and
2. Have a one-time password SecurID card issued to them by either HPCMP or MHPCC.
[unquote]

http://www.mhpcc.hpc.mil/

Thanks for taking the time to remove any doubt whatsoever that you are, in fact, not only a bigot, but a complete idiot.

The US Army Research Laboratory will be receiving two 2,000+ precessor super computers running Linux. ARL already has a 256 processor Linux cluster that throws off enough heat to cook the staff dinner...gotta wonder how much these suckers will dissipate.

The US Army Research Laboratory will be receiving two 2,000+ precessor super computers running Linux. ARL already has a 256 processor Linux cluster that throws off enough heat to cook the staff dinner...gotta wonder how much these suckers will dissipate.

• DREN is an R&D network. You won't find anything sensitive here, and it's considered the least secure of the primary DoD networks.
• NIPRnet is where you find the DoD's mail servers, primarily. This is where your mistake is - NIPRnet is considered at maximum SBU "sensitive but unclassified". The network isn't secure in the sense that Secret systems would be. All DoD systems are required to be 'secure', moreso than most or all commercial machines, but no special effort is expended to secure down NIPRnet systems. It's an analogue to the office network in a commercial environment. If you only used the Secret networks, you could never communicate outside of DoD, mostly.
• SIPRnet - You need a Secret clearance to be here. SIPRnet is for sensitive stuff. It isn't directly connected to anything else. This is what you were thinking about when you were talking about 'secure systems'. However, even stuff on the NIPRnet or DREN has to be secure.

Please note I used completely public sources. There is more to know, but not more that I can say.

In direct answer to your question, we get a decent amount of spam, mostly worm related stuff though. Most spammers seem to be afraid to send Viagra ads to .mil addresses. I dunno why. Maybe they're afraid they'll get a Hummer.

Specifically, an old Fortran quote... default variable types were defined based on the first letter of the variable name.

Variables begining with the letters J-L would be defined as type integer by default. All the others were defined as Real (roughly equiv to float IIRC).

Hence "God" is "Real".

Well, this probably isn't how they do it, but you could always do it the same was as this device (keep a clock and compute a unique hash based on the time).

"Iris Scans", which is what the article stated, are scans of the colored part of the eye, not the retina. These can be easily fooled by contacts, and are therefore an unlikely security mechanism. But none of this is even an issue.

The point is that there will not be stored images of your iris, retina, face, or even your DNA, at least not for the purpose of identification. That's not the way that security systems work. Security systems will only store enough information to uniquely identify you. Here's what I mean with regards to the particular systems currently in development:

Retinal scans are difficult and presently relatively slow and cumbersome processes. I expect that if any sort of retinal scan technology is ever implemented, it is a long way off, if ever. Retinal scanning presently requires you to immobilize your head in a fixture so that the system can take a picture of the INSIDE of your eye. Only then can it match that based on identifying points to a record of those key points. It is not likely to store a complete image of your retina, just those identifying structures, which means that it would likely only be useful for ID purposes. For instance it might store the image of a reference point as a "key", and then indentifying structures would be referenced from that. For example, ref #1 is 240 pixels from KEY at 270 degrees (compass direction).

The same is true for face recognition, which only stores data-points in regards to facial feature locations. In the future, I suspect that these would be further reduced as an algorithm which can be used to recreate those features. These will not be actually images of your face, as that would be entirely inefficient. No system will likely store all of the information needed to recreate the owner even in a general sense.

Even if we develop a "DNA scanner", it would be ridiculous to store the gigabytes of genomic data for a single individual, just for the purpose of security. Those systems would work just like every other system, storing only the combination of points necessary to identify the specific user. And as I stated before, these would likely be reduced even further to an algorithm of some sort.

The other particular aspect of this is that many systems will need to work remotely. That means that unless you want to install these systems in remote locations, then the process is pointless.

With that said, I suspect that any sort of future security system will likely incorporate some sort of simple key system, perhaps combined with one of the above technologies (I tend to think biometrics is the likely candidate at present). Even the DOD HPMC uses SecurID and is satisfied. My personal suspicion is that we will likely have some sort of biometric-keyed SecurID card with the scanner in the card. The card will use the features of the scan to create an algorithn used to encode a password, and the controling system will use it's stored user id algorithm to decode that password to use for access. If the algorithm or password don't match that of the user, then access cannot be granted.

First of all, the article said "Iris Scans". The iris is that part of the eye that has the color. It can easily be fooled by colored contacts, which many people wear. How is this any kind of security. Second, even if the article had stated "retinal scans", I think this likely will never catch on, as it requires one to place their eye against some sort of reader. This is not only inconvenient, but it is also a relatively slow process (at least at present, as there are alot of variables involved). All-in-all, I think that these sort of recognition systems are quite a way off, if they are implemented at all. I tend to believe that the more likely options are face, fingerprint, and body chemistry recognition systems for business security, but expect that even those will be less likely than the old standby of a simple key system or something akin to SecurID (see the DOD HPCMP page).

Is this perhaps the same thing as stochastic resonance ? I remember reading about it once; it relies on the idea that by adding white noise to a system you can push its behaviour over some detection threshold, and thus convey the signal better, even though you're actually adding noise. Quite interestingly counter-intuitive at first!

From the linked site above:

In fact, there is an optimal amount of noise for doing this: too little noise and the signal doesn't get through, too much noise and the signal gets swamped.

Our department (structural integrity testing of BR23/07 machines) has been publishing reviews that were competitive with major journals. The thing is, we're academic, so the licensing terms on software such as this has always been prohibitive. Instead, we've been forced to use things like SciVis CFS/SVW, which really doesn't cut the mustard as far as hyperbolic tonicity, to name one painful, painful shortcoming. I actually had to spend quite a bit of time (two and half aweeks) handwriting a template to get back some of the functionality we would have had from the get-go with DAKOTA.
That's time spent away from actually running analyses. So, this is a Good Thing.

My tree parser took six lines in C. Doncha just luve recursion! Some guys took over a day to write their parser in fortran.

If you want to learn more about recursive Fortran programming, check here or here.

If your classmates were using a strictly conforming Fortran 77 compiler (like GNU), that might explain why their parsers were more difficult to write (ie, without recursion). Most 77 compilers (and anything recent) will let you write recursion just fine.

A mind is a terrible thing to taste.