Marco d'Itri wrote: > glenn@zewt.org wrote: >>Huh? If a driver requires a firmware blob be copied from a driver CD, > > Please repeat after me: "drivers do not require firmwares, hardware > devices require firmwares". First of all, no: *both* require the firmware in order to perform their function. See my reply <417D32C4.2000902@verizon.net> in the thread "Re: firmware status for eagle-usb-*" for a full explanation of why, including actual code from such a driver. However, suppose that your statement were true. Why stop there? Consider the case of a piece of hardware which could not be initialized correctly except by the Windows driver. In order for the device to work, a user would need to boot up Windows, allow the driver to initialize the device, and soft-boot into GNU/Linux, at which point the driver could control the device. Also suppose that the Windows driver was shipped on the manufacturer's CD, so the user already has it (which is almost always the case). Repeat after me: "Drivers don't require initialization, hardware devices require initialization". :) So why can't this driver go in main too? For that matter, the Linux driver could even be coded to load the relevant piece of the Windows driver at runtime, and use it to initialize the hardware; that's obviously more convenient for end-users. The user still has the Windows driver already, and the amount of non-free code has actually decreased (since they don't need Windows anymore); why not put the Linux driver in main? What if more and more new drivers started to work this way (something similar was speculated at one point, when there were discussions about a uniform driver interface for different OSes)? Would you begin to change your arguments based on convenience, just to try to get more people running Free Software (on a non-free base), as you are for drivers that require firmware? Quoting from your message <cke9i5$3mf$1@wonderland.linux.it>: > bts@alum.mit.edu wrote: >>So rather than ship the driver in contrib and the firmware in >>non-free, you're suggesting that the driver go in main and the >>firmware not be shipped at all, even though that reduces the >>functionality of the driver to "Error: no firmware found." > > Yes. I believe that this better serves our users. I can think about at > least two common situations in which an hard dependency would not be > appropriate or even possible: > - when distribution is restricted by copyright, so we cannot distribute > it even in non-free (usually when the driver has been developed from > scratch by a third party) > - when the firmware is used by a device needed to install the system, > like a network card or a modem (if the user has got the Debian system > on a CD it may be easier for him to get the firmware from the vendor > CD than downloading it and the transfering it to the target system > using some removable media) > >>>That seems as clear a dependence as any other foo and foo-data package >>>in the repository. > > Probably because you did not think much about real-life issues... So it certainly sounds like your reasoning is based primarily on practicalities; if a large number of drivers started to be based on proprietary hardware initialization code provided by the manufacturer, it would certainly be more practically convenient to permit drivers requiring this code to go in main. For another example, suppose there were a new, proprietary 3D graphics interface, ClosedGL, only implemented by ATI's and nVidia's proprietary driver. Suppose someone wanted to package a game that used ClosedGL. Repeat after me: "Programs don't require drivers, hardware devices require drivers (to provide APIs)". :) So by your arguments, why can't this game go in main? - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature