On Thu, Jan 19, 2012 at 2:40 PM, Andrew S. Baker <[email protected]> wrote: >> Remember when Microsoft had nearly taken >> over the browser world? We sat on IE 6 for *years* and *years*. > > My point being that although the underpinnings were > open standards, HTML included, that didn't afford any > automatic advantage.
Automatic? No. But it's possible; there are ways to improve the situation. But if Adobe Flash Player sucks (and it does), I can't switch to Brand X's Flash Player. Sure, I can uninstall Flash Player and install Silverlight, but that doesn't help view the brazilians of web sites using Flash content. And let's say Bill Gates finds a magic lamp and wishes that all the Flash content in the universe instantly transmute to Silverlight content. Now Linux, Android, and iOS users are all sunk, because there is no viable Silverlight player for those platforms, nor can there be without Microsoft providing one. (Silverlight is not an open standard. In practice, Silverlight is heavily tied to Microsoft proprietary libraries, codecs, formats, patents, and the like. The Moonlight project had to get special access to non-public documentation to do anything, and even then it's near-useless because all the sites using Silverlight are using stuff only available on the Microsoft .NET platform. Silverlight is an open standard the same way Adobe Flash is.) > A proprietary plug-in doesn't prevent competition with other > standards or plug-ins, so I'll have to disagree with your > assertion that "proprietary = bad" under the discussed > scenario. A proprietary plug-in doesn't prevent competition with other plug-ins, true. But it does prevent competition between other implementations of whatever the first plug-in does, which is my point: Proprietary plug-ins are a bad thing, for this reason. > A bad implementation is a bad implementation independent of the > openness or proprietaryness of the thing involved. Agreed, but irrelevant to the point I'm making. > Sure, if we're dealing with open source, then there's the > theoretical option to fix the broken/bad implementation, but > in practice, someone else just develops a competing app > and/or protocol, and people move to that instead. Your argument seems to be confusing protocols with implementations. > Case in point: For many years, Sendmail was routinely chastised > for being buggy and insecure, and the apparent solution was to > create other MTAs like qmail, postfix, etc. Fixing sendmail > (which eventually happened) was not nearly the primary > approach taken. Sure. Largely because the Sendmail code is a mess.[1] But because Sendmail was an *implementation* of an open *protocol*, those other MTAs were a practical option. If Sendmail was an implementation of a proprietary email protocol, with no other implementations possible, I wouldn't be able to communicate with anyone else using still Sendmail if I switched. -- Ben [1] The Sendmail code still is a mess, by all accounts. It's just most of the obvious bugs have been fixed, so there are fewer easy targets to attack. Low-hanging fruit and all that. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
