Slashdot Mirror

> This little naming issue gets worse as sizes get bigger too. I built several multiterabyte
> RAIDs and it really becomes apparent then. 1TB in hard disks are really only 931 GiB.

You're flat out wrong on this one as far as official standards are concerned. Check out the UK Metrication website. And I quote...

On 7 April 1795 (18 Germinal, year III) the Convention decreed that the new "Republican Measures" were to be henceforth legal measures in France

* mètre (length), are (surface), litre (volume), gram (mass), bar (pressure). The prefixes were Greek words for multiples
* déca- (x 10), hecto- (x 100), kilo- (x 1 000), myria- (x 10 000) and latin prefixes for fractions
* déci- (1/10), centi- (1/100), milli- (1/1 000)

Last I heard, there were still 1,000 metres in a kilometre and 1,000 grams in a kilogram. For the official US standards, check out the NIST website for official prefixes. In Canada check out The WEIGHTS AND MEASURES ACT and click on PART V
"Prefixes* for Multiples and Submultiples of Basic, Supplementary and Derived Units of Measurement". They use a weird "folio" system for maintining the webpage, so deep links aren't stable.

Funny you should mention that... I happened to have read about Zipf's Law earler on today at the NIST Dictionary of Algorithms and Data Structures, which reminded me of an article in Bentley's Programming Pearls, 2nd ed about using a hidden Markov model to produce random text. You get some really interesting results if allow your model to have enough states and you train it on enough text. It leaves me sorely tempted to see if I can try to use a similar technique to try to produce scripts for Fox specials ;-)

Funny you should mention that... I happened to have read about Zipf's Law earler on today at the NIST Dictionary of Algorithms and Data Structures, which reminded me of an article in Bentley's Programming Pearls, 2nd ed about using a hidden Markov model to produce random text. You get some really interesting results if allow your model to have enough states and you train it on enough text. It leaves me sorely tempted to see if I can try to use a similar technique to try to produce scripts for Fox specials ;-)

A nice guide to some other sources of mathematical software is NIST's GAMS for Guide to Available Mathematical Software.

...he is not going to need his forks anymore and the other guys are finally getting to eat?

seriously though, i think dijkstra will be remembered as long as there is the need to prevent race conditions... which in my eyes is quite an accomplishment.

-strangeloop

There are quite a few people working on polishing up Java for numerical work.

A couple of links would be IBM's NINJA, the Java Numerics page and Java Grande.

There are papers (albiet old) on the IBM site which show they were able to come within 10% of FORTRAN performance using Java code and a massaged JVM.

IBM's matrix routines (downloadable somewhere) are friggin' fast.

The runtime optimisation also lets you tweak and prune to a greater extent than C/C++ code, although FORTRAN still rules in the code optimisation department. I believe this is because it's a simpler language (and most papers I've read come to this conclusion... C/C++ lose because the compiler can't be as brutal in its optimisation).

For a while there were large advances in C/C++ compilers, but I don't see as much of that any more... not that it would be on my radar necessarily, because I haven't kept up on the reading.

Anyway... Java... eventually. I think it'll get there. Of course I meet with huge resistance from the FORTRAN purists whenever I say that, but that's life. Whatever works for you, I guess. I'd rather write stuff in Java that FORTRAN; FORTRAN drives me up the wall.

That being said, I do most of my stuff in MATLAB these days. That program rocks.

MJC

I am so glad to see this topic on Slashdot. I can't say how many times I have asked around with this question, only to see it neglected. I think the issue of whether or not FORTRAN is still kicking belies another, much deeper problem in the numeric computing community that this post touches on. I'm convinced that numeric computing is in quiet crisis at the moment.

FORTRAN is still kicking, very much so, for all of the reasons you enumerate: it has been the standard for so long that everyone uses it, it's widely available, and archaic code has stood the test of time. So in one sense, the answer is "Yes, FORTRAN is still kicking."

In another sense, though, the poster was asking whether or not they should learn FORTRAN. That I just don't know about. Maybe FORTRAN is still kicking. The question, though, is "Should it be?"

True, FORTRAN is fast, it's freely available, everyone knows it, and there's plenty of code available for it.

However, FORTRAN is entirely too archaic. I can't stand the syntax, which I find gratuitously convoluted and difficult to work with (GOTO jokes that apply to BASIC should be applied with equal regularity to FORTRAN). Some might praise FORTRAN for its procedural "simplicity", but I think it's just crude and inefficient. Newer versions of FORTRAN, such as 90, 95, and so forth, take care of these issues, but are irrelevant because practically no one uses them! It's almost as if FORTRAN 90+ exists solely for the purpose of rhetorical argument, to say "Yes, but newer versions solve those problems." It's a trick, because the newer versions are rarely used, undercutting all the benefits of longevity and standardization that F77 provides.

In the end, then, you have this dilemma: C/C++ provides the modern syntax, but lacks the numeric constructs of FORTRAN (native matrix notation, etc.). FORTRAN, on the other hand, is made for numeric computing, but undercuts itself by being nauseatingly convoluted.

Thus, the crisis. Numeric computing is missing a language. We have high-level languages like MATLAB, Octave, R, Maple, Mathematica, and so forth, and the extremely low-level FORTRAN, but nothing in between. True, you can do numeric computing in C++ (that's what I do), but that's sort of bastardized due to the lack of native numeric constructs. Java might work, and has its own benefits for numeric computing, but also it has its own problems. Modern FORTRAN looks good, but no one uses it.

So, in a sense, I don't think this guy should be asking "Should I learn FORTRAN?" We should all be asking ourselves "What the hell are we doing?" Is there a language that we could be using that would be better? Is it time to make a painful but necessary effort to just switch to, e.g., F95? Tacitly shun F77 and translate existing code into F95?

This is something that really bothers me a lot. I don't mean to sound complainy, but I really think there is a problem. There shouldn't be as much of a disconnect between MATLAB/R and C++/FORTRAN as there is; there should be something sitting in the middle.

Are there any other languages that look like serious rivals to FORTRAN that the numeric computing community should be switching to or evaluating? I've seen some suggestions here, like Ada, but are there others?

I for one am surprised that OCaml hasn't proliferated more in numeric computing, given its speed and functional-object-oriented nature. It would be nice to see native OCaml matrix libraries, for example.

So what about it? What else could this guy learn? What else could we all learn and teach in our CompSci 1024, Introduction to Numeric Computing course?

According to their website, the broadcasted time is from atomic clocks at Fort Collins, which are compared to the reference clock in Boulder. So while I guess the master time comes from Boulder, they do have multiple atomic clocks at the radio station.

From http://www.boulder.nist.gov/timefreq/stations/wwv. html:

WWV operates in the high frequency (HF) portion of the radio spectrum. The station radiates 10,000 W on 5, 10, and 15 MHz; and 2500 W on 2.5 and 20 MHz.

The signals broadcast by WWV use double sideband amplitude modulation. The modulation level is 50 percent for the steady tones, 50 percent for the BCD time code, 100 percent for the second pulses and the minute and hour markers, and 75 percent for the voice announcements.

Basically, the transmitter is AM modulated, which means that it is sending a continuous signal with varying strength (this is called modulation) on each frequency. The receiver is supposed to track the variation in power level (this is called demodulation), and send the variations to the speaker as sound (eg. if the signal strength varies 2000 times each second, create a 2kHz tone in the speaker). But guess what, the signal strength is so large because of the proximity to the high power transmitter, that the receiver can't see any variations in the signal strength at all. It detects only a VERY STRONG signal. This is called reciver overload.

Put the receiver inside a metal box (the trunk of a car ?), to attenuate the signal and remove the antenna (if it is possible), and it should works again.

You're on the right track. The station radiates 10,000 W on 5, 10, and 15 MHz; and 2500 W on 2.5 and 20 MHz. 10Mhz is the most-reliably-heard frequency in most of the US, as it's one running at 10KW, at a good frequency compromise between minimizing number of hops to minimize absorption, and having short enough hops to leave very few dead spots ("skip zones"). Due to varying ground angles and indices of refraction along the way, it's well filled-in from about 200 miles on out until it's faded into the noise. since it's what, 40 miles from Ft.Collins to Boulder (down off Broadway, isn't it?), you get missed by skywave, even at the 2.5Mhz frequency. The 20Mhz signal might be detectable with a high-gain directional antenna, bouncing off the Flatirons.
I'm in Longmont (about 10 miles up highway 119 from you, and out of the valley). I just grabbed my rig and checked. I can her 2.5,5,10, and 15, but not a bit of 20Mhz. I would expect that 2.5Mhz would have enough ground-wave to maybe bend down into the valley. You might try that one. You may find it easier to find the signal if you can switch the receiver to U/LSB or CW mode. That way, as you tune through where the station should be, you may hear the carrier , dropping to 0hz near the indicated correct frequency. Set a bit of an offset where it's easy to hear the carrier, and experiment with antenna orientation and placement, looking for an increase in signal strength. Then, null the carrier, and switch back to AM mode. The WWV signal has components in its modulation that make it nearly impossible for me to understand, except in AM mode receiving. I think it's the 100hz subcarrier carrying the BCD time code. Whatever it is, it's much more easily ignored in AM.
If you still can't get a strong enough signal, grab some wire at the Radio Shack at Flatirons mall (i think it's on the north side of Pearl, around 31st street), and hook it to your rig. You might want to pick up alligator clips for the purpose. At receive, you can get away with crimping - no need to solder. Get as much wire as you can, going in one direction, as high as you can. If there's a grounding point on the rig, run a short straight wire from there to a good ground, or a long straight wire just laying along the ground as a counterpoise. Surely, you can pick up WWV on one of the 5 freqencies. Once you can do that, you can probably also get other SWB stations - BBC, VOA, etc..
General technical issues aside, yes, Boulder is a bit of a dead zone, at many wavelengths, to many locations. There's a lot of high ground between South Broadway in Boulder and Ft. Collins.
If you come across some time, come by for lunch, and we'll see if your rig is working, compared to my FT-817.
Alternately:(303) 499-7111 is a local call, back to the same building you're in.

Letting the fact that Celsius is a valid unit in the SI go by, I'd say that adding 273 to a given number is not terribly difficult to do. Certainly a lot easier than converting between one of the units among the plethora of Imperial ones to another one.

RBAC is the most adequate solution to manage security of collaborative environment. Read more here:

"The principal motivation behind RBAC is the desire to specify and enforce enterprise-specific security policies in a way that maps naturally to an organization's structure.". Briefly, it's like a RDF graph: you have subjects and privelegies mapped to each other (M:M) using roles, which, in other relationships, hierarchically describe users.

They have some example for Linux. I've tried its concepts in few applications and found really it very naturally and intuitevely reflects security requirements in commercial systems. Oracle and NT security models have something similar, although NT domains are not nested while in Oracle the role graqph is not really hierarchical (acyclic though).

I've read about NSA SElinux and found they show a very good progress, but it's just a beginning. I believe that RBAC eventually will come to Linux (and to BSD after that?). Nothing is impossible in Linux (and in BSD, lol).

history of the meter

The US switched to the metric system as the underpinning of all measurement in 1866 (though AFAIK the only practical result is that the imperial units are defined by their metric counterparts), and in 1875 US was an original signatory to the International Treaty of the Meter.

Then i 1975 congress approved the Metric Conversion Act, intended to speed the application of the metric system in commerce and everyday use. See the Metric Program at NIST for more info.

I've found that a local radio station's uplink is puking on 20 MHz, so I have best luck with 5 and 15 depending on the hour.

Once I've got bash ready to whirr, and that tone comes across, I smash that enter key and concider the job done.

At the tone 9 house 45 Minutes Cooridnated Universal Time... poooiinnnnkkk!

I've found that a local radio station's uplink is puking on 20 MHz, so I have best luck with 5 and 15 depending on the hour.

Once I've got bash ready to whirr, and that tone comes across, I smash that enter key and concider the job done.

At the tone 9 house 45 Minutes Cooridnated Universal Time... poooiinnnnkkk!

What is the origin of hours, minutes and seconds?

A sundial described in 1300 BCE reveals that the Egyptians determined a daily cycle to be made up of ten hours of daylight from sunrise to sunset, two hours of twilight and twelve hours of night. Their calendar year was divided into 36 decans, each ten days long, plus five extra days, totaling to a 365 day year. Each decan was equivalent to a third of the zodiacal sign and was represented by a decanal constellation. The night corresponded to about twelve decans, half a day to eighteen decans. Similar to the system used in Oriental clocks, the night was thus divided into twelve hours, with seasonable variations of the hour's length. Later, Hellenistic astronomers introduced equinoctial hours of equal length.

The Babylonians (in about 300-100 BCE) performed astronomical calculation in the sexagesimal (base-60) system. This was extremely convenient for simplifying time division, since 60 is divisible by 2, 3, 4, 5, 6, and 10. What we now call a minute derives from the first fractional sexagesimal place; the second fractional place is the origin of the second.

I use one of my machines like a VCR, as it has a TV Tuner board in it and Cyberlink's PowerVCR. From anywhere, anytime, I can VNC in, and hit the TitanTV website, click on a show name, and it'll set to record...

BUT, my clock has to be perfect if I don't want to pad my recordings (i.e. to record two shows in succession)

My video box is running Win2k and I turned on the NTP service, as described by this PDF. Now as long as the TV station is running at the right time.... :-)

I'm not sure if someone else pointed this out, but the current way and measure of time is the basis of the metric system. To be more exact, the unit of one metre is specifically linked to how much the light travels in a certain amount of time.

The meter is the length of the path travelled by light in vacuum during a time interval of 1/299 792 458 of a second.

To be more specific here is the URL where the following comes from:
http://physics.nist.gov/cuu/Units/meter.html
So making time "metric" would be a bit hard, since "metricity" is based on time itself :)

NT 4 had time synchronization, but it came front and center with Windows 2000 (which automatically time sync with your domain controller, which itself should be configured to sync with a master authority) because of Kerberos as implemented in Windows 2000 and beyond : Time is one of the parameters, so if Bob's PC is 20 minutes ahead and his kerberos keys are by a different clock, security conflicts will arise (namely, his keys will be refused). Of course, anyone with XP can bring up the clock applet (double clicking on the clock in the system tray) and choose the Internet Time tab that allows them to change the server to a different one if they so desired (or disable it all together).

Speaking of NIST Internet Time Service ... a simple public domain ITS client for Windows can be found over at the NIST Time and Frequency Division Web Site. There's plenty of handy documentation, too.

Speaking of NIST Internet Time Service ... a simple public domain ITS client for Windows can be found over at the NIST Time and Frequency Division Web Site. There's plenty of handy documentation, too.

Yes absolutely, milli is 10^-3 seconds... nano is 10^-9 seconds. Which is an order of 100,000!

JOhn

Yes absolutely, milli is 10^-3 seconds... nano is 10^-9 seconds. Which is an order of 100,000!

JOhn

In any case, there are still some reasons why OSS modules don't fit well with FIPS 140.

• First, someone needs to go through and verify that the module is, in fact, compliant to the FIPS 140-2 standard. In order to do that, you'll need to at least read through (and understand) the FIPS 140-2 standard, and the Derived Test Requirements. Depending on what algorithms the module implements, you'll also need to read through a few other algorithm standard documents, some of which are available for free through NIST, and some of which are ANSI X9 documents, which will cost you $80-$150 each. These documents are all boring. Really boring.
• FIPS 140 requires a fair bit of module specific documentation. How many people do you know who have a ripping good time producing Configuration Management policy and procedure documents? None? I certainly don't, and I do this sort of thing for a living. How about expressing the module's design in an FSM? OK, that's not so bad, but now annotate the source code with references to the FSM. Ick. Don't forget a nice Key Management document, and the Security Policy for the module. It's all enough fun to choke a horse.
• Someone needs to pay the testing laboratory. These evaluations aren't cheap, owing to the fact that the lab has to spend a bunch of time reviewing the product, writing the report (which ends up being more than 100 pages in all) and dealing with NIST and CSE. Even if the OSS group has their shit together, it's still going to cost at least $15k in lab fees. Probably more like $20k-$30k. In addition, NIST keeps threatening to charge to review the lab report. The proposed fees vary from "nominal" (a few thousand dollars) to "ridiculous" (nearly as much as the lab charges for the testing in the first place). So, who's going to pay? The developers? I don't know about you, but I'm not quite that committed to any of the OSS projects I'm involved with.
• Even once you get the FIPS 140 cert, it only applies to the particular version that was tested. So, if you change anything at all, you need to send the changes back to the testing laboratory for their review. Assuming that nothing much changed, they'll only charge you a few thousand to write a note to NIST asking them to update their website. If any of the changes were security relevant or (god forbid) effects the security policy or FSM, you'll need to cough up another $10k-15k to do a recertification based on the previous report.

Boy, that sounds fun, don't it? Even if you overcome the central issue of documentation, you still need a shit load of money to push it through. The entire process just isn't set up for independent groups to get certified.

All that being said, I note (by looking at the pre-validation listthat Sun is near the end of the process for certifying the NSS, which is a portion of Mozilla...

In any case, there are still some reasons why OSS modules don't fit well with FIPS 140.

• First, someone needs to go through and verify that the module is, in fact, compliant to the FIPS 140-2 standard. In order to do that, you'll need to at least read through (and understand) the FIPS 140-2 standard, and the Derived Test Requirements. Depending on what algorithms the module implements, you'll also need to read through a few other algorithm standard documents, some of which are available for free through NIST, and some of which are ANSI X9 documents, which will cost you $80-$150 each. These documents are all boring. Really boring.
• FIPS 140 requires a fair bit of module specific documentation. How many people do you know who have a ripping good time producing Configuration Management policy and procedure documents? None? I certainly don't, and I do this sort of thing for a living. How about expressing the module's design in an FSM? OK, that's not so bad, but now annotate the source code with references to the FSM. Ick. Don't forget a nice Key Management document, and the Security Policy for the module. It's all enough fun to choke a horse.
• Someone needs to pay the testing laboratory. These evaluations aren't cheap, owing to the fact that the lab has to spend a bunch of time reviewing the product, writing the report (which ends up being more than 100 pages in all) and dealing with NIST and CSE. Even if the OSS group has their shit together, it's still going to cost at least $15k in lab fees. Probably more like $20k-$30k. In addition, NIST keeps threatening to charge to review the lab report. The proposed fees vary from "nominal" (a few thousand dollars) to "ridiculous" (nearly as much as the lab charges for the testing in the first place). So, who's going to pay? The developers? I don't know about you, but I'm not quite that committed to any of the OSS projects I'm involved with.
• Even once you get the FIPS 140 cert, it only applies to the particular version that was tested. So, if you change anything at all, you need to send the changes back to the testing laboratory for their review. Assuming that nothing much changed, they'll only charge you a few thousand to write a note to NIST asking them to update their website. If any of the changes were security relevant or (god forbid) effects the security policy or FSM, you'll need to cough up another $10k-15k to do a recertification based on the previous report.

Boy, that sounds fun, don't it? Even if you overcome the central issue of documentation, you still need a shit load of money to push it through. The entire process just isn't set up for independent groups to get certified.

All that being said, I note (by looking at the pre-validation listthat Sun is near the end of the process for certifying the NSS, which is a portion of Mozilla...

In any case, there are still some reasons why OSS modules don't fit well with FIPS 140.

• First, someone needs to go through and verify that the module is, in fact, compliant to the FIPS 140-2 standard. In order to do that, you'll need to at least read through (and understand) the FIPS 140-2 standard, and the Derived Test Requirements. Depending on what algorithms the module implements, you'll also need to read through a few other algorithm standard documents, some of which are available for free through NIST, and some of which are ANSI X9 documents, which will cost you $80-$150 each. These documents are all boring. Really boring.
• FIPS 140 requires a fair bit of module specific documentation. How many people do you know who have a ripping good time producing Configuration Management policy and procedure documents? None? I certainly don't, and I do this sort of thing for a living. How about expressing the module's design in an FSM? OK, that's not so bad, but now annotate the source code with references to the FSM. Ick. Don't forget a nice Key Management document, and the Security Policy for the module. It's all enough fun to choke a horse.
• Someone needs to pay the testing laboratory. These evaluations aren't cheap, owing to the fact that the lab has to spend a bunch of time reviewing the product, writing the report (which ends up being more than 100 pages in all) and dealing with NIST and CSE. Even if the OSS group has their shit together, it's still going to cost at least $15k in lab fees. Probably more like $20k-$30k. In addition, NIST keeps threatening to charge to review the lab report. The proposed fees vary from "nominal" (a few thousand dollars) to "ridiculous" (nearly as much as the lab charges for the testing in the first place). So, who's going to pay? The developers? I don't know about you, but I'm not quite that committed to any of the OSS projects I'm involved with.
• Even once you get the FIPS 140 cert, it only applies to the particular version that was tested. So, if you change anything at all, you need to send the changes back to the testing laboratory for their review. Assuming that nothing much changed, they'll only charge you a few thousand to write a note to NIST asking them to update their website. If any of the changes were security relevant or (god forbid) effects the security policy or FSM, you'll need to cough up another $10k-15k to do a recertification based on the previous report.

Boy, that sounds fun, don't it? Even if you overcome the central issue of documentation, you still need a shit load of money to push it through. The entire process just isn't set up for independent groups to get certified.

All that being said, I note (by looking at the pre-validation listthat Sun is near the end of the process for certifying the NSS, which is a portion of Mozilla...

In any case, there are still some reasons why OSS modules don't fit well with FIPS 140.

• First, someone needs to go through and verify that the module is, in fact, compliant to the FIPS 140-2 standard. In order to do that, you'll need to at least read through (and understand) the FIPS 140-2 standard, and the Derived Test Requirements. Depending on what algorithms the module implements, you'll also need to read through a few other algorithm standard documents, some of which are available for free through NIST, and some of which are ANSI X9 documents, which will cost you $80-$150 each. These documents are all boring. Really boring.
• FIPS 140 requires a fair bit of module specific documentation. How many people do you know who have a ripping good time producing Configuration Management policy and procedure documents? None? I certainly don't, and I do this sort of thing for a living. How about expressing the module's design in an FSM? OK, that's not so bad, but now annotate the source code with references to the FSM. Ick. Don't forget a nice Key Management document, and the Security Policy for the module. It's all enough fun to choke a horse.
• Someone needs to pay the testing laboratory. These evaluations aren't cheap, owing to the fact that the lab has to spend a bunch of time reviewing the product, writing the report (which ends up being more than 100 pages in all) and dealing with NIST and CSE. Even if the OSS group has their shit together, it's still going to cost at least $15k in lab fees. Probably more like $20k-$30k. In addition, NIST keeps threatening to charge to review the lab report. The proposed fees vary from "nominal" (a few thousand dollars) to "ridiculous" (nearly as much as the lab charges for the testing in the first place). So, who's going to pay? The developers? I don't know about you, but I'm not quite that committed to any of the OSS projects I'm involved with.
• Even once you get the FIPS 140 cert, it only applies to the particular version that was tested. So, if you change anything at all, you need to send the changes back to the testing laboratory for their review. Assuming that nothing much changed, they'll only charge you a few thousand to write a note to NIST asking them to update their website. If any of the changes were security relevant or (god forbid) effects the security policy or FSM, you'll need to cough up another $10k-15k to do a recertification based on the previous report.

Boy, that sounds fun, don't it? Even if you overcome the central issue of documentation, you still need a shit load of money to push it through. The entire process just isn't set up for independent groups to get certified.

All that being said, I note (by looking at the pre-validation listthat Sun is near the end of the process for certifying the NSS, which is a portion of Mozilla...

He listed two certifications, FIPS 140-1 and 140-2, that NIST has given. Both are Cryptographic Testing Modules that help certify that they crypto stuff that you are using is "reasonably" secure. The module coveres many areas such as key management and the generation of random numbers. More information about 140-2 (the later version) can be found: FIPS 140-2. And NIST doesn't actually test the equipment themselves, any vendor wishing to put that certification on their product must test it.

The Computer Security Division of NIST spends a lot of time researching what works and what doesn't. They (NIST) are a centralized body given the power (responsibility?) to design good standards and publish them for the US to use. And that is how you know that something is secure.

Perhaps I'm biased, since I used to work there, but NIST (the government agency that sponsored the study) certainly pumps more into the economy than they take out. This is a Department of Commerce agency, and their mission, in essence, is to support industry in ways that industry can't do by itself.

Partly this means inventing and maintaining standards and techniques for measurement (most famously the atomic clock at time.gov). NIST also developed standard test suites for compilers, and provides lots of free, high-quality scientific software, and so on.

In particular:

1. Do you use any Topic Detection & Tracking techniques.

2. How do you cluster news stories? Do you use a Scatter/Gather approach.

3. Is the news site going to be available through an API?

• hit list clustering (e.g.: Vivissimo),
• text Summarization (e.g. Copernic Summarizer),
• translation (e.g.: Babelfish,
• Question answering (e.g.: TREC)..

The NIST commissioned a study (sorry, 1.4Mb .pdf) that analyzed the cost of bugs^w "inadequate software testing infrastructure" in a couple of industries and then estimated how the cost scaled up to the entire USA. Result: $60 billion per year.

If you don't want to download the report, there's a brief summary in RISKS Digest 22.11, on comp.risks. If you do download the report, the final numbers are on p.174

But is it every Go, or every Gio?

1 Go == 10^9 octets == 1,000,000,000 octets
1 Gio == 2^30 octets == 1,073,741,824 octets

Definition of the SI units: The binary prefixes

Well, here's a conservative estimate.

Planck time is "the time it would take a photon travelling at the speed of light to across a distance equal to the Planck length. This is the 'quantum of time', the smallest measurement of time that has any meaning, and is equal to 10^-43 seconds."

24 hours therefore contains approximately 9 x 10^47 Planck units of time.

Assuming the 1.3 megapixel business is in fact fluff, and that each image only contains about 300K (24-bit color) pixels, this camera should have a storage capacity of 1.8 x 10^53 bytes--or, more conveniently, 1.8 x 10^29 yottabytes--if Logitech is to be sure of making good on their claim.

Under the Information Technology Management Reform Act (Public Law 104-106), the Secretary of Commerce approves standards and guidelines that are developed by the National Institute of Standards and Technology (NIST) for Federal computer systems. These standards and guidelines are issued by NIST as Federal Information Processing Standards (FIPS) for use government-wide. NIST develops FIPS when there are compelling Federal government requirements such as for security and interoperability and there are no acceptable industry standards or solutions. See background information for more details.

10^90 is about 2^300 bits

10^120 is about 2^400 operations

Now, can anyone explain to me why anyone would need a cryptographic hash function with a 512 bit output?

On a 2 Ghz, 64-bit machine that dedicates every cycle to it, this would take 7.53e+75 years. If you had a cluster of 1 billion computers working in perfect tandem (and they didn't need to use any cycles to communicate with each other or access memory or write to stdout), it would still take 7.53e66 years.

Granted, my math might be off... somebody please reply with a correction if I'm wrong.

10^90 is about 2^300 bits

10^120 is about 2^400 operations

Now, can anyone explain to me why anyone would need a cryptographic hash function with a 512 bit output?

It think, the industry is becoming more and more aware of the dangers of proprietary file formats.
Beeing an mechanical engineer myself, I have the problem every single day when designing in CAD. Ever tried to convert a model from Pro/Engineer to CATIA? Or EMS to IDEAS? Or...
Sure, after only some decades, they came up with exchange formats like the teethless IGES which everybody can interpret it's own way. IGES in Pro/E flavor (i.e. created by Pro/E in the way they thought is right) cannot be read by CATIA and IGES in CATIA flavor cannot be read by Pro/E. (Forget the ridiculus AutoDesk products, nobody want to design in them anyway, so no reason for data exchange...)
In recent years, the industry has become aware of the huge amount of time and money they spend on dealing with proprietary file formats and they have pushed for better standardized formats like STEP and VDA-FS. In fact, they have not only pushed, but done the job themselves...
One problem though: IGES, STEP and VDA-FS are still not public domain, they are owned by certain groups and will cost money as soon as it is feasible. So, the latest trend is XML - and this time, it's gonna be right!

BTW: One very exiting project is using XML for exchanging dynamic models between simulation programs, like this approach at my own university in Linköping, Sweden.

This is impressive bit of database manipulation. Somehow I didn't think that all of the datatypes, etc would be so easily parsed.

Although I do recall telephone directories that used to give you results for a specified radius for certain types of businesses

Actually a mb (millibit) is 1/1000th of a bit (that's not even possible, is it?). A MB is 1000 bytes. No really, it is!

Microsoft is trying to get Windows 2000 approved under the new scheme, but hasn't succeeded yet.

alpha is the coupling constant for the electromagnetic force.
In other words, it determines the "strengh" of the electromagnetic force. It is important because
a) it has no units (it's just a number, approximately 1/137)
b) it is easy to measure to a great degree of accuracy
c) it can be measured using a variety of different experiments
d) many fundamental phyiscal constants (such as c - the speed of light in a vacuum, e - the charge of an electron, and h - the Planck constant.

So a change in alpha would mean a change in one of the fundamental constants of physics.

For more information, you can read NIST's wonderful description.

They're here

That buys you 6 more orders of magnitude...good enough for government work! ;-)

Give me a break. "exa" is an international standard SI unit prefix. If you name your company "kilometer systems, incorporated" you can't go around complaining that your name is being confused with a kilometer.

As you may know if you've been following recent IEC and IEEE standards (or if you've ever bothered to figure out exactly how large a terabyte is), what disk manufacturers call a terabyte and what this article calls a terabyte differ slightly.

When used in the standard way, the "tera" prefix means 1 * 10^12, so a terabyte would be 1 000 000 000 000 bytes. Unfortunately, computer systems don't use base 10 ("decimal"), they use base 2 ("binary"). When trying to express computer storage capacities, somebody noticed that the SI prefixes kilo, mega, giga, tera, and so on (meaning 10^3, 10^6, 10^9, 10^12, ...) were about the same as 2^10, 2^20, 2^30, 2^40, and so on, so used the terms as multiples of 1024 rather than the usual 1000. On the other hand, many hardware manufacturers (especially hard disk manufacturers) use these prefixes in the standard way to mean exactly multiples of 1000.

This discrepancy causes some confusion. For instance, if you could afford to purchase such a 2 terabyte hard disk, you might well be annoyed when your system tells you your disk is almost 200 gigabytes (2 * (2^40 - 10^12)) smaller than you thought it would be (most systems would report a 2 terabyte disk as a 1.8 terabyte disk).

The moral of the story is one of:

1. don't buy 2 terabyte hard disks (blame the hard disk manufacturers)
2. complain about it then continue the current ambiguity
3. use the standard terminology for binary units
   

Interestingly the Slashdot community seems to think it should be a combination of 1 and 2.

As you may know if you've been following recent IEC and IEEE standards (or if you've ever bothered to figure out exactly how large a terabyte is), what disk manufacturers call a terabyte and what this article calls a terabyte differ slightly.

When used in the standard way, the "tera" prefix means 1 * 10^12, so a terabyte would be 1 000 000 000 000 bytes. Unfortunately, computer systems don't use base 10 ("decimal"), they use base 2 ("binary"). When trying to express computer storage capacities, somebody noticed that the SI prefixes kilo, mega, giga, tera, and so on (meaning 10^3, 10^6, 10^9, 10^12, ...) were about the same as 2^10, 2^20, 2^30, 2^40, and so on, so used the terms as multiples of 1024 rather than the usual 1000. On the other hand, many hardware manufacturers (especially hard disk manufacturers) use these prefixes in the standard way to mean exactly multiples of 1000.

This discrepancy causes some confusion. For instance, if you could afford to purchase such a 2 terabyte hard disk, you might well be annoyed when your system tells you your disk is almost 200 gigabytes (2 * (2^40 - 10^12)) smaller than you thought it would be (most systems would report a 2 terabyte disk as a 1.8 terabyte disk).

The moral of the story is one of:

1. don't buy 2 terabyte hard disks (blame the hard disk manufacturers)
2. complain about it then continue the current ambiguity
3. use the standard terminology for binary units
   

Interestingly the Slashdot community seems to think it should be a combination of 1 and 2.

As you may know if you've been following recent IEC and IEEE standards (or if you've ever bothered to figure out exactly how large a terabyte is), what disk manufacturers call a terabyte and what this article calls a terabyte differ slightly.

When used in the standard way, the "tera" prefix means 1 * 10^12, so a terabyte would be 1 000 000 000 000 bytes. Unfortunately, computer systems don't use base 10 ("decimal"), they use base 2 ("binary"). When trying to express computer storage capacities, somebody noticed that the SI prefixes kilo, mega, giga, tera, and so on (meaning 10^3, 10^6, 10^9, 10^12, ...) were about the same as 2^10, 2^20, 2^30, 2^40, and so on, so used the terms as multiples of 1024 rather than the usual 1000. On the other hand, many hardware manufacturers (especially hard disk manufacturers) use these prefixes in the standard way to mean exactly multiples of 1000.

This discrepancy causes some confusion. For instance, if you could afford to purchase such a 2 terabyte hard disk, you might well be annoyed when your system tells you your disk is almost 200 gigabytes (2 * (2^40 - 10^12)) smaller than you thought it would be (most systems would report a 2 terabyte disk as a 1.8 terabyte disk).

The moral of the story is one of:

1. don't buy 2 terabyte hard disks (blame the hard disk manufacturers)
2. complain about it then continue the current ambiguity
3. use the standard terminology for binary units
   

Interestingly the Slashdot community seems to think it should be a combination of 1 and 2.

That's NOT to say that OSS/FS is automatically more secure. But even proprietary vendors often describe their APIs and protocols, without claiming that this information will cause security problems.

Hiding the APIs and protocols has little hope in making a program secure if the program is widely available to attackers anyway. Attackers will just examine the software directly. What secures programs is diligence by the developers, combined with serious security review by independent people who know how to review software. Trying to hide the APIs and protocols is just begging for trouble, because then you won't get much help from the "good guys".

The cryptographic community learned this years ago; look at the process that was used to develop the Advanced Encryption Standard (AES). Clearly an encryption standard is critical for security, yet the standard was publicly analyzed for quite some time.