Vested interest or not, they have no special rights to police the release of information outside of corporate property. They don't get to play vigilante just because they have a lot to lose...
So if you consider yourself to be a good person, you should be doing everything that you can to prevent the abuse to women and esp children. If not then you are no better then the person that is committing the acts.
I know this is flamebait, but it hits on one of the major fallacies used to promote this sort of assinine semi-constitutional (at best) law. "We must do everything possible to fight child pornographers." This is jingoistic bullshit and nothing more. Everything and I mean EVERYTHING we do is weighed in a cost-benefit analysis. If it costs too much for too small a benefit, then it just doesn't make sense.
Even child porn/abduction/abuse is not so awful that it trumps any conceivable objection to a law that might in some way reduce it. For example, why not pass a law that allows a parent to kill any adult who looks at their child. Don't you know that 99% of child molesterers have seen their victim in the presence of a parent before they molester them?? It's for the children! But, no, of course, that is ridiculously out of proportion and no one would ever seriously propose such a thing. It's not even a good example of humorous legal hyperbole, but it illustrates one thing -- no one is willing to go "to any length" to save the children. There is some cost at which it is no longer worth it.
Exactly how much we're willing to "spend" (maybe "give up" is a better word) to prevent these crimes is up for some debate, but you can't ignore the analysis based on the nature of the crime. Personally, I believe that an abusive oppressive government is a frightening enough thing that we need to keep it on a very tight leash, even at the cost of some heinous crimes going unpunished. "Better that ten guilty men go free than one innocent man be punished" is the doctrine -- note that it doesn't go on to say "unless a politician with an agenda believes that innocent man might have abused a child; then let him fry."
On aircraft, you have the additional problem that you are moving from cell to cell much faster than the system was designed to handle. So even if you are able to lock and stay locked to a single tower, it'll have to hand you off to the next tower before it's ready to do so.
I've experienced problems which I am pretty sure are related to hopping between towers -- not on an aircraft, but when hiking in the Smokey Mountains in North Carolina. We got up to the top and I was surprised to find that I had 4 or 5 bars! However, when I tried to make calls, I was denied and the signal strength would go up and down. I believe I was seeing towers on both sides of the mountain and the system and/or my phone was getting confused.
Not sure what the flaw in your reasoning is. One glaring flaw based on his article was that he seemed awfully happy to abort and start over from scratch as soon as something went wrong. Further, when he started over, rather than repeating what he'd done before but correcting his misstep, he chose a different install option. That doesn't strike me as a recipe for success. I think, perhaps more than other distros, Gentoo just demands that you either really know what you're doing or you follow the instructions precisely until you do. It doesn't sound like this was his approach...
My first install was a bit hairy -- had a few false starts. However, mistakes rarely meant starting ALL the way over. Since the steps are all just executed at the command prompt, it's pretty easy to reboot and pick up from where you screwed up and do the right thing. This requires fairly good knowledge of Linux, but is certainly not guru level magic.
I've never really looked much at the baselayout stuff. I'd be interested to learn though, so if you are so inclined, there's at least one person out here who'd read your documentation.
To be honest, as I've aged, I find I more and more fall into the "happy that it just works" camp. I've got a pretty solid grasp of how Linux/Unix works, but I haven't taken much time to figure out the nitty-gritty of how Gentoo manages things. I occasionally have to delve into it when things end up outside the "most of the time" part, though. Fortunately, things are usually done sensibly and I don't often find myself hacking to fix something the "wrong" way. Still, sometimes the temptation is pretty strong...
Most of the failure stories I've seen are more like complaining that a cake recipe didn't turn out because you skipped the step where you add the flour in step 3 and used cheese instead of eggs in step 5.
As others have pointed out, Gentoo is not intended for people who are uncomfortable with very low-level configuration. If you're not comfortable following its detailed instructions, then it's quite unapologetically not the distro for you. It's not trying to be the end-all be-all distribution for everyone.
Personally, I am quite comfortable with it and have been through half a dozen installs without any significant problems. I found its instructions to be excellent, although I would say they could do a better job documenting some of the more advanced configuration options (or at least pointing to the existing documentation more obviously from the end of the install). The article's point about incorrectly setting ~x86 globally is a good one -- there are a few wrong ways to set ~x86 for a single package, all of which can screw things up in subtle ways. Still, for my purposes it's been the best distro I've ever used and has lasted me at least as long as any other single distro.
I started off as an emacs user (well, after first starting with the Turbo C++ wordstar-esque(?) IDE). When I got out of college, I worked at a place where vi was the editor of choice for many of the more senior programmers. Partly as an exercise and mostly because running emacs on an old HP-UX box sucked hard, I started using vi. I got pretty good with it, too. Learned all the shortcuts I needed, etc.
After about 6 months, though, I noticed something funny happening. I found that I was subconsciously trying to avoid making more changes to a file than I needed to. I'd adjust my programming/debugging style to keep the number of lines I had to edit to a minimum. Sometimes this was a good thing, but often it ended up making things take longer. After a bit I realized it was because I really found working in vi to be a pain -- I switched back to emacs and had never felt so free in my programming life.
Not much point to my story, other than to share my experience. I still do use vi for quick editing tasks such as config file updates. Still, if I spend too much time in it, my quality of life deteriorates pretty quickly. Not to say there's anything wrong with vi, just doesn't suit the way my brain functions.
Probably not much, but that's not really the point. It's good publicity that can't hurt. People won't go out and think "wow i can help fold proteins," they'll just give a little thought to Sony and the PS3 when they read the articles about it. It's all about marketing, and subliminal marketing is the best kind.
Well, many (such as the New York Times) have recent content online openly, then move it to an archive that you must pay to access later. In that case, they would certainly be upset if google was mirroring their content later.
yeah, yeah, like the same thing doesn't happen to you when you make the mistake of posting to slashdot before noon on a sunday. I don't know why I was even awake...
That's only true if you're really obvious with your betting. There's no reason to scatter the bets to cover the entire target section, just bet on one number in that section. Over a large number of spins, this will have the same statistics as betting on all the numbers in the target. The only difference is it takes longer and is less obvious.
They do everything they can to use these as much as possible, or didn't you notice the thousands of slot machines lining every wall in all of Las Vegas?
Many people find these boring and are more wiling to throw big money at more traditional games. The physical mechanism is part of the attraction...
My father is a professor and uses near-daily quizzes to keep students up on the material, but also has regular exams. He goes to a lot of effort to detect cheating in these. Seating charts were part of it. My favorite touch involved using multiple versions of the exam. These would have the same questions in different order and differently ordered answer options in the multiple choice sections. He would distribute these so he knew which student had which exam. Further, the exams would be printed on different colors of paper. The kicker is that the color of the paper was meaningless, but the students would assume that it differentiated the version of the exam. He would invariably get several students who turned in a set of answers that matched a neighboring student who had a different version of the exam in the same color.
If a professor is reproducing a graphic (or any other verbatim information from another source) in a lecture, the source should be cited, just as for any other presentation. If it's just shown in class, a verbal citation is ok, but if it's printed and distributed in lecture notes, the citation should be in the notes as well (usually at the bottom of the slide with the graphic).
Yep, you're quite right. This is part of the reason that a two-way communication between users and designers/architects is important. Since the users and the architects typically think about the software in different ways, there's usually some back-and-forth to make sure that the architect understands what it is that the user is trying to do. Then, if the architect needs to specify a different way to accomplish that goal, someone needs to pass that along to the user so he knows how to get his job done.
As for connectiong functional specs and requirements, I think you're probably right that they never quite match up. In my experience, this is one of those things you've just got to live with. Often, the paper-pushing effort to nail down those last few things just doesn't pay off.
Maybe it can store the charge for a while, but unless you have more energy storage than an alkaline, you're going to run out of energy pretty quickly at 100x the power delivered. I'm not sure offhand what the energy capacity of a standard double-layer capacitor is, but it's substantially lower than an alkaline battery.
Regardless of how long you're storing the energy, you'd only use this technology (as described) in surge applications. If you don't need 100x the power, then use an alkaline because it'll last longer for low-drain use.
Perhaps I'm not understanding you right, but are you really suggesting that users have no place in the software development cycle other than buying the software and firing off feature requests into the void? That seems like a broken view, but I may not understand what you're saying.
Now, I'll agree that the *developers* are probably not the right people to be fielding user feedback directly. This isn't because they have "more important things to do," rather, it's because a developer doesn't usually have the authority over the architecture of the product to engage in that sort of decision one-on-one with the end user in the first place.
However, to suggest that the users should be left out of the loop entirely is an arrogant view that puts WAY too much confidence in the ability of the architects ("designers" in this article's lingo, I guess) to anticipate every need of the users. Instead, the architects should have some mechanism to get feedback from users. The users are the folks who actually know what they're trying to do with the software, so even if they don't know what's easy to implement, they know what is holding them up. The architects are in a place to understand why the user has requested a feature and to decide whether it is consistent with the design and reasonable to implement.
Every company I've worked for has done this and it's often invaluable, but it does require some effort and discipline. It's a part of understanding the application that the architects must do to some degree as part of the design process. The level of hand-holding that the user gets while making requests will depend on his clout as a customer, ranging from application engineers or even architects going on-site to tailor software to a key customer's needs, to tech support tallying requests for various features and passing them along in aggregate.
One other thought -- just as the user shouldn't be telling the *developer* what to implement, it's also more useful to solicit feedback as "capability requests" rather than "feature requests." The distinction is that a feature request implies (to me, anyway) something like "I want to click here and here and then type "blah blah" and it's done." This is usually too detailed. Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.
Get the information in the hands of the users? What on earth are my parents going to do with information about a buffer overflow exploit?
Stop using the software until its fixed? Ask you, their technically inclined grandchild, what to do to avoid being hacked? Any number of things to ensure they don't become victims while idly waiting for the vendor to solve the problem.
But really, your grandparents aren't going to be helped much because, as you say, they aren't going to patch very often anyway. However, there are plenty of users who ARE technically sophisticated and would be able to take advanced steps to mitigate risk due to a security hole in one piece of software.
Still, even if not legally protected, there is a big ethical problem if someone else is using your lecture, verbatim, without attribution. Academically, that is about as wrong as it gets. So the GP (and I) may be confused about IP law, but I don't think there's any question that a professor should reasonably expect that no one will give his lecture without at LEAST crediting him. Preferably he'd be asked and his permission (or lack thereof) be respected.
With regard to handouts or transcripts, there is no question. If those are being duplicated, it's still copyright violation.
No, it really is is IP. His specific wording certainly is his IP, and his examples may be as well. It is a performance. If you simply take his lecture and paraphrase it, you are probably producing a derivative work of his performance. This is not allowed. You are, however, free to take the facts you learned and put together your own lecture from scratch, and I don't think he was trying to claim otherwise.
I'd be pretty upset if someone was taking my work, even work I've been paid for, and presenting it as his own. The GP mentioned his course notes/outline being used by another lecturer without permission and without attribution. That's a BIG no-no. It's not mean-spirited to demand credit or compensation for your work (and no, being paid to give the original lecture is not compensation for someone who turns around and gives a verbatim or paraphrased copy of the lectures later).
Great insight, thanks for clearing that up for us.
The cost of switching is a lot higher than just the "Microsoft tax." Most companies are heavily invested in particular software packages (CAD, accounting, payroll, etc). These are very specialized packages that often must be guaranteed (and often certified) to meet specific regulatory requirements. Unless the companies behind those packages can be convinced to migrate, there really is no option to switch for the company. When you factor in the costs like these, it's a no-brainer to stay on the Microsoft wagon. Compared to the overall cost of doing business, the software costs are negligible.
This is certainly a complex subject which is difficult for an armchair observer to understand completely. Plus, it's extremely difficult to evaluate the success rates given the rarity of events. However, I'm often skeptical that the efforts put in place justify their costs, both in terms of dollars and morale. Your points are well-founded (and I have not read in great detail, either). However, a couple things to consider.
First, I think it's a dubious proposition that you can do much to prevent agents from measuring their susceptibility to additional scrutiny. Unless you can perform extra searches unbeknownst to the searchee, it's going to be difficult to battle the strategy of simply going "dark" (to prevent contact with other agents setting off a new profiling flag), traveling repeatedly over some period of time, determining whether one is being searched more than average, and then using this to determine whether one is a good candidate for carrying out a mission.
Second, unless you're sure the profiled searches are better than random, you're better off putting all your efforts into performing as many random searches as possible. Without more knowledge of the efficacy and costs of "modern" profiling, it's really hard to judge this.
Anyway, my biggest problem with all this is that it's essentially impossible to measure the actual effectiveness of any of these measures. Terrorist events are so rare that you can't just divide hits by total attempts and come up with a percentage. Add to this that most of the details of the measures are (often by necessity) kept confidential, it's very difficult to watchdog the system for abuse. Given the less-than-stellar record of governments (not just US) actually respecting the rights of citizens when not under strict scrutiny, I tend to have very little patience for the "Trust us" mantra that seems to be so common.
I guess this doesn't really affect the mathematical question of random versus profiled scrutiny. However, it's hard to separate these questions -- without information about the profiling, it's hard to reach an independent conclusion as to whether the costs of profiling are justified.
Slashdot Mirror
Note that, at least for Halo 2, if you just waited a few months, the premium maps were released for free.
Vested interest or not, they have no special rights to police the release of information outside of corporate property. They don't get to play vigilante just because they have a lot to lose...
Even child porn/abduction/abuse is not so awful that it trumps any conceivable objection to a law that might in some way reduce it. For example, why not pass a law that allows a parent to kill any adult who looks at their child. Don't you know that 99% of child molesterers have seen their victim in the presence of a parent before they molester them?? It's for the children! But, no, of course, that is ridiculously out of proportion and no one would ever seriously propose such a thing. It's not even a good example of humorous legal hyperbole, but it illustrates one thing -- no one is willing to go "to any length" to save the children. There is some cost at which it is no longer worth it.
Exactly how much we're willing to "spend" (maybe "give up" is a better word) to prevent these crimes is up for some debate, but you can't ignore the analysis based on the nature of the crime. Personally, I believe that an abusive oppressive government is a frightening enough thing that we need to keep it on a very tight leash, even at the cost of some heinous crimes going unpunished. "Better that ten guilty men go free than one innocent man be punished" is the doctrine -- note that it doesn't go on to say "unless a politician with an agenda believes that innocent man might have abused a child; then let him fry."
On aircraft, you have the additional problem that you are moving from cell to cell much faster than the system was designed to handle. So even if you are able to lock and stay locked to a single tower, it'll have to hand you off to the next tower before it's ready to do so.
I've experienced problems which I am pretty sure are related to hopping between towers -- not on an aircraft, but when hiking in the Smokey Mountains in North Carolina. We got up to the top and I was surprised to find that I had 4 or 5 bars! However, when I tried to make calls, I was denied and the signal strength would go up and down. I believe I was seeing towers on both sides of the mountain and the system and/or my phone was getting confused.
Not sure what the flaw in your reasoning is. One glaring flaw based on his article was that he seemed awfully happy to abort and start over from scratch as soon as something went wrong. Further, when he started over, rather than repeating what he'd done before but correcting his misstep, he chose a different install option. That doesn't strike me as a recipe for success. I think, perhaps more than other distros, Gentoo just demands that you either really know what you're doing or you follow the instructions precisely until you do. It doesn't sound like this was his approach...
My first install was a bit hairy -- had a few false starts. However, mistakes rarely meant starting ALL the way over. Since the steps are all just executed at the command prompt, it's pretty easy to reboot and pick up from where you screwed up and do the right thing. This requires fairly good knowledge of Linux, but is certainly not guru level magic.
I've never really looked much at the baselayout stuff. I'd be interested to learn though, so if you are so inclined, there's at least one person out here who'd read your documentation.
To be honest, as I've aged, I find I more and more fall into the "happy that it just works" camp. I've got a pretty solid grasp of how Linux/Unix works, but I haven't taken much time to figure out the nitty-gritty of how Gentoo manages things. I occasionally have to delve into it when things end up outside the "most of the time" part, though. Fortunately, things are usually done sensibly and I don't often find myself hacking to fix something the "wrong" way. Still, sometimes the temptation is pretty strong...
Most of the failure stories I've seen are more like complaining that a cake recipe didn't turn out because you skipped the step where you add the flour in step 3 and used cheese instead of eggs in step 5.
As others have pointed out, Gentoo is not intended for people who are uncomfortable with very low-level configuration. If you're not comfortable following its detailed instructions, then it's quite unapologetically not the distro for you. It's not trying to be the end-all be-all distribution for everyone.
Personally, I am quite comfortable with it and have been through half a dozen installs without any significant problems. I found its instructions to be excellent, although I would say they could do a better job documenting some of the more advanced configuration options (or at least pointing to the existing documentation more obviously from the end of the install). The article's point about incorrectly setting ~x86 globally is a good one -- there are a few wrong ways to set ~x86 for a single package, all of which can screw things up in subtle ways. Still, for my purposes it's been the best distro I've ever used and has lasted me at least as long as any other single distro.
I started off as an emacs user (well, after first starting with the Turbo C++ wordstar-esque(?) IDE). When I got out of college, I worked at a place where vi was the editor of choice for many of the more senior programmers. Partly as an exercise and mostly because running emacs on an old HP-UX box sucked hard, I started using vi. I got pretty good with it, too. Learned all the shortcuts I needed, etc.
After about 6 months, though, I noticed something funny happening. I found that I was subconsciously trying to avoid making more changes to a file than I needed to. I'd adjust my programming/debugging style to keep the number of lines I had to edit to a minimum. Sometimes this was a good thing, but often it ended up making things take longer. After a bit I realized it was because I really found working in vi to be a pain -- I switched back to emacs and had never felt so free in my programming life.
Not much point to my story, other than to share my experience. I still do use vi for quick editing tasks such as config file updates. Still, if I spend too much time in it, my quality of life deteriorates pretty quickly. Not to say there's anything wrong with vi, just doesn't suit the way my brain functions.
This is one of the funniest posts I've read on slashdot in a very long time. Nice work.
Probably not much, but that's not really the point. It's good publicity that can't hurt. People won't go out and think "wow i can help fold proteins," they'll just give a little thought to Sony and the PS3 when they read the articles about it. It's all about marketing, and subliminal marketing is the best kind.
Well, many (such as the New York Times) have recent content online openly, then move it to an archive that you must pay to access later. In that case, they would certainly be upset if google was mirroring their content later.
yeah, yeah, like the same thing doesn't happen to you when you make the mistake of posting to slashdot before noon on a sunday. I don't know why I was even awake...
That's only true if you're really obvious with your betting. There's no reason to scatter the bets to cover the entire target section, just bet on one number in that section. Over a large number of spins, this will have the same statistics as betting on all the numbers in the target. The only difference is it takes longer and is less obvious.
They do everything they can to use these as much as possible, or didn't you notice the thousands of slot machines lining every wall in all of Las Vegas?
Many people find these boring and are more wiling to throw big money at more traditional games. The physical mechanism is part of the attraction...
My father is a professor and uses near-daily quizzes to keep students up on the material, but also has regular exams. He goes to a lot of effort to detect cheating in these. Seating charts were part of it. My favorite touch involved using multiple versions of the exam. These would have the same questions in different order and differently ordered answer options in the multiple choice sections. He would distribute these so he knew which student had which exam. Further, the exams would be printed on different colors of paper. The kicker is that the color of the paper was meaningless, but the students would assume that it differentiated the version of the exam. He would invariably get several students who turned in a set of answers that matched a neighboring student who had a different version of the exam in the same color.
If a professor is reproducing a graphic (or any other verbatim information from another source) in a lecture, the source should be cited, just as for any other presentation. If it's just shown in class, a verbal citation is ok, but if it's printed and distributed in lecture notes, the citation should be in the notes as well (usually at the bottom of the slide with the graphic).
Yep, you're quite right. This is part of the reason that a two-way communication between users and designers/architects is important. Since the users and the architects typically think about the software in different ways, there's usually some back-and-forth to make sure that the architect understands what it is that the user is trying to do. Then, if the architect needs to specify a different way to accomplish that goal, someone needs to pass that along to the user so he knows how to get his job done.
As for connectiong functional specs and requirements, I think you're probably right that they never quite match up. In my experience, this is one of those things you've just got to live with. Often, the paper-pushing effort to nail down those last few things just doesn't pay off.
Maybe it can store the charge for a while, but unless you have more energy storage than an alkaline, you're going to run out of energy pretty quickly at 100x the power delivered. I'm not sure offhand what the energy capacity of a standard double-layer capacitor is, but it's substantially lower than an alkaline battery.
Regardless of how long you're storing the energy, you'd only use this technology (as described) in surge applications. If you don't need 100x the power, then use an alkaline because it'll last longer for low-drain use.
Perhaps I'm not understanding you right, but are you really suggesting that users have no place in the software development cycle other than buying the software and firing off feature requests into the void? That seems like a broken view, but I may not understand what you're saying.
Now, I'll agree that the *developers* are probably not the right people to be fielding user feedback directly. This isn't because they have "more important things to do," rather, it's because a developer doesn't usually have the authority over the architecture of the product to engage in that sort of decision one-on-one with the end user in the first place.
However, to suggest that the users should be left out of the loop entirely is an arrogant view that puts WAY too much confidence in the ability of the architects ("designers" in this article's lingo, I guess) to anticipate every need of the users. Instead, the architects should have some mechanism to get feedback from users. The users are the folks who actually know what they're trying to do with the software, so even if they don't know what's easy to implement, they know what is holding them up. The architects are in a place to understand why the user has requested a feature and to decide whether it is consistent with the design and reasonable to implement.
Every company I've worked for has done this and it's often invaluable, but it does require some effort and discipline. It's a part of understanding the application that the architects must do to some degree as part of the design process. The level of hand-holding that the user gets while making requests will depend on his clout as a customer, ranging from application engineers or even architects going on-site to tailor software to a key customer's needs, to tech support tallying requests for various features and passing them along in aggregate.
One other thought -- just as the user shouldn't be telling the *developer* what to implement, it's also more useful to solicit feedback as "capability requests" rather than "feature requests." The distinction is that a feature request implies (to me, anyway) something like "I want to click here and here and then type "blah blah" and it's done." This is usually too detailed. Instead, the feedback should be "I need to accomplish XYZ rapidly" and the architect should be free to design a solution to this that's consistent with the existing design.
But really, your grandparents aren't going to be helped much because, as you say, they aren't going to patch very often anyway. However, there are plenty of users who ARE technically sophisticated and would be able to take advanced steps to mitigate risk due to a security hole in one piece of software.
Ok, you're right about the lecture not being copyrightable (here's a link that confirms), thanks. With all the noise coming out of the various __AA organizations, it's sometimes hard to remember that the natural legal state of information is actually free.
Still, even if not legally protected, there is a big ethical problem if someone else is using your lecture, verbatim, without attribution. Academically, that is about as wrong as it gets. So the GP (and I) may be confused about IP law, but I don't think there's any question that a professor should reasonably expect that no one will give his lecture without at LEAST crediting him. Preferably he'd be asked and his permission (or lack thereof) be respected.
With regard to handouts or transcripts, there is no question. If those are being duplicated, it's still copyright violation.
No, it really is is IP. His specific wording certainly is his IP, and his examples may be as well. It is a performance. If you simply take his lecture and paraphrase it, you are probably producing a derivative work of his performance. This is not allowed. You are, however, free to take the facts you learned and put together your own lecture from scratch, and I don't think he was trying to claim otherwise.
I'd be pretty upset if someone was taking my work, even work I've been paid for, and presenting it as his own. The GP mentioned his course notes/outline being used by another lecturer without permission and without attribution. That's a BIG no-no. It's not mean-spirited to demand credit or compensation for your work (and no, being paid to give the original lecture is not compensation for someone who turns around and gives a verbatim or paraphrased copy of the lectures later).
and we all know that the web browser saved the DreamCast...
The cost of switching is a lot higher than just the "Microsoft tax." Most companies are heavily invested in particular software packages (CAD, accounting, payroll, etc). These are very specialized packages that often must be guaranteed (and often certified) to meet specific regulatory requirements. Unless the companies behind those packages can be convinced to migrate, there really is no option to switch for the company. When you factor in the costs like these, it's a no-brainer to stay on the Microsoft wagon. Compared to the overall cost of doing business, the software costs are negligible.
This is certainly a complex subject which is difficult for an armchair observer to understand completely. Plus, it's extremely difficult to evaluate the success rates given the rarity of events. However, I'm often skeptical that the efforts put in place justify their costs, both in terms of dollars and morale. Your points are well-founded (and I have not read in great detail, either). However, a couple things to consider.
First, I think it's a dubious proposition that you can do much to prevent agents from measuring their susceptibility to additional scrutiny. Unless you can perform extra searches unbeknownst to the searchee, it's going to be difficult to battle the strategy of simply going "dark" (to prevent contact with other agents setting off a new profiling flag), traveling repeatedly over some period of time, determining whether one is being searched more than average, and then using this to determine whether one is a good candidate for carrying out a mission.
Second, unless you're sure the profiled searches are better than random, you're better off putting all your efforts into performing as many random searches as possible. Without more knowledge of the efficacy and costs of "modern" profiling, it's really hard to judge this.
Anyway, my biggest problem with all this is that it's essentially impossible to measure the actual effectiveness of any of these measures. Terrorist events are so rare that you can't just divide hits by total attempts and come up with a percentage. Add to this that most of the details of the measures are (often by necessity) kept confidential, it's very difficult to watchdog the system for abuse. Given the less-than-stellar record of governments (not just US) actually respecting the rights of citizens when not under strict scrutiny, I tend to have very little patience for the "Trust us" mantra that seems to be so common.
I guess this doesn't really affect the mathematical question of random versus profiled scrutiny. However, it's hard to separate these questions -- without information about the profiling, it's hard to reach an independent conclusion as to whether the costs of profiling are justified.