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. :)

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.

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.

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.

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.

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 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.

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 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.

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.