You also have to pay close attention to the biological processes involved. One of the favorite "proofs" that evolution is all wrong and therefore the literal interpretation of the Christian book of Genesis *must* be accurate is the fact that some breed of oyster (or at least some type of clam) preferentially uses one isotope of carbon over another. It's enough so that you can pull an oyster from the ocean, eat most of the meat, and date the rest as thousands of years old.
I don't remember the mechanism involved, but it's something that makes sense to the scientists involved and they can account for it. But anyone who's only had the standard K-12 exposure to science would be utterly confused by the results.
IIRC, ISO-8601 is the spec for dates and times. It's 2002-07-04, or 2002W264 (if you prefer week numbers and days-of-week, plus variants for Julian days (not Julian Dates, which are entirely different), etc.
Most people who have tried it quickly like it. It's also trivial to sort dates without special logic.
Unfortunately, I think Windows apps may still not really support it. I remember trying to switch to it during Y2K, and a lot of programs barfed on this format (giving me an oh-so-useful blank field) even while working on silly formats like d/y/m.
Another point is that it's unnecessary to update more often than daily except for the most exacting situations. Do you really need to keep your clocks synchronized to within milliseconds? I've found daily updates against a time server (which is sync'd to my ISP's NTP source) via a cron job running 'rdate' is good enough to keep my systems synced to within a second.
The other nice thing about this aproach is that it's easy to toss the Windows equivalence of 'rdate' into the startup scripts managed by Samba, so whenever a Windows box comes onto the network it's also synced.
If you're concerned about security, it's not hard to toss a second NIC into a trusted system and set up a daemon to handle a bounce queue. That queue can handle encryption and authentication, and the printer itself is sitting on a crossover cable connected only to that trusted print server.
Unstated assumptions
on
Secure Printing?
·
· Score: 3, Insightful
LPRng seems to support Kerberos, but I don't know if it provides data encryption or is just used for authentication. I've also been playing around with the idea of adding direct SSL support to LPRng as an experiment, but it would probably only work with this bounce queues from another system.
The reason I'm mentioning this is to point out the unstated assumption that the worst that happens is that somebody can sniff the traffic to your printer. To me, that takes a distance back seat to the risk that somebody could impersonate your printer or feed it additional jobs.
As an example of this, imagine a shared printer in the sales department where someone has quietly changed the IP address - the print jobs are actually going to a laptop hidden in a closet where they'er spooled off to a competitor before being forwarded to the expected printer.
Or imagine monthly checks being spooled to the same system where the attacker can learn exactly who you get services from... and/or insert checks to dummy organizations they control into the data stream.
You can use SSL tunnels to provide a measure of confidentiality, but if you're serious about security you really need to be thinking about autheticating the printer (and possibly clients as well).
Do you know where you can get approximate (single-quantity) prices along with product descriptions? Even something in a reasonably-large band ($250-400, 400-750, 750-1000, etc.) would be enough to rule out some SBCs for some applications.
All of the sites I've found will give you everything you could possibly want except the price... despite the fact that price is the critical factor in many applications. E.g., if you want to experiment with an intelligent firewall, you'll need to focus on SBCs in the sub-400 range since you can get a COTS box for under $100.
I know most sites want me to talk to their sales rep, but I think that's a waste of time for both of us when the anticipated volume can be counted on the fingers of one hand. Just tell me the price with a single-unit premium.
I gotta stop multitasking - that's 6 and 24, not 6 and 4. The '...4' becomes '...40' and we need to add 24 (not 4) to get it back to a '...64' pattern.
It was an informal inductive proof. Find any x, y such that x/y = 1/4 and you satisfy the other conditions listed. The proof says that x:6/6:y (where ':' indicates concatenation of the digits) is also equal to 4. It says nothing at all about whether any values of x, y exist that satisfy that relation, but in this case we already know about 16/64.
(As I mentioned elsewhere, the '4' was a typo. I can divide 24 by 6...)
I know how to write a formal proof by induction, but I didn't have the time to figure out the most general case and (wrongly) assumed everyone would recognize the back-of-the-envelope inductive proof.
Mathematics is one of those fields where there's a huge variety of topics covered by a single label. What does "math" mean to you, and what are you interested in?
If you're interested in calculus (differential equations, dynamic systems, chaos, etc.), you would probably be best served by getting a current university calculus book and Maple/MathLab/Mathematica/whatever and working through it. The software handles the mechanical aspects of the process and you'll probably find the material easier to pick up than before.
Same thing if you're interested in number theory (cryptology, matrices, etc.) If you get an introductory text designed to work with one of these programs it will handle the mechanical grunt work and allow you to focus on the concepts.
If your interest is precalculus (algebra, trig, etc.), you may be better off working through the problems by hand. You want the software to be a tool, not a crutch, and one of the main reasons for the usual introductory sequence (up through PDQ) is just to train the students how to reliably perform the necessary work.
Most of the laws we need already exist, but some people have tried to claim otherwise for their own benefit.
Say someone is a child rapist? Just because it's said online doesn't mean it's not actionable (unless the person really was convicted of raping a child), but some of the internet kooks routinely did that.
A pyramid chain letter is still illegal even if it's distributed by email, but it took a number of prosecutions by the FTC and Postal Inspector to convince many people of that.
As for the argument that destroying data causes no harm because the owner can restore it, that's flat-out wrong. There are some businesses that can literally lose a million dollars every minute their computers are down (think airline reservation system, other big-ticket high-volume retailers), and most businesses will suffer real losses until the data is restored. To say nothing of data permanently lost because it's not yet backed up - 100% stable storage is extremely expensive.
If you still think it's no big deal, tell us where you live and we'll "move" your car for you. You'll get it back, eventually, so it's no harm when you're unable to use it to get to work or to go out on your hot date.
Cars introduced new laws (e.g., the infamous "red flag/red lantern" law in Britain), but it didn't invalidate any of the earlier laws.
If you couldn't cut across a field with horse and buggy, you couldn't cut across a field in your new car.
If you horse trampled a child and caused injury, you were responsible. If your car ran over a child and caused injury, you were responsible.
If you couldn't transport something in your horse-drawn buggy (e.g., moonshine), you couldn't transport it in your car.
In contrast, a lot of sleazy characters <i>are</i> attempting to claim that commonsense laws don't apply to the net. E.g., how many pyramid scheme letters did you get that were "legal" since they didn't use the mail. Too bad the Postal Inspector held that he did have jurisdiction since they used the postal mail to get the money! How many companies continue to push illegal products (drugs, both prescription and illicit), or "low rate" insurance which has a low rate because you'll never have a claim paid, or any of the other scams in circulation. Or how about the companies that are fradulently impersonating third parties to get past the spam filters. (Want to see the bounce messages for fradulent messages sent out "by" my company?)
Even the new laws that the 'net does need should be informed by historic precedence. The specifics are, but almost none of the concepts haven't been seen repeatedly over the past few centuries.
There's a similar story circulating, perhaps in the Jargon files. A guy gets a report that the system will allow the operators to log in when they're sitting at the console, but not when they're standing.
This makes no sense - there's absolutely no connection between the seat (or raised floor) and the system. How could it possibly know whether the person was standing or sitting?
The answer was in the keyboard. Somebody had dropped it and put the n and m keys back in the wrong place. While sitting, the operators could touch-type and they hit the right keys. But when standing, they had to look at the keys since they didn't have the muscle memory in this position to touch type. The two keys were in about the right place, they look similar, and nobody noticed that there was a problem with the keyboard.
The story has a fun personal touch since years before I heard about it I did the same thing with the office phone. We accidently dropped it, and as a joke I put the keys back in the standard calculator/keyboard layout, not the telephone layout. We all knew the numbers were reversed and could dial the right numbers, but one day a phone guy was in the office for some reason and got a very strange look on his face when he saw the phone. He insisted on "fixing" it.
They also had some serious practical considerations. They couldn't hold public office, or public service jobs, or attend university, or participate in many other sectors of public life. Life was great if you wanted to remain a serf on the lord's (with a little 'l') land, but if you wanted anything better for your children and grandchildren you needed to get out of there.
It's interesting to speak with a true conservative/fundamentalist, not the twits you see on TV.
What you noticed is actually a serious concern - the pledge, the "flag descration" bills, etc., all add up to a single thing in their mind. Idolatry. It's not a golden calf at the base of Mt. Nebo, but the mindset, the fixation on a concrete symbol instead of the abstract concepts behind it, are the same.
Unfortunately, when they speak up they get dumped on by both sides. Many liberals have also been brainwashed into believing that they have to reject all religious arguments on principal, instead of accepting that the rationale may seem a bit odd to us but the conclusions are the same so why worry?
It's much stronger than that. Many early American colonists from the United Kingdom were not members of the Church of England - they were Pilgrims (Anabaptists?), Quakers (Society of Friends), etc.
Under British law, they could not work for the crown. They could not attend university. (Remember, until recently the *only* degree granted by British universities was a Doctorate of Divinity with concurrent ordination in the Church of England. That's why it was the Rev. Charles Darwin who came up with those radical ideas regarding human evolution.) They were excluded from almost all aspects of public life.
The framers of the US Constitution were very much aware of this recent history (to them), and they were emphantic in their intent that the US never require membership in a state religion to hold office or otherwise participate in social life. Some states (e.g., Georgia) have clauses in their state constitutions requiring that all officeholders be Christians in good standing (whatever that means), but these clauses haven't been considered enforceable for many generations.
If you think it's weird now, wait until you learn that many of our learned representatives were outraged that foreign nationals in our schools didn't want to recite any pledge of allegiance to the US. These kids aren't common, but they are present because their parents are working in the US for their overseas employer, are in foreign military units stationed at US bases or attached to Ameriacn units, are diplomats, etc.
inc vs. add
on
Pet Bugs?
·
· Score: 3, Interesting
When I was in college, we had an introductory class to digital logic (for physics majors) with the emphasis on switches, latches, etc. We also had a single-board processor (8080) that we programmed with hand-assembled code punched into the hex keypad - one of our first projects was *always* to set up a binary->7 segment display encoder so we could read hex output instead of the binary.
Anyway, our instructors were physics profs who focused on the hardware and never really put any effort into describing the instructions available on an 8080. We had been working at an extremely low level of logic design. At one point we had to write a program to add two numbers and display the results, and I actually wrote one looking something like
l1: inc ax
dec bx
jnz l1
I was truly dreading doing multiplication and division, but fortunately someone pointed out the basic math opcodes first.
I'm showing my age, but I've seen loaders that failed to initialize the BSS segment to zero. If you don't initialize a value, it would have a random value. Since this was DOS 5.x, everyone shared the same real memory space so you would have bits of whatever other program had been run recently.
(I also recall this happening with Ada, but I can't remember if that behavior was specified by the language.)
We had fun trying to convince people that this was the real problem. What finally worked was me writing a couple of very small assembly routines that wrote 00 or FFh to all memory from just past the end of the program to the top of memory. If we cleared memory, we could reliably eliminate the bugs. If we set the memory to FFh, we could reliably produce the buggy behavior.
Naturally, one of the managers wanted to fix the problem by just running my memory clearer every time before running the application.
Round to even is not expensive
on
Pet Bugs?
·
· Score: 2
Round to even is not expensive, at least when you're talking about the binary computations in hardware that the IEEE routines address. In this case you just need a lookup table with your guard bits and the last significant digit. Even with 7 guard bits, that's a table with only 256 possible results (do nothing, decrement or increment). With RTE you may only need "do nothing" and "increment."
Of course, this is just the rounding performed by a single calculation. Most coprocessors use a few extra bytes over what they publish, e.g., the registers for a IEEE double (64 bits) will actually be 80 bits long.
One option that seems to work fairly well, if you have the resources, is to set up a local news spool, then filter out the crap locally. With a local spool, you can perform checks that are too expensive to perform in the reader, e.g., not just verifying a valid looking sender, but actually performing A and MX record lookups for the domain to eliminate one class of spamware. (Unfortunately other spamware sees nothing wrong with criminally impersonating innocent third parties, but there are other ways to catch them.) Or you could do some regular expression matching looking for suspicious phrases, decoding uuencoded/base64-encoded blocks to check for viral loads, etc.
If you decide to do this, you can usually perform the tests during the ingest process (if it's always running), or as a daemon that periodically runs and checks the most recent messages.
The results can be staggering. I was doing this on a couple alt.* groups as a test, and a few simple rules could reduce the SNR from about 1-in-20 messages to about 2-in-3 messages. More importantly, this approach tends to eliminate the stuff that's mindlessly repeated hundreds of times. Most people don't mind getting a spam message once, but seeing the 247th identical message to make your breasts and penis larger (*who* needs this stuff?!) can make anyone lose it.
Your question, and the answers, have confused apples and oranges. They look similar (round, fruit), but there are some key differences.
Specifically, you could use a tunnel (stunnel, ssh), or you can use applications that directly support SSL. Setting up the applications takes a bit of research since it hasn't been standardized yet, but it's not too hard once you figure out where the documentation has been hidden. (Sometimes in the source code. *grrr*.) Setting up a tunnel is probably a bit easier, but it requires that the server explicitly provide a tunnel.
The benefits of a tunnel is that it provides a "one size fits all" solution - if you can do it for one application, you can do it for others. More importantly, you can use it with applications that don't yet support SSL directly.
The benefits of direct SSL support is that the clients can almost always verify the identity of the server (it is possible to set up a server so it doesn't require an X.509 certificate, but it's much more common for the server to require one). Optionally, the server can require that clients provide a certificate to identify themselves.
If you control the server, the choice may come down to authentication and identity. If you don't care who connects, or who they connect to, e.g., because you'll be using (username,password) to log in, you should probably go with a tunnel. If you need to establish identity, or want to use a "login-less" mechanism, you should probably go with direct SSL and possibly require client certs.
Wouldn't the "closest" approach title belong to one of the asteroids that actually struck us?
A bit more seriously, I thought that there was actually at least one near-impact in Colorado in the 1970s where an object passed through the upper atmosphere, producing a fireball visible in daylight, before escaping back into space.
Slashdot Mirror
You also have to pay close attention to the biological processes involved. One of the favorite "proofs" that evolution is all wrong and therefore the literal interpretation of the Christian book of Genesis *must* be accurate is the fact that some breed of oyster (or at least some type of clam) preferentially uses one isotope of carbon over another. It's enough so that you can pull an oyster from the ocean, eat most of the meat, and date the rest as thousands of years old.
I don't remember the mechanism involved, but it's something that makes sense to the scientists involved and they can account for it. But anyone who's only had the standard K-12 exposure to science would be utterly confused by the results.
IIRC, ISO-8601 is the spec for dates and times. It's 2002-07-04, or 2002W264 (if you prefer week numbers and days-of-week, plus variants for Julian days (not Julian Dates, which are entirely different), etc.
Most people who have tried it quickly like it. It's also trivial to sort dates without special logic.
Unfortunately, I think Windows apps may still not really support it. I remember trying to switch to it during Y2K, and a lot of programs barfed on this format (giving me an oh-so-useful blank field) even while working on silly formats like d/y/m.
Another point is that it's unnecessary to update more often than daily except for the most exacting situations. Do you really need to keep your clocks synchronized to within milliseconds? I've found daily updates against a time server (which is sync'd to my ISP's NTP source) via a cron job running 'rdate' is good enough to keep my systems synced to within a second.
The other nice thing about this aproach is that it's easy to toss the Windows equivalence of 'rdate' into the startup scripts managed by Samba, so whenever a Windows box comes onto the network it's also synced.
If you're concerned about security, it's not hard to toss a second NIC into a trusted system and set up a daemon to handle a bounce queue. That queue can handle encryption and authentication, and the printer itself is sitting on a crossover cable connected only to that trusted print server.
LPRng seems to support Kerberos, but I don't know if it provides data encryption or is just used for authentication. I've also been playing around with the idea of adding direct SSL support to LPRng as an experiment, but it would probably only work with this bounce queues from another system.
The reason I'm mentioning this is to point out the unstated assumption that the worst that happens is that somebody can sniff the traffic to your printer. To me, that takes a distance back seat to the risk that somebody could impersonate your printer or feed it additional jobs.
As an example of this, imagine a shared printer in the sales department where someone has quietly changed the IP address - the print jobs are actually going to a laptop hidden in a closet where they'er spooled off to a competitor before being forwarded to the expected printer.
Or imagine monthly checks being spooled to the same system where the attacker can learn exactly who you get services from... and/or insert checks to dummy organizations they control into the data stream.
You can use SSL tunnels to provide a measure of confidentiality, but if you're serious about security you really need to be thinking about autheticating the printer (and possibly clients as well).
Do you know where you can get approximate (single-quantity) prices along with product descriptions? Even something in a reasonably-large band ($250-400, 400-750, 750-1000, etc.) would be enough to rule out some SBCs for some applications.
All of the sites I've found will give you everything you could possibly want except the price... despite the fact that price is the critical factor in many applications. E.g., if you want to experiment with an intelligent firewall, you'll need to focus on SBCs in the sub-400 range since you can get a COTS box for under $100.
I know most sites want me to talk to their sales rep, but I think that's a waste of time for both of us when the anticipated volume can be counted on the fingers of one hand. Just tell me the price with a single-unit premium.
I gotta stop multitasking - that's 6 and 24, not 6 and 4. The '...4' becomes '...40' and we need to add 24 (not 4) to get it back to a '...64' pattern.
It was an informal inductive proof. Find any x, y such that x/y = 1/4 and you satisfy the other conditions listed. The proof says that x:6/6:y (where ':' indicates concatenation of the digits) is also equal to 4. It says nothing at all about whether any values of x, y exist that satisfy that relation, but in this case we already know about 16/64.
(As I mentioned elsewhere, the '4' was a typo. I can divide 24 by 6...)
I know how to write a formal proof by induction, but I didn't have the time to figure out the most general case and (wrongly) assumed everyone would recognize the back-of-the-envelope inductive proof.
Exists x, y, n such that nx = y.
Let x' = 10x + a, y' = 10y + b.
Then...
where this particular set is n = 4, a = 6, b = 4.
It was a typo. I can divide 24 by 6, despite the evidence to the contrary.
Assume x/y = 1/4, and x ends with 6 and y starts with 6 and ends with 4.
Let x' = 10x + 6. This essentially adds a '6' to the end of the numerator.
Let y' = 10y + 24. This essentially adds a '6' to the start of the denominator.
Then x'/y' = (10x + 6) / (10y + 24) = (10x + 6) / (40x + 24) = 1/4 [(10x + 6)/(10x + 4)] = 1/4.
Mathematics is one of those fields where there's a huge variety of topics covered by a single label. What does "math" mean to you, and what are you interested in?
If you're interested in calculus (differential equations, dynamic systems, chaos, etc.), you would probably be best served by getting a current university calculus book and Maple/MathLab/Mathematica/whatever and working through it. The software handles the mechanical aspects of the process and you'll probably find the material easier to pick up than before.
Same thing if you're interested in number theory (cryptology, matrices, etc.) If you get an introductory text designed to work with one of these programs it will handle the mechanical grunt work and allow you to focus on the concepts.
If your interest is precalculus (algebra, trig, etc.), you may be better off working through the problems by hand. You want the software to be a tool, not a crutch, and one of the main reasons for the usual introductory sequence (up through PDQ) is just to train the students how to reliably perform the necessary work.
Most of the laws we need already exist, but some people have tried to claim otherwise for their own benefit.
Say someone is a child rapist? Just because it's said online doesn't mean it's not actionable (unless the person really was convicted of raping a child), but some of the internet kooks routinely did that.
A pyramid chain letter is still illegal even if it's distributed by email, but it took a number of prosecutions by the FTC and Postal Inspector to convince many people of that.
As for the argument that destroying data causes no harm because the owner can restore it, that's flat-out wrong. There are some businesses that can literally lose a million dollars every minute their computers are down (think airline reservation system, other big-ticket high-volume retailers), and most businesses will suffer real losses until the data is restored. To say nothing of data permanently lost because it's not yet backed up - 100% stable storage is extremely expensive.
If you still think it's no big deal, tell us where you live and we'll "move" your car for you. You'll get it back, eventually, so it's no harm when you're unable to use it to get to work or to go out on your hot date.
Your analogy proves their point.
Cars introduced new laws (e.g., the infamous "red flag/red lantern" law in Britain), but it didn't invalidate any of the earlier laws.
If you couldn't cut across a field with horse and buggy, you couldn't cut across a field in your new car.
If you horse trampled a child and caused injury, you were responsible. If your car ran over a child and caused injury, you were responsible.
If you couldn't transport something in your horse-drawn buggy (e.g., moonshine), you couldn't transport it in your car.
In contrast, a lot of sleazy characters <i>are</i> attempting to claim that commonsense laws don't apply to the net. E.g., how many pyramid scheme letters did you get that were "legal" since they didn't use the mail. Too bad the Postal Inspector held that he did have jurisdiction since they used the postal mail to get the money! How many companies continue to push illegal products (drugs, both prescription and illicit), or "low rate" insurance which has a low rate because you'll never have a claim paid, or any of the other scams in circulation. Or how about the companies that are fradulently impersonating third parties to get past the spam filters. (Want to see the bounce messages for fradulent messages sent out "by" my company?)
Even the new laws that the 'net does need should be informed by historic precedence. The specifics are, but almost none of the concepts haven't been seen repeatedly over the past few centuries.
There's a similar story circulating, perhaps in the Jargon files. A guy gets a report that the system will allow the operators to log in when they're sitting at the console, but not when they're standing.
This makes no sense - there's absolutely no connection between the seat (or raised floor) and the system. How could it possibly know whether the person was standing or sitting?
The answer was in the keyboard. Somebody had dropped it and put the n and m keys back in the wrong place. While sitting, the operators could touch-type and they hit the right keys. But when standing, they had to look at the keys since they didn't have the muscle memory in this position to touch type. The two keys were in about the right place, they look similar, and nobody noticed that there was a problem with the keyboard.
The story has a fun personal touch since years before I heard about it I did the same thing with the office phone. We accidently dropped it, and as a joke I put the keys back in the standard calculator/keyboard layout, not the telephone layout. We all knew the numbers were reversed and could dial the right numbers, but one day a phone guy was in the office for some reason and got a very strange look on his face when he saw the phone. He insisted on "fixing" it.
They also had some serious practical considerations. They couldn't hold public office, or public service jobs, or attend university, or participate in many other sectors of public life. Life was great if you wanted to remain a serf on the lord's (with a little 'l') land, but if you wanted anything better for your children and grandchildren you needed to get out of there.
It's interesting to speak with a true conservative/fundamentalist, not the twits you see on TV.
What you noticed is actually a serious concern - the pledge, the "flag descration" bills, etc., all add up to a single thing in their mind. Idolatry. It's not a golden calf at the base of Mt. Nebo, but the mindset, the fixation on a concrete symbol instead of the abstract concepts behind it, are the same.
Unfortunately, when they speak up they get dumped on by both sides. Many liberals have also been brainwashed into believing that they have to reject all religious arguments on principal, instead of accepting that the rationale may seem a bit odd to us but the conclusions are the same so why worry?
It's much stronger than that. Many early American colonists from the United Kingdom were not members of the Church of England - they were Pilgrims (Anabaptists?), Quakers (Society of Friends), etc.
Under British law, they could not work for the crown. They could not attend university. (Remember, until recently the *only* degree granted by British universities was a Doctorate of Divinity with concurrent ordination in the Church of England. That's why it was the Rev. Charles Darwin who came up with those radical ideas regarding human evolution.) They were excluded from almost all aspects of public life.
The framers of the US Constitution were very much aware of this recent history (to them), and they were emphantic in their intent that the US never require membership in a state religion to hold office or otherwise participate in social life. Some states (e.g., Georgia) have clauses in their state constitutions requiring that all officeholders be Christians in good standing (whatever that means), but these clauses haven't been considered enforceable for many generations.
If you think it's weird now, wait until you learn that many of our learned representatives were outraged that foreign nationals in our schools didn't want to recite any pledge of allegiance to the US. These kids aren't common, but they are present because their parents are working in the US for their overseas employer, are in foreign military units stationed at US bases or attached to Ameriacn units, are diplomats, etc.
Anyway, our instructors were physics profs who focused on the hardware and never really put any effort into describing the instructions available on an 8080. We had been working at an extremely low level of logic design. At one point we had to write a program to add two numbers and display the results, and I actually wrote one looking something like
I was truly dreading doing multiplication and division, but fortunately someone pointed out the basic math opcodes first.
I'm showing my age, but I've seen loaders that failed to initialize the BSS segment to zero. If you don't initialize a value, it would have a random value. Since this was DOS 5.x, everyone shared the same real memory space so you would have bits of whatever other program had been run recently.
(I also recall this happening with Ada, but I can't remember if that behavior was specified by the language.)
We had fun trying to convince people that this was the real problem. What finally worked was me writing a couple of very small assembly routines that wrote 00 or FFh to all memory from just past the end of the program to the top of memory. If we cleared memory, we could reliably eliminate the bugs. If we set the memory to FFh, we could reliably produce the buggy behavior.
Naturally, one of the managers wanted to fix the problem by just running my memory clearer every time before running the application.
Round to even is not expensive, at least when you're talking about the binary computations in hardware that the IEEE routines address. In this case you just need a lookup table with your guard bits and the last significant digit. Even with 7 guard bits, that's a table with only 256 possible results (do nothing, decrement or increment). With RTE you may only need "do nothing" and "increment."
Of course, this is just the rounding performed by a single calculation. Most coprocessors use a few extra bytes over what they publish, e.g., the registers for a IEEE double (64 bits) will actually be 80 bits long.
One option that seems to work fairly well, if you have the resources, is to set up a local news spool, then filter out the crap locally. With a local spool, you can perform checks that are too expensive to perform in the reader, e.g., not just verifying a valid looking sender, but actually performing A and MX record lookups for the domain to eliminate one class of spamware. (Unfortunately other spamware sees nothing wrong with criminally impersonating innocent third parties, but there are other ways to catch them.) Or you could do some regular expression matching looking for suspicious phrases, decoding uuencoded/base64-encoded blocks to check for viral loads, etc.
If you decide to do this, you can usually perform the tests during the ingest process (if it's always running), or as a daemon that periodically runs and checks the most recent messages.
The results can be staggering. I was doing this on a couple alt.* groups as a test, and a few simple rules could reduce the SNR from about 1-in-20 messages to about 2-in-3 messages. More importantly, this approach tends to eliminate the stuff that's mindlessly repeated hundreds of times. Most people don't mind getting a spam message once, but seeing the 247th identical message to make your breasts and penis larger (*who* needs this stuff?!) can make anyone lose it.
Your question, and the answers, have confused apples and oranges. They look similar (round, fruit), but there are some key differences.
Specifically, you could use a tunnel (stunnel, ssh), or you can use applications that directly support SSL. Setting up the applications takes a bit of research since it hasn't been standardized yet, but it's not too hard once you figure out where the documentation has been hidden. (Sometimes in the source code. *grrr*.) Setting up a tunnel is probably a bit easier, but it requires that the server explicitly provide a tunnel.
The benefits of a tunnel is that it provides a "one size fits all" solution - if you can do it for one application, you can do it for others. More importantly, you can use it with applications that don't yet support SSL directly.
The benefits of direct SSL support is that the clients can almost always verify the identity of the server (it is possible to set up a server so it doesn't require an X.509 certificate, but it's much more common for the server to require one). Optionally, the server can require that clients provide a certificate to identify themselves.
If you control the server, the choice may come down to authentication and identity. If you don't care who connects, or who they connect to, e.g., because you'll be using (username,password) to log in, you should probably go with a tunnel. If you need to establish identity, or want to use a "login-less" mechanism, you should probably go with direct SSL and possibly require client certs.
Wouldn't the "closest" approach title belong to one of the asteroids that actually struck us?
A bit more seriously, I thought that there was actually at least one near-impact in Colorado in the 1970s where an object passed through the upper atmosphere, producing a fireball visible in daylight, before escaping back into space.