Holy crap, please mod parent up.

I've seen some distasteful comments, but that's just incredibly fucked up. Someone with points, please mod parent down.

He cares more about the product being right than other peoples' opinion of him.

Sometimes the truth hurts.

Nope. Linus has been Linus his whole life. This "story" isn't anything new. Oddly enough, Linux keeps marching onward, with plenty of contributors who are both volunteers and paid by various corporations to contribute work.

Again, the truth hurts. Projects like these don't tolerate stupidity well, especially given the fact that it's a community effort and there has to be a lot of lack of testing and communication on the part of the responsible party when something breaks like this. The price to be paid is twofold: (1) very public expressions of the harm caused by such issues, and (2) potential relief from duties related to the issue at hand, whether temporary or permanent in nature.

Step right up if you can do it better or know others who can. It takes strong leadership founded on the idea that others follow you primarily for you technical ability, and secondarily for your "soft skills" to manage a technical project of this scale. Sometimes people have problems replacing their famous bosses because while the old boss may have been widely regarded as an asshole, he was an effective asshole, and numbers (whether measured in uptime, lack of showstopping functional bugs, level of attention to security issues, or profit per quarter) don't lie.

All things considered, I saw far worse than this in my prior military service (Navy submarine force, ET-COM) in cases where somebody did something stupid that resulted in a systems failure, and oddly enough some aspects of this whole deal remind me a bit of organizational units in the services that pride themselves on putting job performance and technical ability first. Those who get butthurt about being dressed down are free to find something else to do with their time.

The type of DDoS discussed in TFS/TFA isn't TCP-based. It's UDP-based, is referred to a DNS amplification attack, and abuses DNS servers that permit public recursion to accomplish its goals. There is no handshake involved, as UDP is a connectionless protocol.

Speaking as someone who's been writing software since 1988, please enlighten us with more information on your background as a programmer. I strongly suspect the the GP was right in positing that you simply don't have the faintest idea what you're talking about.

I'm going to break the rules and feed a troll here by replying with a very simple sentiment: Go fuck yourself, asshole. Some things aren't fit to joke about. Also, next time you decide to try to be funny, at least get it straight: the region is known as the Mid-Atlantic. Have a nice day, prick.

Speaking as someone who deals with Cisco gear on nearly a daily basis, I fully agree with the premise of people needing to understand the difference between Cisco gear and alternatives designed for smaller environments. That said, most of the issues with Linksys products in recent years have been attributable to Cisco neglecting the hell out of Linksys branded product lines, and simply using the resulting failures to attempt to sell Cisco branded gear. It's been truly shameful, and I'd love to see it come to a stop.

Linksys produced some decent gear prior to the acquisition. After Cisco bought the company, the default answer for any sort of serious trouble with SOHO gear became "oh, I see you're referring to our Linksys brand; if you're serious about small office or branch office communications, you need to upgrade to our HOLY SHIT THAT'S EXPENSIVE Cisco brand gear instead." This applied nearly universally to cases where a prior generation piece of Linksys gear had performed quite well in the same role. Here's to hoping the brand can get back to its roots instead of serving as a loss leader for more expensive gear.

Attempting to justify the continued existence of unions by pointing to past efforts that resulted in the creation of an entirely separate (and useful) entity is a logical fallacy. Prior good work alone doesn't support something existed in perpetuity, unless you're also of the opinion that going to work for a single day should result in continued pay for a year whether you show up or not. You may well have other justifications to present, but this one doesn't work. No pun intended.

While I strongly advocate for IPv6 adoption/support at the ISP, large scale network, and datacenter levels, I believe you're totally correct on your basic premise. Until having native IPv6 connectivity for your LAN devices represents a value add in terms of functionality, IPv4 only capabilities are fine for them. IPv6 and IPv4 can and do comfortably coexist; in fact, this is how the Internet will look for many, many years to come.

A guy walking down the street wearing a bathrobe chanting odes to aliens that resemble giant bunnies is only dangerous to the extent that motor vehicle collisions might occur due to the distraction of the spectacle. Conversely, people who generally appear stable and sane, but hold deeply ingrained lunatic views and occupy seats of power are the ones you need to worry about.

Wait just a second. If his listeners are sheep, and he shows up wearing a kilt, you know about those jokes; man I'm just going to stop right here.

To quote my original post:

Apparently you cannot read more than 25 words in sequence before losing track of what you're doing. Please go away until your focus improves.

The first rule of software is that all software beyond the barest of trivial examples will have bugs. Compilers are software, and have the same long and sordid history of bugs. Since compilers have been mentioned specifically, you might be interested in the classic work Reflections on Trusting Trust (it was apparently written by a guy who knows a thing or two about the topic, some Ken Thompson fellow).The same goes for test suites. In many cases, bugs translate to security vulnerabilities. In some cases, perfectly rational behavior demonstrated by entities known as programs results in unexpected behavior when they are made to exchange data. This phenomenon is referred to as "novel outcomes" in some circles, and "wow, that's some fucked up shit" in others. There is a reason the field of information security is as broad as it always has been, is, and always will be.

Your post proves you have never worked as a professional developer, or for an organization where your role was deeply connected to systems or development work. Heck, it proves you've never worked on any major open source project either, for that matter. I suppose we should all stop using anything resembling software immediately to prevent the planet from caving in under the weight of its own failure. Or perhaps you should take your obviously extremely advanced software engineering skills and produce the one true invulnerable platform for everyone, one layer and application at a time.

As Bruce Schneier famously said, "security is a process, not a product." That process never ends, and involves complexities I believe could be delicately framed as things that aren't exactly your area of expertise. That's okay, though; you can always start educating yourself immediately. We're all looking forward to your next batch of brilliant revelations on infosec strategy.