Fortunately, there are a number of people who have had to deal with this subject in a different forum - Lycos, Google, AltaVista... search engines deal with a different kind of spam, but it's spam, all the same. Perhaps some current (or former) search engine folks could spend some time trying to improve how they extract relevant text from the message before hashing.
Question: At what point does it become "bulk" email? 5 people? 10? 20? 50? 100? I've sent out personal party invitations with close to a hundred people; was I a spammer?
No, I don't think so. I may have been sending unsolicited email to a large number of people, but I had an established, existing relationship with those people already. It would be entirely reasonable for me to presume that, if I had sent them each a personal email message about the event in question, that none of them would have thought it as an inappropriate use of email.
I think any definition of spam needs to take that into account. We need to differentiate between these two types of email abuse - the blind use of purchased email lists vs. the misuse of legitimately acquired email lists. IMHO, the second is the more disturbing activity, while the first is more annoying, and more deserving of the title "spam".
Somehow young people with alot of energy are always seen in this light - like we are wasting are time or being frivalous because we don't value our time.
I don't think he was daying that young people don't value thir time; I think he was saying that, since he no longer has the energy of youth, he has less time to do all the things he might want to do, so he needs to be careful about how he spends his time in order to get to do all the stuff he wants.
Speaking as someone who, three years ago, couldn't even begin to dream how much a toddler could eat up your personal time, I understand (in some sense) exactly what he's saying:-)
So, the tool ensure that only sane kernel configs are built is where the real meat of the problem is. XML wouldn't be much help there.
It couldn't do the job completely by itself; but it could help simplify the process.
Instead of building a DTD that expresses every potential ascpect or relationship that describes a "sane" kernel, you could build one that describes 95% of the configuration relationship information. Then, make sure that the DTD includes definitions for hooks into executable code (shell scripts, most likely) that are hand-written to handle the inevitable unusual or impossible-to-model situations.
I'll admit that I'm making some assumptions here - I've never delved into the kernel config code, so I'm just guessing that you would be able to express enough of it consistently in XML to make this type of approach work. Still, that seems like a safe assumption; if it was all special case code, then something like CML wouldn't really be of any use at all.
Re:Who didn't realize this after reading the GPL?
on
Freedom or Power?
·
· Score: 2
He also says you may not modify the license, so you couldn't remove that clause and use the rest of the GPL without it... It's all or nothing.
Interesting. Never really thought about it, but what you're pointing out here is that the GPL itself is not GPL'd... which, by RMS's own definition of freedom and power, demonstrates that it is the means by which the FSF maintains it's power at the expense of your freedom.
You will once TrollTech, the GTK team, or anyone with that particular need releases a cross-platform GUI library for C#. Open source development being what it is, once the first one's out, there will be 2-3 competing projects starting up almost immediately.
Seriously - how can open source advocates trumpet how wonderful it is to have so many choices, and then turn around and state that it's a Good Thing to have a single GUI specification as part of the langauge?
Apple and proprietary developers have generally gotten along well with the BSD and gcc people as far as license issues go.
What?
Recently, maybe, but take a look at this link to a copy of the 1993 g++ FAQ:
Because the legal policies of Apple threaten the long-term goals of FSF, as well as the concept of free software, no support will be lent to efforts to port GNU software to Macintosh or other Apple hardware.
The FSF didn't end the boycott of Apple until 1995, and even then, they pretty much said that unless supporting MacOS was ridiculously easy, they wouldn't bother accepting patches because that might impact their effort to produce the "GNU operating system".
If you want a quick summary of the boycott, the reasons, and how the FSF eventually "forgave" Apple the same way he "forgave" KDE, you can check out this link. Frankly, I'm surprised that the FSF and Apple are managing to get along as well as they are; it speaks volumes about Apple's commitment, and about the way the FSF has matured over the years, as well.
After 8 years as a developer, my handwriting is fine (well, my printing... I never really was one for cursive.) After four years in the Navy, though, while all my other handwriting skills remained more or less consistent, my signature went from something readable to an almost completely illegible scrawl. At about the same time, the exact same thing happened to my wife's signature - she was working as a social worker in a nursing home, and signing something every five minutes.
I don't think either one of us could actually produce a readable signature anymore even if we tried.
Yep. It plays MP3's just fine. However, if you want to create MP3's, you need to purchase or download additional software.
Compare that with the fact that XP will allow you to rip CD tracks to WMA files without additional software, and it looks an awful lot like MS is doing their best to use their operating system monopoly to promote a completely seperate proprietary technology (WMA) at the expense of a competitor (MP3).
Which just happens to be what the whole DOJ hearings were supposed to be about.
Hmmm... that's interesting; precisely because it parallels the US version of the income tax: supposed to be voluntary, was supposedly improperly ratified as a constitutional amendment, and was supposed to be temporary.
Just out of curiosity, does the Candian equivalent of the US Internal Revenue Service have it's own court system as well? (Yes, that's right; if you have a dispute here with the IRS, apparently you cannot press your case in a US court. You are required to go to a seperate court run by the IRS. That's probably voluntary, too...)
However, this is not all that useful for general-purpose OSes and may even be detrimental to servers, where throughput matter more than response time.
Actually, I would think that this would be overall beneficial to servers. Yah, raw server throughput is important; but so is response time, particularly when a server is heavily loaded. I would think that a pre-emptible kernel would servers to handle more simultaneous users in heavy load cases.... you'd effectively be sacrificing some I/O throughput in light load situations for a guaranteed I/O throughput and responsiveness under heavy loads.
For the same reason folks in other countries misuse American words and phrases, and vice versa... because language evolves. Does it really matter, so long as everyone understands what you're talking about?
Oh, and the correct plural of mongoose is polygoose. Well, OK, maybe not. But if there was any linguistic justice in the world, it would be.
There is filtering software that works well in these instances. Instead of depending on pattern recognition, keywords, or any other technology, you set up your kid's filter to "deny all except" and then explictly enumerate the sites that s/he is allowed to access.
Before you start screaming: no, you can't cover every possible "good" site this way. But you can cover a heaping helping, and add more as needed. This sort of filter doesn't work too well past a point, but - as the original poster said - that's the point where you need to sit down, talk to you kid about things, and let them start flying solo.
Until that point, strong filters can help keep your 7 year old from being baraged with porn if they misspell "nickatnite.com"; and personally, I think that's a good thing.
First of all there are no dependency problems with apt.
Wow! A bug-free program! Has the press been notiied?
If the package is on the CD you can install it with dpkg (or some gui equavalent). You don't need to download anything or change your apt.sources
No - you yourself said that apt would need to download dependent packages if they were not also on the CD. So the problem still remains - either I have a CD or some other installation media with all required packages, or I end up hitting the net.
Why are you afraid of downloading something from the net and installing it but not afraid to install a monster package from some CD?
Personally, I'm not; then again, I'm just admining a single home box. Administrators tend to be jumpy about this sort of thing. It comes down to this: what is on the CD is unchangeable. What is on the net is inherently changeable. If I examine a set of packages on a CD, or in a single archive that I've downloaded, I can be sure that what I install is what I have examined. With apt, if it goes out onto the net, there's no guarantee that what I looked at 5 minutes ago is, indeed, what's going to get installed. That sort of variability is unacceptable to some class of people, usually the same class of people that are resonsible for administering large networks.
Both are black boxes as far as you are concerned except that apt-get install performs checksums for you. In effect it's safer then installing it from CD.
Hardly. And you still ignore the problem of performing an installation where network connectivity is not assumed.
Besides if you want to take apart a massive package and examine each package why do you want a install program in the first place?
As I said: convenience. Knowing that I can download a single package that contains all the disparate pieces needed to install a program. I will repeat my earlier point: I personally don't care if it's apt, running off a local package archive (on CD or on disk), or something else. What I would like to see is a common, accepted way of packaging a program and it's dependencies into a single archive that can then be installed simply. That's what apt and rpm do; only they work at the file level, instead of at the package level. Something like apt or rpm that works with a collection of packages as an autonomous unit has value, whether or not you care to admit it.
Under your "Installshield" scheme, you would be redundently distributing out-of-date libraries with your software, in addition to the overhead of the Installshield wrapper. Its simply not efficient. In fact, it is very wasteful compared to the apt-get way of doing things.
Yah, but you're thinking like a developer or a systems adminstrator, not an end-user. For someone running Linux on their desktop, they want to pop a CD into the drive, have an "Install this program?" window pop up, answer a few questions, and have everything Just Work.
This is more or less what every major Linux install does today. Why is that appropriate for the OS, but not for other programs? More importantly, why do you think that I should not be able to obtain an installation package that contains all the files that I might need to get Fookinator 2.0 up and running on my system? I can see multiple reasons why I might do that:
apt assumes you have all packages handy, or that it can get them from some remote location. What about non-networked machines? A home system connected by a 56.6 dialup? A laptop that's currently not connected? Oops.
I don't want to use apt; maybe as a system administrator, the idea of getting random software from somewhere on the net and chucking it onto a box makes my skin crawl. I want a single package I can pull apart and verify before installing.
Maybe I *need* those out of date libraries. Backwards compatability is something honored (if not near-worshiped) in the commercial OS camp; I can reasonably expect a 3-year-old program to run on a modern version of Windows, for example. Not so with Linux. If I need to install and run a 3-year-old program, how is apt going to find me the versions of the packages I need, when nobody's archived them anyplace reasonable for at least 18 months?
Yah, I know. You're now going to tell me that I could do all this by burning myself a CD with all the packages I need, running apt with a command line that sets the search path to the CD, etc.
Using your own argument... if a few thousand people do that, isn't that "very wasteful"? Bandwidth is cheap, and getting cheaper; storage is cheap, and getting cheaper... doesn't it make sense, then, for one person to invest their (increasingly valuable) time and effort into putting together an installer, so that thousands of other people don't waste their time doing the same thing?
By all means, let the installer be something very similar to apt... heck, it could just be a nice front end (GUI and command-line) on top of a structured package archive. The way it's put together doesn't really matter. What does matter is that it becomes trivial to download a single data blob and know that is the only thing you need to install a bit of software that you need, so that instead of spending 4 days playing "find that dependency!", you can actually get the program installed and get some work done.
I agree - we can't look for an absolute, 100% certain solution, because there isn't any. My concern is that something like face recognition software, because it's this slick technological solution, will be seen as a silver bullet, and none of the other steps that are vital to security (training, working to retain qualified personnel, regular covert tests of airline security, etc.) will ever be taken.
The one thing I would most like to see out of this would be a division of the FAA or FBI who's sole responsibility was to actively test and break airport security, and who had the authority to tell airlines how they must change things to prevent successful security breaks in the future. Unlikely to ever happen, since that's probably the most effective and least intrusive thing that could be done.
But I must say that I feel very differently about face recognition - particularly in airports. Such a system could have caught some of the hijackers - several of whom who were WANTED BY THE FBI and FLEW UNDER THEIR OWN NAMES!
If they were flying under their own names, then the airlines didn't need face recognition software to idenitfy them. The airlines simply were not concerned enough about security to even bother to compare flight manifests against lists of known, dangerous criminals.
Face it (no pun intended) - there is no silver bullet. We, the people of the US, are going to get exposed to a thousand different logical fallacies over the next few weeks: "If we had done <X>, then this wouldn't have happened." Anyone associated with computers should understand that there is no silver bullet for security, and there never will be. We had a lax security posture in our airports, and somebody exploited that to our detriment. If we want to keep the next terrorist from doing the same, we need to start actively testing and probing our own security in a meaningful way, fixing those security problems we do find, and making sure that those fixes remain in place and are not relaxed when the current situation passes.
If that sort of procedure indicates that face-recognition software is of value in beefing up airport security, then fine - let's use it. Until that point, I'm unwilling to accept that the CEO of a face-recognition software company has only my own best interest at heart when he starts peddling his product in a way obviously designed to take advantage of the emotional situation surrounding a tragedy.
I just finished putting together a review of C/C++ coding standards from various sources. Some were from commercial companies, some from academic institutions, and some were either personal or open-source project standards.
Every single one of them either flat out prohibited or strongly suggested avoiding variable or function names that differ only in case.
It's too confusing; there are too many ways to screw up, and there is absolutely no real benefit to using case-sensitive function or variable names. Oh, sure, you can have functions named "Sum", "sum", and "SUM"... but, what, exactly, is the difference between them? Unless you know what each function does, then there's no way to tell them apart - human experience doesn't account for three possible meanings of the term "sum", at least in this context.
If you do have multiple ways to produce a sum, you are far, far better off either having three functions:
SUM_ROW() SUM_COL() SUM_MATRIX()
Now, there's no question what each does... at the very least, you can make a guess; and if you see code calling SUM_ROW(inputMatrix), well, the error there is pretty obvious. The difference between Sum(inputMatrix) and sum(inputMatrix) is a lot easier to overlook, particularly at 3am (when these things always seem to jump up and bite you.)
Don't get me wrong. I do a lot of work in C/C++, and I like case sensitivity in those langauges... they are more than willing to allow you to shoot yourself in the foot, if you need to do so. (If that seems weird, I do know of a man who shot himself in the foot... with a nailgun, to keep himself from falling off a roof.) Macro languages, like those in office suites, don't need that same level of flexibility; their point is to provide a simple way to access complex functionality.
There aren't just two sides in the Middle East. There are factions who want to strike at the US because of our involvement in the region. There are factions who want to strike at the US because they don't believe we are involved enough. There are factions who want the US involved, but only on their terms, or.. you guessed it. Then there are the factions that are opposed to the US for ideological or religious reasons, and who will do their best to harm US citizens and interests regardless of what foreign policy we follow.
In other words, the people of the Middle East have, one way or another, done their best to draw the US into their conflicts. We cannot - and never could - ignore events there; particularly since any action on our part, including no action at all, would result in an attack on our people and our country.
No, you didn't reply to it. You spouted off a lot of inflamatory rhetoric and propaganda. There's a slight difference between the two.
Any point you might have made (and I don't doubt there's a valid point or two lurking somewhere in that mess) were obscured by your desire to attempt to paint the US in the absolutely worst light possible. Ignoring the good and noble things done by the US and US citizens is as much an error as ignoring the base and evil things that the same government and people have done. Both try and produce a mental image of a country that is, at best, a caricature. The real truth is that the US has, at times, acted despicably; and, at times, acted nobly. My personal opinion is that, overall, the US has done more good than evil in the world.
I was doing my own paranoid-fantasy spinning... imagine that the NSA/CIA knew of or were fairly sure about this, but decided to downplay the risk in order to up the chance of getting some beefy anti-terrorist powers afterwards.
Or imagine a wealthy, ruthless individual, who's really only interested in taking out the WC and causing a US stock market collapse so s/he can profit from the chaos; and who manipulates a bunch of fanatics into doing the actual dirty work.
Most software design is lousy. Most software is so bad, in fact, that if it were a bridge, no one in his or her right mind would walk across it... Instead of trying to create software that works in a minimal sense, we should be creating software that has internal beauty.
If you want to follow your bridge analogy, then get out and take a look at a real bridge. Quite frankly, there's nothing very "beautiful" about it, except in an abstract sense, and even then, most likely from a distance. If you get right up close to it, you'll see rust spots, cracks, welds, patches, odd and seemingly arbitrary scars, and other features that look entirely out of place on a bridge... until you see an inspector's scaffolding hanging from the knobs you thought served no useful purpose.
In other words, by your standards, bridges are a friggin mess. Really... I mean, they have no "internal beauty", once you're close enough to see how they're put together.
Just like software.
The folks using the bridge don't care about it's internal beauty, except peripherally... they care that the hunk o' steel and concrete under them doesn't give way and dump them into a river. Similarly, the folks using software don't care about it's internal beauty, as long as it doesn't give way and dump their data into oblivion.
In fact, the only people who really manage to care at all about how bridges are put together are the people who build 'em. The same goes for software. There are plenty of reasons to write clear, easy to understand, well-documented code, without having to resort to some sort of appeal to a completely subjective quality like "beauty"; and there are plenty of ways to write high quality, reliable, high-performance software without making the same sort of subjective appeal. (Note that there is a difference, IMHO, between beautiful code and elegant code. I've seen some quite elegant hacks that had particularly butt-ugly implementations.)
I'll go as far as to argue that while there are exceptions, generally, good software does not come from pretty code. Think about it - when your code is "beautful", first and foremost, that means that eventually you'll sacrifice reliability or functionality rather than produce "ugly" code. I'd rather ahve my source code be ugly and correct than beautiful and full of bugs any day of the week.
Slashdot Mirror
Fortunately, there are a number of people who have had to deal with this subject in a different forum - Lycos, Google, AltaVista... search engines deal with a different kind of spam, but it's spam, all the same. Perhaps some current (or former) search engine folks could spend some time trying to improve how they extract relevant text from the message before hashing.
Question: At what point does it become "bulk" email? 5 people? 10? 20? 50? 100? I've sent out personal party invitations with close to a hundred people; was I a spammer?
No, I don't think so. I may have been sending unsolicited email to a large number of people, but I had an established, existing relationship with those people already. It would be entirely reasonable for me to presume that, if I had sent them each a personal email message about the event in question, that none of them would have thought it as an inappropriate use of email.
I think any definition of spam needs to take that into account. We need to differentiate between these two types of email abuse - the blind use of purchased email lists vs. the misuse of legitimately acquired email lists. IMHO, the second is the more disturbing activity, while the first is more annoying, and more deserving of the title "spam".
I don't think he was daying that young people don't value thir time; I think he was saying that, since he no longer has the energy of youth, he has less time to do all the things he might want to do, so he needs to be careful about how he spends his time in order to get to do all the stuff he wants.
Speaking as someone who, three years ago, couldn't even begin to dream how much a toddler could eat up your personal time, I understand (in some sense) exactly what he's saying :-)
Interesting. Never really thought about it, but what you're pointing out here is that the GPL itself is not GPL'd... which, by RMS's own definition of freedom and power, demonstrates that it is the means by which the FSF maintains it's power at the expense of your freedom.
You will once TrollTech, the GTK team, or anyone with that particular need releases a cross-platform GUI library for C#. Open source development being what it is, once the first one's out, there will be 2-3 competing projects starting up almost immediately.
Seriously - how can open source advocates trumpet how wonderful it is to have so many choices, and then turn around and state that it's a Good Thing to have a single GUI specification as part of the langauge?
The maintainers of the museum apparently enjoyed your comment... it's now quoted at the bottom of their page.
What?
Recently, maybe, but take a look at this link to a copy of the 1993 g++ FAQ:
The FSF didn't end the boycott of Apple until 1995, and even then, they pretty much said that unless supporting MacOS was ridiculously easy, they wouldn't bother accepting patches because that might impact their effort to produce the "GNU operating system".
If you want a quick summary of the boycott, the reasons, and how the FSF eventually "forgave" Apple the same way he "forgave" KDE, you can check out this link. Frankly, I'm surprised that the FSF and Apple are managing to get along as well as they are; it speaks volumes about Apple's commitment, and about the way the FSF has matured over the years, as well.
After 8 years as a developer, my handwriting is fine (well, my printing... I never really was one for cursive.) After four years in the Navy, though, while all my other handwriting skills remained more or less consistent, my signature went from something readable to an almost completely illegible scrawl. At about the same time, the exact same thing happened to my wife's signature - she was working as a social worker in a nursing home, and signing something every five minutes.
I don't think either one of us could actually produce a readable signature anymore even if we tried.
Yep. It plays MP3's just fine. However, if you want to create MP3's, you need to purchase or download additional software.
Compare that with the fact that XP will allow you to rip CD tracks to WMA files without additional software, and it looks an awful lot like MS is doing their best to use their operating system monopoly to promote a completely seperate proprietary technology (WMA) at the expense of a competitor (MP3).
Which just happens to be what the whole DOJ hearings were supposed to be about.
Interesting. If you're anywhere near Pittsburgh, I'd be interested in seeing the process and/or results firsthand.
Hmmm... that's interesting; precisely because it parallels the US version of the income tax: supposed to be voluntary, was supposedly improperly ratified as a constitutional amendment, and was supposed to be temporary.
Just out of curiosity, does the Candian equivalent of the US Internal Revenue Service have it's own court system as well? (Yes, that's right; if you have a dispute here with the IRS, apparently you cannot press your case in a US court. You are required to go to a seperate court run by the IRS. That's probably voluntary, too...)
Mavra Chang!
Actually, I would think that this would be overall beneficial to servers. Yah, raw server throughput is important; but so is response time, particularly when a server is heavily loaded. I would think that a pre-emptible kernel would servers to handle more simultaneous users in heavy load cases.... you'd effectively be sacrificing some I/O throughput in light load situations for a guaranteed I/O throughput and responsiveness under heavy loads.
For the same reason folks in other countries misuse American words and phrases, and vice versa... because language evolves. Does it really matter, so long as everyone understands what you're talking about?
Oh, and the correct plural of mongoose is polygoose. Well, OK, maybe not. But if there was any linguistic justice in the world, it would be.
There is filtering software that works well in these instances. Instead of depending on pattern recognition, keywords, or any other technology, you set up your kid's filter to "deny all except" and then explictly enumerate the sites that s/he is allowed to access.
Before you start screaming: no, you can't cover every possible "good" site this way. But you can cover a heaping helping, and add more as needed. This sort of filter doesn't work too well past a point, but - as the original poster said - that's the point where you need to sit down, talk to you kid about things, and let them start flying solo.
Until that point, strong filters can help keep your 7 year old from being baraged with porn if they misspell "nickatnite.com"; and personally, I think that's a good thing.Wow! A bug-free program! Has the press been notiied?
No - you yourself said that apt would need to download dependent packages if they were not also on the CD. So the problem still remains - either I have a CD or some other installation media with all required packages, or I end up hitting the net.
Personally, I'm not; then again, I'm just admining a single home box. Administrators tend to be jumpy about this sort of thing. It comes down to this: what is on the CD is unchangeable. What is on the net is inherently changeable. If I examine a set of packages on a CD, or in a single archive that I've downloaded, I can be sure that what I install is what I have examined. With apt, if it goes out onto the net, there's no guarantee that what I looked at 5 minutes ago is, indeed, what's going to get installed. That sort of variability is unacceptable to some class of people, usually the same class of people that are resonsible for administering large networks.
Hardly. And you still ignore the problem of performing an installation where network connectivity is not assumed.
As I said: convenience. Knowing that I can download a single package that contains all the disparate pieces needed to install a program. I will repeat my earlier point: I personally don't care if it's apt, running off a local package archive (on CD or on disk), or something else. What I would like to see is a common, accepted way of packaging a program and it's dependencies into a single archive that can then be installed simply. That's what apt and rpm do; only they work at the file level, instead of at the package level. Something like apt or rpm that works with a collection of packages as an autonomous unit has value, whether or not you care to admit it.
Yah, but you're thinking like a developer or a systems adminstrator, not an end-user. For someone running Linux on their desktop, they want to pop a CD into the drive, have an "Install this program?" window pop up, answer a few questions, and have everything Just Work.
This is more or less what every major Linux install does today. Why is that appropriate for the OS, but not for other programs? More importantly, why do you think that I should not be able to obtain an installation package that contains all the files that I might need to get Fookinator 2.0 up and running on my system? I can see multiple reasons why I might do that:
Yah, I know. You're now going to tell me that I could do all this by burning myself a CD with all the packages I need, running apt with a command line that sets the search path to the CD, etc.
Using your own argument... if a few thousand people do that, isn't that "very wasteful"? Bandwidth is cheap, and getting cheaper; storage is cheap, and getting cheaper... doesn't it make sense, then, for one person to invest their (increasingly valuable) time and effort into putting together an installer, so that thousands of other people don't waste their time doing the same thing?
By all means, let the installer be something very similar to apt... heck, it could just be a nice front end (GUI and command-line) on top of a structured package archive. The way it's put together doesn't really matter. What does matter is that it becomes trivial to download a single data blob and know that is the only thing you need to install a bit of software that you need, so that instead of spending 4 days playing "find that dependency!", you can actually get the program installed and get some work done.
The one thing I would most like to see out of this would be a division of the FAA or FBI who's sole responsibility was to actively test and break airport security, and who had the authority to tell airlines how they must change things to prevent successful security breaks in the future. Unlikely to ever happen, since that's probably the most effective and least intrusive thing that could be done.
If they were flying under their own names, then the airlines didn't need face recognition software to idenitfy them. The airlines simply were not concerned enough about security to even bother to compare flight manifests against lists of known, dangerous criminals.
Face it (no pun intended) - there is no silver bullet. We, the people of the US, are going to get exposed to a thousand different logical fallacies over the next few weeks: "If we had done <X>, then this wouldn't have happened." Anyone associated with computers should understand that there is no silver bullet for security, and there never will be. We had a lax security posture in our airports, and somebody exploited that to our detriment. If we want to keep the next terrorist from doing the same, we need to start actively testing and probing our own security in a meaningful way, fixing those security problems we do find, and making sure that those fixes remain in place and are not relaxed when the current situation passes.
If that sort of procedure indicates that face-recognition software is of value in beefing up airport security, then fine - let's use it. Until that point, I'm unwilling to accept that the CEO of a face-recognition software company has only my own best interest at heart when he starts peddling his product in a way obviously designed to take advantage of the emotional situation surrounding a tragedy.
I just finished putting together a review of C/C++ coding standards from various sources. Some were from commercial companies, some from academic institutions, and some were either personal or open-source project standards.
Every single one of them either flat out prohibited or strongly suggested avoiding variable or function names that differ only in case.
It's too confusing; there are too many ways to screw up, and there is absolutely no real benefit to using case-sensitive function or variable names. Oh, sure, you can have functions named "Sum", "sum", and "SUM"... but, what, exactly, is the difference between them? Unless you know what each function does, then there's no way to tell them apart - human experience doesn't account for three possible meanings of the term "sum", at least in this context.
If you do have multiple ways to produce a sum, you are far, far better off either having three functions:
SUM_ROW()SUM_COL()
SUM_MATRIX()
Now, there's no question what each does... at the very least, you can make a guess; and if you see code calling SUM_ROW(inputMatrix), well, the error there is pretty obvious. The difference between Sum(inputMatrix) and sum(inputMatrix) is a lot easier to overlook, particularly at 3am (when these things always seem to jump up and bite you.)
Don't get me wrong. I do a lot of work in C/C++, and I like case sensitivity in those langauges... they are more than willing to allow you to shoot yourself in the foot, if you need to do so. (If that seems weird, I do know of a man who shot himself in the foot... with a nailgun, to keep himself from falling off a roof.) Macro languages, like those in office suites, don't need that same level of flexibility; their point is to provide a simple way to access complex functionality.
There aren't just two sides in the Middle East. There are factions who want to strike at the US because of our involvement in the region. There are factions who want to strike at the US because they don't believe we are involved enough. There are factions who want the US involved, but only on their terms, or.. you guessed it. Then there are the factions that are opposed to the US for ideological or religious reasons, and who will do their best to harm US citizens and interests regardless of what foreign policy we follow.
In other words, the people of the Middle East have, one way or another, done their best to draw the US into their conflicts. We cannot - and never could - ignore events there; particularly since any action on our part, including no action at all, would result in an attack on our people and our country.
Any point you might have made (and I don't doubt there's a valid point or two lurking somewhere in that mess) were obscured by your desire to attempt to paint the US in the absolutely worst light possible. Ignoring the good and noble things done by the US and US citizens is as much an error as ignoring the base and evil things that the same government and people have done. Both try and produce a mental image of a country that is, at best, a caricature. The real truth is that the US has, at times, acted despicably; and, at times, acted nobly. My personal opinion is that, overall, the US has done more good than evil in the world.
I was doing my own paranoid-fantasy spinning... imagine that the NSA/CIA knew of or were fairly sure about this, but decided to downplay the risk in order to up the chance of getting some beefy anti-terrorist powers afterwards.
Or imagine a wealthy, ruthless individual, who's really only interested in taking out the WC and causing a US stock market collapse so s/he can profit from the chaos; and who manipulates a bunch of fanatics into doing the actual dirty work.
If you want to follow your bridge analogy, then get out and take a look at a real bridge. Quite frankly, there's nothing very "beautiful" about it, except in an abstract sense, and even then, most likely from a distance. If you get right up close to it, you'll see rust spots, cracks, welds, patches, odd and seemingly arbitrary scars, and other features that look entirely out of place on a bridge... until you see an inspector's scaffolding hanging from the knobs you thought served no useful purpose.
In other words, by your standards, bridges are a friggin mess. Really... I mean, they have no "internal beauty", once you're close enough to see how they're put together.
Just like software.
The folks using the bridge don't care about it's internal beauty, except peripherally... they care that the hunk o' steel and concrete under them doesn't give way and dump them into a river. Similarly, the folks using software don't care about it's internal beauty, as long as it doesn't give way and dump their data into oblivion.
In fact, the only people who really manage to care at all about how bridges are put together are the people who build 'em. The same goes for software. There are plenty of reasons to write clear, easy to understand, well-documented code, without having to resort to some sort of appeal to a completely subjective quality like "beauty"; and there are plenty of ways to write high quality, reliable, high-performance software without making the same sort of subjective appeal. (Note that there is a difference, IMHO, between beautiful code and elegant code. I've seen some quite elegant hacks that had particularly butt-ugly implementations.)
I'll go as far as to argue that while there are exceptions, generally, good software does not come from pretty code. Think about it - when your code is "beautful", first and foremost, that means that eventually you'll sacrifice reliability or functionality rather than produce "ugly" code. I'd rather ahve my source code be ugly and correct than beautiful and full of bugs any day of the week.