Here's Fermilab's statment. Of course they are an interested party, but at least their statement contains information, unlike the snide popular press article.
"Saying the opposite of what you mean" is but one sense of irony. Here's another:
OED 2 fig. A condition of affairs or events of a character opposite to what was, or might naturally be, expected; a contradictory outcome of events as if in mockery of the promise and fitness of things.
Look in the incoming/outgoing connection log on your Linksys (or whatever) broadband router. If you see connections to all sorts of places you shouldn't -- especially on port 25, yank your ethernet cable and consult a professional.
No broadband router? Go buy one. They're free (after rebate, of course!)
Many teams lost untold time on J because the judge data did not meet the input specification.
ICPC has had this problem before. Four times in my direct experience, most notably ICPC World Finals 2000 at which they refused to acknowledge their error until weeks later.
This year the data for problem J was wrong, so teams got "run time error" instead of "wrong answer;" many spent vast amounts of time trying to find the source of their crash when in fact it was the judges' fault. All submissions were rejudged at the eleventh hour, when it was too late to fix the problem or to move on to another question.
There is really no excuse for this sort of error. Published guidelines make it clear that input checkers should be written for all problems, yet the finals judges don't bother, and the finals organization imposes no standard on them to do so. Furthermore, the organizers refuse to release any information about the test sets, so we have no idea how many screwups have been covered up.
Here is a list of data errors for which I have first-hand knowledge. I'm sure there are many more.
Finals '97 -- Problem C has ambigous output but the
judges rejected some correct solutions
(all but their expected one?) Complaints
were responded to with "no response."
Finals '98 -- Problem D had empty lines in the input,
contrary to the specification.
Finals '00 -- The infamous graph that was not connected,
contrary to the problem spec (Problem F)
Finals '07 -- Problem J was supposed to have maximum size
64, but was 100. Rejudged in the last hour
of contest. Many submissions changed from
run-time or time limit to wrong answer.
I am at a loss to understand why the organizers fail to implement better quality control, and why they refuse to release the data and solutions. Bad calls will happen, but the lack of quality control and the lack of transparency exacerbates the problem considerably. These failures, in my opinion, detracts substantially from the contest.
CEAS (www.ceas.cc) will be running a live spam filter test Aug 2-3.
I invite you, or anybody else who wishes to prove that (a) content filtering is hopeless and/or (b) RBLs are a slam-dunk, to demonstrate your superiority by participating in this test.
Here's an independent confirmation:
Although it has been written in various places that Rick Moranis and Dave Thomas received the Order of Canada for their contribution to Canadian culture, a phone call to Rideau Hall revealed that they were not members of the Order of Canada.
MT[TB]F has become a completely BS metric because it is so poorly understood. It only works if your failure rate is linear with respect to time. Even if you test for a stupendously huge period of time, it is still misleading because of the bathtub curve effect. You might get an MTBF of say, two years, when the reality is that the distribution has a big spike at one month, and the rest of the failures forming a wide bell curve centered at say, five years.
The simplest model for survival analysis is that the failure rate is constant. That yields an exponential distribution, which I would not characterize as a bell curve. The Weibull distribution more aptly models things (like people and disks) that eventually wear out; i.e. the failure rate increases with time (but not linearly).
With the right model, it is possible to extrapolate life expectancy from a short trial. It is just that the manufacturers have no incentive to tell the truth, so they don't. Vendors never tell the truth unless some standardized measurement is imposed on them.
I can tolerate fake tears more than phone numbers that start with 555, comic-book format computer interfaces with security that can be cracked in a couple of keystrokes, noisy explosions in space,...
Where's the evidence that RBLs provide lower false positive and/or false negative rates than content filtering? Just because you think it's so doesn't make it so. Or that filtering introduces 5 hour delays? etc.
The above rant is just a string of strawman arguments without an iota of evidence. It ascribes to filters disadvantages which do not exist, and to RBLs fantastic properties that also don't exist.
Maybe RBLs are useful in the fight against spam -- maybe not. To suggest that they obviate content filtering is preposterous.
Ease of use and compatibility with DOS/Windows is a major reason that Microsoft got us into this security mess. The default user in XP was an administrator with no login password. Non-priveleged accounts were practically useless, mainly because you couldn't install any software using them. Now Vista is touted as allowing non-priveleged accounts, but the price you pay is that any old installer is priveleged. What an advance!
While I'm at it, why does a printer (or other non-intrusive peripheral) driver have to have unfettered access to the life blood of the OS?
And don't forget that the corn gets the CO2 from... the air.
And even an inefficient process can be bootstrapped; that is, is is not essential to burn fossil fuels for the harvesting, transportation, or distillation.
So corn alcohol might not be the most efficient approach, I wouldn't dismiss it out of hand.
(And overall subsidies/taxes are very difficult to estimate. Consider the historical and current investment in military support and shipping infrastructure for oil.)
XML (and open for that matter) is just a synonym for "good." So read "OOXML format" simply as "(MS) Office format." The fact that it is sort of based on XML is irrelevant.
But if you never get penny stock spam, there's no need to filter against it, is there? And if you're a penny stock trader, such training may well hurt the performance of your filter.
While you might imagine a filter being able to harness this information, real filters are instead distracted by it. Just like your immune system would be distracted were you to be vaccinated against all sorts of human and animal diseases that you would be unlikely to contract. Exactly the reason why Americans are not routinely given typhoid and smallpox vaccinations.
Mailing lists are poor examples of ham email. Useful, perhaps for training the filter attached to a mailing list, but not for training a filter that handles individuals' email.
Spam filters do a differential comparision between ham and spam. If the ham and spam are taken from different places, the difference between the source of the messages overwhelms the difference between the ham and the spam.
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 is silly to have such a small denomination of currency. Every time you buy something you go through this stupid ritual of counting pennies that make no material difference to either the merchant or the purchaser. Or else have some obsequious interaction about whether or not to offer/accept them. Vending machines don't even take pennies. They wear out our pockets.
So get rid of them. And if you get rid of nickels too, the arithmetic will be even simpler.
Timeliness and reliability are continuous, not discrete, quantities. So is immediacy, for that matter.
For the majority of people with whom I correspond -- even people in China and Bangladesh -- an email message has about 99.9% chance of being delivered (with a notification message, not just silently to their mailbox) within 2 minutes.
That's a much, much better chance, and much less work on my part (and theirs), than trying to catch them on the phone or in an IM session.
Synchronous and asynchronous communication both admit delay and failure. They manifest themselves differently, but in both cases there is a tradeoff and one wants in general to minimize both.
Play with words as you see fit. When I say immediacy I mean timeliness, and when you say immediate you mean interactive. I do not wish to be forced to enter into a synchronous dialogue in order to transmit or receive information in a timely and reliable manner.
The utility of email (or any mail) depends on timeliness, and its utility is compromised by the introduction of transmission delay. Split hairs if you like as to how timely email should be in order to fulfill its purpose, but please don't tell me timeliness isn't an issue. Also, please don't tell me how I should or should not use the medium; I'm telling you how I do use it and I'm telling you that greylisting compromises its utility for that purpose.
The phone is intrusive. It interrupts what I'm doing, or whatever whomever I call is doing. Who am I to say that what I wish to transmit needs to be handled immediately? I merely want it to be *available* immediately so that if the sender and recipient both see value in quick turnaround, they have it. Email is immediate without being intrusive. If I want a conversation I use the phone (or IM). If I want to exchange information I use email.
The problem with the boss who phones to follow up email is the phone call, not the email.
I invented a device that you could bolt on to the gas line of your automobile and get 1000 miles/gallon (0.235221 l/100km). But there's a conspiracy between the oil companies and the auto manufacturers to prevent me from marketing it, so I wasn't able to acquire the funding to build a prototype.
But I have the formulas that *prove* that it works!
Slashdot Mirror
Many of the questions asked here are answered in the Challenge Call for Participation
Or the overview talk that Rich Segal gave at the MIT Spam Conference.
The guidelines are scheduled to be finalized May 1.
Here's Fermilab's statment. Of course they are an interested party, but at least their statement contains information, unlike the snide popular press article.
e nts/2007/LHCInnerTriplet.html
http://user.web.cern.ch/user/QuickLinks/Announcem
Spamhouse requested that this case be handled by the court.
This statement requires substantiating evidence.
Look in the incoming/outgoing connection log on your Linksys (or whatever) broadband router. If you see connections to all sorts of places you shouldn't -- especially on port 25, yank your ethernet cable and consult a professional.
No broadband router? Go buy one. They're free (after rebate, of course!)
Perhaps the big SEC bust actually had some effect. My personal harvest of spam has dropped recently from 1000/day to 500/day.
My mistake. The problem says 50, not 64.
Many teams lost untold time on J because the judge data did not meet the input specification.
ICPC has had this problem before. Four times in my direct experience, most notably ICPC World Finals 2000 at which they refused to acknowledge their error until weeks later.
This year the data for problem J was wrong, so teams got "run time error" instead of "wrong answer;" many spent vast amounts of time trying to find the source of their crash when in fact it was the judges' fault. All submissions were rejudged at the eleventh hour, when it was too late to fix the problem or to move on to another question.
There is really no excuse for this sort of error. Published guidelines make it clear that input checkers should be written for all problems, yet the finals judges don't bother, and the finals organization imposes no standard on them to do so. Furthermore, the organizers refuse to release any information about the test sets, so we have no idea how many screwups have been covered up.
Here is a list of data errors for which I have first-hand knowledge. I'm sure there are many more.
Finals '97 -- Problem C has ambigous output but the
judges rejected some correct solutions
(all but their expected one?) Complaints
were responded to with "no response."
Finals '98 -- Problem D had empty lines in the input,
contrary to the specification.
Finals '00 -- The infamous graph that was not connected,
contrary to the problem spec (Problem F)
Finals '07 -- Problem J was supposed to have maximum size
64, but was 100. Rejudged in the last hour
of contest. Many submissions changed from
run-time or time limit to wrong answer.
I am at a loss to understand why the organizers fail to implement better quality control, and why they refuse to release the data and solutions. Bad calls will happen, but the lack of quality control and the lack of transparency exacerbates the problem considerably. These failures, in my opinion, detracts substantially from the contest.
Gordon Cormack
Coach, Waterloo ACM Team
CEAS (www.ceas.cc) will be running a live spam filter test Aug 2-3.
I invite you, or anybody else who wishes to prove that (a) content filtering is hopeless and/or (b) RBLs are a slam-dunk, to demonstrate your superiority by participating in this test.
Guidelines will be posted shortly.
For further information email information@ceas.cc
Here's an independent confirmation: Although it has been written in various places that Rick Moranis and Dave Thomas received the Order of Canada for their contribution to Canadian culture, a phone call to Rideau Hall revealed that they were not members of the Order of Canada.
- Member of the Order of Canada
- Officer of the Order of Canada
- Companion of the Order of Canada
http://en.wikipedia.org/wiki/Order_of_CanadaWith the right model, it is possible to extrapolate life expectancy from a short trial. It is just that the manufacturers have no incentive to tell the truth, so they don't. Vendors never tell the truth unless some standardized measurement is imposed on them.
I can tolerate fake tears more than phone numbers that start with 555, comic-book format computer interfaces with security that can be cracked in a couple of keystrokes, noisy explosions in space, ...
The above rant is just a string of strawman arguments without an iota of evidence. It ascribes to filters disadvantages which do not exist, and to RBLs fantastic properties that also don't exist.
Maybe RBLs are useful in the fight against spam -- maybe not. To suggest that they obviate content filtering is preposterous.
Mod parent down.
While I'm at it, why does a printer (or other non-intrusive peripheral) driver have to have unfettered access to the life blood of the OS?
And don't forget that the corn gets the CO2 from ... the air.
And even an inefficient process can be bootstrapped; that is, is is not essential to burn fossil fuels for the harvesting, transportation, or distillation.
So corn alcohol might not be the most efficient approach, I wouldn't dismiss it out of hand.
(And overall subsidies/taxes are very difficult to estimate. Consider the historical and current investment in military support and shipping infrastructure for oil.)
XML (and open for that matter) is just a synonym for "good." So read "OOXML format" simply as "(MS) Office format." The fact that it is sort of based on XML is irrelevant.
While you might imagine a filter being able to harness this information, real filters are instead distracted by it. Just like your immune system would be distracted were you to be vaccinated against all sorts of human and animal diseases that you would be unlikely to contract. Exactly the reason why Americans are not routinely given typhoid and smallpox vaccinations.
Mailing lists are poor examples of ham email. Useful, perhaps for training the filter attached to a mailing list, but not for training a filter that handles individuals' email.
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 is silly to have such a small denomination of currency. Every time you buy something you go through this stupid ritual of counting pennies that make no material difference to either the merchant or the purchaser. Or else have some obsequious interaction about whether or not to offer/accept them. Vending machines don't even take pennies. They wear out our pockets.
So get rid of them. And if you get rid of nickels too, the arithmetic will be even simpler.
[ad hominem and strawman arguments ignored]
Timeliness and reliability are continuous, not discrete, quantities.
So is immediacy, for that matter.
For the majority of people with whom I correspond -- even people
in China and Bangladesh -- an email message has about 99.9% chance of
being delivered (with a notification message, not just silently
to their mailbox) within 2 minutes.
That's a much, much better chance, and much less work on my
part (and theirs), than trying to catch them on the phone or
in an IM session.
Synchronous and asynchronous communication both admit delay
and failure. They manifest themselves differently, but in
both cases there is a tradeoff and one wants in general
to minimize both.
Play with words as you see fit. When I say immediacy I mean timeliness, and when you say immediate you mean interactive. I do not wish to be forced to enter into a synchronous dialogue in order to transmit or receive information in a timely and reliable manner.
The utility of email (or any mail) depends on timeliness, and its utility is compromised by the introduction of transmission delay. Split hairs if you like as to how timely email should be in order to fulfill its purpose, but please don't tell me timeliness isn't an issue. Also, please don't tell me how I should or should not use the medium; I'm telling you how I do use it and I'm telling you that greylisting compromises its utility for that purpose.
The phone is intrusive. It interrupts what I'm doing, or whatever whomever I call is doing. Who am I to say that what I wish to transmit needs to be handled immediately? I merely want it to be *available* immediately so that if the sender and recipient both see value in quick turnaround, they have it. Email is immediate without being intrusive. If I want a conversation I use the phone (or IM). If I want to exchange information I use email.
The problem with the boss who phones to follow up email is the phone call, not the email.
I invented a device that you could bolt on to the gas line of your automobile and get 1000 miles/gallon (0.235221 l/100km). But there's a conspiracy between the oil companies and the auto manufacturers to prevent me from marketing it, so I wasn't able to acquire the funding to build a prototype.
But I have the formulas that *prove* that it works!