Agreed that location is very important. You should also avoid placing a smoke detector right next to a bathroom door. When you shower, the steam can set it off. Move the detector a few feet farther away and the problem goes away.
That said, what you're saying about detector sensitivity is not entirely correct. As I understand it, most household smoke detectors effectively get more sensitive due to dust gathering in the smoke chamber. It takes less smoke to trigger an alarm because the dust in the chamber is contributing to a higher baseline level, which more than makes up for the decreased sensitivity of the actual sensors. Newer designs supposedly compensate for this, so I'd expect this to be less relevant in the coming years, but at least for the smoke detectors that are old enough that they ought to be replaced today, I don't think any of them did.
Taking the battery out of the smoke alarm is an option right after you burn the food, but leaving it out for a month isn't. If the alarm is that much of an annoyance, that means the smoke alarm is too old, and you should replace the smoke alarm.
Besides, this is not at all like a smoke alarm where the alarm might just be a nuisance (burnt popcorn, too many candles, steam from the bathroom, overcooked biscuits, etc.) and where the cause is understood (poor placement, stove fire, etc.). When alarms on an oil rig go off, you know you have a problem. The only questions you should ask are "How big?" and "What do I need to replace?".
There are no false positives when you're talking about critical safety systems on something that could cause such widespread damage in the event of a failure. Any problem is something that needs to be dealt with; if it's a bad sensor causing a false positive, the sensor needs to be replaced.
Indeed, one of the causes of the last disaster was that alarms had been going off for weeks and instead of fixing the underlying problem, they turned off the alarms. The alarms were not the problem. The alarms were indications that something was wrong. The problem was that A. things were not working, and B. people ignored the problems rather than taking corrective measures.
If we were talking about safety systems that, due to their complexity, cannot be made reliable---if constant false positives were inevitable (e.g. car alarms)---then yes, I would agree that the alarms were the problem. That said, I have no reason to believe that this is the case, and more to the point, if that is the case, then proper oil rig safety is impossible, which means that we should not be drilling off the coast, period.
If a company was really interested in making a product, they'd check the relevant patent numbers online (which is pretty easy to do) and see that they had expired. No company that is/seriously/ interested in a product would simply look at it and give up. The company would certainly look up the patent to try to "get around it" and see that it had expired.
When this law was written, looking up the patent likely meant somebody taking a horseback ride to Washington D.C. to the patent office and paying a patent clerk to locate the patent and bring it out for inspection. At the time, the law made perfect sense. However, technological progress has rendered the law unnecessary and absurd.
And this, friends, is a perfect example of why EVERY law should be required to have a sunset clause after which time it is abandoned if not explicitly renewed. The fact that all these archaic laws are still on the books is embarrassing. Important laws will, of course, be renewed. Unimportant laws won't. This would also effectively cap the number of laws that can exist at any given time, which would be a good thing.
Because they can. And this is why tethering apps are the most popular jailbreak apps on iPhone according to several websites. Want to know why so many iPhone users jailbreak? Look no farther than AT&T.
AT&T will look for any opportunity to overcharge their customers---to squeeze a little more blood out of them. They are fundamentally harmful by any standard, whether you're talking about the Internet, phone, whatever, but they are such an entrenched monopoly that they are too big to take behind the barn and shoot.
Thanks, Reagan, for the most completely failed monopoly breakup in our nation's history.
Except that the studies have been leaning fairlly conclusively this direction for decades. We've known about the heart benefits since the 1970s, and recent studies continue to point even more strongly in this direction.
True, though, that it is a balancing act---binge drinking is linked to increased rates of certain benign breast diseases in women that can be precancerous, for example---but that seems to be true for pretty much everything.
I find that garbage collection actually reduces maintainability significantly. Instead of having well defined points where objects are disposed of (which you can find with a simple grep), you now have objects disappearing (or not disappearing) magically, seemingly at random, whenever any of a million variables gets changed. It's like the difference between counting the number of people on a train and counting the number of people in a city park. The more places people can get in or out, the more intractable the problem.
When GC fails to do the right thing (and it inevitably does if your program gets complex enough) and you end up with a colossal memory leak or an entire object subgraph suddenly disappearing because one piece of code inadvertently used a weak reference where it should have used a strong one, you now have a nightmarishly hard-to-find bug on your hands that makes maintaining manually memory-managed code seem positively simple by comparison.
I've maintained large projects with both GC and manually memory managed schemes. I'll never write a large piece of code in a garbage collected language again except by force. Garbage collection may take away the need to spend extra effort on managing memory in the simple cases, but it takes away control and ease of debugging in the complex cases. In the long run, all successful software becomes complex. Thus in terms of long-term maintenance, garbage collection will always eventually come back to bite you on the rear.
You're assuming that governments don't already have a backdoor into all these services that you mention. They have done so. Read your terms of use and privacy policy for gmail, yahoo, etc. They specifically mention the fact that they will not hand over your stuff to anyone _unless_ the request is backed by a government agency (subpoena, state orders, etc.).
Turning over data in response to a subpoena is not the same thing as warrantless wiretaps, and turning over data in response to a subpoena from another country is not the same thing as turning it over in response to a subpoena from the country where ISP is. I would expect the latter. The former would be horrifying. If any arbitrary country could subpoena anybody's mail, then we would have some pretty serious problems.
Further, even if those particular companies have agreements with India's government, the near-total anonymity afforded by many of those services would make it very difficult for the government to determine much beyond what that one person knows. You can usually get that much from interrogation alone. If you're going to be spying on someone over a long period of time, it's usually because you're trying to find out who that person knows, and find out who the other players are. That's problematic if you're trying to get subpoenas against a dozen different ISPs in a dozen countries, only to come up dry because all the accounts were created under pseudonyms.
Of course, you're also assuming that terrorists are these highly efficient government run outfits. Surprise, they're not always that way.
I'm not assuming that terrorists are highly efficient outfits, but I am assuming that they have computer people among their ranks. That's a very safe assumption, from everything I've read on the subject. And even if I'm wrong, you have to assume that they're not complete morons. If they are aware that their communication channel is compromised, they won't keep using it as if nothing has changed.... It's not like phone wiretaps. The bad guys have to assume that the government has the ability to tap everything, filter it, and identify threats. So as soon as the government gets the ability to tap it at all, the entire use of that channel becomes immediately worthless, ensuring its swift replacement with something more secure.
And even if the Indian government managed to get EVERY ISP in the entire world to cooperate, there's still stuff like Freenet that makes encrypted email seem like a toy.
In short, tapping electronic communications can only work against VERY clueless bad guys, and the government can't possibly be clueless enough not to know this, so you have to ask yourself what they're really trying to accomplish.
Two things. First it is hard. It takes an almost anal level of attention to detail especially in a multi-threaded environment. That's something woefully missing in your run of the mill programmer. Second, the bugs introduced can be EXTREMELY subtle and VERY difficult to find especially in a multi-threaded environment.
No, and no. If you are doing multithreaded programming, you can use reference counting. It's not at all hard to do explicit retain/release unless your program is crap by design. In many cases, doing so explicitly and with careful thought can greatly improve performance.
For example, not all garbage collectors do a great job when you have complex circular data structures. However, if you know that your complex structure is principally a tree with some links to higher nodes, you can simply not use a reference count, but rather a reverse reference list to point to the nodes that link backwards, then unlink the back-references as part of your destructor when the reference count goes to zero. Yes, you can potentially use weak references for the same thing, but that assumes that you don't need to change some other aspect of the data structure when the uplinked node becomes unavailable, e.g. caching the last value of some field in the higher node.
And, of course, if you know that the entire data structure, regardless of complexity, comes and goes away as soon as there are no references to the root node remaining, then you can make things much, much simpler with explicit memory management. You use a reference-counted object that points to the root node instead, and in its destructor, you recursively nuke the actual data structure with abandon. Then, there's no reason to worry about whether a particular reference should be strong or weak.
Likewise, many garbage collectors aren't good at quickly disposing of objects that are only created momentarily, used, then disposed of within a single function. For those objects, manual allocation is always a better choice in terms of performance because you can be absolutely certain that they don't linger any longer than necessary. If those data objects are large, this can have a significant impact on performance versus GC.
And without regard to how good or bad the GC system is, you can always get a big performance win by manually managing everything. As soon as you have a thread traversing an object graph to check reachability, you've already lost the performance battle at a very fundamental level. You're either wasting CPU cycles, wasting memory, or both to determine whether an object can be freed---information that the programmer should be able to much more easily and quickly determine due to having a better understanding of which objects can realistically reference it.
Sure, a naive multithreaded programmer who doesn't use any reference counters and tries to free things while another thread is still using them can break things, but that's also true of the naive programmer who doesn't use reader-writer locks around data structures to prevent somebody from reading them while another thread is taking nodes out of a linked data structure, etc. Your example could just as easily have occurred with somebody assigning a value to NULL outside the lock. Indeed, your example is actually trivial to detect with proper tests (particularly when compared with arbitrary data structure mutations, hence the reason that you should religiously confine code that modifies data structures to a handful of functions that do nothing but modify the data structure in a particular way). You can simply add code in the destructor (C++ example):
#if DEBUG object_type *rootObject = this->getRootObject(); for (int i=0; i<100; i++) { int islockedforwriting = pthread_rwlock_tryrdlock(rootObject->rdwrlock(); assert(islockedforwriting != 0);// We should not be able to obtain a read lock right now. } #endif
There is huge difference in the way Indians perceive terrorism when compared to Americans. Americans easily dismiss govt. efforts such as these in the name of privacy invasion. But, when you are closer to getting your ass bombed by a neighborhood terrorist, then privacy is the last thing on your mind. You will be actually grateful that your govt is pulling all stops to giving terrorist easy options to communicate and escape their radar. Terrorism in India is daily reality. Its more direct. US has not faced a terror attack on its soil since 2001. India, OTOH, faces a huge terror attack every year (remember 26/11 Mumbai), in addition to attacks in Kashmir every other day. So, when Indians look at this issue, its much less about invasion of privacy and much more about security and closing gaps for insurgents (Maoists) and terrorists from across the border.
Has it ever occurred to you that the very environment of fear and distrust is what breeds terrorism in the first place and that one of the reasons that the U.S. has had few terrorist attacks is that the vast majority of the public as a whole doesn't feel like the government is out to get them? We get to know our neighbors, and for the most part, if a neighbor were hatching a terrorist plot, usually somebody would notice. We do that because we know that the only thing standing between us and anarchy or tyranny is ourselves. Historically, the closer any country has come to being a police state, beyond a certain point, the more problems they have had. It's a vicious cycle, and the harder you try to clamp down, the more violent the dissent, until it becomes uncontrollable. That's basic psychology, really.
Most of the intelligence attack trawthed by Indian Intelligence agencies are through wiretaps and intercepts of mobile calls between terrorists and their handlers across the border in Kashmir. So, from the point of Indian Intelligence agencies, its very important to intercept RIM calls as well. When you are faced with fear that the daily metro train you take to office might be blown off or that restaurant you visit for dinner might be attacked by gunmen, privacy invasion is the last thing on your mind. I am an Indian and have gone through such moments in my life. And I very well understand what my govt. is trying to do here!
It would take any competent user all of five minutes to get around this. All you have to do is use an IMAP mail service other than RIM's. The people who care about using push email are not the terrorists. They are the businesses that employ your citizens. The terrorists couldn't give a rat's ass about push email. They use it because it is there. The second they get wind that RIM is going to make all their email available, they will migrate their data to Gmail, delete all their email, and close their accounts. By the time RIM actually capitulates, any information the Indian government could possibly hope to obtain will have long since been destroyed. And when the Indian government goes after Gmail, they'll move to Yahoo Mail. And when they go after Yahoo Mail, they'll move to something else. It's so easy to change ISPs that it is utterly naive to think that what you're talking about will have ANY real impact on terrorism.
You can't stop terrorism by screwing over everyone else. That just makes your citizens angry and resentful of the government. And after long enough, those angry, resentful citizens decide to take up arms. Then, a terrorist cell is born.
Except that unless you limit it to Indian MobileMe users, no matter how you threaten them, Apple cannot feasibly provide the same service to the Indian government. The only reason RIM can is that all the email data going to your phone is stored by RIM's servers. In effect, RIM is acting as an ISP operating in India. All a user has to do is NOT use an Indian ISP and NOT use any other ISP that has agreed to their demands and that user will have encryption without government eavesdropping. It's such a low technical hurdle that the Indian government must be a bunch of complete idiots if they honestly think that terrorists or other bad people won't be capable of figuring it out....
Thus, in effect, RIM's choices are really:
Cave in, get sued by many of their business customers, and lose many more of their customers to ISPs with mail servers in other countries, then kick back and watch as people slowly dump their hardware for iPhones and Droids once they are no longer tied down to Blackberry's mail service. The government will then go after other companies like Google for the same concessions, but will either fail miserably or will drive users to less centralized services and then fail miserably. The end result is Epic FAIL for India's attempt to eavesdrop, but RIM loses big time.
Stop being an ISP in India, make small businesses support their own email without using RIM's servers (bigger ones already do, AFAIK), and provide non-business users with the means to migrate to another mail service like Gmail. Then the government has to go after tens of thousands of ISPs individually. Kick back and watch as non-business users slowly dump their hardware for iPhones and Droids once they are no longer tied down to Blackberry's mail service. Again, Epic FAIL for India's attempt to eavesdrop, and again RIM loses pretty badly, but not quite as badly.
Draw a line in the sand and refuse to cooperate. Then, MAYBE India will shut them down, but their highly wealthy customers will throw a massive fit and the government will back down.
I know which one I'd choose if I were in RIM's position. Standing up means risking a complete loss immediately with at least some possibility of continuing to do business ethically, whereas backing down is almost a guarantee of a nearly complete loss (at least of your business customers), but spread over a longer period. Thus, RIM really has little to lose by betting it all and telling India's government to get bent. Either way, caving in clearly isn't a viable option---not for RIM and not for the rest of the companies on the Internet. RIM made their bed through a fundamentally flawed mail delivery architecture. Now they have to lie in it.
Wrong. The user put the media in the machine with the intent of doing something. Even with commercial CD-ROMs, quite often, the media contains other things besides the installer. It might contain documentation, it might contain installers for other tools, and so on. And in that case, auto-launching the installer is the wrong thing.
And further, the disc is not always an install disc. Whether it's a USB stick, a movie DVD, an audio CD, or whatever, having Windows install some piece of software behind your back is undesirable. In this case, non-install discs are getting autorun installers added to them that infect people's systems. That's pretty clearly not something the user intended to do by inserting the media.
Short of requiring autorun files to be signed by Microsoft, with Microsoft providing appropriate background checks, code auditing, and a properly designed CRL system, autorun is an inherently insecure concept. Even with code signing, it is completely unnecessary and presents a juicy target for malware exploitation. For example, somebody's malware might use a code signed installer to install something else.
In short, it is a gaping hole by design that cannot feasibly be made secure.
... but rather the stipulation under law changing the royalty schema from artist to publisher.
Except that if the comment at the bottom of that blog is correct, that's not what has happened. In effect, they increased the artists' royalties by 20% and added an additional publisher royalty equal to 2/3rds of the newly increased author's royalty.
Previous royalty for the author: 0.5 CZK. New royalty 1.0 CZK. Author's part:.6 CZK. Publisher's part:.4 CZK.
But saying that they've increased the author's royalty by 20% and added a publisher royalty isn't as headline-grabbing as saying that they've reduced the percentage of the royalty that authors get.... Why does all the news have to be about twisting reality to create more shocking headlines? A lie of egregious omission is still a lie.
There should never have been a way to enable autorun in the first place. The very notion of automatically executing code or installers form a piece of media without the user explicitly taking any action is antithetical to proper security.
Slashdot Mirror
No, no, no. When you push the button, the sensei has to come out and kick you in the nuts.
And do they die en masse every few months? I'm still a bit skittish over the whole bad bump debacle....
Probably when Michael Dell said it about Apple.
Isn't it funny when people start suggesting that you take your own advice?
Aaack! Does that mean that soon I'll have to do all those things I said I would do when DNF shipped!?!
*runs away in terror*
Agreed that location is very important. You should also avoid placing a smoke detector right next to a bathroom door. When you shower, the steam can set it off. Move the detector a few feet farther away and the problem goes away.
That said, what you're saying about detector sensitivity is not entirely correct. As I understand it, most household smoke detectors effectively get more sensitive due to dust gathering in the smoke chamber. It takes less smoke to trigger an alarm because the dust in the chamber is contributing to a higher baseline level, which more than makes up for the decreased sensitivity of the actual sensors. Newer designs supposedly compensate for this, so I'd expect this to be less relevant in the coming years, but at least for the smoke detectors that are old enough that they ought to be replaced today, I don't think any of them did.
Taking the battery out of the smoke alarm is an option right after you burn the food, but leaving it out for a month isn't. If the alarm is that much of an annoyance, that means the smoke alarm is too old, and you should replace the smoke alarm.
Besides, this is not at all like a smoke alarm where the alarm might just be a nuisance (burnt popcorn, too many candles, steam from the bathroom, overcooked biscuits, etc.) and where the cause is understood (poor placement, stove fire, etc.). When alarms on an oil rig go off, you know you have a problem. The only questions you should ask are "How big?" and "What do I need to replace?".
There are no false positives when you're talking about critical safety systems on something that could cause such widespread damage in the event of a failure. Any problem is something that needs to be dealt with; if it's a bad sensor causing a false positive, the sensor needs to be replaced.
Indeed, one of the causes of the last disaster was that alarms had been going off for weeks and instead of fixing the underlying problem, they turned off the alarms. The alarms were not the problem. The alarms were indications that something was wrong. The problem was that A. things were not working, and B. people ignored the problems rather than taking corrective measures.
If we were talking about safety systems that, due to their complexity, cannot be made reliable---if constant false positives were inevitable (e.g. car alarms)---then yes, I would agree that the alarms were the problem. That said, I have no reason to believe that this is the case, and more to the point, if that is the case, then proper oil rig safety is impossible, which means that we should not be drilling off the coast, period.
When this law was written, looking up the patent likely meant somebody taking a horseback ride to Washington D.C. to the patent office and paying a patent clerk to locate the patent and bring it out for inspection. At the time, the law made perfect sense. However, technological progress has rendered the law unnecessary and absurd.
And this, friends, is a perfect example of why EVERY law should be required to have a sunset clause after which time it is abandoned if not explicitly renewed. The fact that all these archaic laws are still on the books is embarrassing. Important laws will, of course, be renewed. Unimportant laws won't. This would also effectively cap the number of laws that can exist at any given time, which would be a good thing.
Bonus points to the first person who rips off the song "You give love a bad name" for the chorus (You give hacking a bad name).
Because they can. And this is why tethering apps are the most popular jailbreak apps on iPhone according to several websites. Want to know why so many iPhone users jailbreak? Look no farther than AT&T.
AT&T will look for any opportunity to overcharge their customers---to squeeze a little more blood out of them. They are fundamentally harmful by any standard, whether you're talking about the Internet, phone, whatever, but they are such an entrenched monopoly that they are too big to take behind the barn and shoot.
Thanks, Reagan, for the most completely failed monopoly breakup in our nation's history.
Except that the studies have been leaning fairlly conclusively this direction for decades. We've known about the heart benefits since the 1970s, and recent studies continue to point even more strongly in this direction.
True, though, that it is a balancing act---binge drinking is linked to increased rates of certain benign breast diseases in women that can be precancerous, for example---but that seems to be true for pretty much everything.
I find that garbage collection actually reduces maintainability significantly. Instead of having well defined points where objects are disposed of (which you can find with a simple grep), you now have objects disappearing (or not disappearing) magically, seemingly at random, whenever any of a million variables gets changed. It's like the difference between counting the number of people on a train and counting the number of people in a city park. The more places people can get in or out, the more intractable the problem.
When GC fails to do the right thing (and it inevitably does if your program gets complex enough) and you end up with a colossal memory leak or an entire object subgraph suddenly disappearing because one piece of code inadvertently used a weak reference where it should have used a strong one, you now have a nightmarishly hard-to-find bug on your hands that makes maintaining manually memory-managed code seem positively simple by comparison.
I've maintained large projects with both GC and manually memory managed schemes. I'll never write a large piece of code in a garbage collected language again except by force. Garbage collection may take away the need to spend extra effort on managing memory in the simple cases, but it takes away control and ease of debugging in the complex cases. In the long run, all successful software becomes complex. Thus in terms of long-term maintenance, garbage collection will always eventually come back to bite you on the rear.
Turning over data in response to a subpoena is not the same thing as warrantless wiretaps, and turning over data in response to a subpoena from another country is not the same thing as turning it over in response to a subpoena from the country where ISP is. I would expect the latter. The former would be horrifying. If any arbitrary country could subpoena anybody's mail, then we would have some pretty serious problems.
Further, even if those particular companies have agreements with India's government, the near-total anonymity afforded by many of those services would make it very difficult for the government to determine much beyond what that one person knows. You can usually get that much from interrogation alone. If you're going to be spying on someone over a long period of time, it's usually because you're trying to find out who that person knows, and find out who the other players are. That's problematic if you're trying to get subpoenas against a dozen different ISPs in a dozen countries, only to come up dry because all the accounts were created under pseudonyms.
I'm not assuming that terrorists are highly efficient outfits, but I am assuming that they have computer people among their ranks. That's a very safe assumption, from everything I've read on the subject. And even if I'm wrong, you have to assume that they're not complete morons. If they are aware that their communication channel is compromised, they won't keep using it as if nothing has changed.... It's not like phone wiretaps. The bad guys have to assume that the government has the ability to tap everything, filter it, and identify threats. So as soon as the government gets the ability to tap it at all, the entire use of that channel becomes immediately worthless, ensuring its swift replacement with something more secure.
And even if the Indian government managed to get EVERY ISP in the entire world to cooperate, there's still stuff like Freenet that makes encrypted email seem like a toy.
In short, tapping electronic communications can only work against VERY clueless bad guys, and the government can't possibly be clueless enough not to know this, so you have to ask yourself what they're really trying to accomplish.
Okay, I'll bite. What do you think social and economic tensions are, if not an atmosphere of distrust?
Well, the original was half aluminum, anyway.... They were also pretty easy to take apart, if memory serves. Good times. Good times.
No, and no. If you are doing multithreaded programming, you can use reference counting. It's not at all hard to do explicit retain/release unless your program is crap by design. In many cases, doing so explicitly and with careful thought can greatly improve performance.
For example, not all garbage collectors do a great job when you have complex circular data structures. However, if you know that your complex structure is principally a tree with some links to higher nodes, you can simply not use a reference count, but rather a reverse reference list to point to the nodes that link backwards, then unlink the back-references as part of your destructor when the reference count goes to zero. Yes, you can potentially use weak references for the same thing, but that assumes that you don't need to change some other aspect of the data structure when the uplinked node becomes unavailable, e.g. caching the last value of some field in the higher node.
And, of course, if you know that the entire data structure, regardless of complexity, comes and goes away as soon as there are no references to the root node remaining, then you can make things much, much simpler with explicit memory management. You use a reference-counted object that points to the root node instead, and in its destructor, you recursively nuke the actual data structure with abandon. Then, there's no reason to worry about whether a particular reference should be strong or weak.
Likewise, many garbage collectors aren't good at quickly disposing of objects that are only created momentarily, used, then disposed of within a single function. For those objects, manual allocation is always a better choice in terms of performance because you can be absolutely certain that they don't linger any longer than necessary. If those data objects are large, this can have a significant impact on performance versus GC.
And without regard to how good or bad the GC system is, you can always get a big performance win by manually managing everything. As soon as you have a thread traversing an object graph to check reachability, you've already lost the performance battle at a very fundamental level. You're either wasting CPU cycles, wasting memory, or both to determine whether an object can be freed---information that the programmer should be able to much more easily and quickly determine due to having a better understanding of which objects can realistically reference it.
Sure, a naive multithreaded programmer who doesn't use any reference counters and tries to free things while another thread is still using them can break things, but that's also true of the naive programmer who doesn't use reader-writer locks around data structures to prevent somebody from reading them while another thread is taking nodes out of a linked data structure, etc. Your example could just as easily have occurred with somebody assigning a value to NULL outside the lock. Indeed, your example is actually trivial to detect with proper tests (particularly when compared with arbitrary data structure mutations, hence the reason that you should religiously confine code that modifies data structures to a handful of functions that do nothing but modify the data structure in a particular way). You can simply add code in the destructor (C++ example):
Has it ever occurred to you that the very environment of fear and distrust is what breeds terrorism in the first place and that one of the reasons that the U.S. has had few terrorist attacks is that the vast majority of the public as a whole doesn't feel like the government is out to get them? We get to know our neighbors, and for the most part, if a neighbor were hatching a terrorist plot, usually somebody would notice. We do that because we know that the only thing standing between us and anarchy or tyranny is ourselves. Historically, the closer any country has come to being a police state, beyond a certain point, the more problems they have had. It's a vicious cycle, and the harder you try to clamp down, the more violent the dissent, until it becomes uncontrollable. That's basic psychology, really.
It would take any competent user all of five minutes to get around this. All you have to do is use an IMAP mail service other than RIM's. The people who care about using push email are not the terrorists. They are the businesses that employ your citizens. The terrorists couldn't give a rat's ass about push email. They use it because it is there. The second they get wind that RIM is going to make all their email available, they will migrate their data to Gmail, delete all their email, and close their accounts. By the time RIM actually capitulates, any information the Indian government could possibly hope to obtain will have long since been destroyed. And when the Indian government goes after Gmail, they'll move to Yahoo Mail. And when they go after Yahoo Mail, they'll move to something else. It's so easy to change ISPs that it is utterly naive to think that what you're talking about will have ANY real impact on terrorism.
You can't stop terrorism by screwing over everyone else. That just makes your citizens angry and resentful of the government. And after long enough, those angry, resentful citizens decide to take up arms. Then, a terrorist cell is born.
The only thing certain when it comes to dealing with businesses and government is that in the end, we lose.
Except that unless you limit it to Indian MobileMe users, no matter how you threaten them, Apple cannot feasibly provide the same service to the Indian government. The only reason RIM can is that all the email data going to your phone is stored by RIM's servers. In effect, RIM is acting as an ISP operating in India. All a user has to do is NOT use an Indian ISP and NOT use any other ISP that has agreed to their demands and that user will have encryption without government eavesdropping. It's such a low technical hurdle that the Indian government must be a bunch of complete idiots if they honestly think that terrorists or other bad people won't be capable of figuring it out....
Thus, in effect, RIM's choices are really:
I know which one I'd choose if I were in RIM's position. Standing up means risking a complete loss immediately with at least some possibility of continuing to do business ethically, whereas backing down is almost a guarantee of a nearly complete loss (at least of your business customers), but spread over a longer period. Thus, RIM really has little to lose by betting it all and telling India's government to get bent. Either way, caving in clearly isn't a viable option---not for RIM and not for the rest of the companies on the Internet. RIM made their bed through a fundamentally flawed mail delivery architecture. Now they have to lie in it.
Wrong. The user put the media in the machine with the intent of doing something. Even with commercial CD-ROMs, quite often, the media contains other things besides the installer. It might contain documentation, it might contain installers for other tools, and so on. And in that case, auto-launching the installer is the wrong thing.
And further, the disc is not always an install disc. Whether it's a USB stick, a movie DVD, an audio CD, or whatever, having Windows install some piece of software behind your back is undesirable. In this case, non-install discs are getting autorun installers added to them that infect people's systems. That's pretty clearly not something the user intended to do by inserting the media.
Short of requiring autorun files to be signed by Microsoft, with Microsoft providing appropriate background checks, code auditing, and a properly designed CRL system, autorun is an inherently insecure concept. Even with code signing, it is completely unnecessary and presents a juicy target for malware exploitation. For example, somebody's malware might use a code signed installer to install something else.
In short, it is a gaping hole by design that cannot feasibly be made secure.
Except that if the comment at the bottom of that blog is correct, that's not what has happened. In effect, they increased the artists' royalties by 20% and added an additional publisher royalty equal to 2/3rds of the newly increased author's royalty.
Previous royalty for the author: 0.5 CZK. New royalty 1.0 CZK. Author's part: .6 CZK. Publisher's part: .4 CZK.
But saying that they've increased the author's royalty by 20% and added a publisher royalty isn't as headline-grabbing as saying that they've reduced the percentage of the royalty that authors get.... Why does all the news have to be about twisting reality to create more shocking headlines? A lie of egregious omission is still a lie.
I see no apparent difference between those two statements in modern English usage.
If they send you a C&D, you should at least have standing to sue for harassment.
There should never have been a way to enable autorun in the first place. The very notion of automatically executing code or installers form a piece of media without the user explicitly taking any action is antithetical to proper security.
http://www.youtube.com/watch?v=wIDfcspoInw
Indeed. We've always been at war with Al Qaeda
(Just in case they fix it, it's a Google News search that lists an article about the fighting against Al Qaeda dated January 4, 1600.)