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.

Man, I must be using my MacBook wrong, too. About a third of my active desktop real estate is perpetually occupied by a terminal window, and I've even got an icon for it in two places. It's almost like some people use Unix-based operating systems for, well, things that Unix-based operating systems are historically used for. Crazy.

Actually, /. has always been like this. I've been a reader here since 2000, and suspect you're suffering from Gool Ol' Days Syndrome.

You appear to presume the creation of some mystical system whereby the automatic availability of the former is assured, which would be a miraculous medical and social development even in the western world. In other words, without the latter, you may find yourself lacking the former. Yes Virginia, organ availability is primarily a social problem. It's a problem that isn't solvable in the political context, as the core of the issue deals with aspects of human rights and human nature that can't by any stretch of the imagination be forced or otherwise ethically regulated.

Depending upon the severity of your need, this may be of grave concern to you, and you may find yourself willing to rethink your personal system of ethics accordingly.

Given that conciliatory is a synonym for propitiatory, I suspect any scenarios involving Red Hat becoming litigious are unlikely to involve Red Hat acting in a conciliatory fashion on the matter at any point in the next decade or so thereafter.