Expected speeds, as explained through the entire remainder of my post, are based on actual historical performance on the machine. A brand-new device never seen before has no expectation, until the first read - which conveniently happens while mounting the filesystem. By the time the OS is ready for any user-facing operations, it's already read several blocks of data at minimum. That's enough of a history for a basic estimate, recognizing that it's going to be inaccurate for a while.
"Reasonable for the device type" means a quick I/O test should be run on hard disks and optical disks, and anything else where seeking actually makes sense. Flash memory devices, for example, should only be tested for read speed, since excessive writes would reduce the lifespan of the device. Network mounts naturally don't have a "beginning" or "end", so the OS shouldn't try to estimate speeds on that. Likewise, wasting time to test a tape's speed would be ridiculous. I don't think it's excessive for an OS to know about every type of storage device, and whether it's sane to seek on it.
As for knowing in advance where the files are stored, that's part of the filesystem driver. Given that Windows only supports a small handful of filesystems, it'd be a small matter for the API to require planning as the first step in writing a file. When a program asks for an estimate of operations, it should be able to say what those operations are. The OS could go ahead and do the filesystem work of planning where the files will be transferred to and from (conveniently predicting "disk full" errors ahead of time, rather than 2 hours into the process), and from that determine the speed for each operation. Once the planning is complete, the actual copying could commence.
If they don't, then the cost is even higher for them, and you can pursue a claim in court. Most insurance companies will also offer coverage for you being hit by an uninsured driver, as well.
Assuming you can afford to lose the use of your car for several days, possibly weeks.
If you're getting hit at a stoplight, from behind, hard enough to disable your car, then there's something much worse than just tailgating going on. Did you anticipate the stoplight? Were you speeding grossly? Were you being followed by a tank?
Assuming you don't injure yourself.
If you're getting hit at a stoplight, from behind, hard enough to injure, then there's something much worse than just tailgating going on. Also, medical care is often covered by insurance as well.
Assuming they don't strike you with such force that you are then driven into the vehicle in front of you, which by golly usually winds up being your fault anyway.
Yet again, covered by many good insurance plans, and easily mitigated by staying back from the car in front of you.
Assuming your insurance company won't raise your rates for being hit by someone else.
Which is likely, but the rates won't go up by much or for very long.
Yeah, what you say sure makes sense, until you start actually digging in to what the real costs of someone else hitting your car may be.
I've been hit by other cars before. I'm well aware of what the real costs are, and I'm also well aware that the vast majority of cost can be eliminated by driving defensively. Maintain larger buffer spaces, anticipate conditions, and be aware of what hazards are likely to arise soon.
This makes me wonder about the connection between social behavior and a natural inclination toward gambling.
In social settings, a selfish individual can ask others for help (or resources, protection, etc.), and gambles on the chance that they'll have to help someone else. If nobody needs their help, they basically win free resources. If somebody does ask for help, they break even. The only losers are the ones who don't ask for help, but still give to others.
So how do you calculate how long it will take to copy files?
Off the top of my head:
Maintain a table of expected speeds for each storage device on the filesystem. Record how long it takes to read the filesystem information. When a device is mounted, if it's reasonable for the device type, seek to the middle and end, measuring speeds there, too. Get approximate curves for the read and write speeds across locations, and use those for future estimates. For future read and write operations, take note of where they are and how fast they go, and adjust the curves accordingly.
When an operation starts, look at the curves for input and output for the respective devices. Find the expected speed for the target location. Whichever speed is lower should be used for the estimate.
With so many conditions and edge cases and minutia, simply projecting estimates from sampled speed data seems like a pretty good compromise if you want an estimate of the time.
Edge cases are edge cases, and shouldn't be causing incorrect estimates most of the time. Estimating based on the first few seconds of an operation makes sense if that's all the information you have, but a modern operating system should be able to know so much more than that now. It should be able to know the effects of virus scanners and verification. It should know how fast a device has performed in the past.
Problem is, people don't understand it's an estimate.
Saying that your transfer will take somewhere between 5 minutes and 9 hours is not an estimate. It's a mockery. What I want to know is whether I should get a cup of coffee, watch some TV, or read a novel. What I'm told is that my OS has no idea what it's working with.
Are you sick? Come ask your invisible friend in the sky for help! Come share air with dozens of others asking for other things. Too sick to leave home? We'll send a carrier to your home to take your problems back to the church!
I jest, of course, but not by much. Religion relies on community, just as much as an epidemic does. That said, there's also a few interesting correlations between some religious taboos and common disease carriers. It's like whoever designed the religious laws somehow knew about germ theory hundreds of years before anyone else. Either that, or they just noticed that certain things smelled bad, and people who spent time near bad-smelling things got sick.
I know it's terribly unpopular to be the voice of reason in a "GOVERNMENT IS BAD" discussion, but this meeting may not be a bad thing. Perhaps the government just wants insight into how they can get advance notice of violent trends. Perhaps Twitter can provide easy access to its data, to find people bragging about the loot they took. Perhaps whatever socioeconomic factors (if any) that led to the riots could be derived from other posts by the rioters, and the government could better understand the problems it faces.
But hey... never mind me. Let's all continue jumping to conclusions anyway. Up next, Linux Torvalds looks at Windows 8. Could this mean Microsoft secretly controls Linux development?
And yet, a farmer can increase his yield by using monitoring equipment to more accurately time the addition of fertilizers. Harvesters can be driven with the aid of laser mapping, allowing for safer early-morning and late-night operation. Animals can be given more freedom and mad more comfortable, thanks to tracking beacons and climate-controlled housing.
All of that nice equipment is managed by software.
Every major cable provider tracks what you watch already. Your cable box asks the provider for a particular show, and that request is logged. The logs are collected and reports are generated. This has been going on for many years, and no, you don't need to consent.
I'm not saying this is a good thing, but I do wonder how many of the folks saying they'll never buy these TVs because of privacy concerns already use cable.
both old plugs and new plugs are going to fall out all the fucking time.
Unless somebody does something intelligent, like using a rare-earth magnet. A quick test with a neodymium magnet and a nearby pair of headphones shows that even a line of contact (cylinder/plane contact) is enough to hold the plug while I put it in my pocket. Pulling the magnet out of my pocket by the cord did separate the two, but note that's a shearing motion. A neodymium jack would have much more contact area, so the magnetic attraction would be even stronger, and the physical shape of the tip will hold the plug even more securely.
No, it's probably not going to be as resistant to disconnects as other plugs, and I certainly won't be hoping to see it in my stage sound system, but it'll be just fine for an iPod or iPhone, even for joggers.
Well, the fact is Kenya's not Korea in in terms of Internet access. Here's hoping they catch up.
Do you have firsthand knowledge of this? When I volunteered in Ghana (which is more well-developed than Kenya, but not by much), most mid-size villages of about 500 or more people had Internet access. No, it wasn't spectacularly fast or reliable, but for $0.75 you could spend an hour online. Anyone with enough income to spend $80 on a phone can likely also afford to go online for long enough to set up whatever they need.
Then there's the mobile network itself. Ghana's cellular coverage was more widespread than its landline grid, because the country almost skipped the whole "wired telephone" phase, going from having nothing to having widespread cellular use. In Kenya, the more rural territory isn't covered, but most urban areas appear to be. Based on what I saw in Ghana, service is likely 3G or better, meaning decent data service is available to those who can afford it. Again, if someone can afford a $80 phone, they likely have a friend with Internet access on their phone.
It's just Africa. It's not some remote uncivilized wilderness, despite what enduring stereotypes may have you believe.
Quite obviously and openly so, but at least their facts check out. Just like every other source I've seen on both sides of the issue, there's missing data, but everybody jumps to their preferred conclusion.
I've seen it, and it also lacks base-line data for many of its statements. The majority of the "facts" presented are exaggerated at best, and often outright wrong.
The Duke study just compares drilling areas to non-drilling areas. There is a correlation between drilling and having methane, but there's also a correlation between having naturally-high amounts of methane in the ground and getting the first drills. To my knowledge, there was no before-and-after testing, and little testing of wells in high-methane areas without drilling.
Interestingly, the study you linked is the one mentioned in the summary, but you went straight to the study, rather than the news article which also mentions these problems.
Every other study I've seen has been similar: Evidence of correlation, but not much supporting causation. Do you have anything more conclusive?
I quit paying attention to your explanation/rant after one particular choice of words:
avoid the Cloud at all costs.
I immediately envision a scenario where the cost of setting up management, infrastructure, and equipment is significantly larger than the cost of losing a portion (or perhaps even all) of a company's data or processing capacity. Rejecting cloud services as a viable option regardless of the actual cost is just as asinine as rejecting the option for turning on hot water in the bathroom sink, because it just might be too warm for somebody.
When I risk my sanity long enough to pick out a few more words, I find you dismissing the cloud as being only suitable for "irrelevant" data. Apparently, all data is either "core business data" or "irrelevant", and there's no such thing as "nice to have around", "those old backups", or simply "not worth handling on our own". Of course, the existence of special-purpose clouds is ignored, along with private and internal clouds.
As for auditing, uptime, and legal consequences, you've apparently never dealt with a service contract. If the contract mandates five nines of uptime, and includes a clause making them liable for all damages and loss, that's a pretty hefty legal comeback.
I do sincerely hope I'm never a customer of your company.
I worked with medical records, stored in HBase with minimal structure. The application dealt with statistics over millions of patients. Missing a few elements of a record by the time a processing job went looking for them was practically irrelevant, and even desirable sometimes. By discarding most of the structure of the data, the meaningful information could be summarized in a concise form suitable for the needs of the application. The application I worked on could deliver results from scratch in 3 hours comparable to a (Oracle-using) competitor's results after 6 months. That speed improvement came primarily from being able to directly compare medical cases, regardless of how the records were originally organized.
The benefits of flexibility are significant. Use an RDBMS for things it's good at - like storing data where ACID is necessary - but please don't require unnecessary constraints on the possible uses. Flexibility is good!
The linked article proves nothing, and in fact outright says it doesn't matter, because the data's inconclusive. Again, the summary's misleading.
The data used was based on StackOverflow users' ages and reputation scores. The correlation is that users with higher recorded ages have better reputations. That hardly equates to being a better programmer. Perhaps, after 20 more years of dealing with society, those older users have learned that writing a thorough response with proper grammar is better than "u shud look 4 the widget lib." Perhaps the older users have simply seen more of the world, and can infer more about the question's actual meaning without being given explicit details. Perhaps those users who are young and knowledgeable have lied about their age, to avoid the ageism that pervades the professional world. Perhaps those younger users don't bother building up a reputation, because of objections to establishing permanent identities.
Even if we we accept that the StackOverflow data shows a correlation between age and actual programming ability, we still need to define that ability in a meaningful sense for each workplace application. Consider, for example, the current biases surrounding the use of NoSQL storage systems. To someone with a background in traditional RDBMSs, this NoSQL fad is ridiculous, because it abandons ACID, seemingly only to avoid SQL. To someone with a more theoretical background, a database unfettered by ACID is more flexible, and if using that flexibility requires a different means of expression, then so be it. Which approach is correct depends entirely upon whether the business needs flexibility or consistency.
If someone is looking for "good" programmers, they should first be able to define exactly what "good" means to them. StackOverflow reputation isn't really a very good metric for each personal opinion.
I certainly don't make the claim that the organizations supporting terror have "won", or even come significantly closer to accomplishing whatever it is they seek. That sort of assertion would require far more insight into international politics than I care to pursue.
In any negotiation, from a child's sidewalk lemonade stand to international politics, there is a common element: persuasion. One party must convince the other that life will be better if they go along with the proposed plan. In the case of a lemonade stand, a smile and a cool drink will often suffice. For politics, more drastic measures are usually needed. For various reasons, certain people and groups have determined that the best method for persuading other governments is to make their lives worse. That's where terror comes in.
Terrorism itself is not the final goal, but it is an intermediate one. If the kid down the street wants to buy a bike, his intermediate goal is to save enough money, and that means that first he has to convince you to buy lemonade. He could talk about how refreshing the lemonade is, to persuade you to buy. If al-Qaeda wants to collapse the U.S. economy, their intermediate goal is to provoke the United States into going to war, and that means they first have to convince the U.S. government that they're worth hunting down. They can cause terror, to convince the government that they're a hazard that should be attacked.
It's not a question of "good-vs-evil". It's a matter of choosing tactics to reach the desired outcome, and meeting intermediate goals along the way. Given that the American public now lives in fear, often assuming everything abnormal is a serious threat, I'd say that anyone looking to cause terror in the United States has met that particular goal. I'm sure there are further goals ahead, and I'm sure there are more complicated issues at hand than there are for a lemonade stand. As stated in the thread topic, it's all about goals.
An inventor who's exhausted his budget on R&D has an incentive to lower the value of his patent, to lower the cost to register. Big companies with money to burn on registration can artificially inflate their value, giving them justification for high licensing prices. Knowing that the patent will be awarded doesn't help, because it's likely more profitable for an investor to license the technology after the fact than invest in the patent itself.
Mandatory licensing partially defeats the purpose of patents in the first place, because the inventor is no longer able to control their invention. Instead, anyone with money can make a one-time purchase of the technology and be done with it. The idea of founding a company to sell a new product becomes impractical.d
There is no difference between misjudging a patent's practical use, or intentionally trying to troll. Consider Microsoft's Kinect: What started as a video game controller became a robot navigation system, assistance tool for the blind, and many other things. If another invention sees a similar explosion in application, should the inventor really be prohibited from capitalizing on the technology they created?
The only difference between an underdog inventor and a patent troll is intent. No matter how many complications are added to the patent system, somebody's going to abuse the system and screw over somebody else. In my opinion, a better response to patent trolling is a RICO-style legislation that criminalizes using repetitively using patents to stifle innovation. If some entity consistently is slow to act on infringement, acquires many patents they never attempt to produce, or repeatedly sues companies for vague patents, they get in trouble. Penalties could range from fines to losing patents.
Don't think of it as a franchise. Think of it in the same way that Marvel does/wants us to think they do: It's a single enormous story, told in several parts from several perspectives.
Slashdot Mirror
...a committed Chiropractor.
I think all chiropractors should be committed. They're all crazy.
Expected speeds, as explained through the entire remainder of my post, are based on actual historical performance on the machine. A brand-new device never seen before has no expectation, until the first read - which conveniently happens while mounting the filesystem. By the time the OS is ready for any user-facing operations, it's already read several blocks of data at minimum. That's enough of a history for a basic estimate, recognizing that it's going to be inaccurate for a while.
"Reasonable for the device type" means a quick I/O test should be run on hard disks and optical disks, and anything else where seeking actually makes sense. Flash memory devices, for example, should only be tested for read speed, since excessive writes would reduce the lifespan of the device. Network mounts naturally don't have a "beginning" or "end", so the OS shouldn't try to estimate speeds on that. Likewise, wasting time to test a tape's speed would be ridiculous. I don't think it's excessive for an OS to know about every type of storage device, and whether it's sane to seek on it.
As for knowing in advance where the files are stored, that's part of the filesystem driver. Given that Windows only supports a small handful of filesystems, it'd be a small matter for the API to require planning as the first step in writing a file. When a program asks for an estimate of operations, it should be able to say what those operations are. The OS could go ahead and do the filesystem work of planning where the files will be transferred to and from (conveniently predicting "disk full" errors ahead of time, rather than 2 hours into the process), and from that determine the speed for each operation. Once the planning is complete, the actual copying could commence.
Natural selection at its finest.
Assuming they have insurance.
If they don't, then the cost is even higher for them, and you can pursue a claim in court. Most insurance companies will also offer coverage for you being hit by an uninsured driver, as well.
Assuming you can afford to lose the use of your car for several days, possibly weeks.
If you're getting hit at a stoplight, from behind, hard enough to disable your car, then there's something much worse than just tailgating going on. Did you anticipate the stoplight? Were you speeding grossly? Were you being followed by a tank?
Assuming you don't injure yourself.
If you're getting hit at a stoplight, from behind, hard enough to injure, then there's something much worse than just tailgating going on. Also, medical care is often covered by insurance as well.
Assuming they don't strike you with such force that you are then driven into the vehicle in front of you, which by golly usually winds up being your fault anyway.
Yet again, covered by many good insurance plans, and easily mitigated by staying back from the car in front of you.
Assuming your insurance company won't raise your rates for being hit by someone else.
Which is likely, but the rates won't go up by much or for very long.
Yeah, what you say sure makes sense, until you start actually digging in to what the real costs of someone else hitting your car may be.
I've been hit by other cars before. I'm well aware of what the real costs are, and I'm also well aware that the vast majority of cost can be eliminated by driving defensively. Maintain larger buffer spaces, anticipate conditions, and be aware of what hazards are likely to arise soon.
If they're following close and hit you, it's usually legally their fault and their insurance paying the cost. They'll learn, eventually.
This makes me wonder about the connection between social behavior and a natural inclination toward gambling.
In social settings, a selfish individual can ask others for help (or resources, protection, etc.), and gambles on the chance that they'll have to help someone else. If nobody needs their help, they basically win free resources. If somebody does ask for help, they break even. The only losers are the ones who don't ask for help, but still give to others.
So how do you calculate how long it will take to copy files?
Off the top of my head:
Maintain a table of expected speeds for each storage device on the filesystem. Record how long it takes to read the filesystem information. When a device is mounted, if it's reasonable for the device type, seek to the middle and end, measuring speeds there, too. Get approximate curves for the read and write speeds across locations, and use those for future estimates. For future read and write operations, take note of where they are and how fast they go, and adjust the curves accordingly.
When an operation starts, look at the curves for input and output for the respective devices. Find the expected speed for the target location. Whichever speed is lower should be used for the estimate.
With so many conditions and edge cases and minutia, simply projecting estimates from sampled speed data seems like a pretty good compromise if you want an estimate of the time.
Edge cases are edge cases, and shouldn't be causing incorrect estimates most of the time. Estimating based on the first few seconds of an operation makes sense if that's all the information you have, but a modern operating system should be able to know so much more than that now. It should be able to know the effects of virus scanners and verification. It should know how fast a device has performed in the past.
Problem is, people don't understand it's an estimate.
Saying that your transfer will take somewhere between 5 minutes and 9 hours is not an estimate. It's a mockery. What I want to know is whether I should get a cup of coffee, watch some TV, or read a novel. What I'm told is that my OS has no idea what it's working with.
Are you sick? Come ask your invisible friend in the sky for help! Come share air with dozens of others asking for other things. Too sick to leave home? We'll send a carrier to your home to take your problems back to the church!
I jest, of course, but not by much. Religion relies on community, just as much as an epidemic does. That said, there's also a few interesting correlations between some religious taboos and common disease carriers. It's like whoever designed the religious laws somehow knew about germ theory hundreds of years before anyone else. Either that, or they just noticed that certain things smelled bad, and people who spent time near bad-smelling things got sick.
I know it's terribly unpopular to be the voice of reason in a "GOVERNMENT IS BAD" discussion, but this meeting may not be a bad thing. Perhaps the government just wants insight into how they can get advance notice of violent trends. Perhaps Twitter can provide easy access to its data, to find people bragging about the loot they took. Perhaps whatever socioeconomic factors (if any) that led to the riots could be derived from other posts by the rioters, and the government could better understand the problems it faces.
But hey... never mind me. Let's all continue jumping to conclusions anyway. Up next, Linux Torvalds looks at Windows 8. Could this mean Microsoft secretly controls Linux development?
And yet, a farmer can increase his yield by using monitoring equipment to more accurately time the addition of fertilizers. Harvesters can be driven with the aid of laser mapping, allowing for safer early-morning and late-night operation. Animals can be given more freedom and mad more comfortable, thanks to tracking beacons and climate-controlled housing.
All of that nice equipment is managed by software.
Every major cable provider tracks what you watch already. Your cable box asks the provider for a particular show, and that request is logged. The logs are collected and reports are generated. This has been going on for many years, and no, you don't need to consent.
I'm not saying this is a good thing, but I do wonder how many of the folks saying they'll never buy these TVs because of privacy concerns already use cable.
both old plugs and new plugs are going to fall out all the fucking time.
Unless somebody does something intelligent, like using a rare-earth magnet. A quick test with a neodymium magnet and a nearby pair of headphones shows that even a line of contact (cylinder/plane contact) is enough to hold the plug while I put it in my pocket. Pulling the magnet out of my pocket by the cord did separate the two, but note that's a shearing motion. A neodymium jack would have much more contact area, so the magnetic attraction would be even stronger, and the physical shape of the tip will hold the plug even more securely.
No, it's probably not going to be as resistant to disconnects as other plugs, and I certainly won't be hoping to see it in my stage sound system, but it'll be just fine for an iPod or iPhone, even for joggers.
One of my in-laws is ranked in the top 150 Scrabble players in North America. Last I knew, his three daughters were fairly sure they existed.
Well, the fact is Kenya's not Korea in in terms of Internet access. Here's hoping they catch up.
Do you have firsthand knowledge of this? When I volunteered in Ghana (which is more well-developed than Kenya, but not by much), most mid-size villages of about 500 or more people had Internet access. No, it wasn't spectacularly fast or reliable, but for $0.75 you could spend an hour online. Anyone with enough income to spend $80 on a phone can likely also afford to go online for long enough to set up whatever they need.
Then there's the mobile network itself. Ghana's cellular coverage was more widespread than its landline grid, because the country almost skipped the whole "wired telephone" phase, going from having nothing to having widespread cellular use. In Kenya, the more rural territory isn't covered, but most urban areas appear to be. Based on what I saw in Ghana, service is likely 3G or better, meaning decent data service is available to those who can afford it. Again, if someone can afford a $80 phone, they likely have a friend with Internet access on their phone.
It's just Africa. It's not some remote uncivilized wilderness, despite what enduring stereotypes may have you believe.
Wasn't that done in a movie?
Quite obviously and openly so, but at least their facts check out. Just like every other source I've seen on both sides of the issue, there's missing data, but everybody jumps to their preferred conclusion.
I've seen it, and it also lacks base-line data for many of its statements. The majority of the "facts" presented are exaggerated at best, and often outright wrong.
The Duke study just compares drilling areas to non-drilling areas. There is a correlation between drilling and having methane, but there's also a correlation between having naturally-high amounts of methane in the ground and getting the first drills. To my knowledge, there was no before-and-after testing, and little testing of wells in high-methane areas without drilling.
Interestingly, the study you linked is the one mentioned in the summary, but you went straight to the study, rather than the news article which also mentions these problems.
Every other study I've seen has been similar: Evidence of correlation, but not much supporting causation. Do you have anything more conclusive?
Gravity-powered fluidics?
I quit paying attention to your explanation/rant after one particular choice of words:
avoid the Cloud at all costs.
I immediately envision a scenario where the cost of setting up management, infrastructure, and equipment is significantly larger than the cost of losing a portion (or perhaps even all) of a company's data or processing capacity. Rejecting cloud services as a viable option regardless of the actual cost is just as asinine as rejecting the option for turning on hot water in the bathroom sink, because it just might be too warm for somebody.
When I risk my sanity long enough to pick out a few more words, I find you dismissing the cloud as being only suitable for "irrelevant" data. Apparently, all data is either "core business data" or "irrelevant", and there's no such thing as "nice to have around", "those old backups", or simply "not worth handling on our own". Of course, the existence of special-purpose clouds is ignored, along with private and internal clouds.
As for auditing, uptime, and legal consequences, you've apparently never dealt with a service contract. If the contract mandates five nines of uptime, and includes a clause making them liable for all damages and loss, that's a pretty hefty legal comeback.
I do sincerely hope I'm never a customer of your company.
I worked with medical records, stored in HBase with minimal structure. The application dealt with statistics over millions of patients. Missing a few elements of a record by the time a processing job went looking for them was practically irrelevant, and even desirable sometimes. By discarding most of the structure of the data, the meaningful information could be summarized in a concise form suitable for the needs of the application. The application I worked on could deliver results from scratch in 3 hours comparable to a (Oracle-using) competitor's results after 6 months. That speed improvement came primarily from being able to directly compare medical cases, regardless of how the records were originally organized.
The benefits of flexibility are significant. Use an RDBMS for things it's good at - like storing data where ACID is necessary - but please don't require unnecessary constraints on the possible uses. Flexibility is good!
The linked article proves nothing, and in fact outright says it doesn't matter, because the data's inconclusive. Again, the summary's misleading.
The data used was based on StackOverflow users' ages and reputation scores. The correlation is that users with higher recorded ages have better reputations. That hardly equates to being a better programmer. Perhaps, after 20 more years of dealing with society, those older users have learned that writing a thorough response with proper grammar is better than "u shud look 4 the widget lib." Perhaps the older users have simply seen more of the world, and can infer more about the question's actual meaning without being given explicit details. Perhaps those users who are young and knowledgeable have lied about their age, to avoid the ageism that pervades the professional world. Perhaps those younger users don't bother building up a reputation, because of objections to establishing permanent identities.
Even if we we accept that the StackOverflow data shows a correlation between age and actual programming ability, we still need to define that ability in a meaningful sense for each workplace application. Consider, for example, the current biases surrounding the use of NoSQL storage systems. To someone with a background in traditional RDBMSs, this NoSQL fad is ridiculous, because it abandons ACID, seemingly only to avoid SQL. To someone with a more theoretical background, a database unfettered by ACID is more flexible, and if using that flexibility requires a different means of expression, then so be it. Which approach is correct depends entirely upon whether the business needs flexibility or consistency.
If someone is looking for "good" programmers, they should first be able to define exactly what "good" means to them. StackOverflow reputation isn't really a very good metric for each personal opinion.
I certainly don't make the claim that the organizations supporting terror have "won", or even come significantly closer to accomplishing whatever it is they seek. That sort of assertion would require far more insight into international politics than I care to pursue.
In any negotiation, from a child's sidewalk lemonade stand to international politics, there is a common element: persuasion. One party must convince the other that life will be better if they go along with the proposed plan. In the case of a lemonade stand, a smile and a cool drink will often suffice. For politics, more drastic measures are usually needed. For various reasons, certain people and groups have determined that the best method for persuading other governments is to make their lives worse. That's where terror comes in.
Terrorism itself is not the final goal, but it is an intermediate one. If the kid down the street wants to buy a bike, his intermediate goal is to save enough money, and that means that first he has to convince you to buy lemonade. He could talk about how refreshing the lemonade is, to persuade you to buy. If al-Qaeda wants to collapse the U.S. economy, their intermediate goal is to provoke the United States into going to war, and that means they first have to convince the U.S. government that they're worth hunting down. They can cause terror, to convince the government that they're a hazard that should be attacked.
It's not a question of "good-vs-evil". It's a matter of choosing tactics to reach the desired outcome, and meeting intermediate goals along the way. Given that the American public now lives in fear, often assuming everything abnormal is a serious threat, I'd say that anyone looking to cause terror in the United States has met that particular goal. I'm sure there are further goals ahead, and I'm sure there are more complicated issues at hand than there are for a lemonade stand. As stated in the thread topic, it's all about goals.
Isn't this the very goal of terrorism? To disrupt our daily activities with irrational fear?
Disadvantages:
The only difference between an underdog inventor and a patent troll is intent. No matter how many complications are added to the patent system, somebody's going to abuse the system and screw over somebody else. In my opinion, a better response to patent trolling is a RICO-style legislation that criminalizes using repetitively using patents to stifle innovation. If some entity consistently is slow to act on infringement, acquires many patents they never attempt to produce, or repeatedly sues companies for vague patents, they get in trouble. Penalties could range from fines to losing patents.
Don't think of it as a franchise. Think of it in the same way that Marvel does/wants us to think they do: It's a single enormous story, told in several parts from several perspectives.