On Thu, Oct 28, 2004 at 09:36:51PM +0100, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 28, 2004 at 12:33:59PM +0100, Matthew Garrett wrote:
> >> d-i is modular. The module that provided that functionality would be
> >> likely to do little of any use without the
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 28, 2004 at 12:33:59PM +0100, Matthew Garrett wrote:
>> d-i is modular. The module that provided that functionality would be
>> likely to do little of any use without the presence of contrib.
>
> So, libdvdread3 making use of libdvdcss by havi
[EMAIL PROTECTED] wrote:
>Does anyone know if it is possible to obtain an IDE disc drive that
>contains no non-free software,
I do not believe that this is possible.
--
ciao,
Marco
On Thu, Oct 28, 2004 at 12:33:59PM +0100, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote:
> >> That would require certain parts of d-i (and hence certain parts of
> >> main) to rely upon the contents of contrib.
Matthew Garrett <[EMAIL PROTECTED]>:
> I possibly didn't make that clear. "depend", when used by policy, refers
> to dependencies that are expressed by the package management system. As
> a result, it's possible to argue that a driver doesn't "depend" on the
> firmware that's in a chip on a PCB of
> Raul Miller <[EMAIL PROTECTED]> wrote:
> > Software which we don't and can't ship, which is a part of the platform
> > we're running on, which is not application code, and which basically is
> > outside the scope of the project is software we ignore.
On Thu, Oct 28, 2004 at 05:50:09PM +0100, Mat
Raul Miller <[EMAIL PROTECTED]> wrote:
> Software which we don't and can't ship, which is a part of the platform
> we're running on, which is not application code, and which basically is
> outside the scope of the project is software we ignore.
In many of these cases, we /could/ ship it (well, th
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> > Sure it does. The Debian Free Software Guidelines only apply to
> > software. Hardware is hard, not soft.
On Thu, Oct 28, 2004 at 12:40:02PM +0100, Matthew Garrett wrote:
> That's an unfortunate circumstance of naming. Anything that we could
Matthew Garrett <[EMAIL PROTECTED]>:
> The social contract uses "require", which is a stronger term than
> policy's "depend". The driver software requires the portion of the
> hardware that can also be described as software.
I assume the relevant quote is: "We will never make the system require
t
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>> Two issues:
>>
>> 1) The social contract doesn't give us any leeway here. There's no
>> way to claim that hardware doesn't have to conform to the DFSG, and
>> there's no way to claim that large parts of
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote:
>> That would require certain parts of d-i (and hence certain parts of
>> main) to rely upon the contents of contrib. We can't do that.
>
> No, I believe that would create a Suggests-style r
On Thu, Oct 28, 2004 at 12:33:38AM +0100, Matthew Garrett wrote:
> That would require certain parts of d-i (and hence certain parts of
> main) to rely upon the contents of contrib. We can't do that.
No, I believe that would create a Suggests-style relationship, not
a Depends, since d-i would still
On Wed, Oct 27, 2004 at 05:36:36PM -0700, Josh Triplett wrote:
> I don't see how adding support for handling contrib udebs would actually
> create a dependency; it just makes it possible to install them if
> desired.
It doesn't create the dependency -- it just forces us to recognize their
contents
Matthew Garrett wrote:
> Josh Triplett <[EMAIL PROTECTED]> wrote:
>
>>Matthew Garrett wrote:
>>
>>>We could do that, but it couldn't reasonably form part of the standard
>>>debian-installer. A forked d-i doesn't do anyone any favours.
>>
>>I don't see why we couldn't put support for using contrib
Josh Triplett <[EMAIL PROTECTED]> wrote:
> Matthew Garrett wrote:
>> We could do that, but it couldn't reasonably form part of the standard
>> debian-installer. A forked d-i doesn't do anyone any favours.
>
> I don't see why we couldn't put support for using contrib udebs for
> things such as driv
On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote:
> (I'm obviously happy to see you resorting to ad hominems as it probably
> means you have no more arguments.)
You're the one trying to convince people of a new position (that non-free
dependencies in main are acceptable), so you're the
Matthew Garrett wrote:
> Josh Triplett <[EMAIL PROTECTED]> wrote:
>>Matthew Garrett wrote:
>>
>>>It is certainly the case that I would like our users to be able to use
>>>their computers regardless of the mechanism that the vendor uses to ship
>>>firmware, yes. Remember that we don't ship contrib a
Josh Triplett <[EMAIL PROTECTED]> wrote:
> Matthew Garrett wrote:
>> It is certainly the case that I would like our users to be able to use
>> their computers regardless of the mechanism that the vendor uses to ship
>> firmware, yes. Remember that we don't ship contrib as part of the
>> installer,
Raul Miller <[EMAIL PROTECTED]> wrote:
>> > This is the wrong mailing list for that sort of proposal.
>
> On Tue, Oct 26, 2004 at 08:32:47PM +0100, Matthew Garrett wrote:
>> That's why I'm not actively proposing it here. Brian asked me a
>> question, and I answered it.
>
> In that case, perhaps y
[EMAIL PROTECTED] wrote:
>On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote:
>> I explained my principles at the beginning of the discussion, and I do
>> not feel the need to state them again because they are not relevant here:
>
>How about something that is relevant, then?
>
>If that's
On Wed, Oct 27, 2004 at 10:56:58AM +0200, Marco d'Itri wrote:
> I explained my principles at the beginning of the discussion, and I do
> not feel the need to state them again because they are not relevant here:
How about something that is relevant, then?
If that's not possible, maybe you don't wa
[EMAIL PROTECTED] wrote:
>Argh. Yes, but the firmware in these eeproms is something that we're
>entirely logically capable of shipping. Claiming that firmware is
>sometimes software (when it's on a compact flash card, say) and
>sometimes hardware (when it's on an eeprom, say) is the sort of argume
[EMAIL PROTECTED] wrote:
>On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
>> >In cases where firmware is basically indistinguishable from hardware,
>> >we treat it as hardware, and not as software.
>> Really? Which part of policy states this?
>It's very interesting how quickly people
Matthew Garrett wrote:
> It is certainly the case that I would like our users to be able to use
> their computers regardless of the mechanism that the vendor uses to ship
> firmware, yes. Remember that we don't ship contrib as part of the
> installer, either.
Thanks to the excellent work of the in
Matthew Garrett <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>> Yes, Marco. We all understand the model you propose, based around the
>> idea "all firmware is essentially hardware, even if it's clearly a
>> file that has to be there on disk for a driver to functio
"Marco d'Itri" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>>Yes, Marco. We all understand the model you propose, based around the
>>idea "all firmware is essentially hardware, even if it's clearly a
>>file that has to be there on disk for a driver to function". An
> Now it's quite
"Marco d'Itri" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>>Then there's no point continuing this conversation. An FPGA design,
>>living as a file on disk and possibly even shipped by Debian is
>>clearly software under Debian's definitions. Runtime-loaded firmware
> I was not discu
On Tue, Oct 26, 2004 at 06:46:34PM -0400, Michael Poole wrote:
> How many significant free examples of DVD content are there?
I have Debian main (sarge) on DVD, so there's at least one example.
If you're talking about audio-visual materials, I imagine that the right
way to find such materials wou
Raul Miller writes:
> In that case, we should probably be treating this as analogous to
> players for various forms of content. If there are any significant free
> examples of that content we allow the player into main. If there are
> no significant examples of that content, the loader really do
> > This is the wrong mailing list for that sort of proposal.
On Tue, Oct 26, 2004 at 08:32:47PM +0100, Matthew Garrett wrote:
> That's why I'm not actively proposing it here. Brian asked me a
> question, and I answered it.
In that case, perhaps you should take your discussion elsewhere?
Correct
On Tue, Oct 26, 2004 at 04:42:45PM -0400, Glenn Maynard wrote:
> No, the entire point was to make it clear that, as far as the Social
> Contract is concerned, everything in Debian is software. (This is
> my understanding, based both on the changes made by 2004-003 and the
> discussions surrounding
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> There is no "contortion of logic" involved in the conclusion that the
> Social Contract is only talking about the stuff that Debian ships (or
> is logically capable of shipping), and not the physical hardware that
> stuff runs on.
Argh. Yes, but the firm
> Raul Miller writes:
> > It's a matter of point of view.
On Tue, Oct 26, 2004 at 03:42:41PM -0400, Michael Poole wrote:
> I am quite certain that you have never worked with the drivers I was
> describing, and the chance you have worked with any of the boards is
> nearly zero. Your assumption tha
On Tue, Oct 26, 2004 at 08:41:02PM +0100, Matthew Garrett wrote:
> I think it's the only rational way to interpret it that's consistent
> with the discussion surrounding the GR. The entire point of changing the
> social contract was to make it clear that the DFSG were supposed to be
> used on every
Don Armstrong <[EMAIL PROTECTED]> wrote:
> So your argument is, in effect, that because we can't ship DFSG Free
> computers (I mean, the system "requires" them after all) then we
> should just give up and go home?
>
> Or are you trying to say that because we can't satisfy SC 1 for
> hardware, we
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> The status quo, as I understand it, is that firmware which is uploaded
> from disk by a driver is a dependency, but firmware embedded in the hardware
> is treated as part of the hardware--that's certainly how it looks and acts
> to me, as a user. I belie
Adam McKenna <[EMAIL PROTECTED]> wrote:
> 'Main' is what we ship. Splitting it into two parts and calling one part
> something else does not make it any different. If you're going to try to
> amend the social contract, you might as well amend itto allow non-free
> firmware into main (after satis
Raul Miller <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
>> Modify the social contract to create a new section that would be
>> distributed alongside main, and put the firmware in there.
>
> This is the wrong mailing list for that sort of proposal.
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
> >In cases where firmware is basically indistinguishable from hardware,
> >we treat it as hardware, and not as software.
> Really? Which part of policy states this?
It's very interesting how quickly people who fail badly at backing the
Raul Miller <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 25, 2004 at 11:46:03PM +0100, Matthew Garrett wrote:
>> I see nothing that suggests that "non-free component" is only meant to
>> apply to material shipped by Debian. Nor is there any suggestion that
>> it applies only to software (which is unsu
Raul Miller writes:
> > > That said, it sounds like the drivers do behave differently depending on
> > > the firmware -- you've asserted that the difference is not of interest
> > > to the driver, but that's not at all the same as asserting that there
> > > is no difference.
>
> On Tue, Oct 26, 2
> > That said, it sounds like the drivers do behave differently depending on
> > the firmware -- you've asserted that the difference is not of interest
> > to the driver, but that's not at all the same as asserting that there
> > is no difference.
On Tue, Oct 26, 2004 at 01:47:06PM -0400, Michael
Ken Arromdee wrote:
> On Mon, 25 Oct 2004, Josh Triplett wrote:
>>>I would disqualify that driver from main not because it depended on a
>>>Windows driver, but because it depended on having Windows itself.
>>
>>I see; so some dependencies on non-free software are to be considered
>>acceptable, whil
Raul Miller writes:
> > In my day job, I work on a device driver that can talk to a device
> > programmed using several different firmwares. Other drivers I have
> > worked on can downloaded firmware but the boards also have EEPROMs
> > that hold default firmwares. Importantly, the drivers do no
> >> >In cases where firmware is basically indistinguishable from hardware,
> >> >we treat it as hardware, and not as software.
> >> Really? Which part of policy states this?
> [EMAIL PROTECTED] wrote:
> >Historical practice.
On Tue, Oct 26, 2004 at 06:07:28PM +0200, Marco d'Itri wrote:
> OK, th
On Tue, Oct 26, 2004 at 11:51:22AM +0100, Matthew Garrett wrote:
> 1) The social contract doesn't give us any leeway here. There's no
> way to claim that hardware doesn't have to conform to the DFSG
The "S" in DFSG stands for Software, so I don't see how you would get that it
applies to hardware.
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>
> > OK. What course of action do you advocate? So far I hear you telling
> > other people they're wrong -- useful if they are, not so useful if
> > they're the least wrong of all
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> > OK. What course of action do you advocate?
On Tue, Oct 26, 2004 at 04:12:20PM +0100, Matthew Garrett wrote:
> Modify the social contract to create a new section that would be
> distributed alongside main, and put the firmware in there.
This i
> Brian Thomas Sniffen writes:
> > So if I have a program which loads a library, and replace the library
> > with random data, the program will continue to do what I expect and
> > what I can follow by reading its source. It is the library that will
> > not perform, not living up to its end of the
[EMAIL PROTECTED] wrote:
>Yes, Marco. We all understand the model you propose, based around the
>idea "all firmware is essentially hardware, even if it's clearly a
>file that has to be there on disk for a driver to function". An
Now it's quite clear that you did not understand at all what I have
[EMAIL PROTECTED] wrote:
>> >In cases where firmware is basically indistinguishable from hardware,
>> >we treat it as hardware, and not as software.
>> Really? Which part of policy states this?
>Historical practice.
OK, thank you for confirming that this has no foundation in the policy.
--
ciao,
[EMAIL PROTECTED] wrote:
>Then there's no point continuing this conversation. An FPGA design,
>living as a file on disk and possibly even shipped by Debian is
>clearly software under Debian's definitions. Runtime-loaded firmware
I was not discussing Debian's definitions now.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>> >I'm telling you some drivers *do depend* on a certain firmware. You're
>> >still repeating the opposite. Now explain me how in ipw2200 case the
>> >driver doesn't *depend* on the firmware, since you seem to know the
>> >truth.
>> You are using a different meaning of "d
> Raul Miller <[EMAIL PROTECTED]> wrote:
> > I said similar, not identical.
> >
> > The difference I was referring to was the difference of convenience --
> > using software from contrib requires a few extra steps. Similarly,
> > using an external copy of firmware requires a few extra steps.
On
Brian Thomas Sniffen writes:
> Michael Poole <[EMAIL PROTECTED]> writes:
> > Not at all. If you fill the block with random data, the driver will
> > continue to do what you expect and what you can follow by reading its
> > source code. It is the device that will not perform and that will not
> >
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> OK. What course of action do you advocate? So far I hear you telling
> other people they're wrong -- useful if they are, not so useful if
> they're the least wrong of all possible arguments -- but I haven't
> heard what you'd like to do about the
Matthew Garrett <[EMAIL PROTECTED]> writes:
> main. We argued that this was not allowed under the social contract and
> the DFSG, and in the end people were forced to agree. I am now arguing
> that the social contract gives us no right to engage in this form of
> historical practice - given the cu
Michael Poole <[EMAIL PROTECTED]> writes:
> Not at all. If you fill the block with random data, the driver will
> continue to do what you expect and what you can follow by reading its
> source code. It is the device that will not perform and that will not
> live up to its end of the interface. T
Raul Miller <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>> >In cases where firmware is basically indistinguishable from hardware,
>> >we treat it as hardware, and not as software.
>
> On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
>> Really? Which part of policy states th
Raul Miller <[EMAIL PROTECTED]> wrote:
>> Raul Miller <[EMAIL PROTECTED]> wrote:
>> > Note that this difference is similar in character to the difference
>> > between main and contrib.
>
> On Tue, Oct 26, 2004 at 01:39:03PM +0100, Matthew Garrett wrote:
>> How? Main is free software that doesn't r
> [EMAIL PROTECTED] wrote:
> >In cases where firmware is basically indistinguishable from hardware,
> >we treat it as hardware, and not as software.
On Tue, Oct 26, 2004 at 12:27:09PM +0200, Marco d'Itri wrote:
> Really? Which part of policy states this?
Historical practice.
--
Raul
> Raul Miller <[EMAIL PROTECTED]> wrote:
> > It's different because, when the firmware is built into the device,
> > the person who has the device has the firmware.
> >
> > Note that this difference is similar in character to the difference
> > between main and contrib.
On Tue, Oct 26, 2004 at 01:
Raul Miller <[EMAIL PROTECTED]> wrote:
> It's different because, when the firmware is built into the device,
> the person who has the device has the firmware.
>
> Note that this difference is similar in character to the difference
> between main and contrib.
How? Main is free software that doesn'
Glenn Maynard writes:
> On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote:
> > > That doesn't really change the fact that drivers that only work after
> > > pointing it at a non-free data block have a non-free dependency, and
> > > belong in contrib, though.
> >
> > The driver operate
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Yes, Marco. We all understand the model you propose, based around the
> idea "all firmware is essentially hardware, even if it's clearly a
> file that has to be there on disk for a driver to function". An
> equally valid model has been proposed ar
On Tue, Oct 26, 2004 at 12:23:43PM +0200, Marco d'Itri wrote:
> [EMAIL PROTECTED] wrote:
> >I'm telling you some drivers *do depend* on a certain firmware. You're
> >still repeating the opposite. Now explain me how in ipw2200 case the
> >driver doesn't *depend* on the firmware, since you seem to kn
Yes, Marco. We all understand the model you propose, based around the
idea "all firmware is essentially hardware, even if it's clearly a
file that has to be there on disk for a driver to function". An
equally valid model has been proposed around the idea that all
software is software, and anythin
"Marco d'Itri" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
>
>>Heck, for all I know there's a device out there where the "firmware on
>>disk" is verilog code, and it's compiled by the driver and loaded to
>>an FPGA on the device.
>>
>>Surely that's software.
> I'm not so sure that an FP
[EMAIL PROTECTED] wrote:
>On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri 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".
>The driver is opening a block of
[EMAIL PROTECTED] wrote:
>In cases where firmware is basically indistinguishable from hardware,
>we treat it as hardware, and not as software.
Really? Which part of policy states this?
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
>While this is true, it is incomplete: the driver Depends, in the
>policy sense, on the device, and the device Depends on the firmware.
I do not think policy can justify this.
>> Obviously any kind of device driver has limited practical use[1] if
>> you do not own the har
[EMAIL PROTECTED] wrote:
>On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote:
>> >> Please repeat after me: "drivers do not require firmwares, hardware
>> >> devices require firmwares".
>> >Then, how do you explain the ipw2200 case where driver version 0.5 and
>> >less will only work wit
[EMAIL PROTECTED] wrote:
>Heck, for all I know there's a device out there where the "firmware on
>disk" is verilog code, and it's compiled by the driver and loaded to
>an FPGA on the device.
>
>Surely that's software.
I'm not so sure that an FPGA design is software (for sane definitions of
softwar
On Mon, 25 Oct 2004, Josh Triplett wrote:
> > I would disqualify that driver from main not because it depended on a
> > Windows driver, but because it depended on having Windows itself.
> I see; so some dependencies on non-free software are to be considered
> acceptable, while others are not?
I me
Ken Arromdee wrote:
> On Mon, 25 Oct 2004, Josh Triplett wrote:
>>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 nee
On Mon, Oct 25, 2004 at 11:40:22PM -0400, Michael Poole wrote:
> > That doesn't really change the fact that drivers that only work after
> > pointing it at a non-free data block have a non-free dependency, and
> > belong in contrib, though.
>
> The driver operates as designed regardless of what is
Glenn Maynard writes:
> So you're saying that the loaded-at-runtime option allows for DFSG-free
> versions to be implemented, so they should be allowed in main to encourage
> that particular design option over the "static ROM" option. (There's
> also the EPROM option, which acts like hardware--th
On Mon, Oct 25, 2004 at 09:50:42PM -0400, Michael Poole wrote:
> One argument that has appeared previously is that the driver depends
> on the firmware blob because if a different blob were used, the
> hardware might behave differently. That begs for consideration of the
> obverse case: the hardwa
Glenn Maynard writes:
> Marco's argument appears to be that drivers should be allowed in main
> that only function if they have access to a non-free firmware blob;
> that a driver that, lacking the file, merely bails and says "download
> this non-free piece first" should be allowed in main.
One a
On Mon, 25 Oct 2004, Matthew Garrett wrote:
> I see nothing that suggests that "non-free component" is only meant
> to apply to material shipped by Debian. Nor is there any suggestion
> that it applies only to software (which is unsurprising, given the
> care taken to remove all reference to softwa
On Mon, Oct 25, 2004 at 11:46:03PM +0100, Matthew Garrett wrote:
> I see nothing that suggests that "non-free component" is only meant to
> apply to material shipped by Debian. Nor is there any suggestion that it
> applies only to software (which is unsurprising, given the care taken to
> remove al
On Mon, Oct 25, 2004 at 11:46:03PM +0100, Matthew Garrett wrote:
> Oh, come off it. The social contract says:
>
> "We provide the guidelines that we use to determine if a work is "free"
> in the document entitled "The Debian Free Software Guidelines". We
> promise that the Debian system and all it
Glenn Maynard <[EMAIL PROTECTED]> wrote:
> Fundamentally, if I can say "apt-get install driver" and have the driver
> work (at least for some hardware), it's main; if I have to first track
> down and install some non-free pieces, it's contrib. This "but it's not
> the driver that needs it, the dr
On Mon, Oct 25, 2004 at 02:23:52PM -0700, Ken Arromdee wrote:
> And if the device has an eprom, then "for the driver to work, you have to find
> and install an eprom containing a copy of the code". (The eprom is harder to
> lose, of course, so it's *usually* already installed, but it's not clear t
On Mon, 25 Oct 2004, Brian Thomas Sniffen wrote:
> > And that is a functional difference: in one case the owner of the
> > device who has downloaded some Debian software has to go get some
> > other software and load it onto his machine; in the other case he
> > doesn't.
On Mon, Oct 25, 2004 at 02
On Mon, Oct 25, 2004 at 02:23:52PM -0700, Ken Arromdee wrote:
> And if the device has an eprom, then "for the driver to work, you have to find
> and install an eprom containing a copy of the code".
Which device is this?
> (The eprom is harder to lose, of course, so it's *usually* already
> instal
On Mon, 25 Oct 2004, Josh Triplett wrote:
> 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,
On Mon, 25 Oct 2004, Brian Thomas Sniffen wrote:
> And that is a functional difference: in one case the owner of the
> device who has downloaded some Debian software has to go get some
> other software and load it onto his machine; in the other case he
> doesn't.
That's not a functional difference
On Mon, 25 Oct 2004, Glenn Maynard wrote:
> The driver is opening a block of data on disk, reading it and sending it
> to the hardware. If that data does not exist, the driver will be
> incapable of driving the hardware. For the driver to work, in addition
> to installing it and the hardware devi
Marco d'Itri wrote:
> [EMAIL PROTECTED] 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
fun
On Mon, 2004-10-25 at 14:51 -0400, Brian Thomas Sniffen wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
> > There's no interesting functional difference between these two things,
> > except that in one case the driver has to make a call to load the
> > firmware and in the other case it doesn't
Matthew Garrett <[EMAIL PROTECTED]> writes:
> Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
>> Matthew Garrett <[EMAIL PROTECTED]> writes:
>>
>>> Regardless of whether this dependency is expressed in our package
>>> management system, most drivers depend on non-free firmware.
>>
>> They depen
On Mon, Oct 25, 2004 at 11:44:37AM +0200, Marco d'Itri 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".
The driver is opening a block of data on disk, reading it and
Raul Miller <[EMAIL PROTECTED]> wrote:
>> Raul Miller <[EMAIL PROTECTED]> wrote:
>> > And, if that seems nonsensical to you, you're right -- or, at least,
>> > that scenario seems rather nonsensical to me. Debian currently doesn't
>> > represent the kind of market which could lead to this kind of
> Raul Miller <[EMAIL PROTECTED]> wrote:
> > And, if that seems nonsensical to you, you're right -- or, at least,
> > that scenario seems rather nonsensical to me. Debian currently doesn't
> > represent the kind of market which could lead to this kind of situation.
On Mon, Oct 25, 2004 at 05:44:3
Brian Thomas Sniffen <[EMAIL PROTECTED]> wrote:
> Matthew Garrett <[EMAIL PROTECTED]> writes:
>
>> Regardless of whether this dependency is expressed in our package
>> management system, most drivers depend on non-free firmware.
>
> They depend on the presence of appropriate and properly functio
On Mon, Oct 25, 2004 at 04:43:50PM +0200, Marco d'Itri wrote:
> >> Please repeat after me: "drivers do not require firmwares, hardware
> >> devices require firmwares".
> >Then, how do you explain the ipw2200 case where driver version 0.5 and
> >less will only work with a certain firmware and versio
Matthew Garrett <[EMAIL PROTECTED]> writes:
> Regardless of whether this dependency is expressed in our package
> management system, most drivers depend on non-free firmware.
They depend on the presence of appropriate and properly functioning
devices, which are typically implemented using non-fr
Ken Arromdee <[EMAIL PROTECTED]> writes:
> On Mon, 25 Oct 2004, Brian Thomas Sniffen wrote:
>> >> > The person who has the device doesn't neceessarily have the firmware,
>> >> > because
>> >> > the firmware can be removed.
>> >> The person doesn't have the device at that point -- only part of it.
Raul Miller <[EMAIL PROTECTED]> wrote:
> That quip was a comment on the straw-man scenario where hardware vendors
> were redesigning their products to move a driver for that hardware from
> debian contrib to main.
>
> And, if that seems nonsensical to you, you're right -- or, at least,
> that sce
1 - 100 of 214 matches
Mail list logo
