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
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 Debian don't
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
the use of
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
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, the
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, Matthew
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. We can't
[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
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 clear that you
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 function. An
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
[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 who fail
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
[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 not
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 you should
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, either.
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 as part of the
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
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 drivers in
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 udebs for
things
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
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 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 in the
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 need to
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 meant
[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
software).
[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 hardware
[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 with a certain
[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 data on
[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
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 FPGA design is
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 anything
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 know the
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 around
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 operates as designed
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't
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:39:03PM
[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:
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 require non-free
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 this?
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. That
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 current
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
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
live up
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 Tue, Oct 26,
[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:
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,
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 depend than 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
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
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 is the
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 possible
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.
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, thank you for
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, while others are
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 Poole
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, 2004 at
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 unsurprising,
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 their
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.
That's
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
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 believe
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 should
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
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 that the
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 firmware in
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
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 me
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 does
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
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 discussing
On Sun, Oct 24, 2004 at 10:59:50PM +0100, Matthew Garrett wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote:
Is this the case even if the firmware is in a flash chip attached to the
device? If the total amount of non-free software
On Sun, Oct 24, 2004 at 10:45:18PM -0700, Steve Langasek wrote:
Ok, I guess somewhere I lost track of exactly what was being argued in this
thread. I agree, if the user (or some group of users to whom the driver is
useful) already have the required firmware, either in the device's flash or
on
On Sun, Oct 24, 2004 at 10:45:18PM -0700, Steve Langasek wrote:
Ok, I guess somewhere I lost track of exactly what was being argued in this
thread. I agree, if the user (or some group of users to whom the driver is
useful) already have the required firmware, either in the device's flash or
on
Glenn Maynard [EMAIL PROTECTED] wrote:
I don't understand how there's any disagreement in this case: it's clearly
software, covered by the DFSG (or at least the one Debian will be using
soon), it's required (a Depends), and clearly non-free.
On the other hand, if it's clearly software when
[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.
--
ciao,
Marco
[EMAIL PROTECTED] wrote:
The total amount of non-free software on a user's system is different if the
firmware comes pre-loaded on the device than if we have to load it from the
OS, isn't it?
No.
--
ciao,
Marco
Ken Arromdee [EMAIL PROTECTED] writes:
On Sun, 24 Oct 2004, Raul Miller 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.
The same reasoning applies for
Matthew Garrett [EMAIL PROTECTED] writes:
Glenn Maynard [EMAIL PROTECTED] wrote:
I don't understand how there's any disagreement in this case: it's clearly
software, covered by the DFSG (or at least the one Debian will be using
soon), it's required (a Depends), and clearly non-free.
On the
Marco d'Itri [EMAIL PROTECTED] writes:
[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.
And the driver requires a functioning hardware device. Thus,
[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.
And the driver requires a functioning hardware device. Thus, the
This is not an use of the verb require
[EMAIL PROTECTED] wrote:
On the other hand, if it's clearly software when it's on CD then it's
clearly software when it's on eeprom.
False. That's why we call it firmware, not just software living on a device.
Get real. Software does not change its nature depending on the media
it's stored on.
Brian Thomas Sniffen [EMAIL PROTECTED]:
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.
And the driver requires a functioning hardware device. Thus, the
loadable firmware
On Mon, Oct 25, 2004 at 11:44:37AM +0200, 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.
Then, how do you explain the ipw2200
On Mon, Oct 25, 2004 at 01:18:18PM +0200, Marco d'Itri wrote:
Get real. Software does not change its nature depending on the media
it's stored on.
Some aspects do change. But it's true that what a person thinks about
that software doesn't need to change (depending on the person doing the
On Mon, 2004-10-25 at 07:07 -0400, Brian Thomas Sniffen wrote:
Matthew Garrett [EMAIL PROTECTED] writes:
On the other hand, if it's clearly software when it's on CD then it's
clearly software when it's on eeprom.
False. That's why we call it firmware, not just software living on a
On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote:
Brian, we are talking about identical code.
Are we?
Software doesn't stop being software if it's burned into a ROM instead
of being supplied with the OS.
It does, however, cease to be a dependency issue if those who have the
Raul Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote:
Brian, we are talking about identical code.
Are we?
In many contexts, yes.
Software doesn't stop being software if it's burned into a ROM instead
of being supplied with the OS.
It
Raul Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 12:52:19PM +0100, Matthew Garrett wrote:
Brian, we are talking about identical code.
Are we?
In many contexts, yes.
Software doesn't stop being software if it's burned into a ROM instead
of being supplied with the OS.
It
On Mon, Oct 25, 2004 at 02:21:03PM +0100, Matthew Garrett wrote:
Whichever argument you're using, it leads to the following situation. A
vendor releases a piece of hardware. It requires run-time loadable
firmware. We put the driver in contrib. A customer comes to the vendor
and asks for a
Raul Miller [EMAIL PROTECTED] wrote:
On Mon, Oct 25, 2004 at 02:21:03PM +0100, Matthew Garrett wrote:
Does this not strike you as mad? We make a distinction between main and
contrib because we want to discourage non-free code. The distinction
you're drawing instead merely encourages vendors to
[EMAIL PROTECTED] wrote:
Oh, wait, maybe you're suggesting that they had some OTHER reason for
putting those bits in rom? If that's the case, your claim that it
doesn't help our users is a bit specious.
It's not obvious that this would be an improvement which benefits users.
--
ciao,
Marco
[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.
Then, how do you explain the ipw2200 case where driver version 0.5 and
less will only work with a
Matthew Garrett [EMAIL PROTECTED] writes:
On Mon, 2004-10-25 at 07:07 -0400, Brian Thomas Sniffen wrote:
Matthew Garrett [EMAIL PROTECTED] writes:
On the other hand, if it's clearly software when it's on CD then it's
clearly software when it's on eeprom.
False. That's why we call it
On Mon, 25 Oct 2004, Matthew Garrett wrote:
The reason we don't include free software that has non-free
dependencies in main is that we want to discourage people from using
non-free software. If the user already has non-free code in ROM,
then there is the same amount of non-free software being
Marco d'Itri [EMAIL PROTECTED] writes:
[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.
And the driver requires a functioning hardware device. Thus,
Edmund GRIMLEY EVANS [EMAIL PROTECTED] writes:
Brian Thomas Sniffen [EMAIL PROTECTED]:
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.
And the driver requires a
On Sun, Oct 24, 2004 at 10:59:50PM +0100, Matthew Garrett wrote:
Steve Langasek [EMAIL PROTECTED] wrote:
On Sun, Oct 24, 2004 at 03:41:13AM +0100, Matthew Garrett wrote:
Is this the case even if the firmware is in a flash chip attached to the
device? If the total amount of non-free software
On Oct 25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Marco d'Itri [EMAIL PROTECTED] writes:
[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.
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Oct 25, Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Marco d'Itri [EMAIL PROTECTED] writes:
[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
1 - 100 of 207 matches
Mail list logo
