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" > >> > In India we recently established a "Open Standard Policy".It > >> > is the great success of FOSS communities and our leaders. In > >> > the same way we need to have a policy on Hardware selling. > >> > This policy must specify that "Anything which Govt is buying > >> > must have a Open Specification of their Driver." > >> > > >> > Why this is important ? > >> > > >> > Let me explain by an example. > >> > A school from my town has purchased hardware 1 year ago. At > >> > the time of purchase they are not knowing about Linux. Now > >> > even If they want to move they have to take expert consultancy > >> > to install Linux. Because many a time some device refuse to > >> > work with GNU/Linux because GNU/Linux do not have proprietary > >> > drivers. For example some WebCam do not work directly on > >> > GNU/Linux or most of the whiteboards which is a high trend in > >> > schools etc. > >> > > >> > Dear all FOSS advocates, You need to remember that you can > >> > visit a school or college and try for installing GNU/Linux BUT > >> > you can't change hardware from a system. We must have a clear > >> > policy that says - "every device must have a open > >> > specification or driver for all available operating systems". > >> > > >> > We seriously need to blacklist proprietary driver and hardware > >> > from market and stop their sell. > >> > Proprietary hardware is one from of monopoly which is more > >> > dangerous then proprietary software, > > > > I agree fully with the above. > > > >> This needs more of a debate. There are existing hardware > >> compatibility lists e.g.[1], which serve as advisories, but have > >> limited impact on policy. > > > > The hardware compatability lists are a community provided > > service, which has nothing to do with crooked vendors. > > These are lists from which you would derive a white/black list. > They exist. This thread is to work through a procurement policy > which encourages and allows FOSS adoption. You need to expand on > crooked vendors: Are they vendors who intentionally keep feature > specifications obfuscated to protect their market?
Yes. See my other mail. > 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? > > >> 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. On a side note it would be a real pain to have to write the innards of such stuff merely for use as per it's intended purposes. However minds in the FLOSS world work differently and vendors would do well to pull their heads out of the sand and look at new markets being created for them (CUDA, Netbooks, SDR, OSLR) > > "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. 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. > >> it is probably a better > >> idea to look at a white list with a layered acceptance criteria > >> to filter hardware at procurement. > > > > A blacklist alongside is a must. carrot-stick etc. > > There are practical issues with procurement: It is better to define > what can be procured, rather than list what cannot. This is not > just a matter of semantics - if we stick to a black-list, it MUST > be comprehensive, as the obvious interpretation is what can be > procured is (Universe -minus- blacklist). No. Blacklist means never buy THIS and think ten times before buying from THIS vendor. > > >> To seed this discussion I propose that one such layered > >> approach could be to define a policy such as: > >> > >> All hardware procured should be (additionally) certified to > >> demonstrate the integration of all in-built and specified > >> peripheral devices using all features/functionalities on the > >> device with at least three community based popular GNU/Linux > >> distributions namely Fedora, Open-Suse and Debian, through the > >> following criteria > > > > does not cut it at all. The average life of a distro is around 6 > > months. What happens after 3 years?. Throw away all that > > hardware?. > > My choice of these distros is that they were midway upstream, full > featured, and have sufficient community interest both for support > and to keep them alive. I did mention we need some way to deal with > redundancy, and specified stable and testing. Perhaps Narinder > Sisodiya's reply that we adopt a distro like BOSS/SchoolOS as a > benchmark is a good idea. > > >> (1) Devices should adhere to the specifications of the Linux > >> Kernel[2] (AND) > > > > You mean the drivers should adhere to the coding standards of the > > kernel. linux does not specify the innards of any hardware (byte > > ordering, or cache, or network device fifio or whatever). > > Not coding standards. Standards for loading and interfacing the > driver with the linux kernel. I was assuming the now debated point > that the Linux kernel is the defacto standard for GNU/FOSS distros. Any driver would have to meet that to be able to run. > > >> (2) Devices with the source code for the drivers/peripherals > >> released under GNU GPLv2/3 license > >>(OR) > >> > >> (3) In the inability of the manufacturer to release the driver > >> under the criteria (2) above, > > > > The government shall not procure such devices or recommend such > > devices for purchase (eg RBI mandating properitary hardware for > > connecting to the NEFT) > > The govt. should not procure hardware containing devices for which > open standards exist and viable hardware with drivers for these > open standards that fully meets the users requirement exist. > > >> the driver should be available in > >> stable and testing repositories compatible with the above named > >> mainstream community distributions.[3] > > > > Bitrot will guarantee any such availability to be worse than > > useless. > > Bitrot will not set in even if the distro has a short half-life, as > long as it keeps an active (current) stable and testing repository. Check out the old NVIDIA and ATI boards. -- Rgds JTD _______________________________________________ network mailing list [email protected] http://lists.fosscom.in/listinfo.cgi/network-fosscom.in
