On Tue, Oct 28, 2008 at 06:01:45PM +0100, David Weinehall wrote:
[...]
Post by David Weinehallsome cases, the binary blobs *is* the source code; I've spent more than
enough time programming 8-bit directly from a machine-code monitor).
And many people write non-modular programs; use non-usual constructs; do
not comment their code; include pre-calculated constants. Is Debian
going to remove a table of primes that were calculated and then stamped
on code in an array, because the source code for the prime number
generator was not made available? I'd rather have said source code if
it, in fact, existed at all. People may have written a one-liner in some
high-level code or did it by their hands or used some other tool already
distributed by Debian. I guess it is just not feasible to verify all
that.
Post by David WeinehallAs a bonus, an increasing amount of firmware these days is
cryptographically signed (cpu microcode, for instance), which means that
even if you had the source of the firmware, and the development kit, you
would still not be able to load the firmware onto your device.
Which the GPLv3 tries to solve, stating that if the vendor can do it
(the software distributed by the vendor in this case being under the
GPLv3 license, of course), the user must be able to do it also. Even if
that means providing the private key.
Post by David WeinehallNow, I always prefer to buy hardware I can get the drivers for,
so both my laptops and my server uses Intel chipsets to and through.
The CPU microcode
The iwl3945 firmware
I'm 100% certain I wouldn't have any use for the CPU microcode sources,
I know this because the microcode is cryptographically signed, and thus
any modified version I could possibly produce won't be able to load on
the CPU anyway (and apart from that, I seriously doubt that there is any
means of editing it in a sane way available in Debian anyway)
Again, this is not about what your computer use, but about what Debian
distributes in its main section.
Post by David WeinehallAs for the iwl3945 firmware, I do not know for sure whether it's written
in C, assembler, or whatever else (I'm fairly certain it's NOT in some
obscure 8-bit CPU or similar). Personally I wouldn't mind having
the source code, but I do know, that if the choice is between either
having the firmware in EEPROM or having it as a binary blob, I'd take
the binary blob anytime.
Some people have claimed this does not concern Debian, but I am for the
Free Software Foundation fights, and fighting for free/libre "firmware"
and hardware is worth, in my opinion.
Anyway, Debian is about a free/libre universal operating system, and
distributing non-free/libre pieces of "firmware" Debian knows there is
unavailable better forms of modification would not be the perfect way of
doing that.
Post by David WeinehallI see firmware sources as a nice bonus in cases where it's written in
a language that we can actually modify and build using Debian tools.
I don't see it as a necessity. Throwing out the firmware doesn't help
our users, it makes things worse for our users. And our users are our
number one priority.
Is it not providing them the best free/libre operating system?
Post by David WeinehallThe same could of course be argued for non-free software as well, but
the difference is that we can write replacements for the non-free
software. We don't have the option of replacing our users hardware.
And why can't we write replacements for non-free/libre "firmware"? Is it
because you don't consider reverse-engineering network protocols and
file formats as hard as reverse-engineering hardware? And as someone
else has compared hardware to network services, Debian does provide
software that communicate with those just as Debian provides drivers
that communicate with the hardware. But if Debian cannot provide a
service software, does that mean Debian should exclude the access software?
That would be an argument for the maintenance of the drivers, which I am
for. But would Debian be required to distribute the service software?
Debian does not provide the service software that will run in another
machine, but if it did, it would comply with the DFSG to be in main. The
same should be required from "firmwares". Debian does not distribute
hardware to run "firmware", neither it does distribute the hardware to
run "service software".
Post by David WeinehallThe closest we can get is to petition the hardware manufacturers for
specs or source code to the firmware, but if they don't answer, or if
they say no, we have to face he fact: our users are better off with
binary only firmware in Debian. Not in non-free.
They are better off with free/libre firmware written by people who care
about them. If it requires reverse-engineering, so be it.
Post by David WeinehallFor laptops running Intel chipsets, the most common wireless chipsets are
iwl3945, iwl4965, and iwl 5000 these days. All of them requiring binary
only firmware. With Intel's recent track record of releasing
sources, it's reasonable to assume that they would have released the
sources if they saw it as possible, so hoping for a source release seems
fairly futile.
Write a replacement! Go for other hardware! Copy the firmware yourself
if you have the author permission! But do not distribute non-free/libre
software in Debian main!
Post by David WeinehallNow, imagine Debian having this hypothetical yearly conference, called,
oh, let's say DebConf. During that conference we organise a special day
for our users, let's call it Debian Day. Lots of potential new Debian
users show up with their laptops and wants to install Debian. As the
kind souls we are, we hand out credit-card CD's with netinst images that
they can use with the WiFi available at the conference.
Oh, but wait. They cannot access the WiFi, because their wireless cards
are not supported. Or rather, the drivers are available, but they all
report the same error message "Firmware not found". Happy, happy, joy,
joy. I'm sure those potential Debian users will feel really happy about
Debian's consistent policy that dictates that software running on
non-cpu == software running on cpu. They might not feel equally please
The hardware manufacturer is at fault! Not Debian!
Post by David Weinehallwith the fact that Debian isn't consistent in its dedication to
prioritising the users though...
I will try to be short in telling something about the history of
education in my place. The government passed some resolution that
students must be approved always. Well, some teachers interpreted that
as that they should just give some grade to the student so they could
"achieve" that. What they should have done was everything so the student
would learn and not be able to fail.
If Debian interprets that its prioritising of users' software and
"firmware" availability is in favor of their freedom, why don't forget
the DFSG and include whichever distributable work in main? Debian could
tell them about the known issues with known hardware as well as tell
them about known issues with known network services and ask them for
help.
Post by David Weinehall[snip]
Regards: David
--
// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ // Diamond-white roses of fire //
\) http://www.acc.umu.se/~tao/ (/ Beautiful hoar-frost (/
Regards,
Cascardo.