You know, it's almost a shame to screw up the amusing notions/.ers come up with by adding actual information, but I can't help it, all those years of teaching I guess.
Okay, first of all: "mean time between failures" is obviously a statistical measure -- it is an average over a large number of individual items. In most electronic components (including light bulbs!) the statistical distribution of the time between failures is the exponential distribution, which has the odd property that it's "memory-less" -- it doesn't matter how long since the last failure it's been, the mean time to the next failure will still be the same. A consequence of this is that if the MTBF is 10,000 hours, the probability of failure in any particular hour would be 1/10,000th. So, if you set up 10,000 components, all running simultaneously, you'd expect one of them to fail within the first hour; conversely, if you ran them for 1000 hours, and 998 of them failed, you could be fairly certain that the MTBF would be around 10,000 hours.
Note, by the way, that this is only true when the failure time distribution is exponential -- so it works for electronic components, but not for, say, bicycles and cars and roller skates, which are more likely to fail the older they get.
This has an obvious problem, of course: if the MTBF is high, it can take forever to test. Consider, for example, something I worked on for NASA some years ago: trying to prove that a fly-by-wire system will have a mean time between failures of 1e10 hours. (This is about the same failure rte as the airframe, which is how they came up with the number.) 1e10 hours is about 1.141 million years, by the way.
(Pop quiz: if MTBF is a million years, how do you explain the occasional airframe failure, say, eg TWA 800? Hint: It doesn't require any foul play.)
At that point, you've got a couple of choices: first, you can make a lot of copies and run them simultaneously. Relatively easy for $50 disks, hard for billion dollar 747s.
Second, you can make the estimate by computation and modeling which is what you do for web systems. Conceptually, it's pretty simple to do this, although it can be a kind of pain in the ass.
The third way, which is new and cool, is by Bayesian estimation of failure rates. This method lets you make increasingly accurate estimates of the failure rate based on short experiments. I don't have time to go into it, but there are some good sources available on the web.
And, in fact, Tethers Unlimited, the company proposing this beast, was founded by scientist, engineer and science fiction writer Dr Robert L Forward. Sadly, Dr Forward died last September.
With hard-drive costs less than $1 a GIGABYTE (you younger folks have NO IDEA how impossible that sounds) I'm not sure that keeping file deltas is worth the effort any longer. VMS versioning was fairly straightforward and you didn't HAVE to look at all the back versions: if I recall the syntax correctly, 'dir foo.*;-3' would show you the three most recent versions (don't bother to flame me if I'm wrong, it's been 20 years) and a DCL macro would let you make it easy. Add to that a way to transparently archive the files to WORM, like Plan/9 does, and you're in fat city.
The OpenGroup (which used to be X/Open) is a nonprofit, like the FSF, which owns the trademark and licenses it when a system has successfully passed a compatibility test. The notion is that any UNIX should be (at least approximately) compatible. I'm not at all sure if Linux could pass, since it has, eg, a rename(2) system call in place of unlink. The money that OpenGroup gets is used to continue their standards operation. See
What the OpenGroup doesn't do is support open source per se -- unlike GPL'ed code, you can be OpenGroup certified and still be closed source. Bad bad OpenGroup, they're not RMS-correct.
Okay, AIX is a UNIX because IBM got it certified against SvR4; OpenGroup has the UNIX trademark because AT&T sold it to Novell (UnixWare) which gave it to OpenGroup; SCO has the UnixWare code base because they bought it(+/- copyrights, trademarks, trade secrets, and customized mouse pads) from Novell; and SCO is suing IBM about AIX.
Changing positions like that may well help, but be warned that the explanation they give is, well, crap. RSI isn't really well understood, but (in the case of carpal tunnel disease) it's pretty certainly not because of lack of blood flow.
As to the issue about moving the arm rather than the fingers, those of us who are old enough to have had real penmanship classes remember that this is the way we were taught to write, too. After my own bout of RSI (caused by playing rogue for about 36 hours straight during grad school) I retrained myself to keep my wrists straight while typing (instead of resting them on the keyboard) and to use my armj rather than my hand for the mouse, and have since had no trouble.
In a fair number of cases, it's stupidity that does it. Example: back when I worked for Sun, one of our customers was A Big Speciality Retailer (I'm a little limited here, but ABRS sells stuff that is big at Christmas for small humans, okay?) The CEO, P.H. Boss, had decided that a web presence was the Next Big Thing, so he'd hired a couple guys to build a web site, which they did in good ars Technica fashion, using tcl on a little bitty Sun server -- as I recall it was a single processor desktop box, like a 250. Connected to a DSL line, I believe.
Mr. Boss thought this was such a great site that he went out and made a $50 million advertising buy, nationally, starting at Thanksgiving. What he didn't do was tell the technical people.
The result was that everyone's mom left the Thanksgiving football games, logged on and tried to hit the server. Later measures suggested the server peaked at more than 1000 hits/sec. Needless to say, this served as a very effective smoke test, and sure enough the server smoked.
Old P.H. was most disturbed with the technical people, with Sun, and with the whole web thing -- he couldn't understand why he couldn't spend $10K on a web site and $50 million on advertising and get perfect performance.
It's a terminology quibble on what's otherwise an insightful post, but a secure system (to the extent it means anything at all) is a system that protects things to the level which the security policy requires.
A system that keeps its promises (nice phrase) is a good description of a trusted system.
(The history of this all goes back to the old Trusted Computing System Evaluation Criteria (TCSEC), also known as the "Orange Book.")
In order to have a secure system, you need a security policy to determine what's required, and you need a system that can be trusted to do what the policy requires.
What you say about Microsoft's "trusted computing" initiative is just right, however. Palladium and the Trusted Computing Initiative have nothing much to do with enforcing your security policy, and everything to do with enforcing Microsoft's digital rights management policy.
It could be done (someone else mentioned the cat experiments) but long before you got the resolution of the eye, you'd run into something we used to call the "pincushion problem" -- by the time you've got enough electrodes to capture the information, you no longer have the tissue of interest, you have a pincushion -- and pincushions don't act like normal tissue.
But let's assume you did it somehow (nanotech, maybe -- everyone knows nanotech can do ANY magic desired). The eye isn't really like a digital camera at all: each of the sensory cells has a photosensitive dye called rhodopsin which is bleached out by exposure to light, in the process changing its electrical properties. (What I recall is that it liberates electrons, but look it up as I'm not certain.) This degree of bleaching is what produces the signal, which becomes encoded as a series of pulses on the optical neurons.
This sounds like a digital signal, but it's more complicated than that, because the rhodopsin regenerates slowly -- this is why it takes minutes to get your night vision back after exposure to light. The cells in the retina communicate among themselves as well. The result is that the signal from the retina is... well, weird.
The point is that while you might be able to make it work (if you solve the pincushion problem) you wouldn't gain much, because the eye is a crappy camera. It's the signal processing afterwards that's good. If you want to really get a good representation of what the "eye" sees -- or rather what the brain sees -- you ought to use a good digital camera, and try to figure out the signal processing instead,
There is no such thing as being too anal retentive with reference to the words of a law. Cf. "that depends on what the meaning if 'is' is".
This is not intended as an anti-Clinton troll (although I'll be happy to post one if anyone needs one). Being anal-retentive about the wording is what one does in the law; if there is any conceivable way in which a law can be interpreted (technically called the "theory" of the prosecution) then you can be tried. If you're charged and tried, whether you are convicted or not, you may lose your job, bankrupt yourself in your defense, generally have your life ruined -- and under "sovereign immunity" you can't recover except for really specific and egregious abuses.
If you want disinterested, you're not gonna find it. Everyone has some interest or another.
If you want good, complete information, watch/read several sources and integrate it yourself; you'll probably be disappointed, since that seems to correlate pretty well with what the major news sources tell you.
If your definition of "unbiased" is "unpatriotic" -- or at least "anti-Allied" -- then why bother with looking for unbiased sources that might screw up your assumptions?
The first thing you've `got to do is stop thinking about how you're going to buy a couple of boxes and that'll make your network, because, Bullwinkle, that trick never works. Except, at least, for those of us who consult for a living, because we often get gigs out of saving someone's shorts from the George Foreman.
Now, back up and think about this:
who will use the machines on the network?
what will they be doing?
In your case, you're talking primarily about engineers, and they are primarily (for job functions) going to be doing engineering... which means (this is not sarcasm) that they will spend anywhere from 2-4 hours a day interacting with their tools of choice for circuits and engineering, and the remainging time with web browsers, email programs, etc., particularly including word processors or the like. Since you're starting with a Sun network, you at least have confidence that everything people would normally use is UNIX-able.
Now, on you EXISTING network, measure what a few users do for at least a few days. If you've got admin on, you should be able to extract information from the logs. This will give you a chance to get at how much load there really is.
Next task: establish some of your "non-functional" requirements. In particular, how long can response time be for your most important tools, how long can you afford to have the system as a whole be unavailable, and how much work (an hour, half a day, a week?) can you afford to lose. Divide all of those by two and make them your basic "service level agreement" -- which is simply a statement of the service you promise the users, it doesn't have to be fancy.
Here are some reasonable values, from experience, but YMMV: most people will put up with the whole system being unavailable for an hour, they want half-second response time from specialized tools and more like about 4 seconds on a web page, and engineers hate losing ANYTHING but usually don't get too pissed off if it's less than a couple of hours work and doesn't happen very often.
Next: what's the environment? Do you have to think about firewalling yourself from the rest of the network? (Don't assumme just because you're inside the corporate firewall that you're protected. Get AND READ the corporate security policy, as well as talking with the admins who own the network as a whole.) How will you do backups? How do you fit into the corporate disaster planning scheme? (Lots of people forget that one, but just look into what happened to the Wall Street Journal on 9/11 to see how essential it really is.) This analysis will give you a good idea what you need.
And now, having said all that, it will turn out that what you're going to need is (1) a "big enough" file server with 5/4 RAID and a good periodic backup onto "archival media" like tapes or writeable CDs; (2) one workstation good enough for all your applications, and with at least a years' room for growth, for each desktop (plan to buy at leasy one for a spare, and set it up "hot" so a single failure doesn't slow anyone down"); (3) a smallish box as a print server (if you manage your own email, it can often go onto this); and (4) a firewall box or a router (betcha 50 cents Canadian that the company will insist on this.)
Plan for a full week, plus one day per user workstation, for installation. That is, with 4 users, plan on 5 + 4 = 9 days for two people.
All the other stuff, like using NIS, NFS, Kerberos, etc, will more or less fall out if you get these steps right first.
Well, if there're thousands of people to mail them out, some of them are likely to be in the DC area, don't you think?
But let's take your random-mailing notion seriously for a moment. To capture the majority of employees at FBI, CIA, NSA -- the groups that use most polygraph clearances -- you've got to cover all of both the DC and Baltimore metro areas, (remember that lots of people commute from B'more, especially to NSA which is actually closer to B'more than downtown DC.) Several web sources seem to suggest a total population in the neighborhood of 8 million, and DoJ says the total employment of FBI is about 128,000 . Total for all three isn't going to be more than double that. (Trust me on this, I actually have worked with all three agencies.) We can guess that the average number of people per individual address is between 2 and 3 -- and this estimate isn't very sensitive to the assumption because because big households are rare. So let's say conservatively that there are 3 million households in that area. This means it's about seven percent of the total households, or that in order to hit 7 Agency households you've got to mail 100 copies. That's 185000 copies to get 50 percent coverage.
I don't think this is working out.
(You might also want to recall that FBI didn't do polygraph clearances until they were forced to for political reasons.)
Honest, I'm not defending polys: I know myself of one guy who was a completely pure new grad college boy from Utah who could never get a clearance because he got so ajitated at the questions that they couldn't get a clear reading. I'm just pointing out that not only is your scheme not feasible, but that the "secrets" are not particularly secret: I don't think you're going to get a useful result.
It's an interesting and amusing notion. You can do a lot better than using random addresses, though: the FBI building is public knowledge, and there is certainly some point around the building that is not under FBI control any longer. Print up copies of the book -- or summarize the basic points on a smaller handout -- and hand them out at FBI, at DoJ, and make them available in the usual places like lefty bookstores and so forth. (It's not commonly known, but CIA and DoJ employees are at least as likely to be politically liberal as the general population. They'll be in the local bookstores, the local equivalent of Whole Foods and so forth just as often as anyone else.)
But as far as the existence of polygraph countermeasures making these people admit that polygraph testing is a fraud... well, perhaps you didn't notice that the person who objects to "antipolygraph.org" teaches polygraph countermeasures for the Department of Defense.
If they've got a curriculum in polygraph countermeasures, you can be pretty certain they know they exist, don't you think?
Slashdot Mirror
Your interpretation is correct, assuming the exponential distribution (which is the common assumption.)
Actually, here's some more references: at CiteSeer, a good (if expensive) book on practical examples, and my favorite textbook. I'll shut up now.
You know, it's almost a shame to screw up the amusing notions /.ers come up with by adding actual information, but I can't help it, all those years of teaching I guess.
Okay, first of all: "mean time between failures" is obviously a statistical measure -- it is an average over a large number of individual items. In most electronic components (including light bulbs!) the statistical distribution of the time between failures is the exponential distribution, which has the odd property that it's "memory-less" -- it doesn't matter how long since the last failure it's been, the mean time to the next failure will still be the same. A consequence of this is that if the MTBF is 10,000 hours, the probability of failure in any particular hour would be 1/10,000th. So, if you set up 10,000 components, all running simultaneously, you'd expect one of them to fail within the first hour; conversely, if you ran them for 1000 hours, and 998 of them failed, you could be fairly certain that the MTBF would be around 10,000 hours.
Note, by the way, that this is only true when the failure time distribution is exponential -- so it works for electronic components, but not for, say, bicycles and cars and roller skates, which are more likely to fail the older they get.
This has an obvious problem, of course: if the MTBF is high, it can take forever to test. Consider, for example, something I worked on for NASA some years ago: trying to prove that a fly-by-wire system will have a mean time between failures of 1e10 hours. (This is about the same failure rte as the airframe, which is how they came up with the number.) 1e10 hours is about 1.141 million years, by the way.
(Pop quiz: if MTBF is a million years, how do you explain the occasional airframe failure, say, eg TWA 800? Hint: It doesn't require any foul play.)
At that point, you've got a couple of choices: first, you can make a lot of copies and run them simultaneously. Relatively easy for $50 disks, hard for billion dollar 747s.
Second, you can make the estimate by computation and modeling which is what you do for web systems. Conceptually, it's pretty simple to do this, although it can be a kind of pain in the ass.
The third way, which is new and cool, is by Bayesian estimation of failure rates. This method lets you make increasingly accurate estimates of the failure rate based on short experiments. I don't have time to go into it, but there are some good sources available on the web.
And, in fact, Tethers Unlimited, the company proposing this beast, was founded by scientist, engineer and science fiction writer Dr Robert L Forward. Sadly, Dr Forward died last September.
With hard-drive costs less than $1 a GIGABYTE (you younger folks have NO IDEA how impossible that sounds) I'm not sure that keeping file deltas is worth the effort any longer. VMS versioning was fairly straightforward and you didn't HAVE to look at all the back versions: if I recall the syntax correctly, 'dir foo.*;-3' would show you the three most recent versions (don't bother to flame me if I'm wrong, it's been 20 years) and a DCL macro would let you make it easy. Add to that a way to transparently archive the files to WORM, like Plan/9 does, and you're in fat city.
I was reading the Linux Kernel programming book and it mentioned 'rename' as the dual of 'link' rather than unlink.
Oh my God! I made an error.
The OpenGroup (which used to be X/Open) is a nonprofit, like the FSF, which owns the trademark and licenses it when a system has successfully passed a compatibility test. The notion is that any UNIX should be (at least approximately) compatible. I'm not at all sure if Linux could pass, since it has, eg, a rename(2) system call in place of unlink. The money that OpenGroup gets is used to continue their standards operation. See
This press release on the UNIX trademark and SCO
this one on testing and certification.
What the OpenGroup doesn't do is support open source per se -- unlike GPL'ed code, you can be OpenGroup certified and still be closed source. Bad bad OpenGroup, they're not RMS-correct.
You're right ... you don't have any idea who OpenGroup is. You should have stopped there, because the rest just makes you sound like a moron.
Okay, AIX is a UNIX because IBM got it certified against SvR4; OpenGroup has the UNIX trademark because AT&T sold it to Novell (UnixWare) which gave it to OpenGroup; SCO has the UnixWare code base because they bought it(+/- copyrights, trademarks, trade secrets, and customized mouse pads) from Novell; and SCO is suing IBM about AIX.
Feel better now?
... because if you took this stuff any more seriously, you'd have to cry.
SCO suing IBM
Open Group suing Apple
Apple suing Open Group
It's starting to sound like a game of "Six Degrees".
Does anyone have the numbers at hand to see if this makes a "beanstalk" feasible?
Thank God this came out. I'd been somewhat worried about TIA. Now that I know Bruce Sterling is against it, I feel ever so much better.
Armstrong, Aldrin land on Moon
Kennedy beats Nixon by narrow margin
Allies land on Normandy beach -- D-Day has arrived!
Paint Drying Web CamN
GrassGrowing.com
SausageBeingMade.org
CSPA
Changing positions like that may well help, but be warned that the explanation they give is, well, crap. RSI isn't really well understood, but (in the case of carpal tunnel disease) it's pretty certainly not because of lack of blood flow.
As to the issue about moving the arm rather than the fingers, those of us who are old enough to have had real penmanship classes remember that this is the way we were taught to write, too. After my own bout of RSI (caused by playing rogue for about 36 hours straight during grad school) I retrained myself to keep my wrists straight while typing (instead of resting them on the keyboard) and to use my armj rather than my hand for the mouse, and have since had no trouble.
Knock wood.
In a fair number of cases, it's stupidity that does it. Example: back when I worked for Sun, one of our customers was A Big Speciality Retailer (I'm a little limited here, but ABRS sells stuff that is big at Christmas for small humans, okay?) The CEO, P.H. Boss, had decided that a web presence was the Next Big Thing, so he'd hired a couple guys to build a web site, which they did in good ars Technica fashion, using tcl on a little bitty Sun server -- as I recall it was a single processor desktop box, like a 250. Connected to a DSL line, I believe.
Mr. Boss thought this was such a great site that he went out and made a $50 million advertising buy, nationally, starting at Thanksgiving. What he didn't do was tell the technical people.
The result was that everyone's mom left the Thanksgiving football games, logged on and tried to hit the server. Later measures suggested the server peaked at more than 1000 hits/sec. Needless to say, this served as a very effective smoke test, and sure enough the server smoked.
Old P.H. was most disturbed with the technical people, with Sun, and with the whole web thing -- he couldn't understand why he couldn't spend $10K on a web site and $50 million on advertising and get perfect performance.
It's a terminology quibble on what's otherwise an insightful post, but a secure system (to the extent it means anything at all) is a system that protects things to the level which the security policy requires.
A system that keeps its promises (nice phrase) is a good description of a trusted system.
(The history of this all goes back to the old Trusted Computing System Evaluation Criteria (TCSEC), also known as the "Orange Book.")
In order to have a secure system, you need a security policy to determine what's required, and you need a system that can be trusted to do what the policy requires.
What you say about Microsoft's "trusted computing" initiative is just right, however. Palladium and the Trusted Computing Initiative have nothing much to do with enforcing your security policy, and everything to do with enforcing Microsoft's digital rights management policy.
"Charlie Foxtrot nine" of course.
Answer: Yes. Is it enough to matter? No.
It could be done (someone else mentioned the cat experiments) but long before you got the resolution of the eye, you'd run into something we used to call the "pincushion problem" -- by the time you've got enough electrodes to capture the information, you no longer have the tissue of interest, you have a pincushion -- and pincushions don't act like normal tissue.
... well, weird.
But let's assume you did it somehow (nanotech, maybe -- everyone knows nanotech can do ANY magic desired). The eye isn't really like a digital camera at all: each of the sensory cells has a photosensitive dye called rhodopsin which is bleached out by exposure to light, in the process changing its electrical properties. (What I recall is that it liberates electrons, but look it up as I'm not certain.) This degree of bleaching is what produces the signal, which becomes encoded as a series of pulses on the optical neurons.
This sounds like a digital signal, but it's more complicated than that, because the rhodopsin regenerates slowly -- this is why it takes minutes to get your night vision back after exposure to light. The cells in the retina communicate among themselves as well. The result is that the signal from the retina is
The point is that while you might be able to make it work (if you solve the pincushion problem) you wouldn't gain much, because the eye is a crappy camera. It's the signal processing afterwards that's good. If you want to really get a good representation of what the "eye" sees -- or rather what the brain sees -- you ought to use a good digital camera, and try to figure out the signal processing instead,
There is no such thing as being too anal retentive with reference to the words of a law. Cf. "that depends on what the meaning if 'is' is".
This is not intended as an anti-Clinton troll (although I'll be happy to post one if anyone needs one). Being anal-retentive about the wording is what one does in the law; if there is any conceivable way in which a law can be interpreted (technically called the "theory" of the prosecution) then you can be tried. If you're charged and tried, whether you are convicted or not, you may lose your job, bankrupt yourself in your defense, generally have your life ruined -- and under "sovereign immunity" you can't recover except for really specific and egregious abuses.
If you want disinterested, you're not gonna find it. Everyone has some interest or another.
If you want good, complete information, watch/read several sources and integrate it yourself; you'll probably be disappointed, since that seems to correlate pretty well with what the major news sources tell you.
If your definition of "unbiased" is "unpatriotic" -- or at least "anti-Allied" -- then why bother with looking for unbiased sources that might screw up your assumptions?
Now, back up and think about this:
In your case, you're talking primarily about engineers, and they are primarily (for job functions) going to be doing engineering
Now, on you EXISTING network, measure what a few users do for at least a few days. If you've got admin on, you should be able to extract information from the logs. This will give you a chance to get at how much load there really is.
Next task: establish some of your "non-functional" requirements. In particular, how long can response time be for your most important tools, how long can you afford to have the system as a whole be unavailable, and how much work (an hour, half a day, a week?) can you afford to lose. Divide all of those by two and make them your basic "service level agreement" -- which is simply a statement of the service you promise the users, it doesn't have to be fancy.
Here are some reasonable values, from experience, but YMMV: most people will put up with the whole system being unavailable for an hour, they want half-second response time from specialized tools and more like about 4 seconds on a web page, and engineers hate losing ANYTHING but usually don't get too pissed off if it's less than a couple of hours work and doesn't happen very often.
Next: what's the environment? Do you have to think about firewalling yourself from the rest of the network? (Don't assumme just because you're inside the corporate firewall that you're protected. Get AND READ the corporate security policy, as well as talking with the admins who own the network as a whole.) How will you do backups? How do you fit into the corporate disaster planning scheme? (Lots of people forget that one, but just look into what happened to the Wall Street Journal on 9/11 to see how essential it really is.) This analysis will give you a good idea what you need.
And now, having said all that, it will turn out that what you're going to need is (1) a "big enough" file server with 5/4 RAID and a good periodic backup onto "archival media" like tapes or writeable CDs; (2) one workstation good enough for all your applications, and with at least a years' room for growth, for each desktop (plan to buy at leasy one for a spare, and set it up "hot" so a single failure doesn't slow anyone down"); (3) a smallish box as a print server (if you manage your own email, it can often go onto this); and (4) a firewall box or a router (betcha 50 cents Canadian that the company will insist on this.)
Plan for a full week, plus one day per user workstation, for installation. That is, with 4 users, plan on 5 + 4 = 9 days for two people.
All the other stuff, like using NIS, NFS, Kerberos, etc, will more or less fall out if you get these steps right first.
Well, if there're thousands of people to mail them out, some of them are likely to be in the DC area, don't you think?
But let's take your random-mailing notion seriously for a moment. To capture the majority of employees at FBI, CIA, NSA -- the groups that use most polygraph clearances -- you've got to cover all of both the DC and Baltimore metro areas, (remember that lots of people commute from B'more, especially to NSA which is actually closer to B'more than downtown DC.) Several web sources seem to suggest a total population in the neighborhood of 8 million, and DoJ says the total employment of FBI is about 128,000 . Total for all three isn't going to be more than double that. (Trust me on this, I actually have worked with all three agencies.) We can guess that the average number of people per individual address is between 2 and 3 -- and this estimate isn't very sensitive to the assumption because because big households are rare. So let's say conservatively that there are 3 million households in that area. This means it's about seven percent of the total households, or that in order to hit 7 Agency households you've got to mail 100 copies. That's 185000 copies to get 50 percent coverage.
I don't think this is working out.
(You might also want to recall that FBI didn't do polygraph clearances until they were forced to for political reasons.)
Honest, I'm not defending polys: I know myself of one guy who was a completely pure new grad college boy from Utah who could never get a clearance because he got so ajitated at the questions that they couldn't get a clear reading. I'm just pointing out that not only is your scheme not feasible, but that the "secrets" are not particularly secret: I don't think you're going to get a useful result.
It's an interesting and amusing notion. You can do a lot better than using random addresses, though: the FBI building is public knowledge, and there is certainly some point around the building that is not under FBI control any longer. Print up copies of the book -- or summarize the basic points on a smaller handout -- and hand them out at FBI, at DoJ, and make them available in the usual places like lefty bookstores and so forth. (It's not commonly known, but CIA and DoJ employees are at least as likely to be politically liberal as the general population. They'll be in the local bookstores, the local equivalent of Whole Foods and so forth just as often as anyone else.)
But as far as the existence of polygraph countermeasures making these people admit that polygraph testing is a fraud... well, perhaps you didn't notice that the person who objects to "antipolygraph.org" teaches polygraph countermeasures for the Department of Defense.
If they've got a curriculum in polygraph countermeasures, you can be pretty certain they know they exist, don't you think?