Goswin von Brederlow wrote:
[EMAIL PROTECTED] (Nathanael Nerode) writes:
Goswin von Brederlow wrote:
^^
This is wrong. Glenn Maynard?
If it comes down to the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter,
Marco d'Itri wrote:
The reason for this is not only the additional cost of the flash chip,
but also that (good) devices which use flash need to be more complex:
you would have to add a programming device, possibly a dual power supply
to drive it and you would need anyway some intelligent enough
Bruce Perens [EMAIL PROTECTED] wrote:
Certainly there are AVR and ARM chips that do glue-less downloading from
serial FLASH chips at boot time. Atmel sells them, among others.
Reprogramming of the FLASH is done via JPEG and not under the embedded
processor's control.
Bruce, as far as I
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote:
Is a bit of flash or rom that much bigger than ram? Isn't most of the
space in the dongle air or filling material?
Space is space on the board (not to mention the complexity of the board)
as well as three dimenisonal space.
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The manufacturer's concerns regarding the proprietary nature of
information about their device that is below the bus.
2. The fact
Goswin von Brederlow wrote:
If it comes down to the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter, we allow
it aggregated with the rest of the kernel because splitting individual
drivers into contrib is a pain for everyone involved and
Glenn Maynard wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic violation of Debian's principles.
It's not
Hamish Moffatt wrote:
And 4. They're not allowed to by regulations, eg wireless hardware
whose firmware cannot be distributed by FCC rule.
It's not at all clear to me that the type-approval process depends on
security by obscurity in the firmware. Some manufacturers may think it
does, but I
[EMAIL PROTECTED] (Nathanael Nerode) writes:
Goswin von Brederlow wrote:
If it comes down to the driver, on its own, would not be acceptable for
main because it is not functional; but as a practical matter, we allow
it aggregated with the rest of the kernel because splitting individual
drivers
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is a natural
demarcation between our Free
Wouter Verhelst [EMAIL PROTECTED] writes:
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is
On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact, depend on such an item is a pretty
basic
On Dec 12, Bruce Perens [EMAIL PROTECTED] wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is a natural
demarcation between our Free Software and the proprietary hardware
design. It loads an arbitrary
Glenn Maynard [EMAIL PROTECTED] writes:
On Sun, Dec 12, 2004 at 08:53:32AM -0800, Bruce Perens wrote:
contrib exists for software which is free but fails SC#1, we will never
make the system depend on an item of non-free software. Moving something
from contrib to main that does, in fact,
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The manufacturer's concerns regarding the proprietary nature of
On Sun, Dec 12, 2004 at 02:30:51PM +0100, Wouter Verhelst wrote:
Op za, 11-12-2004 te 20:12 -0500, schreef Glenn Maynard:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to
On Sunday 12 Dec 2004 00:43, Bruce Perens wrote:
1. The manufacturer's concerns regarding the proprietary nature of
information about their device that is below the bus.
2. The fact that misprogramming the device at that level can damage the
hardware.
3. They aren't going to want to support
On Sun, 2004-12-12 at 17:37, Matthew Palmer wrote:
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
[..]
There are a number of reasons that a device's firmware won't generally
be opened to us:
1. The
On Mon, Dec 13, 2004 at 10:37:57AM +1100, Matthew Palmer wrote:
On Sun, Dec 12, 2004 at 11:39:30PM +1100, Hamish Moffatt wrote:
And 4. They're not allowed to by regulations, eg wireless hardware
whose firmware cannot be distributed by FCC rule.
I'm pretty sure that FUD got killed last time
On Sun, Dec 12, 2004 at 09:07:55AM -0800, Bruce Perens wrote:
Hamish Moffatt wrote:
I'm going to disagree (violently) here. FLASH costs money, which drives
up costs to consumers directly.
Maybe, maybe not. A lot of the processors come with it on board whether
you want it or not, many of
On Sun, Dec 12, 2004 at 04:09:04AM +0100, Goswin von Brederlow wrote:
Steve McIntyre [EMAIL PROTECTED] writes:
Depends on what you mean by a good hardware design. For example, a
lot of the USB dongles becoming common would be significantly bigger
and/or more expensive if they had to have
Is a driver that loads a BLOB Free Software? The problem is connected
with distribution. The BLOB is unquestionably software. It runs below
the bus, which is our usual demarcation between Free Software
and the rest of the system, but it starts life above the bus at boot
time, and we have to
Bruce Perens [EMAIL PROTECTED] wrote:
Is a driver that loads a BLOB Free Software? The problem is connected
with distribution. The BLOB is unquestionably software. It runs below
the bus, which is our /usual /demarcation between Free Software and the
rest of the system, but it starts life
Bruce Perens wrote:
A good hardware design would put this code in FLASH on the board.
Depends on what you mean by a good hardware design. For example, a
lot of the USB dongles becoming common would be significantly bigger
and/or more expensive if they had to have sufficient space on-board
for a
On Sat, Dec 11, 2004 at 04:43:48PM -0800, Bruce Perens wrote:
What about the rest of the driver? I think that if you remove the BLOB,
it's Free Software. It talks to a bus interface, which is a natural
demarcation between our Free Software and the proprietary hardware
design. It loads an
Glenn Maynard wrote:
It's free, but it has a non-optional dependency on non-free software, which
means contrib, not main.
In the case of a device driver, that dependency would still be there if
the firmware was in ROM. Which would put pretty much all of our device
drivers, X (talks to VESA
On Sat, Dec 11, 2004 at 05:52:36PM -0800, Bruce Perens wrote:
In the case of a device driver, that dependency would still be there if
the firmware was in ROM. Which would put pretty much all of our device
drivers, X (talks to VESA code), APM and ACPI (talks to BIOS), and so
on, in contrib
Bruce Perens [EMAIL PROTECTED] writes:
Is a driver that loads a BLOB Free Software? The problem is
connected with distribution. The BLOB is unquestionably software. It
runs below the bus,
Yes, I would agree that a non software blob is so unlikely that we can
rule it out. If it is non-software
Bruce Perens [EMAIL PROTECTED] writes:
Glenn Maynard wrote:
It's free, but it has a non-optional dependency on non-free software, which
means contrib, not main.
In the case of a device driver, that dependency would still be there
if the firmware was in ROM. Which would put pretty much all of
Steve McIntyre [EMAIL PROTECTED] writes:
Bruce Perens wrote:
A good hardware design would put this code in FLASH on the board.
Depends on what you mean by a good hardware design. For example, a
lot of the USB dongles becoming common would be significantly bigger
and/or more expensive if
Glenn Maynard [EMAIL PROTECTED] writes:
On Sat, Dec 11, 2004 at 05:52:36PM -0800, Bruce Perens wrote:
In the case of a device driver, that dependency would still be there if
the firmware was in ROM. Which would put pretty much all of our device
drivers, X (talks to VESA code), APM and ACPI
31 matches
Mail list logo
