Oh, good. I'm not the only one. It turns out that SunOS (and/or BSD) and I think most modern Unices won't follow.. on a recursive remove. Older SysV sure like to, though. (See my linked post above.)
Back in college, I once told my (at the time, future) roommate how to recursively remove the "dot files" and "dot file directories" in a subdirectory under his home directory, with "rm -rf.*". Under most modern Unices, this isn't an issue. Under the old SVR4 system we were on, it globbed ".." and recursively removed that directory (his home directory) also.
Oops.
Part of the irony of this is what the SunOS 4.x man page had to say about this behavior: (emphasis added)
WARNING
It is forbidden to remove the file `..' to avoid the antisocial consequences of inadvertently doing something like `rm -r.*'.
I guess someone in BSD or SunOS land committed the same boo-boo. I consulted the above man-page after the incident had happened, since I had accounts both on an AT&T StarServer and a Sparc 2.
It appears that this page holds a man page similar to the one on the AT&T box. Notice that it says: "It is an error to specify . (dot) or.. (dot dot) as the final path name component of file, although these entries may be removed with the -r or -R flags."
Your sig mentions: "0x2B | ~0x2B == 0xFFFFFFFF". That's not quite true -- you need to add parentheses to make the statement evaluate to 1 in C. If you wrote the above in a C program, the compiler would parse it as "0x2B | (~0x2B == 0xFFFFFFFF)", and that expression has the value 0x2B.
On a side note, it's worth noting this even more amusing property:
The difference in opinion is that you feel that devices, that is, storage locations, should be invisible to applications and managed only by the filesystem, and I want to specifically know exactly which physical hard drive contains which bytes at all times.
Well, I kinda want both. I want to personally be able to say, given a file or a tree of files, what disk(s) and machine(s) that data is held on, so that I can move them if that drive starts to fail. I don't want to have to tell the app that just to use the data. I don't want the app to care if the data moves (especially if I had to move it because a drive is failing). I've had drive letters sneak into project files in IDEs under Windows. Moving a project from one computer to another, where the drive mappings are different, is an adventure. I want to avoid this.
Knowing the physical mapping of files to drives is useful for the reasons you state. Typically, though, the consumers of that information are the system administrator and system administration tools, not applications.
For compiling software from scratch, it's not so big a deal to handle customizations the first time. If you're reconfiguring a machine, it can become a huge headache quickly. In either case, though, the argument misses the point -- it's not about finding your home in the namespace, but rather that the filesystem namespace shouldn't change radically even if the hard-disks under it do.
For most applications, the physical layout of disks and partitions on a machine should be irrelevant. It should only matter to diagnostic software whose purpose in life is to access those devices at the lowest levels. The OS should provide APIs or other interfaces for this purpose, and these paths should be separate from the generic file hierarchy that apps see. Witness/dev under *nix. I'm sure Windows has low-level APIs as well.
Addressing your statement: For a program that exercises the hardware to the extremes of its physical limitations (for example, a program to test solid fuel rocket motors) you can't afford the overhead, it's too inefficient to have opaque software layers between you and the circuitry.
Device drivers and filesystem software should talk more directly to devices. (Actually, filesystems should talk to block abstractions that talk to devices, thereby enabling RAID and other such things.) High level apps talk to higher level interfaces, such as filesystems, databases, sockets.
If you're testing solid fuel rocket motors, then by all means, talk directly to the hardware. In fact, I imagine you're on something a little more controlled than a PC anyway. (Or maybe not -- look at Armadillo Aerospace and their PC-104 stack running Linux.) In contrast, web browsers shouldn't care about the fact that one of your hard drives is SCSI, one is IDE, that your browser cache is on a RAID partition, and that you use an accelerated video card. It shouldn't care if you're using WiFi, dialup, broadband, or TCP/IP over Avian Carrier. The fact that modern OSes insulate apps from these distracting distinctions is a Good Thing (TM).
Who wants to go back to the bad old days of DOS, where a telnet client had to include its own TCP/IP stack, and you were on your own to find a compatible packet driver for your ethernet card? Or, how about games that may or may not work with your sound card / video card / joystick combination? Who wants the era where each word processor came with its own set of printer drivers? ICK!
I personally view the traditional "C:\Program Files" to be a travesty -- it requires me to put all my stuff on the same HD as the OS, and to make sure it's big enough. I seem to recall that modern Windows lets you do *nix style mounting to some extent to get away from that issue, so maybe there's some light at the end of the tunnel. Fortunately, I only have to endure Windows at work, and I let Those Who Are Paid To Do So administer my machine.
Given that so many things end up with non-relative paths, I find device roots to be rather annoying. A program shouldn't care if "\Program Files\FooBarBaz" is on C: today and D: tomorrow, or that "\Program Files\Foo" is on C: and "\Program Files\Bar" is on D:, or F: for that matter.
Real symlinks would go a long way here, but only as a kludge. They'd allow you to simulate a single-rooted file hierarchy inside of a multi-rooted hierarchy. Fundamentally programs should not care where their physical storage is, only where it is in the namespace. Exposing the physical devices in the namespace requires programs to take note of it, and makes it harder for you to upgrade or change configurations later.
No, it's closer to being akin to complaining about all the billboards and noisy truck traffic that Interstates brought through previously residential neighborhoods.
"Heat Watts" are "regular" Watts. If you dissipate 1000W for 1 second, that means you've put 1000 Joules of energy somewhere.
Possibilities include:
Raising the temperature of something (increased its internal energy),
Making something move (increased its kinetic energy),
Generating light/radio waves (electromagnetic energy), or
Triggering a chemical process (such as charging a battery--increasing its potential energy).
Most of the energy we put into computers eventually comes back out as heat and electromagnetic radiation. (RFI and light from the monitor are both EM.) Even the mechanical energy in HD platters eventually dissipates as heat.
You get a full 360 degrees of sine wave on the hot side. It's "1 phase" current.
If you look at the two outputs of the isolation transformer, you'll see two sine waves, 180 degrees apart, at half the magnitude. If you happen to tie one of the sides to ground, you'll get the same situation as the grounded outlet -- 1 phase at full magnitude.
In the end, it's only the potential difference between the two prongs that matters to the appliance.
I think what you're describing is metastasis, not malignancy.
A malignant tumor is a dangerous/damaging tumor. (The linked definition notes "tendency to metastasize" but that does not mean it is metastasizing. Kinda like HIV isn't AIDS, yet.) The opposite is benign, which means it's unusual but safe, kinda like scar tissue.
When a tumor metastasizes, it does precisely what you described: Sends out seed cells that establish hard-to-get-at tumors throughout the body.
I personally like the Mac/Win/Unix OS Peter's using in Office Space. Mac dialog boxes, UNIX desktop games, and a C:> prompt. (I don't remember if it showed a slash, and if so, which way it faced.)
Not in this case. Someone else pointed out that the ops are 8-bit multiplies and 8-bit accumulates.
Floating point operations are significantly more expensive.
You can build both digital and analog computers from analog components. Indeed, aside from "ideal switches", I'd argue that most circuit components are analog.
The poster to which you responded is correct -- a system built around discrete levels selected from a continuous domain is considered digital. A system built around continuous levels is considered analog.
So, if you build a computer around 4-level signaling, it'd still be digital. Each signal corresponds to a "digit," likely valued 0 thru 3. If you built a differential-equation analyser out of op-amps, resistors, capacitors and inductors to represent the derivatives/integrals in your system of equations, and operated it within the linear region of the op-amps, you'd have an analog computer. Those aren't very popular anymore, nor have they been for some time.
The options you suggested a couple posts up are all variants of digital signaling. The first one is binary signaling. The second one is discrete amplitude modulation. The third one is multi-frequency discrete amplitude modulation.
The real question is, can you build large numbers of sufficiently small gates for a given signaling method? Additionally, do those gates aggregate into computing structures we know how to use effectively?
Related side topic: 3-valued logic (ternary computing) likely won't take off until its proponents have good answers for both questions.
Something tells me the circuits and the gates are the smaller of the two problems. The change in programming paradigm is too big.
The final stage of bootstrapping GCC is to have GCC build itself. So, if you're running a fully installed GCC 3.3.1, it's actually a GCC built with GCC 3.3.1.
This page, down in the glossary, uses the definition you suggest. That is, it defines "times larger" as purely multiplicative. "Three times larger" means "tripled."
In contrast, Dr. Math agrees with me that "times larger" implies adding to the baseline. Dr. Math says '"Three times larger than N" means "4 * N" - but only if you stop
to think about it, as many people do not.'
I think it's amply clear that "X times larger" is ambiguous without the data to disambiguate it. You have one group of people who thinks it clearly means one thing, and another that thinks it clearly means something else. It is therefore (maybe not-so-clearly) ambiguous. Dr. Math sums it up nicely:
So here's my answer: "N times more than X" technically should mean
(N+1)X, but is so commonly used to mean NX that it would be dangerous
to follow the former interpretation without asking questions. I
haven't yet found a dictionary or other authoritative source to
support one view or the other (or both, most likely).
"30% faster" means 1.3x the speed, right? It certainly does not mean 0.3x. "300% faster", then, means 4x the speed. "3 times faster" should also therefore mean 4x the speed.
In that first link you gave, the author says "three times as fast" in the body of the article, not "three times faster." "Three times as fast" means "one third the time," as I stated. (Whoever wrote the title line got it wrong. The author of the article uses "three times as fast" consistently throughout.) In that second link, they use "two to three times faster" to mean "200% to 300% increase", which means 1/3rd to 1/4th the required time, again consistent with my original post. (If you disagree with my interpretation of that second link's text, then do think that the "35% faster" note in the table implies a slowdown? They mention "two times faster" referring to values over 200% in their table, and so on.)
The reason I state it is ambiguous is that most people make the same mistake you did in the body of your post. "Three times faster" means 1/4th the time is required, not 1/3rd, even though many people use it to mean 1/3rd the time is required. "Three times as fast" means 1/3rd the time is required.
Also, what do they mean by "2.5 times faster?"
For instance, if a given benchmark takes 100 seconds with Samba, how many seconds does it take with Windows 2003? Some options:
250 seconds. That is, for every 1 iteration of the benchmark under Windows, SAMBA completes 2.5 iterations.
350 seconds. That is, for every 1 iteration of the benchmark under Windows, SAMBA completes 2.5 additional iterations (3.5 total). ("Times faster" would imply "in addition to the baseline" as opposed to "times as fast", which implies a purely multiplicative ratio. People tend to use the phrases interchangeably, though.)
Some other number?
I'd really like to see some actual numbers. "2.5x faster" reeks of vague, meaningless marketingspeak.
Actually, I think 'intr' and 'soft' have been mount options for, oh, say a decade or more?
Personally, I think a -o hard,intr mount is probably the right choice for most network mounts, and a -o soft mount is a polite option for remote, readonly filesystems shared by a larger crowd. (Almost nobody does that anymore. I believe wuarchive used to offer a read-only public NFS mount around 10 years ago.)
Look into -o intr and/or -o soft for your NFS mounts. From the man page:
hard
The program accessing a file on a NFS mounted file system will
hang when the server crashes. The process cannot be interrupted
or killed unless you also specify intr. When the NFS server is
back online the program will continue undisturbed from where it
was. This is probably what you want.
soft
This option allows the kernel to time out if the nfs server is
not responding for some time. The time can be specified with
timeo=time. This option might be useful if your nfs server
sometimes doesn't respond or will be rebooted while some process
tries to get a file from the server. Usually it just causes
lots of trouble.
Note that the statements "This is probably what you want" etc. in the quoted text above come from the man page, not me.
Uhm, DynDNS has apparently modified their service to allow you to publish SPF records. Thus, if you have a vanity domain (why wouldn't you?), you could have them host the DNS for you and publish an SPF record. Voila, done.
If you're feeling cheap about it, find a bunch of other techie friend that are in the same boat, chip in on a single domain for all of you, and you're all good. Plus, you divide the cost N ways among N friends.
I believe the phrase is used correctly in a court context, wherein the council for one side can raise an objection to an answer stating that it is "begging the question, your honor."
As for "beggaring the question" being nonsense--have you ever searched for uses of that phrase? Look at the hits google brings up. It tends to be used more consistently to mean "answering the question with the question itself."
I personally have heard it used both correctly and incorrectly, although I have heard it used incorrectly more often. It really does grate on my ears though.
That doesn't justify the use, however. For example, here in Texas, for instance, I have heard the word "whenever" used in places where "when" is the correct word. Such as "Whenever I was in third grade, yadda yadda..." or "Whenever I was falling asleep last night..." and so on. Basically, the word "whenever" (which implies any of a multitude of equally interchangeable instances amongst a list of many general such occurrances) used in a context where "when" (which implies a specific instance) should of been used. For instance, you've likely only been in third grade once, and even if you repeated it more than once, it's not a general occurrance. You don't just decide to attend third grade this month for the heck of it. "Whenever" is supposed to be used when describing a general case, such as "Whenever I debate grammatical usage on Slashdot..."
Aren't most of the spams filled with random gibberish these days specifically targeting Bayesian filters?
I've been collecting up spam in order to start writing my own spam filter. (I was planning on taking the Bayesian approach to the next level and using a simple Markov model instead.) One of the things I noticed is that "ham" tends to confine itself to a predictable dictionary, whereas "spam" misses the dictionary fairly often. Thus, biasing unknown tokens towards "spam" should be a fairly cheap and effective filter.
How about a simple layer of redirection to a form, with method "GET" instead of "POST" that is really just an HTML file with a proper mailto: link?
Do spam bots chase form submission links too?
Such an approach should be effective against most
bots, I'd suspect.
If you want to go a step further, just have some text somewhere on the page and a simple CGI on the other side of the form. "Enter this text into the form field below to reveal my email address."
Slashdot Mirror
Oh, good. I'm not the only one. It turns out that SunOS (and/or BSD) and I think most modern Unices won't follow .. on a recursive remove. Older SysV sure like to, though. (See my linked post above.)
--JoeBack in college, I once told my (at the time, future) roommate how to recursively remove the "dot files" and "dot file directories" in a subdirectory under his home directory, with "rm -rf .*". Under most modern Unices, this isn't an issue. Under the old SVR4 system we were on, it globbed ".." and recursively removed that directory (his home directory) also.
Oops.
Part of the irony of this is what the SunOS 4.x man page had to say about this behavior: (emphasis added)
I guess someone in BSD or SunOS land committed the same boo-boo. I consulted the above man-page after the incident had happened, since I had accounts both on an AT&T StarServer and a Sparc 2.
It appears that this page holds a man page similar to the one on the AT&T box. Notice that it says: "It is an error to specify . (dot) or .. (dot dot) as the final path name component of file, although these entries may be removed with the -r or -R flags."
--JoeYour sig mentions: "0x2B | ~0x2B == 0xFFFFFFFF". That's not quite true -- you need to add parentheses to make the statement evaluate to 1 in C. If you wrote the above in a C program, the compiler would parse it as "0x2B | (~0x2B == 0xFFFFFFFF)", and that expression has the value 0x2B.
On a side note, it's worth noting this even more amusing property:
Cosmic, eh?
--JoeWell, I kinda want both. I want to personally be able to say, given a file or a tree of files, what disk(s) and machine(s) that data is held on, so that I can move them if that drive starts to fail. I don't want to have to tell the app that just to use the data. I don't want the app to care if the data moves (especially if I had to move it because a drive is failing). I've had drive letters sneak into project files in IDEs under Windows. Moving a project from one computer to another, where the drive mappings are different, is an adventure. I want to avoid this.
Knowing the physical mapping of files to drives is useful for the reasons you state. Typically, though, the consumers of that information are the system administrator and system administration tools, not applications.
--JoeFor compiling software from scratch, it's not so big a deal to handle customizations the first time. If you're reconfiguring a machine, it can become a huge headache quickly. In either case, though, the argument misses the point -- it's not about finding your home in the namespace, but rather that the filesystem namespace shouldn't change radically even if the hard-disks under it do.
For most applications, the physical layout of disks and partitions on a machine should be irrelevant. It should only matter to diagnostic software whose purpose in life is to access those devices at the lowest levels. The OS should provide APIs or other interfaces for this purpose, and these paths should be separate from the generic file hierarchy that apps see. Witness /dev under *nix. I'm sure Windows has low-level APIs as well.
Addressing your statement: For a program that exercises the hardware to the extremes of its physical limitations (for example, a program to test solid fuel rocket motors) you can't afford the overhead, it's too inefficient to have opaque software layers between you and the circuitry. Device drivers and filesystem software should talk more directly to devices. (Actually, filesystems should talk to block abstractions that talk to devices, thereby enabling RAID and other such things.) High level apps talk to higher level interfaces, such as filesystems, databases, sockets.
If you're testing solid fuel rocket motors, then by all means, talk directly to the hardware. In fact, I imagine you're on something a little more controlled than a PC anyway. (Or maybe not -- look at Armadillo Aerospace and their PC-104 stack running Linux.) In contrast, web browsers shouldn't care about the fact that one of your hard drives is SCSI, one is IDE, that your browser cache is on a RAID partition, and that you use an accelerated video card. It shouldn't care if you're using WiFi, dialup, broadband, or TCP/IP over Avian Carrier. The fact that modern OSes insulate apps from these distracting distinctions is a Good Thing (TM).
Who wants to go back to the bad old days of DOS, where a telnet client had to include its own TCP/IP stack, and you were on your own to find a compatible packet driver for your ethernet card? Or, how about games that may or may not work with your sound card / video card / joystick combination? Who wants the era where each word processor came with its own set of printer drivers? ICK!
I personally view the traditional "C:\Program Files" to be a travesty -- it requires me to put all my stuff on the same HD as the OS, and to make sure it's big enough. I seem to recall that modern Windows lets you do *nix style mounting to some extent to get away from that issue, so maybe there's some light at the end of the tunnel. Fortunately, I only have to endure Windows at work, and I let Those Who Are Paid To Do So administer my machine.
--JoeGiven that so many things end up with non-relative paths, I find device roots to be rather annoying. A program shouldn't care if "\Program Files\FooBarBaz" is on C: today and D: tomorrow, or that "\Program Files\Foo" is on C: and "\Program Files\Bar" is on D:, or F: for that matter.
Real symlinks would go a long way here, but only as a kludge. They'd allow you to simulate a single-rooted file hierarchy inside of a multi-rooted hierarchy. Fundamentally programs should not care where their physical storage is, only where it is in the namespace. Exposing the physical devices in the namespace requires programs to take note of it, and makes it harder for you to upgrade or change configurations later.
--JoeNo, it's closer to being akin to complaining about all the billboards and noisy truck traffic that Interstates brought through previously residential neighborhoods.
You'd have to statically link ALL binaries, I'd think.
Apps that dynamically load libraries on the fly with dlopen() may have problems--dunno. Depends on whether dlopen requires ld-linux.so. I forget.
--Joe"Heat Watts" are "regular" Watts. If you dissipate 1000W for 1 second, that means you've put 1000 Joules of energy somewhere. Possibilities include:
Most of the energy we put into computers eventually comes back out as heat and electromagnetic radiation. (RFI and light from the monitor are both EM.) Even the mechanical energy in HD platters eventually dissipates as heat.
--JoeYou get a full 360 degrees of sine wave on the hot side. It's "1 phase" current.
If you look at the two outputs of the isolation transformer, you'll see two sine waves, 180 degrees apart, at half the magnitude. If you happen to tie one of the sides to ground, you'll get the same situation as the grounded outlet -- 1 phase at full magnitude.
In the end, it's only the potential difference between the two prongs that matters to the appliance.
--JoeI think what you're describing is metastasis, not malignancy.
A malignant tumor is a dangerous/damaging tumor. (The linked definition notes "tendency to metastasize" but that does not mean it is metastasizing. Kinda like HIV isn't AIDS, yet.) The opposite is benign, which means it's unusual but safe, kinda like scar tissue.
When a tumor metastasizes, it does precisely what you described: Sends out seed cells that establish hard-to-get-at tumors throughout the body.
--JoeI personally like the Mac/Win/Unix OS Peter's using in Office Space. Mac dialog boxes, UNIX desktop games, and a C:> prompt. (I don't remember if it showed a slash, and if so, which way it faced.)
Not in this case. Someone else pointed out that the ops are 8-bit multiplies and 8-bit accumulates. Floating point operations are significantly more expensive.
--JoeYou can build both digital and analog computers from analog components. Indeed, aside from "ideal switches", I'd argue that most circuit components are analog. The poster to which you responded is correct -- a system built around discrete levels selected from a continuous domain is considered digital. A system built around continuous levels is considered analog.
So, if you build a computer around 4-level signaling, it'd still be digital. Each signal corresponds to a "digit," likely valued 0 thru 3. If you built a differential-equation analyser out of op-amps, resistors, capacitors and inductors to represent the derivatives/integrals in your system of equations, and operated it within the linear region of the op-amps, you'd have an analog computer. Those aren't very popular anymore, nor have they been for some time.
The options you suggested a couple posts up are all variants of digital signaling. The first one is binary signaling. The second one is discrete amplitude modulation. The third one is multi-frequency discrete amplitude modulation.
The real question is, can you build large numbers of sufficiently small gates for a given signaling method? Additionally, do those gates aggregate into computing structures we know how to use effectively?
Related side topic: 3-valued logic (ternary computing) likely won't take off until its proponents have good answers for both questions. Something tells me the circuits and the gates are the smaller of the two problems. The change in programming paradigm is too big.
--JoeThe final stage of bootstrapping GCC is to have GCC build itself. So, if you're running a fully installed GCC 3.3.1, it's actually a GCC built with GCC 3.3.1.
--JoeThis page, down in the glossary, uses the definition you suggest. That is, it defines "times larger" as purely multiplicative. "Three times larger" means "tripled."
In contrast, Dr. Math agrees with me that "times larger" implies adding to the baseline. Dr. Math says '"Three times larger than N" means "4 * N" - but only if you stop to think about it, as many people do not.'
I think it's amply clear that "X times larger" is ambiguous without the data to disambiguate it. You have one group of people who thinks it clearly means one thing, and another that thinks it clearly means something else. It is therefore (maybe not-so-clearly) ambiguous. Dr. Math sums it up nicely:
--Joe"30% faster" means 1.3x the speed, right? It certainly does not mean 0.3x. "300% faster", then, means 4x the speed. "3 times faster" should also therefore mean 4x the speed.
In that first link you gave, the author says "three times as fast" in the body of the article, not "three times faster." "Three times as fast" means "one third the time," as I stated. (Whoever wrote the title line got it wrong. The author of the article uses "three times as fast" consistently throughout.) In that second link, they use "two to three times faster" to mean "200% to 300% increase", which means 1/3rd to 1/4th the required time, again consistent with my original post. (If you disagree with my interpretation of that second link's text, then do think that the "35% faster" note in the table implies a slowdown? They mention "two times faster" referring to values over 200% in their table, and so on.)
The reason I state it is ambiguous is that most people make the same mistake you did in the body of your post. "Three times faster" means 1/4th the time is required, not 1/3rd, even though many people use it to mean 1/3rd the time is required. "Three times as fast" means 1/3rd the time is required.
--JoeAlso, what do they mean by "2.5 times faster?" For instance, if a given benchmark takes 100 seconds with Samba, how many seconds does it take with Windows 2003? Some options:
I'd really like to see some actual numbers. "2.5x faster" reeks of vague, meaningless marketingspeak.
--JoeGoogle will translate it for you.
Even Ash knows what it means! Groovy!
--JoeActually, I think 'intr' and 'soft' have been mount options for, oh, say a decade or more?
Personally, I think a -o hard,intr mount is probably the right choice for most network mounts, and a -o soft mount is a polite option for remote, readonly filesystems shared by a larger crowd. (Almost nobody does that anymore. I believe wuarchive used to offer a read-only public NFS mount around 10 years ago.)
--JoeLook into -o intr and/or -o soft for your NFS mounts. From the man page:
Note that the statements "This is probably what you want" etc. in the quoted text above come from the man page, not me.
--JoeUhm, DynDNS has apparently modified their service to allow you to publish SPF records. Thus, if you have a vanity domain (why wouldn't you?), you could have them host the DNS for you and publish an SPF record. Voila, done.
If you're feeling cheap about it, find a bunch of other techie friend that are in the same boat, chip in on a single domain for all of you, and you're all good. Plus, you divide the cost N ways among N friends.
--JoeI believe the phrase is used correctly in a court context, wherein the council for one side can raise an objection to an answer stating that it is "begging the question, your honor."
As for "beggaring the question" being nonsense--have you ever searched for uses of that phrase? Look at the hits google brings up. It tends to be used more consistently to mean "answering the question with the question itself."
I personally have heard it used both correctly and incorrectly, although I have heard it used incorrectly more often. It really does grate on my ears though.
That doesn't justify the use, however. For example, here in Texas, for instance, I have heard the word "whenever" used in places where "when" is the correct word. Such as "Whenever I was in third grade, yadda yadda..." or "Whenever I was falling asleep last night..." and so on. Basically, the word "whenever" (which implies any of a multitude of equally interchangeable instances amongst a list of many general such occurrances) used in a context where "when" (which implies a specific instance) should of been used. For instance, you've likely only been in third grade once, and even if you repeated it more than once, it's not a general occurrance. You don't just decide to attend third grade this month for the heck of it. "Whenever" is supposed to be used when describing a general case, such as "Whenever I debate grammatical usage on Slashdot..."
--JoeI've been collecting up spam in order to start writing my own spam filter. (I was planning on taking the Bayesian approach to the next level and using a simple Markov model instead.) One of the things I noticed is that "ham" tends to confine itself to a predictable dictionary, whereas "spam" misses the dictionary fairly often. Thus, biasing unknown tokens towards "spam" should be a fairly cheap and effective filter.
--JoeHow about a simple layer of redirection to a form, with method "GET" instead of "POST" that is really just an HTML file with a proper mailto: link? Do spam bots chase form submission links too?
Such an approach should be effective against most bots, I'd suspect.
If you want to go a step further, just have some text somewhere on the page and a simple CGI on the other side of the form. "Enter this text into the form field below to reveal my email address."
Thoughts?
--Joe