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
Michael Poole [EMAIL PROTECTED] writes:
Brian Thomas Sniffen writes:
But the functionality of the driver is a function of the functionality
of the device.
The functionality of a program is a function of the functionality of
the compiler that compiles it
And Debian requires that its
Marco d'Itri [EMAIL PROTECTED] writes:
[EMAIL PROTECTED] wrote:
These two cases are well different: the first driver already contains
all code needed to manage the hardware device (even if it chooses to not
send some commends to the device until it will be ready to process them),
in the
On Tue, Oct 26, 2004 at 11:43:56PM -0400, Brian Thomas Sniffen wrote:
But the functionality of the driver is a function of the functionality
of the device.
Why do you keep replying without quoting? It's even more annoying than
top-posting.
--
Glenn Maynard
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This did work. Mouse told me that Blockade is public domain,
which I would translate to BSD license. AFAIK this license
allows me to do whatever I like with the sources.
Question: Am I allowed to copy-n-paste some BSD license header
into his sources
[EMAIL PROTECTED] wrote:
No, this is again wrong: a program and the libraries it use are a single
entity (why do you think it's called linking?) while drivers and devices
are different entities.
They interact the same way IM clients and servers interact.
From the point of view of userspace, a
[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
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
Brian Thomas Sniffen writes:
But the functionality of the driver is a function of the functionality
of the device.
The functionality of a program is a function of the functionality of
the compiler that compiles
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
Michael Poole [EMAIL PROTECTED] writes:
And the CPU is hardware, so not covered by the DFSoftwareG.
Is the device you mentioned not hardware?
The device is hardware. The software uploaded to control it, from a
file on disk, is software.
These are not a useful observations.
On the
On Wed, Oct 27, 2004 at 08:05:34AM -0400, Michael Poole wrote:
They are useful only for people who agree with you about certain
premises.
This sentence is true of all communication.
The premises typically being the definitions of the words used.
Examples: the firmware is software rather than
Brian Thomas Sniffen writes:
Michael Poole [EMAIL PROTECTED] writes:
And the CPU is hardware, so not covered by the DFSoftwareG.
Is the device you mentioned not hardware?
The device is hardware. The software uploaded to control it, from a
file on disk, is software.
Even granting
[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
Harald Dunkel wrote:
This did work. Mouse told me that Blockade is public domain,
which I would translate to BSD license. AFAIK this license
allows me to do whatever I like with the sources.
Public domain has a specific legal meaning, and it isn't under the
BSD license. Public domain means
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
Glenn Maynard [EMAIL PROTECTED] writes:
On Tue, Oct 26, 2004 at 11:43:56PM -0400, Brian Thomas Sniffen wrote:
But the functionality of the driver is a function of the functionality
of the device.
Why do you keep replying without quoting? It's even more annoying than
top-posting.
Parsing
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Josh Triplett wrote:
| Harald Dunkel wrote:
|
|This did work. Mouse told me that Blockade is public domain,
|which I would translate to BSD license. AFAIK this license
|allows me to do whatever I like with the sources.
|
|
| Public domain has a
Raul Miller writes:
Another premise which would work better is that firmware is somewhere
between hardware and software and that there are circumstances where it
makes sense to treat firmware as hardware and other circumstances where
it makes sense to treat firmware as software. I feel that
Another premise which would work better is that firmware is somewhere
between hardware and software and that there are circumstances where it
makes sense to treat firmware as hardware and other circumstances where
it makes sense to treat firmware as software. I feel that this premise
is
[No need to CC me; I'm subscribed.]
Harald Dunkel wrote:
Next question: Blockade contains a lot of game levels generated
by a lot of people. I have to assume that the included list
of contributors is complete.
That's generally a reasonable assumption, unless there is evidence to
the contrary.
On Wed, Oct 27, 2004 at 09:45:29AM -0400, Michael Poole wrote:
Even granting that, it does not establish a very clear dependency
chain from the firmware to the driver. Is the driver case different
from the various network clients (AIM, Exchange, etc.) in Debian with
no server implementations
Raul Miller [EMAIL PROTECTED] wrote:
It seems clear to me that the distinction here is whether we
treat the firmware in question as software or hardware.
The firmware that we are talking about is, in every case I've actually
investigated, a set of instructions that are carried out by something
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
Raul Miller [EMAIL PROTECTED] wrote:
It seems clear to me that the distinction here is whether we
treat the firmware in question as software or hardware.
On Thu, Oct 28, 2004 at 12:32:22AM +0100, Matthew Garrett wrote:
The firmware that we are talking about is, in every case I've actually
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
32 matches
Mail list logo
