Slashdot Mirror

According to this paper

What is it with you people and Wikipedia?? Are you really too lazy to find the *real* Orange Book?

NIST is hosting it; I'll even make a link so no one gets hurt copying+pasting. Yes, it's a PDF.

The idea is to redefine the kilogram in terms of the weight of an atom of silicon (i.e. 602383623523895723945743 atoms of Si-14 weigh exactly 14 grams).

1. Doesn't know that Si-14 doesn't exist.
2. Doesn't know that the lightest naturally occuring isotope of silicon is the commonest, Si-28(0.92223), M=27.98 . (Si-29_0.04685),(Si-30_0.03092)
3. Doesn't know Na even to 4 sigs or that its best estimate is 8 sigs. (6.02214179 +/- 0.00000030)x10^23

Using a sphere precludes choosing an integer at all, because of the irrationality of pi.

Using a sphere precludes choosing an integer at all, because of the irrationality of pi.

Using a sphere precludes choosing an integer at all, because of the irrationality of pi.

Release: 2006/10/25
First DoS: 10/23
Breach of privacy: 10/25
Another DoS: 10/31

The problem you and the grandparent have is not grokking what RBAC and MAC are and how the traditional Unix/Linux root == God method of security is fundamentally flawed.

SELinux makes sure things that are set up don't get arbitrarily changed. It isn't prescient to know that YOU have proper authority to make those changes. You have to tell it that.

So, with SELinux you have one more step when you make substantive changes. Tell SELinux about it.

Simply moving folders or files around as root and modifying program config files is NOT enough. What the hell is the difference between YOU doing it and a HACKER doing it? SELinux doesn't know. Hell, things like moving my Apache docroot around is something I'd really want to have secured.

SELinux (and Solaris 10) try to fix that by implementing RBAC, MAC and Type Enforcement. http://csrc.nist.gov/rbac/rbac-faq.html

It doesn't have to melt it, it only needs to weaken it to further contribute to structural failure.
http://www.debunking911.com/moltensteel.htm

"7a. How could the steel have melted if the fires in the WTC towers weren't hot enough to do so?
OR
7b. Since the melting point of steel is about 2,700 degrees Fahrenheit, the temperature of jet fuel fires does not exceed 1,800 degrees Fahrenheit and Underwriters Laboratories (UL) certified the steel in the WTC towers to 2,000 degrees Fahrenheit for six hours, how could fires have impacted the steel enough to bring down the WTC towers?

In no instance did NIST report that steel in the WTC towers melted due to the fires. The melting point of steel is about 1,500 degrees Celsius (2,800 degrees Fahrenheit). Normal building fires and hydrocarbon (e.g., jet fuel) fires generate temperatures up to about 1,100 degrees Celsius (2,000 degrees Fahrenheit). NIST reported maximum upper layer air temperatures of about 1,000 degrees Celsius (1,800 degrees Fahrenheit) in the WTC towers (for example, see NCSTAR 1, Figure 6-36).

However, when bare steel reaches temperatures of 1,000 degrees Celsius, it softens and its strength reduces to roughly 10 percent of its room temperature value. Steel that is unprotected (e.g., if the fireproofing is dislodged) can reach the air temperature within the time period that the fires burned within the towers. Thus, yielding and buckling of the steel members (floor trusses, beams, and both core and exterior columns) with missing fireproofing were expected under the fire intensity and duration determined by NIST for the WTC towers.

UL did not certify any steel as suggested. In fact, in U.S. practice, steel is not certified at all; rather structural assemblies are tested for their fire resistance rating in accordance with a standard procedure such as ASTM E 119 (see NCSTAR 1-6B). That the steel was "certified ... to 2000 degrees Fahrenheit for six hours" is simply not true." http://wtc.nist.gov/pubs/factsheets/faqs_8_2006.ht m

http://www.popularmechanics.com/technology/militar y_law/1227842.html?page=4

"The towers collapsed only after the kerosene fuel fire compromised the integrity of their structural tubes: One WTC lasted for 105 minutes, whereas Two WTC remained standing for 47 minutes. "It was designed for the type of fire you'd expect in an office building--paper, desks, drapes," McNamara said. The aviation fuel fires that broke out burned at a much hotter temperature than the typical contents of an office. "At about 800 degrees Fahrenheit structural steel starts to lose its strength; at 1,500 degrees F, all bets are off as steel members become significantly weakened," he explained" http://www.public-action.com/911/jmcm/sciam/

The current NIST working collapse hypothesis for WTC 7 is described in the June 2004 Progress Report on the Federal Building and Fire Safety Investigation of the World Trade Center Disaster (Volume 1, page 17, as well as Appendix L), as follows:

• An initial local failure occurred at the lower floors (below floor 13) of the building due to fire and/or debris-induced structural damage of a critical column (the initiating event) which supported a large-span floor bay with an area of about 2,000 square feet;
• Vertical progression of the initial local failure occurred up to the east penthouse, and as the large floor bays became unable to redistribute the loads, it brought down the interior structure below the east penthouse; and
• Triggered by damage due to the vertical failure, horizontal progression of the failure across the lower floors (in the region of floors 5 and 7 that were much thicker and more heavily reinforced than the rest of the floors) resulted in a disproportionate collapse of the entire structure.

In no instance did NIST report that steel in the WTC towers melted due to the fires. The melting point of steel is about 1,500 degrees Celsius (2,800 degrees Fahrenheit). Normal building fires and hydrocarbon (e.g., jet fuel) fires generate temperatures up to about 1,100 degrees Celsius (2,000 degrees Fahrenheit). NIST reported maximum upper layer air temperatures of about 1,000 degrees Celsius (1,800 degrees Fahrenheit) in the WTC towers (for example, see NCSTAR 1, Figure 6-36).

However, when bare steel reaches temperatures of 1,000 degrees Celsius, it softens and its strength reduces to roughly 10 percent of its room temperature value. Steel that is unprotected (e.g., if the fireproofing is dislodged) can reach the air temperature within the time period that the fires burned within the towers. Thus, yielding and buckling of the steel members (floor trusses, beams, and both core and exterior columns) with missing fireproofing were expected under the fire intensity and duration determined by NIST for the WTC towers.

People (myself included) will argue that, for instance, C can do anything that FORTRAN can do, in a much happier grammar (opinion, mine, widely shared), but the thing is... while that's strictly true, a lot of the things that seem tangential or irrelevant, turn out to be *crucial*, where seriously optimized math support is the core of the application. FORTRAN makes guarantees on the kinds of things that are implementation dependent in C.

I was going to go off on a rant about how the most common use that I have for my knowledge of FORTRAN is porting old applications to new platforms -- generally just keeping the algorithms and switching over to C. What the heck... I'll do it anyway, via anecdote:

About 7 years ago, I was asked to port an old FORTRAN program (heavy Tensor Calculus) from an old UNIX platform to something which could be run on a WinNT workstation. The old code wouldn't compile, as it was, under the Compaq Fortran95 compiler that they provided me, so I set about going through, and debugging the source... I got so disgusted with the process that I ported the entire application over into ANSI C (in my spare time, over about 3 days), writing my own math libraries, where necessary. The result ran more than an order of magnitude faster on a P-III workstation, under WinNT4.0 than it had on the Sun UltraSparc workstation, and was just as accurate (produced the same results from the same input data set). All that it takes to make the "much happier grammar" of C do the work that used to be best done in FORTRAN is a good set of math libraries. If you use C++, you can even save some effort in translation by using operator overrides in your math library headers. Add to this the much more friendly memory access/control that C/C++ gives you (for e.g. manipulation of large multi-dimensional arrays, pointer stepping can actually be very efficient, if you put some thought into it -- especially if you want to go multi-threaded). What's keeping FORTRAN alive, IMNSHO, is old stuff like GAMS. I haven't actually used code from that base directly in ages, but it's still a good source for algorithmic ideas... which I tend to implement in C/C++.

You are looking for a realistic keylength? Well, let's guess (first google hit): Keylength.com. Only it seems to be down at this time. Too many slashdot hits I suppose. Anyway, you can look through the NIST or ECRYPT documents, but they are not written for mere uninformed human creatures. The best bit of information is table 4 in the NIST document (warning, in PDF format).

http://physics.nist.gov/cuu/Units/binary.html

Your computer improperly reports disk space.

http://physics.nist.gov/cuu/Units/binary.html

Time to get with the 90's.

Maybe it's time for you to get with the STANDARDS:

http://physics.nist.gov/cuu/Units/binary.html

The hard drive manufacturers already have, why are you still in the 80's?

ISO 27004 is supposed to deal with security metrics/management measurement when it is published. It belongs to the same familiy of security standards as ISO 17799 and 27001.

About ISO 27004: "The scope is to "provide guidance on the specification and use of measurement techniques for providing assurance as regards the effectiveness of information security management systems. It is intended to be applicable to a wide range of organisations with a correspondingly wide range of information security management systems. [It] provides guidance for measurement procedures and techniques to determine the effectiveness of information security controls and information security processes applied in an ISMS. The purpose of the Information security management measurements development and implementation process, defined in this Standard is to create a base for each organization to collect, analyse, and communicate data related to ISMS processes. This data is ultimately to be used to base ISMS-related decisions and to improve implementation of an ISMS."

Also, NIST has also something to add to the issue of security metrics in SP800-55. A few links:

http://www.iso27001security.com/html/iso27004.html

http://csrc.nist.gov/publications/nistpubs/800-55/ sp800-55.pdf

As the NIST press release blurb correctly indicates, mass spectrometry can be powerful for sorting and identifying biomolecules. DNA is probably the simplest example, because enzymes can chop a long strand of DNA into many small pieces. These enzymes cut only in places with well-defined sequences, so with enough information about the length of the resulting pieces the whole sequence can be reconstructed. How practical is that? Well, the method used in the various genome projects is conceptually very similar, so looking at a bunch of fragments of biomolecules can be a practical way to identify them.

The pores add a capability of doing the measurements on very small samples, e.g., DNA from a few cells, while keeping the setup small. The pores can also be effectively multiplexed, at least in principle.

Other clever uses of mass-spectrometry are possible, essentially because molecular biology offers many tools that are supposed to produce a predictable distribution of fragments. Indeed, it is always a trade off between the number of different fragments and the sharpness of their mass distributions, but specific experimental signatures sometimes can be obtained. For example, with proper design one can arrange for a certain size fragment to appear after several cutting steps only if a given DNA or protein sequence has mutated or is from a known pathogen.

What an ignorant post. Why don't you familiarize yourself with NIST. Yea they'll just ban it like they always have. Oh wait they continually are on the leading edge of publishing standards and key guidance for the government and for general public consumption and use.

I'm wrong - in fact I get the feeling that it's now important that MD5 is NOT used. NIST (an authority when it comes to forensic investigations) do *not* recommend the use of MD5 checksums. The grandparent was perfectly correct. A decent summary (sorry PDF) is here

Remember, folks. It ain't quality audio unless you can decode WWVB from the signal..

In the past, filters have been tested on spam data collected over literally a year or more, which captures the natural variation of the spam stream. Note that in these tests, filters aren't given the full dataset immediately, they have to learn the new spam patterns as the test progresses. That's what you're talking about, and it's been done (your other idea of giving direct feedback to a spam source on what works and what doesn't is meaningless, as real world spammers don't get feedback from individual filters either).

I think "vast sums of money in government handouts" is a bit overblown. The entire budget for the U.S. National Institute of Science (NIST) is about $640 million for 2008. According to this summary, about $5 million of that was set aside for "Measurements and Standards for the Climate Change Science Program" (although NASA and NOAA probably spend a lot more). Exxon Mobil alone is making 10 billion dollars of profit (not revenue) every 3 months. Who is getting the "vast sums of money"?
 
I suspect this fear of environmentalists is mostly just a fear that someone will try to tell you what you should (or should not) do, and you might not like what they say. That is understandable. However, the mentaility of the lone rugged individualist "doin what I want with MY land" has always been a false abstraction even when people were spread thin, as no piece of land exists in isolation from the rest (unless you happen to live in the biosphere project ;-). It is suicidal when applied to a population approaching 7 billion armed with technology, a market-driven mythology of infinite growth, and 10 million gallons a minute of oil equivalent fossil energy (to put this number into perspective, one gallon of gasoline provides usable energy equivalent to about 2 months worth of human physical labor. Thus, every minute, fossil fuels provide the equivalent energy of over 200 billion extra humans working).
 
And why the hyperbole of "Gaia-worship-by-force"? Most enviromentalists I know are exquisitely practical in their thinking. They see systems in operation that SIMPLY CANNOT BE SUSTAINED OVER TIME and treat this as a problem to be solved. I suspect that you too would acknowledge, if asked in a respectful manner and encouraged to extrapolate things you already observe or believe, that things cannot go on this way much longer. Environmentalists look for workable solutions to this dilemma that can be applied early enough that there is some hope of having an effect before critical natural systems reach a point where they essentially fail to operate. Mostly they want to start by leveling the playing field for alternatives, or by giving them a minor start-up boost to help overcome the inertia of entrenched approaches.
 
As for Gaia worship, yes, environmentalists frequently look to biological systems for guidance. This is because they are the only systems known that can continue to operate successfully for extended time periods without catastrophic failure. Properly cared for farmland can be (and has been) productive for tens or hundreds of generations WITH NO EXTERNAL INPUTS except for the input of the sun and the natural distribution mechnisms of the water, carbon and other cycles. No technological solution ever devised can come close to doing this (the majority of farming done today is an industrial process for turning petroleum and natural gas into food--see The Omnivore's Dilemma for a good exploration of this).
 
Again, I ask, what is the program? Because one's personal unease with the consequences being a sprawling race on a fragile lifeboat is no substitute for a workable plan.

I find it interesting which ones of the object-recognition and scene categorization algorithms make it to Slashdot.
Why does this one make it?
This is a very hot research topic at the moment.
to name a couple of groups:

http://www.robots.ox.ac.uk/~vgg/
http://lear.inrialpes.fr/
http://www.vision.caltech.edu/
http://www.science.uva.nl/research/isla/
http://www.cdvp.dcu.ie/
http://www.informedia.cs.cmu.edu/
http://www.research.ibm.com/slam/
http://www.ee.columbia.edu/ln/dvmm/newResearch.htm

oh, and people should not stare themselves blind on the claimed results.
Research papers *always* have to present good results, or else you do not get published.
Furthermore, these images are of a very high quality, make by professional photographers.
Many algorithms perform very well on these ('corel'-like) sets, while utterly failing if applied on real-world data:
http://www-nlpir.nist.gov/projects/trecvid/

Sounds to me that the designers of your clock were about a short-sighted as those who decided that using two digits to define a year was sound implementation.

If you look at the WWVB signal description NIST encodes a DST signal within the time information. Thus, if the clock you own had been designed properly to derive DST from the radio signal, rather than using an internal calendar, it would have changed just fine (provided that it had a good signal at the time).

The clocks that I have that monitor WWVB (i.e. Atomic clocks) changed when they should have.

One important thing to consider is the set of compilers, tools, target system, and build environments you are using. If you are using MS only products the you will most likely have very good support because most all source code analysis suits will simply import the build information and you will be off and running right away. If your environment is Unix or embedded systems then things may be more difficult because you will need to hook into the build process somehow. The scanner tools usually intercept the CC command from a "make" build and call their back end using their custom processing rather than the compiler proper. Different products do this in different ways so be sure the product you choose knows how to deal with your specific build environment. In my case I walked into another parties environment and needed to simulate a build for a new build environment that I had never seen before, every time. Not one environment ever looked like the next, so the setup and configuration was always a big challenge, just to get started.

Prexis is primarily a tool for life cycle scanning of source code for security issues. There are two ways to perform the code scanning, with either the main engine component which can schedule nightly scans and track progress over time or with the additional Prexis Pro utility, which is designed for quick assessments by the engineers on their own code without logging everything into the main database. The Pro tool worked best for my code assessments since I had no need for tracking changes over time, and it was a little easier to configure which counts for a lot in my situation.

PolySpace is a completely different tool with a different purpose from Prexis. PolySpace attempts to mathematically discover runtime flaws in the code while only using static analysis to do so. It does a great job on smaller projects, but because of the complexity and thoroughness of its analysis, it is somewhat slow. PolySpace needs to evaluate an entire application all at once in order to do a good analysis. If your .5 MSLOC of code is many separate programs/executables then you will be fine, but if you are talking about one huge monolithic application then you may have to evaluate it in chunks which just increases the false positives and forces the engineer to do more manual chasing of details to determine if the issue is really a problem or not. From what I have seen this product is in a class by itself.

BTW - keep you eyes on this site: http://samate.nist.gov/index.php/Main_Page

This is simply not true. The NSA, NIST and DISA (DoD) all create guides for the operating systems, network devices and applications that are commonly used within their agencies. The Mac OS X Server Security Configuration Guide
and Mac OS X Security Configuration Guide posted on the Apple documentation website was developed in cooperation with the NSA too.

http://www.apple.com/server/documentation/

NIST and DISA publicly distribute their security guidance.

http://checklists.nist.gov/
http://iase.disa.mil/stigs/stig/

NIST does a very nice job specifying _how_ to harden a windows PC.

I have a feeling whomever is issuing directives at the white house hasn't bothered to check with NIST. http://csrc.nist.gov/itsec/guidance_WinXP.html

I just noticed they've got a Vista document going.

I've hardened PC's the NIST way. Most applications do very unexpected things when you least expect it.

This, by the way, is clearly the result of strenuous lobbying on Microsoft's part so early in the Vista game.

In comp sci, I believe, this is called a move-to-front heuristic (MTF) which is related to the move to root heuristic used in Splay trees. An interesting conjecture related to this is the dynamic optimality conjecture which claims that the splay tree's performance is no worse than any other binary search tree's within a constant factor. This conjecture remains unproven, and I forget whether or not a similar proof exists/has been proven for array's / lists and MTF.

Why is it dangerous? Do you have anything to support that? Or is it just because of the Hindenburg?

I would guess the refueling infrastructure wouldn't require that much of a change; you'd just have to have pressurized tanks, pumps, etc. The important part is that the vehicles wouldn't all have to be replaced with a totally different technology, as you advocate with your batteries. Hydrogen burns just fine in a slightly modified gasoline engine. Hundreds of millions of cars wouldn't need to be suddenly replaced, and people with older cars could easily modify them to burn the new fuel.

What's wrong with batteries? That's pretty easy.
1) Can't store enough energy (the same thing you say about hydrogen). Has anyone built an all-electric car that can go 400-500 miles without a recharge? If not, then the technology simply isn't ready to use. The best I've heard of was GM's EV-1, which could only go 30-40 miles or so.
2) They take forever to recharge. If I'm taking a weekend road trip, I'm not about to stop every 100 miles and wait 4 hours to recharge my batteries. If it can't be recharged in 5 minutes, it's not ready to use.
3) They're heavy. All-electric cars are very heavy because of the batteries, and that only gives them a pathetic range. Adding more batteries for a better range increases the weight too much.
4) They're expensive. Lead-acid batteries aren't too cheap, but they don't store enough energy. Upgrading to something like Li-ion means an enormous cost.
5) They're not improving fast enough. Sure, I can get 2500 mAh AA batteries for my digital camera now, when I could only get 1800 mAh batteries 4-5 years ago. That's not much improvement when, as I pointed out before, electric cars are WAY behind everything else for range. And you still haven't addressed the recharge time issue: even if you could get 300 miles out of a charge, that's no good if it takes 8 hours to recharge. Very few people are willing to own separate cars for long trips and for commuting.

Lastly, no one wants to move to a new technology just because of some promise of "potential breakthroughs". Sorry, I'm not going to put up with a major pain-in-the-ass technology for 30 years waiting for someone to develop this "super nanocapacitor" so we can finally have the performance with electric that we've had with fossil fuels for almost a century. Develop the new technology first, and then we'll consider it.

As for hydrogen, here's some nice links I found in 10 seconds with Google:

Hydrogen storage in nanotubes - 1998

Hydrogen stored in nano-scale metal-organic frameworks - 2005

Hydrogen stored as solid

Apparently, a lot of real (and expensive) research is being conducted into making hydrogen a realistic replacement for gasoline. That's a lot more than I can say about batteries. From what I see, the idea of an all-electric car has basically been abandoned (though hybrids are certainly becoming very popular).

Nu vulnerabilities in ISA 2004 ?
One quick google and http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-7027

If you want to be strict, the SI defines the "tera" prefix as 10^12, so 1 terabyte = 1000 gigabytes.

If you want to use the binary values, you might as well use the correct "tebi" prefix. NIST says you should, and it looks like the IEC, IEEE and BIPM agree.

For the record I have to FISMA all my Macs and we do fine with that.

qz

I just can't believe that the same vendors that would misrepresent the capacity of their disk by redefining a Gigabyte as 1,000,000,000 bytes instead of 1,073,741,824 bytes would misrepresent their MTBF too!

Not that this is actually relevant or anything, but there's been a long-standing schism between the computing community and the scientific community concerning the meaning of the SI prefixes Kilo, Mega, and Giga. Until computers showed up, Kilo, Mega, and Giga referred exclusively to multipliers of exactly 1,000, 1,000,000, and 1,000,000,000, respectively. Then, when computers showed up and people had to start speaking of large storage sizes, the computing guys overloaded the prefixes to mean powers of two which were "close enough." Thus, when one speaks of computer storage, Kilo, Mega, and Giga refer to 2**10, 2**20, and 2**30 bytes, respectively. Kilo, Mega, and Giga, when used in this way, are properly slang, but they've gained traction in the mainstream, causing confusion among members of differing disciplines.

As such, there has been a decree to give the powers of two their own SI prefix names. The following have been established:

• 2**10: Kibi (abbreviated Ki)
• 2**20: Mebi (Mi)
• 2**30: Gibi (Gi)

These new prefixes are gaining traction in some circles. If you have a recent release of Linux handy, type /sbin/ifconfig and look at the RX and TX byte counts. It uses the new prefixes.

Schwab

Perhaps you were thinking of this.

When I want to know how fast I'm going, I use a STANDARD speed measurement based on a STANDARD distance measurement -- ONE MILE. Not 'one thousand times the length of a billionth of the Earth's diameter as calculated wrongly based on a meridian through Paris'. See how that's not a very obvious or intuitive measure?

First of all, that's not how the meter is currently defined. If memory serves, it's currently defined as the distance light travels in a particular fraction of a second. Prior to that, I believe it was defined as a multiple of the wavelength of light produced by particular type of laser (helium-neon with, IIRC, iodine as a stabilizer).

In point of fact, the meter was never defined as a fraction of the diameter of the earth -- that was more or less a basis, but the actual definition was the length of a particular bar with polished, parallel ends, held at a constant temperature, etc. That remained the standard until 1960, when it was changed to a multiple of a wavelength of light produced by a specific element. Theoretically only one element was the "true" standard, but a couple of others were accepted as secondary.

As far as the definition being the length of a physical item, that was also the case with the US system -- a foot was officially defined as the length of a particular bar of metal, held at constant temperature, etc. Actually, I believe for a while it wasn't technically the entire length of the bar, but the distance between two lines scribed into a bar, but the same general idea applies.

At the present time, I believe all of the US measurements are actually defined in terms of metric measurements. For example, the yard is defined as 0.9144 meters, and the foot as .3048 meters, etc. For anybody who cares, the U.S. NIST maintains a web site devoted to use of SI. Doing a bit of looking, they also have a time-line on the definition of the meter.

Now back to your regularly scheduled (but topical) flaming.

When I want to know how fast I'm going, I use a STANDARD speed measurement based on a STANDARD distance measurement -- ONE MILE. Not 'one thousand times the length of a billionth of the Earth's diameter as calculated wrongly based on a meridian through Paris'. See how that's not a very obvious or intuitive measure?

First of all, that's not how the meter is currently defined. If memory serves, it's currently defined as the distance light travels in a particular fraction of a second. Prior to that, I believe it was defined as a multiple of the wavelength of light produced by particular type of laser (helium-neon with, IIRC, iodine as a stabilizer).

In point of fact, the meter was never defined as a fraction of the diameter of the earth -- that was more or less a basis, but the actual definition was the length of a particular bar with polished, parallel ends, held at a constant temperature, etc. That remained the standard until 1960, when it was changed to a multiple of a wavelength of light produced by a specific element. Theoretically only one element was the "true" standard, but a couple of others were accepted as secondary.

As far as the definition being the length of a physical item, that was also the case with the US system -- a foot was officially defined as the length of a particular bar of metal, held at constant temperature, etc. Actually, I believe for a while it wasn't technically the entire length of the bar, but the distance between two lines scribed into a bar, but the same general idea applies.

At the present time, I believe all of the US measurements are actually defined in terms of metric measurements. For example, the yard is defined as 0.9144 meters, and the foot as .3048 meters, etc. For anybody who cares, the U.S. NIST maintains a web site devoted to use of SI. Doing a bit of looking, they also have a time-line on the definition of the meter.

Now back to your regularly scheduled (but topical) flaming.

I would be very interested in your research, can you post some pointers to modeling feedback?

The caltech datasets are in my opinion artificial, since they rotate all images in the same direction.
For example, a moterbike always faces to the right, and the 'trilobite' is even rotated out of the plane (leaving a white background) so you only need to estimate the right angle of rotation.
for example, see:
http://www.vision.caltech.edu/Image_Datasets/Calte ch101/averages100objects.jpg
you would never get a consistent blurred image if you would allow unconstrained views of an object.

Better datasets in my opinion are the VOC challenge:
http://www.pascal-network.org/challenges/VOC/datab ases.html#VOC2006
and the digital video benchmark Trecvid (where we work on)
http://www-nlpir.nist.gov/projects/trecvid/
which is not only true real-world data, it consists of hundereds of hours of video, instead of a few of thousand images.

Yes, no, maybe. If you look at the claims made by the 2DEM developers, you can discover some information from any encrypted file/disk that uses a block cipher that uses a simple chaining mode. There is no reason to believe Microsoft used a particularly sophisticated encryption mode, there is no reason to believe that other whole-disk systems use only simple chaining modes.

The real criminal masterminds use whatever the Feds and the military are using, which we don't know about because it's classified information.

The military probably uses whatever is FIPS-140 certified. At least that's what was being mandated at the DoD contractor I worked for.

I'm not a coder, but my impression of the vast majority of coders is that they reinvent the wheel because they believe that everyone screwed up their wheel implementation and if no one is going to do it right, they should.

A second issue is that you want current spam; the global characteristics of spam change from week to week. So what's the use of an ancient archive?

And perhaps the biggest problem is that SpamArchive is a hodge-podge of mail from different sources, vetted only by the people who send it in. It isn't a sample of spam in any statistical sense.

Finally, there is no scarcity of spam. Ham is what people don't want to share.

So a collection of spam, particularly an old one sent in by self-selected volunteers, is of little practical use. The hard thing to get is a collection of spam and ham from a common place.

The TREC tests use private corpora that have legitimate mixes of ham and spam. They also use public corpora in which the spam has been carefully spoofed to make it appear to have been sent to the same recipients as the ham. Collecting the spam for the corpus was easy; spoofing was not.

It appears that by technical writing they mean non-technical writing about technical items (as is shown by last year's entries). Since this isn't really technical writing (and who would want to read that in their free time who was not a geek) it should belong in the Best of Non-Fiction Writing for 2006.

But if they ever actually mean technical writing then I have a great entry: NIST-NCSTAR 1. Lots of detail, lots of analysis, and even a couple of introductory chapters than only assume a BS in engineering (with an executive report that assumes no experience in anything except breathing). I'm guessing it might be a little too thick to put in their text. Perhaps they should only include the first thousand or so pages.

> All security software needs to be OSS for this reason.

For serious 2-factor authentication, you're looking at security hardware, not just software. Which, for almost everybody, means trusting the manufacturer, supported by any independent certification that has been done, like NIST's Cryptographic Module Validation Program.

The draft can be found (in PDF) here.

Scimark wasn't even close:

IBM java6:
Composite Score: 482.8282568762099
FFT (1024): 551.8002634079949
SOR (100x100): 568.7588552216857
Monte Carlo : 64.62096017621073
Sparse matmult (N=1000, nz=5000): 219.84569330460474
LU (100x100): 1009.1155122705532

Sun java6:
Composite Score: 617.5119705454583
FFT (1024): 510.7586118547276
SOR (100x100): 829.8686416193439
Monte Carlo : 118.25350583943022
Sparse matmult (N=1000, nz=5000): 470.6355733620428
LU (100x100): 1158.0435200517468

Higher scores are better. Both run on AMD X2 5000+

Sun VM stomped on IBM's. That wasn't true with earlier VM's. IBM used to smoke Sun on scimark. Maybe there's more development to be done.

BTW if a linux user believes that myth you raise and isn't regularly using apt-get update; apt-get upgrade then they get what they deserve. No OS is bug free, I don't trust OSX, AIX or Linux any more than MS.

• SHA-1 encryption does not include MD5
  
• SHA-1 is not an encryption algorithm, it's a one-way hash algorithm
  
• Wang only cracked hash algorithms, "big names" like AES, RSA or ECC are still safe to use
  
• etc...