On Sun, Jan 09, 2005 at 06:11:54PM +0100, Miguel Gea Milvaques wrote:
This is the same point. You are going to care very much abut *which*
firmware are you loading on your driver.
The firmware used by a NIC driver, on the other hand, has no
user-visible content; certainly it has no
even in cases where it *is* documented, this is not by any
stretch of the imagination a typical use case.
[Peter 'p2' De Schrijver]
That's not true. Firmware can created by anyone and requires only
documentation and a compiler/linker for the target processor. In many
cases the CPU
* Raul Miller
| On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote:
| However, if somebody writes a graphviz-client which just pushes the
| dot file over the network to graphviz.example.com on some port and
| gets a postscript file back, it can go into main. No matter what
|
On Sun, 9 Jan 2005 22:01:52 -0800, Steve Langasek [EMAIL PROTECTED] wrote:
It is not enough to say that you *could* create free firmware files. As a
user of xpdf, I can unequivocally say that there are pdfs that I have full
rights to, because *I created them*. I cannot say that about firmware
Tollef Fog Heen [EMAIL PROTECTED] writes:
| This is a canonical example of a network-downloader package.
No, they download something and unpacks it on a file system. They
don't feed the data they download into some device.
So you think the key difference is whether the data downloaded
Michael Poole [EMAIL PROTECTED] writes:
Thomas Bushnell BSG writes:
Tollef Fog Heen [EMAIL PROTECTED] writes:
| This is a canonical example of a network-downloader package.
No, they download something and unpacks it on a file system. They
don't feed the data they download
On Jan 08, Josh Triplett [EMAIL PROTECTED] wrote:
atmel-firmware . Would you argue that at76c503a-source should neither
Depends: nor Recommends: atmel-firmware ? If so, why? If you changed
Yes. Read the debian-legal@ archive if you care about the details.
--
ciao,
Marco
signature.asc
On Sun, 09 Jan 2005, Marco d'Itri wrote:
On Jan 08, Josh Triplett [EMAIL PROTECTED] wrote:
atmel-firmware . Would you argue that at76c503a-source should neither
Depends: nor Recommends: atmel-firmware ? If so, why? If you changed
Yes. Read the debian-legal@ archive if you care about the
Hello,
I don't undestand why software loading files (as we are talking) must be
in contrib. An example: xpdf, if you have not a pdf file you could not
use it, only it gave us a blank page. You could read a lot of different
files, a free pdf files or a non-free pdf files, and xpdf we never thing
to
su, 2005-01-09 kello 16:52 +0100, Miguel Gea Milvaques kirjoitti:
Then if software as xpdf could be in main, software loading firmware
must be in main.
Without commenting on the issue otherwise: This is not a working
analogy. xpdf can load any PDF file. Device drivers can, typically, only
load
[Miguel Gea Milvaques]
I don't undestand why software loading files (as we are talking) must
be in contrib. An example: xpdf, if you have not a pdf file you could
not use it, only it gave us a blank page. You could read a lot of
different files, a free pdf files or a non-free pdf files, and
El dg 09 de 01 del 2005 a les 10:39 -0600, en/na Peter Samuelson va
escriure:
[Miguel Gea Milvaques]
I don't undestand why software loading files (as we are talking) must
be in contrib. An example: xpdf, if you have not a pdf file you could
not use it, only it gave us a blank page. You
On Sun, Jan 09, 2005 at 04:52:40PM +0100, Miguel Gea Milvaques wrote:
Hello,
I don't undestand why software loading files (as we are talking) must be
in contrib. An example: xpdf, if you have not a pdf file you could not
use it, only it gave us a blank page. You could read a lot of different
Firmware files are not the sort of thing people can create their own
versions of. In most cases the format is not documented and there
are no free or even publicly available tools for this, and even in
cases where it *is* documented, this is not by any stretch of the
On Jan 07, Josh Triplett [EMAIL PROTECTED] wrote:
I'll assume for the moment you are only disagreeing with the
driver-firmware dependencies, not the client-server dependencies,
since the latter is standard Debian policy.
No. What I'm saying is that if you stretch the definition of
requirement
Marco d'Itri wrote:
On Jan 07, Josh Triplett [EMAIL PROTECTED] wrote:
I'll assume for the moment you are only disagreeing with the
driver-firmware dependencies, not the client-server dependencies,
since the latter is standard Debian policy.
No. What I'm saying is that if you stretch the
Brian Thomas Sniffen wrote:
So would a web-based firmware loader, that never saved the firmware to
disk allow the drivers to be in main?
Of course not. It's fetching software, then using that software. ICQ
software merely mentions messages, but doesn't use them.
ICQ uses the messages as
Raul Miller wrote:
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
The social contract says ...but we will never make the system depend on
an item of non-free software. not but we will never make the system
depend on an item of non-free software /which we must distribute/.
Josh Triplett wrote:
I would like to suggest an additional option, which I think covers most
cases quite well:
If Debian were to package (a copy of) the non-free item in the non-free
section, would the Free package express a Depends, Recommends, or
Build-Depends on the non-free package? If so,
Anthony DeRobertis [EMAIL PROTECTED] writes:
So would a web-based firmware loader, that never saved the firmware to
disk allow the drivers to be in main?
Of course not. It's fetching software, then using that software.
ICQ software merely mentions messages, but doesn't use them.
ICQ uses the
On Thu, Jan 06, 2005 at 01:54:19PM -0500, Brian Thomas Sniffen wrote:
aren't equivalent. The issue at hand is whether somebody might ever
download software from Debian and find it useless without additional
software which he could download... but not from Debian, since it's
not Free and not
[Please keep either debian-legal or myself in the CC list; I'm not
subscribed to debian-devel.]
Anthony DeRobertis wrote:
Brian Thomas Sniffen wrote:
So would a web-based firmware loader, that never saved the firmware to
disk allow the drivers to be in main?
Of course not. It's fetching
On Jan 06, Josh Triplett [EMAIL PROTECTED] wrote:
An ICQ client wouldn't Depends: icq-server; it might Suggests:
icq-server, but that's OK. A driver might at most Suggests:
burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
Recommends: firmware-loaded-by-driver.
I can't
Marco d'Itri wrote:
On Jan 06, Josh Triplett [EMAIL PROTECTED] wrote:
An ICQ client wouldn't Depends: icq-server; it might Suggests:
icq-server, but that's OK. A driver might at most Suggests:
burned-in-firmware-for-reflashing, but it would Depends: or at a minimum
Recommends:
* Matthew Garrett
| You have argued that drivers don't really depend on firmware, but
| instead depend on the hardware expressing the correct interface. As an
| example, we can compare maria-vis, which depends on the graphviz
| package. maria-vis is in contrib, because it depends on graphviz,
On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote:
However, if somebody writes a graphviz-client which just pushes the
dot file over the network to graphviz.example.com on some port and
gets a postscript file back, it can go into main. No matter what
software said server is
Raul Miller writes:
On Wed, Jan 05, 2005 at 10:16:25AM +0100, Tollef Fog Heen wrote:
However, if somebody writes a graphviz-client which just pushes the
dot file over the network to graphviz.example.com on some port and
gets a postscript file back, it can go into main. No matter what
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Hamish Moffatt [EMAIL PROTECTED] writes:
So if EEPROMs contain software, why don't [you] get to distribute any
drivers? I don't understand.
You can get software out of an firmware-EEPROM on a hardware device.
I don't think it's appropriate to
I demand that Glenn Maynard may or may not have written...
On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
[fetching firmware on finding hardware which needs it: wget or packaged?]
Fetch every time and fetch once. That looks like a difference to me...
How could fetch every time
On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote:
On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
[fetching firmware on finding hardware which needs it: wget or packaged?]
Fetch every time and fetch once. That looks like a difference to me...
How could fetch every
I demand that Glenn Maynard may or may not have written...
On Tue, Jan 04, 2005 at 06:22:20PM +, Darren Salt wrote:
On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
[fetching firmware on finding hardware which needs it: wget or packaged?]
Fetch every time and fetch once. That
Scripsit Thomas Bushnell BSG [EMAIL PROTECTED]
Matthew Garrett [EMAIL PROTECTED] writes:
The obvious thing to do here is not to attempt to find a way that
we can interpret the SC that makes sense - the obvious thing to do
here is to decide what we want the SC to say and then change it so
I demand that Josh Triplett may or may not have written...
[snip]
This criteria covers
These criteria cover, surely - unless you mean criterion :-\
--
| Darren Salt | linux (or ds) at | nr. Ashington,
| woody, sarge, | youmustbejoking | Northumberland
| RISC OS | demon co uk |
I demand that Måns Rullgård may or may not have written...
Anthony DeRobertis [EMAIL PROTECTED] writes:
Henning Makholm wrote:
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
That would, however, cover firmware and wind up sending X to contrib. So
maybe: ... iff it is stored on the local
On Mon, Jan 03, 2005 at 05:42:07PM +, Darren Salt wrote:
Anthony DeRobertis [EMAIL PROTECTED] writes:
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
That would, however, cover firmware and wind up sending X to contrib. So
maybe: ... iff it is stored on the local machine's file system.
I demand that Glenn Maynard may or may not have written...
On Mon, Jan 03, 2005 at 05:42:07PM +, Darren Salt wrote:
Anthony DeRobertis [EMAIL PROTECTED] writes:
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
That would, however, cover firmware and wind up sending X to contrib.
So maybe:
On Tue, Jan 04, 2005 at 01:48:12AM +, Darren Salt wrote:
Fetch every time and fetch once. That looks like a difference to me...
How could fetch every time possibly be acceptable to the SC when
fetch once is not? Are you saying that the rancid-installer package
could go in main, if it
On Fri, Dec 31, 2004 at 05:02:15PM -0500, Anthony DeRobertis wrote:
The social contract says ...but we will never make the system depend on
an item of non-free software. not but we will never make the system
depend on an item of non-free software /which we must distribute/.
We don't make the
Anthony DeRobertis [EMAIL PROTECTED] writes:
Henning Makholm wrote:
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
That would, however, cover firmware and wind up sending X to
contrib. So maybe: ... iff it is stored on the local machine's file
system.
That would be my *intuitive* understanding
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote:
Hamish Moffatt dijo [Tue, Dec 28, 2004 at 04:26:26PM +1100]:
Yet the ICQ client is not useful without a component which is not in
Debian and in fact is not freely available.
If the emulators were extended to be able to fetch
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
Henning Makholm wrote:
Scripsit Anthony DeRobertis [EMAIL PROTECTED]
That would, however, cover firmware and wind up sending X to
contrib. So maybe: ... iff it is stored on the local machine's file
system.
That would be my *intuitive*
On Thu, Dec 30, 2004 at 03:09:52PM -0600, Gunnar Wolf wrote:
The blobs for the in-kernel drivers are not to be executed by the host
CPU itself, neither is the non-free ICQ, MSN or Yahoo servers
(although Gaim can be seen useful by itself as it works with IRC and
Jabber... Well, brain, please
Anthony DeRobertis wrote:
The social contract says ...but we will never make the system depend on
an item of non-free software. not but we will never make the system
depend on an item of non-free software /which we must distribute/.
In order to allow the vast majority of hardware which
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
Please suggest any case which you don't think this criteria adequately
covers.
The bios.
Unless, we decide that the bios we put in non-free isn't the bios we
need to boot the machine.
--
Raul
Scripsit Raul Miller [EMAIL PROTECTED]
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
Please suggest any case which you don't think this criteria adequately
covers.
The bios.
Unless, we decide that the bios we put in non-free isn't the bios we
need to boot the machine.
On
Henning Makholm [EMAIL PROTECTED] writes:
Scripsit Raul Miller [EMAIL PROTECTED]
On Sat, Jan 01, 2005 at 11:33:21AM -0800, Josh Triplett wrote:
Please suggest any case which you don't think this criteria adequately
covers.
The bios.
Unless, we decide that the bios we put in non-free isn't
On Sun, Jan 02, 2005 at 01:27:21AM +0100, Måns Rullgård wrote:
Some Alpha systems (I forgot which) came with only the inferior
AlphaBIOS installed in flash. Later, an SRM version for this system
was released, and installing this is generally considered a good
thing. These firmwares
Matthew Garrett [EMAIL PROTECTED] writes:
The parsimonious explanation is that the issue wasn't thought about in
that much detail when the social contract was written. The archives tend
to support this. The obvious thing to do here is not to attempt to find
a way that we can interpret the SC
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
And now you consider it software just because the method of storage is
different? How can the nature of the bytes change because they are
stored on a disk?
The nature of the bytes do not change. But my name, distributed in a
On Fri, Dec 17, 2004 at 09:53:51AM +0100, Peter Van Eynde wrote:
I'm stunned. So anything in a Debian package is software. With alien I can
convert a tar.gz into a debian package, so all tar files are software. With
tar I can create a tar.gz from any file, so all electronic data is software?
Brian Thomas Sniffen wrote:
Some firmware is part of the hardware. Some isn't. It's easy to tell
-- either it's in the hardware or it isn't. Of course, the name
firmware should make it clear that this is an often ambiguous line.
But this does seem to be a good practical place: can anybody with
Raul Miller wrote:
Fundamentally, the DFSG is aimed at making sure that we can provide the
software that we can support. Restrictions that leave us writing an
opaque blob of bits which drives an unknown API very much put us into
a context where we can't know that we're doing the right thing.
The
Matthew Palmer wrote:
Should I go on?
No, I think you've adequately demonstrated that you don't have the foggiest
idea what you're talking about.
Ok. I'm game. Why? Where is the error my in applying your rules?
Groetjes, Peter
On Fri, Dec 17, 2004 at 10:45:07AM +0100, Peter Van Eynde wrote:
Matthew Palmer wrote:
Should I go on?
No, I think you've adequately demonstrated that you don't have the foggiest
idea what you're talking about.
Ok. I'm game. Why? Where is the error my in applying your rules?
Primary
* Peter Van Eynde
| Architectural plans for a house, shipped in a Debian package, are
| software.
|
| I'm stunned. So anything in a Debian package is software. With alien I
| can convert a tar.gz into a debian package, so all tar files are
| software. With tar I can create a tar.gz from any
Peter Van Eynde [EMAIL PROTECTED] writes:
Brian Thomas Sniffen wrote:
Some firmware is part of the hardware. Some isn't. It's easy to tell
-- either it's in the hardware or it isn't. Of course, the name
firmware should make it clear that this is an often ambiguous line.
But this does seem
Peter Van Eynde [EMAIL PROTECTED] writes:
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
And now you consider it software just because the method of storage is
different? How can the nature of the bytes change because they are
stored on a disk?
The nature of the bytes do
Brian Thomas Sniffen [EMAIL PROTECTED] wrote:
Please at least read Policy on what Depends means first. If you
also read the archives, you'll have a chance at understanding the
position of other debaters here, and of generating original
arguments. So far, this is all a repeat. It wasn't
Raul Miller wrote:
Fundamentally, the DFSG is aimed at making sure that we can provide the
software that we can support. Restrictions that leave us writing an
opaque blob of bits which drives an unknown API very much put us into
a context where we can't know that we're doing the right
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
Is your name input for a state-machine?
You should see what it does to TECO. My name is a killing word.
:-)
[data == software ?]
Bingo. Debian had this debate last year. There was a giant vote over
it. Then another debate
Raul Miller wrote:
On Fri, Dec 17, 2004 at 10:39:26AM +0100, Peter Van Eynde wrote:
The API is known, otherwise there would be no Linux driver.
The API that is programmed by the firmware -- which you shouldn't confuse
with the API used by the driver that downloads the firmware -- is not
known to
Raul Miller wrote:
The API that is programmed by the firmware -- which you shouldn't confuse
with the API used by the driver that downloads the firmware -- is not
known to us.
On Fri, Dec 17, 2004 at 03:51:22PM +0100, Peter Van Eynde wrote:
I don't understand you.
Hmm...
An API is not
On Fri, Dec 17, 2004 at 10:33:41AM -0500, I clumsily wrote:
I was talking about the API the firmware uses -- the one that the program
contained in the API was designed to work with.
That should have read:
I was talking about the API the firmware uses -- the one that the program
contained in
Brian Thomas Sniffen [EMAIL PROTECTED] writes:
Peter Van Eynde [EMAIL PROTECTED] writes:
Brian Thomas Sniffen wrote:
Architectural plans for a house, shipped in a Debian package, are
software.
I'm stunned. So anything in a Debian package is software. With alien I
can convert a tar.gz into
On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote:
No, a definition of software was never decided upon. The vote was
about removing the word software in certain places from the DFSG,
regardless of its definition.
However, the S in DFSG means software; the SC was adjusted to say
On Fri, Dec 17, 2004 at 03:23:54PM +0100, Peter Van Eynde wrote:
Hmm. I remember we had an editorial change that then turned into
something completely different, followed by 6 damage limitation options and
1 hard line option. A damage limitation option won, but I if I read the
matrix
Peter Van Eynde wrote:
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
[data == software ?]
Bingo. Debian had this debate last year. There was a giant vote over
it. Then another debate and another vote.
Hmm. I remember we had an editorial change that then turned
Glenn Maynard [EMAIL PROTECTED] writes:
On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote:
No, a definition of software was never decided upon. The vote was
about removing the word software in certain places from the DFSG,
regardless of its definition.
However, the S in DFSG
On Fri, Dec 17, 2004 at 11:36:09PM +0100, Måns Rullgård wrote:
To me, that seems much like arguing that because an emulator (such as
one for a console system) provides a GUI, and because it can run and
display that GUI without needing a ROM, the emulator should go to main.
I don't believe
On Fri, 17 Dec 2004 09:53:51 +0100, Peter Van Eynde [EMAIL PROTECTED] said:
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
And now you consider it software just because the method of
storage is different? How can the nature of the bytes change
because they are stored
On Fri, 17 Dec 2004 14:52:56 -0800, Brian Nelson [EMAIL PROTECTED] said:
Glenn Maynard [EMAIL PROTECTED] writes:
On Fri, Dec 17, 2004 at 11:07:31AM -0800, Brian Nelson wrote:
No, a definition of software was never decided upon. The vote
was about removing the word software in certain places
On Fri, 17 Dec 2004 15:23:54 +0100, Peter Van Eynde [EMAIL PROTECTED] said:
Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
Is your name input for a state-machine?
You should see what it does to TECO. My name is a killing word.
:-)
[data == software ?]
Bingo.
Glenn Maynard [EMAIL PROTECTED] writes:
On Fri, Dec 17, 2004 at 11:36:09PM +0100, Måns Rullgård wrote:
To me, that seems much like arguing that because an emulator (such as
one for a console system) provides a GUI, and because it can run and
display that GUI without needing a ROM, the
On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote:
I'm convinced enough. Some time ago, I was playing around with an
emulator for Texas Instruments calculators. It obviously required a
ROM image to be useful, and the only legal way of obtaining one was
dumping it from your
Peter Van Eynde [EMAIL PROTECTED] writes:
I think I'm starting to understand your point of view. So _any_ use of
the software without using non-DFSG data makes it free, right?
Any reasonable use. Printing out a firmware not found message
doesn't count!
But what if loading the firmware is
Glenn Maynard [EMAIL PROTECTED] writes:
On Sat, Dec 18, 2004 at 01:28:46AM +0100, Måns Rullgård wrote:
I'm convinced enough. Some time ago, I was playing around with an
emulator for Texas Instruments calculators. It obviously required a
ROM image to be useful, and the only legal way of
hoi :)
On Sat, Dec 11, 2004 at 05:49:26PM -0500, Glenn Maynard wrote:
If the driver has to be able to open the file and read the blob so it
can send it to the device, there's a clear relationship and dependency
between the driver and the blob: if you don't have a copy of the blob,
the driver
hoi :)
On Sun, Dec 12, 2004 at 12:57:09AM +0100, Goswin von Brederlow wrote:
Would you accept a patch for ppp of the form:
char data[] = { 0x17, 0x23, 0x42, ...};
...
*(int (*)(int))data(fd);
After all, it is just data.
No, because these bytes are executed on the system CPU
Martin Waitz [EMAIL PROTECTED] writes:
hoi :)
On Sun, Dec 12, 2004 at 12:57:09AM +0100, Goswin von Brederlow wrote:
Would you accept a patch for ppp of the form:
char data[] = { 0x17, 0x23, 0x42, ...};
...
*(int (*)(int))data(fd);
After all, it is just data.
No, because these
Martin Waitz [EMAIL PROTECTED] writes:
I have a PCMCIA card that lost its flash memory.
So suddenly its driver became non-free?
No; the hardware is damaged. No driver can drive that. The driver
you have is a driver for Foomatic Quxer cards. You don't have a
Foomatix Quxer; you have a broken
Brian Thomas Sniffen wrote:
No; the hardware is damaged. No driver can drive that. The driver
you have is a driver for Foomatic Quxer cards. You don't have a
Foomatix Quxer; you have a broken pile of junk.
So here you argue that because the firmware is gone the hardware is broken,
correct?
On Thu, Dec 16, 2004 at 02:23:54PM +0100, Martin Waitz wrote:
I have a PCMCIA card that lost its flash memory.
So suddenly its driver became non-free?
Only if all such cards have lost their flash memory, which is improbable.
As long as some cards exist with a working flash, the driver is useful
Peter Van Eynde [EMAIL PROTECTED] writes:
Brian Thomas Sniffen wrote:
No; the hardware is damaged. No driver can drive that. The driver
you have is a driver for Foomatic Quxer cards. You don't have a
Foomatix Quxer; you have a broken pile of junk.
So here you argue that because the
On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote:
Peter Van Eynde [EMAIL PROTECTED] writes:
Brian Thomas Sniffen wrote:
No; the hardware is damaged. No driver can drive that. The driver
you have is a driver for Foomatic Quxer cards. You don't have a
Foomatix
[just some minor additions.]
On Thu, Dec 16, 2004 at 09:20:14PM -0500, Brian Thomas Sniffen wrote:
No, I argue that because you've pried chips off the board, the
hardware is broken.
On Thu, Dec 16, 2004 at 09:39:59PM -0500, Glenn Maynard wrote:
Er, no. Flash can be overwritten with
hoi :)
On Sat, Dec 11, 2004 at 01:45:01PM -0800, Thomas Bushnell BSG wrote:
And why it should be different if that firmware is distributed by the
manufacturer on a CD instead of a flash EPROM chip?
Because in that case the manufacturer is hurting the user by not
providing source, and we
What would you gain by having the firmware source.
Please don't tell me that you want to fix bugs there.
The firmware is part of the hardware and we don't ask the vendors to
give away their .vhdl files of the hardware. Both firmware and hardware
source are useless as they usually need
Goswin von Brederlow writes:
Because the former works after installing the deb without the user
ever doing anything about firmware. How do you even know there is
firmware? Maybe it is all hardcoded into the chip? Without taking the
hardware apart you can't know. Call me ignorant but what I
* Goswin von Brederlow
| I think something like Failure: firmware not loaded or Failure:
| path/firmware: No such file or directory counts as a dependency.
Nobody's said that the driver has to load the firmware. The firmware
might well be loaded by first booting to some other OS, then into
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
How does moving firmware from the disk to the hardware (therefore making
it harder to modify and more expensive) further the cause of free
software?
It makes it covered by the hardware manufacturers warentee. If it is
faulty, you can return
Blars Blarson [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
How does moving firmware from the disk to the hardware (therefore making
it harder to modify and more expensive) further the cause of free
software?
It makes it covered by the hardware manufacturers
Matthew Garrett [EMAIL PROTECTED] wrote:
Blars Blarson [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
How does moving firmware from the disk to the hardware (therefore making
it harder to modify and more expensive) further the cause of free
software?
It
On Mon, Dec 13, 2004 at 12:15:31PM +, Matthew Garrett wrote:
Blars Blarson [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED]
[EMAIL PROTECTED] writes:
How does moving firmware from the disk to the hardware (therefore making
it harder to modify and more expensive) further the cause
Hello Brian,
Am 2004-12-10 17:39:05, schrieb Brian Nelson:
As for whether Debian would actually distribute the firmware blobs in
main, I would prefer that we do. It can be a real pain installing
Debian on a system in which I have to retrieve the firmware from an
external source. It's only
Goswin von Brederlow [EMAIL PROTECTED] wrote:
Tim Cutts [EMAIL PROTECTED] writes:
[...]
It's not the driver software depends on the firmware to function; it's
the hardware that depends on the firmware to function. The software
dependency is a side-effect.
With the driver software loading
El dom, 12-12-2004 a las 00:22 +0100, Goswin von Brederlow escribi:
[...]
Installing non-free firmware taints your filesystem, using AIM does
not.
Taints your filesytem??? Oh, this is more than I expected.
Are you really aware that your computer is plenty of non-freeness? That
the device
El dom, 12-12-2004 a las 04:52 +0100, Goswin von Brederlow escribi:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
Yes. Once you eliminate the dependency on the non-free file the driver
becomes suitable for main.
The
On Sat, Dec 11, 2004 at 01:45:01PM -0800, Thomas Bushnell BSG wrote:
[EMAIL PROTECTED] (Marco d'Itri) writes:
On Dec 11, Goswin von Brederlow [EMAIL PROTECTED] wrote:
Your case of hardware wich already includes firmware is totaly
irelevant since Debian does not distributes hardware,
On Sat, Dec 11, 2004 at 11:50:44AM -0800, Thomas Bushnell BSG wrote:
Brian Nelson [EMAIL PROTECTED] writes:
It's a completely inconsistent and arbitrary policy.
It's hardly that. We distribute only free software, that's our rule.
I thought the post
Jose Carlos Garcia Sogo [EMAIL PROTECTED] writes:
El dom, 12-12-2004 a las 04:52 +0100, Goswin von Brederlow escribió:
Wouter Verhelst [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 12:34:10AM +0100, Goswin von Brederlow wrote:
Yes. Once you eliminate the dependency on the non-free
1 - 100 of 213 matches
Mail list logo
