* Thomas Bushnell BSG
| 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 d
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
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 into some device.
>
> So you think the
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
On Mon, 10 Jan 2005 16:51:07 -0500, Glenn Maynard <[EMAIL PROTECTED]> wrote:
> Again, by this logic, all software in contrib due to non-free library
> dependencies should go in main; after all, they're "useful" for developing
> and testing free reimplementations of those libraries. This is just an
* Thomas Bushnell BSG
| Tollef Fog Heen <[EMAIL PROTECTED]> writes:
|
| > Imagine me having an USB device. The driver opens a network
| > connection to firmware.example.com, sends the device identification
| > string and gets another string. This one is sent to the USB device
| > which then do
On Mon, Jan 10, 2005 at 01:32:26PM -0800, Michael K. Edwards wrote:
> All of them are useful for
> developing and testing free firmware, as advocates of reverse
> engineering have pointed out.
Again, by this logic, all software in contrib due to non-free library
dependencies should go in main; aft
[whoops, hit "Send" instead of "Save Draft"]
> I think the best way to be honest about that is to exclude non-free
> firmware images from the kernel binary and modules themselves but to
> permit loading them from the initrd or the root filesystem. Initrd
> images in main shouldn't contain non-fre
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 firm
Tollef Fog Heen <[EMAIL PROTECTED]> writes:
> Imagine me having an USB device. The driver opens a network
> connection to firmware.example.com, sends the device identification
> string and gets another string. This one is sent to the USB device
> which then does what it's supposed to do.
This i
* 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
| >
>
> And I still don't think anyone could argue that it would be reasonable
> to stick a driver on a Debian CD with a README that says "if you want
> to use this driver, you'll need to write a firmware file for your SCSI
> card. Use the following assembler"
>
I never said the USER HAS to wri
> >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
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 ha
>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
>imagi
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 differen
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. Yo
[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, an
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
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
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 abou
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
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 stretc
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
"requi
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: firmware
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
[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 fe
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 no
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.
>
>
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, the
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/."
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 instruct
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 wha
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 r
* 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, whi
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 on
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 "fet
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 ti
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 appr
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
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 con
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 machi
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 o
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
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 th
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 r
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
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 mach
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
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 whi
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, pleas
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 *intuit
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
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 *intui
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 ma
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
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
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 f
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 RO
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
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" i
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 t
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
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
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"
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 c
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
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 co
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 t
> 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
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 u
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:
> > 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
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 was
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 natur
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 th
* 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
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
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
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 A
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
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:
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
D
[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 i
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
> >>
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
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 usefu
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?
...
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 bro
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 i
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
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 driv
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
> 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
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, an
* 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
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 o
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) furt
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
>>>
1 - 100 of 221 matches
Mail list logo
