On Sat, Nov 20, 2010 at 10:19 PM, jtd <[email protected]> wrote: > On Saturday 20 November 2010 15:52:13 Andrew Lynn wrote: > >> On Fri, Nov 19, 2010 at 3:43 PM, jtd <[email protected]> wrote: >> > On Friday 19 November 2010 11:18:03 Andrew Lynn wrote: >> >> On Fri, Nov 19, 2010 at 4:16 AM, Narendra Sisodiya >> >> >> >> <[email protected]> wrote: >> >> > Let me put my voice on the biggest hurdle in FOSS adaptation. >> >> > This hurdle is "Proprietary Hardware Drivers" <snip> > >> What about >> smaller vendors who can mass produce excellent products but are >> tied to upstream third party patent encumberences - should they be >> excluded? > > What has size got to do with it? >
Size has everything to do with it. Hardware is patent encumbered. Open standards, while ideal, do not exist for a large proportion of hardware. Standards have to be defined for data interoperability, and device interoperability, and for obvious reasons many of these are open standards. Many innovative devices - largely peripherals - are produced by smaller companies, and reach the market at lower cost. It would be a far better world to have the primary producers of these ware go to market directly than have them work as bonded entities to a larger entity that re-brands them, simply because the larger entity controls the patents - and set de facto standards - either upstream or downstream of the product's use. >> >> >> While no one would question the argument that proprietary >> >> drivers pose a severe restriction for widespread FOSS adoption, >> >> it is important to provide space to integrate proprietary >> >> drivers if no viable FOSS drivers are available - at risk to >> >> killing FOSS adoption by allowing only basic features. >> > >> > Did I get that right? proprietary drivers killing FOSS. The >> > government is the biggest IT purchaser. Having set guidelines on >> > using FOSS, they must insist that ALL HARDWARE procured by the >> > government must have their specifications mandatorily open. What >> > happens when a hardware vendor winds up in the hands of an >> > inimical foreign government? You cant hold your IT systems >> > hostage to some vendor hardware. >> >> What you specify is an ideal case, but requires a phased >> implementation. We are looking at two extremes: One which is to >> insist on open standards for all hardware, and the other be damned >> as long as it runs - perhaps even permitting an ndiswrapper >> approach to the use of these drivers. The practical issue is that >> due to its hugh market share, MS-Windows is the defacto standard >> with desktop and related computers, and if devices are to survive, >> all they need is a driver compatible with Windows.There are a large >> number of areas where specific hardware devices are required which >> do not have open standards. There are also a large number of >> inexpensive devices produced in the third world which simply do not >> have FOSS drivers - probably due to lack of skills to create these >> locally. > > We are mixing two things. Nobody is saying that you cant have hardware > with some esoteric, non-standard feature and implementation. What we > are saying is that ALL devices should have open interface specs, so > that FLOSS drivers can be written and distributed without hindirance. > Increasingly wifi radios are SDR (software defined radios) and have a > dsp inside. The vendor writes a DSP driver which is loaded in the > internal flash or at runtime to save flash costs. To a PC device > driver the blob + dsp looks like a radio modem, not as PLL, DSP, DDS > etc. So as long as the interface (API) is open its fine. So where is > the problem?. A half smart guy can decode the blob with the help of > the API and the vendor does not want that. > Same logic holds for the NVIDIA cards and many similiar devices. > > While one would be wise to avoid those blobs, It would be ok if the > API is FLOSS compatable and the blobs freely distributable. > Now I am confused. I had earlier set two extremes: One where we play the Gandhian card and work as martyrs fighting to establish a better world completely with open standards, by refusing to accept anything else. The other extreme is to work with an ndiswrapper approach - that defines an API that can plug the proprietary/binary driver into the kernel. I had assumed you were advocating the first extreme. The above statement looks much like the other extreme. If only the interface to the device hardware has to be an open standard, we do not have an argument - or even an issue. A more ideal case would be opening the detailed specification of the hardware, even if patented, so that open drivers could be written, not reverse engineered or re-written by decoding blobs. I was suggesting a policy that encourages the use of open standards, but warning of the perils on FOSS adoption in taking such a hard line in areas where they do not exist for critical devices. <snip> > >> >> "Government" is not a single entity with a singular purpose, and I >> reiterate my earlier point: Without a fully featured driver, you >> get a crippled system. > > >> This is not so much of a problem for the >> server market, and your question related to control by foreign >> entities has become an issue for specialised markets such as >> telecommunications. For mission critical systems, by all means >> insist on open standards. > >> >> How would you advise me to be academically competitive without GPU >> computing or OpenGL when they are required for my work? Or for the >> hugely growing IT enabled design, animation and CG-in film >> industry? Leave FOSS out, because it cannot run on the existing >> state-of-the-art hardware with existing open drivers? > > We all have choices to make. Why do I not cater to the hughe doze > market?. Why bother with FLOSS and not use doze. > ??? I assume this is rhetorical. >YOU make a compromise by all means, but dont ask everyone else to > water down a perfectly valid, logical and commonsense requiremnt > which actually helps everyone longterm except some vendors. > Thanks for the advice, but don't get me wrong: I am all for open standards everywhere. There is, unfortunately, a long way before we reach that ideal world, if ever. It is more common-sense to see that we can use devices with mainstream GNU/Linux, and encourage the use of an application like Blender to run on a gaming machine with all bells and whistles rather than push a policy that forces a shift to Maya on Windows...because the GNU/Linux was crippled for want of a driver. <snip> A. _______________________________________________ network mailing list [email protected] http://lists.fosscom.in/listinfo.cgi/network-fosscom.in
