On Sunday 21 November 2010 02:04:35 Andrew Lynn wrote: > 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.
Actually the "small" vendors do not pay any licence fees at all. And I am sure most of us dont have a problem with that. > > >> >> 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. Sorry I missed two key words: "hardware-software" API It means the specs in front of the blob - the hardware regs, and the rear of the blob - the kernel interface must both be available. The blobs are not freely distributable AND there are no disclosed APIs AND you are prohibited from reverse engineering - not the API but the blob and from there the hardware. > > 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. Not quite. My error is corrected above. I am pointing out that a binary blob is all right IF the specs for the hardware API is available. > > 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. Only the interface is required for writing most of the time. However what you suggest is definetly a huge +. > > 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. No advice there, just pointing out that we are utterly free to make a choice. The policy is to force things onto a particular direction. So a nice shove alongwith the carrot of business or threat of blacklist will work nicely. > > 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. the government is a single entity as far as policy matters go and they need not bother with pretending to be nice or even playing the role of an underdog. That would most certainly help blokes like us. > > <snip> > > A. > _______________________________________________ > network mailing list > [email protected] > http://lists.fosscom.in/listinfo.cgi/network-fosscom.in -- Rgds JTD _______________________________________________ network mailing list [email protected] http://lists.fosscom.in/listinfo.cgi/network-fosscom.in
