The problem with the gridlock is that it is caused by the corporate interests who have lobbied their way into virtual ownership of the elected officials. Until the problem of lobbying is addressed, the US political system will continue along its merry, gridlocked way. If you want to know who's really in power, follow the money.
Nah. I'm just cognizant that cutting the pipe can put businesses out of existence is all. I don't think it helps anybody to put a business out of business. Cutting the pipe should be, IMO, the last resort to the business not getting its ducks in a row.
Obviously, the owner of compromised systems is responsible for those systems. Period, full stop. In my line of work, I'm often the hapless slouch who has to find the root kits and whatnot, cleanse the system, determine (if possible) the vector of entry, etc. Usually, the system was owned by some undetermined means and all I can do is just cleanse and lock down as much as possible. Clients, however, being the meat sacks they are, always manage to encounter PEBKAC events.
I don't think we're actually all that far apart in our line of thinking, Marc. I just am reluctant to pull the pin on their network connection until such time as the company has proven itself either unable or unwilling to address its issues. This approach is fair, I think, when dealing with individual residential and corporate connections. When you threaten upstream disconnection at the ISP level to downstream ISPs, then the collateral damage is too great for such shenanigans. Putting hundreds of companies out of business simply because they chose an ISP who allows botnet traffic to pass its borders would penalize those who are not a part of the problem. That, IMO, is unethical.
So you don't mind pulling the plug on a residential connection, but pulling one on a business connection is the line? The business should have more care in their networks than an average user. So they should be pulled much less than grandma. So I wouldn't think it that huge of an issue. Most are residential connections, aren't they?
Oh, I have just as much of an issue with pulling the plug on a residential connection because of the possibility of negatively impacting business. For example, I do the vast majority of my work from home on a non-commercial connection. Were my ISP to simply pull the plug on my connection because one of the systems began, say, sending out thousands of spam per hour, it would create a huge problem for me. (Finding/cleaning the system not itself being The Problem.)
For any long-term success, we need to find ways to take down the botnets and patch the compromised systems. ISPs disconnecting problem systems/networks does nothing to deal with the malware that creates the zombies for the botnets, nor does it take out the command and control centre that inevitably tells the zombies to attack a particular target. To me, that's the more pressing issue. As long as the botnet lives, more zombies will be recruited.
Yep. Canada has some weird rules. For example, if you have servers in a rack and the feds want to do a search and seizure a la US style, not gonna happen. If the servers are essential for the running of your business, the most the feds can do is to copy all the relevant data. They can't actually seize the servers lest it causes your business damage.
It's actually a pretty good law in that it respects the ideal of innocent until proven guilty beyond reasonable doubt. In other countries, they can just take your crap and if you go out of business because of it - even if you're totally innocent - well, that's just tough luck, innit?
This is getting to become a circular argument, and I'm in no mood to argue. I cannot be more clear: One cannot simply 'pull the plug' on a network that provides service without opening up a complex can of legal worms. There's absolutely _zero_ doubt that DDoS activity is malicious by nature and intent by the botnet operator. There's absolutely _zero_ doubt that pulling the plug would help mitigate the damage to systems on the receiving end of attacks from such compromised systems/network. The fundamental problem, however, is that one does not merrily obstruct a business's capacity to DO business without incurring legal ramifications (dependent upon the jurisdiction in which the service is being hosted/operated).
It is what it is, Mark. It's a simple problem with a veritable rat's nest of legal implications to solve.
It's trivial to cut off service, yes, but if an ISP and upstream providers to cut off all offending networks from access, the internet would pretty much go silent.
I think that's exactly why it's necessary. Most ISPs take very little notice of an obviously infected customer's machine, unless of course it's trying to pour its spam through their SMTP server. Then they immediately get their panties in a twist and pull your plug until you clean up your machine.
The difference here of course being who is the victim. You or me? Not gonna bother. US? Red Alert Ban Hammer Time!
So, your upstream pulling (or threatening to pull) your plug is precisely what's needed to motivate those ISPs. Some are lazy. Most are just too cheap to invest in fixing the problem and would rather bank the dollars than spend them to fix "someone else's problem". Make it their problem. Light a fire under their seat and watch them redirect a processes they already have in place, to fix the problem.
I think we're all in agreement that something needs to be done, but the ethics of disrupting a business's capacity for staying in business is shaky ground. In all of this, I'm certainly not defending the problem, merely discussing the complications associated with cleaning up the problem. In my case, I'm very proactive about making sure the SOHO networks and servers (including multi-tenant web servers) stay clean and patched such that they don't create problems. It's a never-ending story, too.
A typical problem scenario for a hosting provider, for example, is somebody's CMS gets hacked for whatever reason and the server becomes a malware distributor or starts sending out truckloads of spam. It's mindlessly trivial to cut off that customer's account until such time as they get their house in order. Do that in certain jurisdictions, however, and you risk a law suit in case the customer can prove that their capacity to operate their business was damaged by YOUR actions.
It just IS NOT as simple as you and AK Mark would like to see it. One doesn't just walk into Mordor . Oops. Wrong metaphor.:)
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional.
So the Botnet owner isn't doing anything malicious when they perform a DDoS? Again, I think your logic is contrived and quite stupid, trying to defend negligent users who are financing attacks.
I said that the DDoS is malicious activity, and the connection is linked to that, and thus can be shut down. You are disagreeing. That makes you dumb or a liar. Which is it?
It amazes me how many people defend compromised computers and those performing DDoSs.
It occurs to me that reading comprehension may not be your strong suit. I have yet to see a single comment here that defends compromised computers or DDoS. Please, try not to pretend to be so dense. The issue of malicious intent has nothing whatsoever to do with the botnet operator and everything to do with the owner of the compromised computer(s)/network. You seem to be confusing the legality and morality of the perp with that of an ignorant owner/operator. Yes, the DDoS is malicious activity. Nobody that I have seen is arguing that point. Being on the wrong end of a DDoS is damaging and disruptive. That said, there ARE ramifications of simply turning off the tap that are not so simply dealt with as you seem to wish were the case. Were it so easy and legally simple, it already would not be an issue, IMO.
Because crime is common, it would be cheaper and easier to abolish the police and stop trying to fix things.
Nope, that's fucked up logic I'll never buy into.
That's not a logical rejoinder to my comment. I did not state that nobody should try to fix things, I merely stated that cutting off traffic is unlikely to happen for a number of reasons. The cutting off traffic only masks the symptoms, it does not deal with the cause of the DDoS. A holistic approach is required, not an allopathic one, IMO.
Most contracts will allow termination of service for malicious activity.
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional. In certain jurisdictions, Canada comes to mind, it is illegal for processes to make it impossible for a company to do business. So, if an online presence would suffer financial damage or possibly go out of business through having its service cut off, the ISP has no legal ground by which to cut off service.
Besides, as has been described elsewhere, the amount of traffic generated by any individual botnet member is generally limited to the degree that only deep packet inspection will discover it. That opens up a whole different can of legal worms with regard to privacy. If a carrier is precisely that under the letter of law, deep packet inspection and preemptive disruption of service contradict the rules of Common Carriage. A telecommunications carrier cannot follow common carrier regulations while censoring traffic.
ISPs can cut off offenders trivially. Upstream providers can cut off offending ISPs trivially.
The problem here is that compromised systems are pretty much everywhere. I take care of a number of SOHO networks and have had to clean up mess after mess over the years. Drive-by exploits, phishing, worms, etc. are all vectors of infiltrating a network. DDoS and spam are widespread. It's trivial to cut off service, yes, but if an ISP and upstream providers to cut off all offending networks from access, the internet would pretty much go silent.
Short answer: It ain't gonna happen. Local administrators have the task of keeping their own backyard clean. Beyond that, good luck educating the average home user not to click on that supposed love letter from an admirer, not install that free software from some random web site they found on Google, not give out their password to tech support contacting them via e-mail, etc., etc.
In addition to your excellent points, SpaceX made history by being the first private spacecraft to berth with the ISS. NASA and SpaceX have a very complementary collaboration schedule in place. The cost-competitiveness of SpaceX's programs will make for a long-term paradigm shift in space exploration and commercial ventures for the private sector.
If the point of open office or cubicle is to promote sharing and collaboration, he just killed that idea right there.
Having to block out sights and sounds is not a good compromise, it's a symptom of a horribly designed workplace.
Ever tried to speak with someone with earplugs and listening to music?
Sharing and collaboration is easily accomplished by poking one's head around the corner and making eye contact. It shouldn't be necessary for a person to be subjected to incessant background noise/talk for there to be the possibility of collaboration. One's presence is enough. To that end, I mostly telework now, making sure that my Skype is always on for those who require my immediate attention. I'm a huge fan of video conferencing, too, which goes a long way to ensuring that things aren't lost in translation. Interestingly, I find others very quick to shoot down even turning on video during a call. I find that often seems to lead to misunderstandings and increased difficulty during communication.
I'm Canadian, but I've lived abroad so long that I have adopted various idiosyncrasies from other languages/cultures.
Sure you don't mean, "I have foreign nationality, but I've been a resident of Japan for so long that..."?
I surely mean that my English is peppered with American slang, Britishisms, Aussie snarks and all manner of other borrowed '-isms' from living and travelling abroad. To varying degrees, I speak English, Japanese, German and French. My sense of language is no longer defined by Canadian English. I spent some years as a technical rewriter at Fujitsu, which used American English as its baseline for grammar, spelling and punctuation. It damaged my native Canadian English sensibilities. When you combine that with my tendency to include loan words and phrases from various other dialects and languages, it leads to confusion in language identity.
Personally, I find it fascinating. We really do mirror our life experiences.
The combination of globalization and remote working is changing the definition of the corporate culture. I've lived in Japan since 1991 and have clients not only all over Japan, but in Europe and North America. This has given rise to a shift in my cultural outlook from the perspective as a service provider. I think our cultural alliances are now more defined by where and with whom we hang out online. Rather than being more identified with nationality, I think we're more defined by the groups and activities with which we engage. I'm Canadian, but I've lived abroad so long that I have adopted various idiosyncrasies from other languages/cultures.
I can't say I feel very Canadian anymore. I do, however, feel very much in allegiance with software localization and server administration.
I even find cubicles to be a drag. During the 7 years I spent surrounded by 3 partitions, I spent the vast majority of the time in that chair wearing headphones to block out as much of the environment as possible.
Especially when they immediately make you change it.
That should be after clicking on/entering a link in the browser that takes you to a password reset prompt. There is no excuse to send a password over e-mail, encrypted or otherwise.
There is a lot of angst here, but the reality is that putting a CMS online is not the end of the task, it's the beginning. If you want to have a public-facing web site, that means keeping it up to date so that providers have no qualms about upgrading. In many cases, the issue isn't the client, per se, but the requirements of the client site that slow down upgrading. As an example, Zend still hasn't managed to add PHP 5.5 support to their Guard product, so anybody who has clients using Zend in their sites will be stuck on 5.4.x till, well, whenever Zend gets a move on.
In any case, running a provider is a matter of pushing clients to keep up with server changes in a timely yet forgiving fashion. There's no reason that upgrading from PHP 5.4.35 to 5.4.36 should break ANYthing, so there's no excuse for a provider to not keep up with patch releases. Moving from 5.4 to 5.5, for example, will introduce potential incompatibilities, so providers need to give 30-60 days advanced notice to ensure client sites can be checked and upgraded as required. As long as plugins and CMS releases have been updated as they come along, the reality is that most upgrades are pretty painless. It's the big-jump scenario, 5.2-5.5 kind of upgrade that will be a nightmare. Those should never happen.
A good provider will retain legacy servers for those who still toddle along with FrontPage extensions and the like, but only till such time as the base services, e.g., Apache 2.2.x and PHP 5.4.x reach end of life. At that point, a provider needs to come to the realization that putting an entire server at risk at the behest of a few clients who are slow with the updates is bad business. PHP might have its downside, but keeping in tight lockstep with upgrades keeps things (usually/hopefully/OMG-I-pray) one step ahead of the kiddies and blackhats.
The point is that mission planning should have clear focus one way or the other.
The mission was designed to last 90 days. Through the wonder of excellent engineering and fortuitous circumstances during the mission, it has lasted a decade. There is no reason to abandon the mission now while they're still managing to get good science out of the vehicle and its instruments. When such time comes that the cost is greater than the justification to extend the mission, it shall be retired as so many other missions have in the past.
Or, the software is not optimized for "space flight use" but, rather, for "consumer camera memory card", which has a different read/write/erase pattern and error tolerance.
The flash memory controller was created in-house. Back in 2004, Spirit had well-documented memory issues that were traced to file system logic that didn't properly clear deleted files during a reset. Eventually, storage systems were overrun, which forced NASA to basically reformat the storage system and start afresh after reprogramming the controller firmware.
Now pretty much all of their stuff is made by Foxconn, who are well-known to make mediocre hardware.
My mid-2007 MacBook2,1 13" went back to Apple for repairs under APP no fewer than 5 times over the 3 years that it was covered. Amazingly, the thing has been completely reliable since APP expired in 2010. Go figure, but glad for that.
As I understand it, ROHS compliment solder introduces stress cracks (thus a broken circuit) from the constant thermal expansion and contraction from everyday use. With laptops, the delta changes from heating and cooling are huge.
This is one of the reasons that I generally don't power off any of my equipment. Pretty much the only time I ever see hardware failures is when trying to bring a system back online from a complete shutdown. Sleeping a laptop still results in cooling, but not quite as much as a full power-down.
Yes, I'm fully cognizant of the nutjob whale lovers (tried it at my MiL's and nearly vomited) and the danger of fugu (tried it and managed not to die). The joke failed on the "if it takes effort" part. It would have been funny were there any effort being made to promote it; in the absence of any effort, there's also an absence of requisite irony.
Slashdot Mirror
The problem with the gridlock is that it is caused by the corporate interests who have lobbied their way into virtual ownership of the elected officials. Until the problem of lobbying is addressed, the US political system will continue along its merry, gridlocked way. If you want to know who's really in power, follow the money.
Nah. I'm just cognizant that cutting the pipe can put businesses out of existence is all. I don't think it helps anybody to put a business out of business. Cutting the pipe should be, IMO, the last resort to the business not getting its ducks in a row.
Obviously, the owner of compromised systems is responsible for those systems. Period, full stop. In my line of work, I'm often the hapless slouch who has to find the root kits and whatnot, cleanse the system, determine (if possible) the vector of entry, etc. Usually, the system was owned by some undetermined means and all I can do is just cleanse and lock down as much as possible. Clients, however, being the meat sacks they are, always manage to encounter PEBKAC events.
I don't think we're actually all that far apart in our line of thinking, Marc. I just am reluctant to pull the pin on their network connection until such time as the company has proven itself either unable or unwilling to address its issues. This approach is fair, I think, when dealing with individual residential and corporate connections. When you threaten upstream disconnection at the ISP level to downstream ISPs, then the collateral damage is too great for such shenanigans. Putting hundreds of companies out of business simply because they chose an ISP who allows botnet traffic to pass its borders would penalize those who are not a part of the problem. That, IMO, is unethical.
Nope. LOL
P.S. - I noticed that I spelled your name 'Mark' before. Apologies for that!
So you don't mind pulling the plug on a residential connection, but pulling one on a business connection is the line? The business should have more care in their networks than an average user. So they should be pulled much less than grandma. So I wouldn't think it that huge of an issue. Most are residential connections, aren't they?
Oh, I have just as much of an issue with pulling the plug on a residential connection because of the possibility of negatively impacting business. For example, I do the vast majority of my work from home on a non-commercial connection. Were my ISP to simply pull the plug on my connection because one of the systems began, say, sending out thousands of spam per hour, it would create a huge problem for me. (Finding/cleaning the system not itself being The Problem.)
For any long-term success, we need to find ways to take down the botnets and patch the compromised systems. ISPs disconnecting problem systems/networks does nothing to deal with the malware that creates the zombies for the botnets, nor does it take out the command and control centre that inevitably tells the zombies to attack a particular target. To me, that's the more pressing issue. As long as the botnet lives, more zombies will be recruited.
Yep. Canada has some weird rules. For example, if you have servers in a rack and the feds want to do a search and seizure a la US style, not gonna happen. If the servers are essential for the running of your business, the most the feds can do is to copy all the relevant data. They can't actually seize the servers lest it causes your business damage.
It's actually a pretty good law in that it respects the ideal of innocent until proven guilty beyond reasonable doubt. In other countries, they can just take your crap and if you go out of business because of it - even if you're totally innocent - well, that's just tough luck, innit?
This is getting to become a circular argument, and I'm in no mood to argue. I cannot be more clear: One cannot simply 'pull the plug' on a network that provides service without opening up a complex can of legal worms. There's absolutely _zero_ doubt that DDoS activity is malicious by nature and intent by the botnet operator. There's absolutely _zero_ doubt that pulling the plug would help mitigate the damage to systems on the receiving end of attacks from such compromised systems/network. The fundamental problem, however, is that one does not merrily obstruct a business's capacity to DO business without incurring legal ramifications (dependent upon the jurisdiction in which the service is being hosted/operated).
It is what it is, Mark. It's a simple problem with a veritable rat's nest of legal implications to solve.
Happy New Year to you, sire. :)
I think that's exactly why it's necessary. Most ISPs take very little notice of an obviously infected customer's machine, unless of course it's trying to pour its spam through their SMTP server. Then they immediately get their panties in a twist and pull your plug until you clean up your machine.
The difference here of course being who is the victim. You or me? Not gonna bother. US? Red Alert Ban Hammer Time!
So, your upstream pulling (or threatening to pull) your plug is precisely what's needed to motivate those ISPs. Some are lazy. Most are just too cheap to invest in fixing the problem and would rather bank the dollars than spend them to fix "someone else's problem". Make it their problem. Light a fire under their seat and watch them redirect a processes they already have in place, to fix the problem.
I think we're all in agreement that something needs to be done, but the ethics of disrupting a business's capacity for staying in business is shaky ground. In all of this, I'm certainly not defending the problem, merely discussing the complications associated with cleaning up the problem. In my case, I'm very proactive about making sure the SOHO networks and servers (including multi-tenant web servers) stay clean and patched such that they don't create problems. It's a never-ending story, too.
A typical problem scenario for a hosting provider, for example, is somebody's CMS gets hacked for whatever reason and the server becomes a malware distributor or starts sending out truckloads of spam. It's mindlessly trivial to cut off that customer's account until such time as they get their house in order. Do that in certain jurisdictions, however, and you risk a law suit in case the customer can prove that their capacity to operate their business was damaged by YOUR actions.
It just IS NOT as simple as you and AK Mark would like to see it. One doesn't just walk into Mordor . Oops. Wrong metaphor. :)
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional.
So the Botnet owner isn't doing anything malicious when they perform a DDoS? Again, I think your logic is contrived and quite stupid, trying to defend negligent users who are financing attacks.
I said that the DDoS is malicious activity, and the connection is linked to that, and thus can be shut down. You are disagreeing. That makes you dumb or a liar. Which is it?
It amazes me how many people defend compromised computers and those performing DDoSs.
It occurs to me that reading comprehension may not be your strong suit. I have yet to see a single comment here that defends compromised computers or DDoS. Please, try not to pretend to be so dense. The issue of malicious intent has nothing whatsoever to do with the botnet operator and everything to do with the owner of the compromised computer(s)/network. You seem to be confusing the legality and morality of the perp with that of an ignorant owner/operator. Yes, the DDoS is malicious activity. Nobody that I have seen is arguing that point. Being on the wrong end of a DDoS is damaging and disruptive. That said, there ARE ramifications of simply turning off the tap that are not so simply dealt with as you seem to wish were the case. Were it so easy and legally simple, it already would not be an issue, IMO.
Because crime is common, it would be cheaper and easier to abolish the police and stop trying to fix things.
Nope, that's fucked up logic I'll never buy into.
That's not a logical rejoinder to my comment. I did not state that nobody should try to fix things, I merely stated that cutting off traffic is unlikely to happen for a number of reasons. The cutting off traffic only masks the symptoms, it does not deal with the cause of the DDoS. A holistic approach is required, not an allopathic one, IMO.
Most contracts will allow termination of service for malicious activity.
A compromised system that is operating without the knowledge of its owner does not constitute malicious activity. Malicious activity, by its very definition, is intentional. In certain jurisdictions, Canada comes to mind, it is illegal for processes to make it impossible for a company to do business. So, if an online presence would suffer financial damage or possibly go out of business through having its service cut off, the ISP has no legal ground by which to cut off service.
Besides, as has been described elsewhere, the amount of traffic generated by any individual botnet member is generally limited to the degree that only deep packet inspection will discover it. That opens up a whole different can of legal worms with regard to privacy. If a carrier is precisely that under the letter of law, deep packet inspection and preemptive disruption of service contradict the rules of Common Carriage. A telecommunications carrier cannot follow common carrier regulations while censoring traffic.
ISPs can cut off offenders trivially. Upstream providers can cut off offending ISPs trivially.
The problem here is that compromised systems are pretty much everywhere. I take care of a number of SOHO networks and have had to clean up mess after mess over the years. Drive-by exploits, phishing, worms, etc. are all vectors of infiltrating a network. DDoS and spam are widespread. It's trivial to cut off service, yes, but if an ISP and upstream providers to cut off all offending networks from access, the internet would pretty much go silent.
Short answer: It ain't gonna happen. Local administrators have the task of keeping their own backyard clean. Beyond that, good luck educating the average home user not to click on that supposed love letter from an admirer, not install that free software from some random web site they found on Google, not give out their password to tech support contacting them via e-mail, etc., etc.
In addition to your excellent points, SpaceX made history by being the first private spacecraft to berth with the ISS. NASA and SpaceX have a very complementary collaboration schedule in place. The cost-competitiveness of SpaceX's programs will make for a long-term paradigm shift in space exploration and commercial ventures for the private sector.
If the point of open office or cubicle is to promote sharing and collaboration, he just killed that idea right there.
Having to block out sights and sounds is not a good compromise, it's a symptom of a horribly designed workplace.
Ever tried to speak with someone with earplugs and listening to music?
Sharing and collaboration is easily accomplished by poking one's head around the corner and making eye contact. It shouldn't be necessary for a person to be subjected to incessant background noise/talk for there to be the possibility of collaboration. One's presence is enough. To that end, I mostly telework now, making sure that my Skype is always on for those who require my immediate attention. I'm a huge fan of video conferencing, too, which goes a long way to ensuring that things aren't lost in translation. Interestingly, I find others very quick to shoot down even turning on video during a call. I find that often seems to lead to misunderstandings and increased difficulty during communication.
Sure you don't mean, "I have foreign nationality, but I've been a resident of Japan for so long that..."?
I surely mean that my English is peppered with American slang, Britishisms, Aussie snarks and all manner of other borrowed '-isms' from living and travelling abroad. To varying degrees, I speak English, Japanese, German and French. My sense of language is no longer defined by Canadian English. I spent some years as a technical rewriter at Fujitsu, which used American English as its baseline for grammar, spelling and punctuation. It damaged my native Canadian English sensibilities. When you combine that with my tendency to include loan words and phrases from various other dialects and languages, it leads to confusion in language identity.
Personally, I find it fascinating. We really do mirror our life experiences.
The combination of globalization and remote working is changing the definition of the corporate culture. I've lived in Japan since 1991 and have clients not only all over Japan, but in Europe and North America. This has given rise to a shift in my cultural outlook from the perspective as a service provider. I think our cultural alliances are now more defined by where and with whom we hang out online. Rather than being more identified with nationality, I think we're more defined by the groups and activities with which we engage. I'm Canadian, but I've lived abroad so long that I have adopted various idiosyncrasies from other languages/cultures.
I can't say I feel very Canadian anymore. I do, however, feel very much in allegiance with software localization and server administration.
I even find cubicles to be a drag. During the 7 years I spent surrounded by 3 partitions, I spent the vast majority of the time in that chair wearing headphones to block out as much of the environment as possible.
Especially when they immediately make you change it.
That should be after clicking on/entering a link in the browser that takes you to a password reset prompt. There is no excuse to send a password over e-mail, encrypted or otherwise.
Really. Well. Stated! *wild applause*
There is a lot of angst here, but the reality is that putting a CMS online is not the end of the task, it's the beginning. If you want to have a public-facing web site, that means keeping it up to date so that providers have no qualms about upgrading. In many cases, the issue isn't the client, per se, but the requirements of the client site that slow down upgrading. As an example, Zend still hasn't managed to add PHP 5.5 support to their Guard product, so anybody who has clients using Zend in their sites will be stuck on 5.4.x till, well, whenever Zend gets a move on.
In any case, running a provider is a matter of pushing clients to keep up with server changes in a timely yet forgiving fashion. There's no reason that upgrading from PHP 5.4.35 to 5.4.36 should break ANYthing, so there's no excuse for a provider to not keep up with patch releases. Moving from 5.4 to 5.5, for example, will introduce potential incompatibilities, so providers need to give 30-60 days advanced notice to ensure client sites can be checked and upgraded as required. As long as plugins and CMS releases have been updated as they come along, the reality is that most upgrades are pretty painless. It's the big-jump scenario, 5.2-5.5 kind of upgrade that will be a nightmare. Those should never happen.
A good provider will retain legacy servers for those who still toddle along with FrontPage extensions and the like, but only till such time as the base services, e.g., Apache 2.2.x and PHP 5.4.x reach end of life. At that point, a provider needs to come to the realization that putting an entire server at risk at the behest of a few clients who are slow with the updates is bad business. PHP might have its downside, but keeping in tight lockstep with upgrades keeps things (usually/hopefully/OMG-I-pray) one step ahead of the kiddies and blackhats.
The point is that mission planning should have clear focus one way or the other.
The mission was designed to last 90 days. Through the wonder of excellent engineering and fortuitous circumstances during the mission, it has lasted a decade. There is no reason to abandon the mission now while they're still managing to get good science out of the vehicle and its instruments. When such time comes that the cost is greater than the justification to extend the mission, it shall be retired as so many other missions have in the past.
Or, the software is not optimized for "space flight use" but, rather, for "consumer camera memory card", which has a different read/write/erase pattern and error tolerance.
The flash memory controller was created in-house. Back in 2004, Spirit had well-documented memory issues that were traced to file system logic that didn't properly clear deleted files during a reset. Eventually, storage systems were overrun, which forced NASA to basically reformat the storage system and start afresh after reprogramming the controller firmware.
Now pretty much all of their stuff is made by Foxconn, who are well-known to make mediocre hardware.
My mid-2007 MacBook2,1 13" went back to Apple for repairs under APP no fewer than 5 times over the 3 years that it was covered. Amazingly, the thing has been completely reliable since APP expired in 2010. Go figure, but glad for that.
As I understand it, ROHS compliment solder introduces stress cracks (thus a broken circuit) from the constant thermal expansion and contraction from everyday use. With laptops, the delta changes from heating and cooling are huge.
This is one of the reasons that I generally don't power off any of my equipment. Pretty much the only time I ever see hardware failures is when trying to bring a system back online from a complete shutdown. Sleeping a laptop still results in cooling, but not quite as much as a full power-down.
Yes, I'm fully cognizant of the nutjob whale lovers (tried it at my MiL's and nearly vomited) and the danger of fugu (tried it and managed not to die). The joke failed on the "if it takes effort" part. It would have been funny were there any effort being made to promote it; in the absence of any effort, there's also an absence of requisite irony.