On Wed, 19 Jan 2011 11:42:06 +0100
Klistvud <quotations@aliceadsl.fr> wrote:
> Dne, 19. 01. 2011 11:09:03 je Michelle Konzack napisal(a):
>
> > OK tnaks, found the Link to the "ipw2200" and the
> > non-free firmware is provided by the Debian Project.
>
> If at all possible, do not go with non-free firmware binary blobs,
even
> if provided in Debian-related repositories (in addition, non-free is
> not even Debian, strictly speaking -- it's just a "service provided
to
> the Debian users"). Binary blobs can not be
debugged/improved/enhanced
> by Linux developers and, as a result, may lead to unreliable
operation,
> lock-ups, disconnects, unimplemented features, slower speeds, lower
> operating range, or all of the above. When that happens, the
> manufacturer WON'T help you, and the Linux developers CAN'T. So
you'll
> be pretty much fscked. I know, I use a broadcom card with a
proprietary
> driver and it's a living hell.
>
> Really. Go with a free driver if at all possible, you'll be happy
you
> did.
1) Some chips implement all their logic in hardware, and some leave
some for implementation in software (firmware). Why is the latter
case
more problematic than the former? IOW, you'll almost never have open
hardware - the chip is just a black box to you. So why does the fact
that they've moved some of the logic to software (firmware) make
things
worse?
2) Hardware logic certainly can't be debugged/improved/enhanced, so
once again, why are we worse off now that they've moved some of the
logic into software (firmware)?
3) You mention using a Broadcom card with a proprietary driver. Do
you mean driver or firmware? In general, your post suggests that you
may be conflating the problems with closed drivers and closed
firmwares.
The former present much more of a problem, since the code
is actually running on your system and in kernel mode, and can
therefore do do anything it wants to your system. This is not the
case
with firmware running on a card.
Celejar