Re: Dealing with drivers that need firmware on the filesystem
On Sun, Jan 09, 2005 at 03:21:40AM +, Matthew Garrett wrote: > Steve Langasek <[EMAIL PROTECTED]> wrote: > > I don't think I have a problem, conceptually, with a kernel package which > > provides drivers for 10,000 different types of hardware, and needs to load > > firmware from disk for 300 of them, being in main (without a > > Depends:/Recommends: relationship on the firmware-providing packages). > That doesn't quite solve the problem of drivers outside the main kernel > tree. This is the case for a large amount of current wireless hardware, > irritatingly. True enough. I have a harder time justifying to myself keeping such drivers in main, but I also think that the infrastructure needed in order to support grabbing firmware out of non-free (for things like the installer) could easily work for the case of contrib driver + non-free firmware as well. -- Steve Langasek postmodern programmer signature.asc Description: Digital signature
Re: Dealing with drivers that need firmware on the filesystem
On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote: > > You also need to turn this question around and ask it the other way: > > does having these drivers in contrib actually hurt anything? > > Yes. It currently means that we can't ship an installer with support for > this hardware, because we don't use material from contrib and non-free > by default. Putting these drivers into main instead of contrib would not alter this, because it still wouldn't work without non-free. Any *practical* difference? -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Dealing with drivers that need firmware on the filesystem
Andrew Suffield writes: > >On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote: >> > You also need to turn this question around and ask it the other way: >> > does having these drivers in contrib actually hurt anything? >> >> Yes. It currently means that we can't ship an installer with support for >> this hardware, because we don't use material from contrib and non-free >> by default. > >Putting these drivers into main instead of contrib would not alter >this, because it still wouldn't work without non-free. Any *practical* >difference? Yes, quite a lot actually - we can then ask people to feed a floopy or CD containing the vendor-supplied firmware. Do keep up... -- Steve McIntyre, Cambridge, UK.[EMAIL PROTECTED] "Because heaters aren't purple!" -- Catherine Pitt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
Craig Sanders dijo [Sun, Jan 09, 2005 at 05:28:23PM +1100]: > it's worse than just putting them in contrib. there's a whole bunch of > drivers with firmware blobs that have just been deleted from the kernel > sources. they're not in contrib, they're not in non-free, they're just gone. > > this affects even DFSG-free drivers with DFSG-free patches. you often can't > apply the patches to the debianised kernel sources because the context that > the patch needs is missing. > > e.g. try downloading the patch[1] for DVICO Fusion DVB-T card's DFSG-free > driver and applying it to the kernel source from any kernel-source-x.x.x > package. it won't apply to the debian kernel, yet it applies without a > problem to pristine sources downloaded from kernel.org. > (...) If you are patching a kernel, you should patch a pristine kernel.org one - I am sure this will also fail to work with any distribution's kernels. You know, not only we have a butcher knife on our hand. Most distributions ship with a modified kernel. Now, if the patch is DFSG-free as you say, it should not be impossible for you (and I do mean _you_, a DD that cares about this particular driver) to patch the patch so it applies on Debian's tree as well, even probably include it in Debian... Or if introduces no ill side effects, propose it to be included either in the upstream Linux kernel or in Debian's kernel packaging. But even then, people who patch their kernels are expected to be able to download a kernel.org one. > debian has forked the kernel (and not for any sensible or useful reason - just > to satisfy some extremist ideologues), and it is already causing problems for > us and our users. it is also making debian an object of scorn and ridicule by > kernel hackers (and deservedly so). ...Extremist ideologues that happen to share their point of view with most of the DDs. I know this makes you terribly unhappy, but this thread has shown that a majority of DDs agree with the extremist idea of defending software freedom. > > We /could/ put non-free firmware in main, on the grounds that while it > > is in many cases executable code, it does not execute on any processor > > that is under the direct control of the operating system. This would > > possibly require a small alteration to the social contract. A result > > of this would be that not everything in main would be DFSG free. > > IMO, this is the correct approach at least for stuff in the standard kernel > source tree. from the kernel's POV, it is not code, it is just data that gets > uploaded to a peripheral device[1]. the firmware blob is included in > GPL-licensed code and is also GPL. it's no more "non-free" than > pre-calculated lookup tables in programs like gzip and bzip, or the CSS data > in decss and related programs. Yes, but we do hold some promises regarding _all_ of main: We can fix bugs. If we ship this firmware as part of main, we would be expected to be able to fix it. I am not among those who require the original sound samples or vector files for every audio or graphic file we ship, as they can still be altered in the format we have them in... But we would not be able to keep our quality standards if we allowed non-free firmware in main. Greetings, -- Gunnar Wolf - [EMAIL PROTECTED] - (+52-55)1451-2244 / 5554-9450 PGP key 1024D/8BB527AF 2001-10-23 Fingerprint: 0C79 D2D1 2C4E 9CE4 5973 F800 D80E F35A 8BB5 27AF -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
Op ma, 10-01-2005 te 16:58 +, schreef Andrew Suffield: > On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote: > > > You also need to turn this question around and ask it the other way: > > > does having these drivers in contrib actually hurt anything? > > > > Yes. It currently means that we can't ship an installer with support for > > this hardware, because we don't use material from contrib and non-free > > by default. > > Putting these drivers into main instead of contrib would not alter > this, because it still wouldn't work without non-free. Any *practical* > difference? None, indeed. I personally prefer the third idea. In fact, I had been thinking about it myself; it's just that Matthew beat me to it. AIUI, the people that want to see firmware blobs in main aren't actually interested in having those blobs in main; what they are interested in, is for Debian being able to provide an installer that supports the hardware needing such blobs. A section of the archive with the requirement that anything in it must be redistributable on installation media (with the definition of those 'installation media' being "whatever the current implementation of Debian's installer supports") would certainly help here. This kind of compromise would allow us to build installer images using those drivers, so those of us that want all non-free Software to burn in Hell would not use any non-free software--not even accidentally--while those of us with a more pragmatic way of looking at things will still actually have a useful system. -- EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER -- with thanks to fortune -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
On Mon, Jan 10, 2005 at 05:35:59PM +, Steve McIntyre wrote: > Andrew Suffield writes: > > > >On Sun, Jan 09, 2005 at 07:51:58PM +, Matthew Garrett wrote: > >> > You also need to turn this question around and ask it the other way: > >> > does having these drivers in contrib actually hurt anything? > >> > >> Yes. It currently means that we can't ship an installer with support for > >> this hardware, because we don't use material from contrib and non-free > >> by default. > > > >Putting these drivers into main instead of contrib would not alter > >this, because it still wouldn't work without non-free. Any *practical* > >difference? > > Yes, quite a lot actually - we can then ask people to feed a floopy or > CD containing the vendor-supplied firmware. Do keep up... This might be a valid reason for including the driver in main if it actually happened. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
Re: Dealing with drivers that need firmware on the filesystem
[EMAIL PROTECTED] wrote: >On Sun, Jan 09, 2005 at 03:22:45PM +0100, Martin Schulze wrote: >> The larger problem is to identify non-free blobs in the main kernel, >> extract them into non-free and modify the driver so that it is able >> to load the blob from a user provided location; and include this in >> our installer. >Isn't this being done upstream, anyway, for GPL-compatibility purposes? It's not, because almost everybody believes that the result is aggregation and not a derived work. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
[EMAIL PROTECTED] wrote: >Being in contrib doesn't mean that a work is evil, nor is contrib a >second cousin to non-free. It means that something is not part of debian and is not acceptable for install media, which looks like a big enough problem to me. It would be silly to be able to move a driver from contrib to main just by massaging it into a kernel patch. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
[EMAIL PROTECTED] wrote: >True enough. I have a harder time justifying to myself keeping such drivers >in main, but I also think that the infrastructure needed in order to support >grabbing firmware out of non-free (for things like the installer) could >easily work for the case of contrib driver + non-free firmware as well. No, because in many situations the users would only need to copy the firmware binary from media they already have, and installing a package from a different archive (and even more a new udeb) requires more work for them and for us. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Your Managers Don't Have Expertise They Have This.
Get a legal college degree Instantly: Here's the ultimate solution for anybody who needs to get a degree instantly with no attendance requirements or hassle of any kind. Get recognition for your experience. Give us a call @ 1.206.666.6485 narrate initiate torture actinium pixel acadia eigenstate quizzical beirut daze
Re: Dealing with drivers that need firmware on the filesystem
I bet that, with some of these firmware blobs, we could reverse-engineer and "clean room" clone them in a country with permissive reverse engineering laws. At that point, we'd have something that was definitely free. Anyone interested in trying? -- "While the Melissa license is a bit unclear, Melissa aggressively encourages free distribution of its source code." --Kevin Dalley <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
[EMAIL PROTECTED] wrote: >I bet that, with some of these firmware blobs, we could >reverse-engineer and "clean room" clone them in a country with >permissive reverse engineering laws. At that point, we'd have >something that was definitely free. I bet you could not, for interesting devices (DVB receivers, DSL modems, WiFi cards) in a reasonable time. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dealing with drivers that need firmware on the filesystem
On Mon, Jan 10, 2005 at 10:14:02AM -0800, Ben Pfaff wrote: > I bet that, with some of these firmware blobs, we could > reverse-engineer and "clean room" clone them in a country with > permissive reverse engineering laws. At that point, we'd have > something that was definitely free. > > Anyone interested in trying? It's on my todo list, but I have a couple of binary-only drivers to tackle first. -- .''`. ** Debian GNU/Linux ** | Andrew Suffield : :' : http://www.debian.org/ | `. `' | `- -><- | signature.asc Description: Digital signature
