Re: [DRAFT] resolving DFSG violations
On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <srivasta@debian.org> wrote:
> Your argument boils down to: There is function that will never
> be supported by free software. Annoying people by asking them to expose
> their function by freeing the software just irritates them, so we
> should just suck it up and accept it.
I don't think I'm explaining this well, as it seems you are still not
getting it: there isn't any source code to get.
> Guess how we cater to people who need non-free software for
> some functionality they must have? We put it into a place called the
> non-free archive.
Great; totally useless raw data the chips on the machine need so we
can write free device drivers to talk to them. Excellent. So the plan
is: "Debian is only for hardware manufacturers that embed the firmware
in flash. If you hide your non-free stuff, that'd be great because
then we could pretend it doesn't really exist. Please don't disrupt
our perfect version of how the world works."
> You do not have to be a "firmware engineer" to grok that.
I guess I'll find out. I think this proposal is just trying to pretend
that there isn't firmware in the machines now. How does it help the
free software movement if we try to ignore the non-free firmware
booting our machines now? Why are we trying to shuffle that under the
rug?
> ps: back in the day, before I became a quantum mechanic, I toyed around
> with seeing if designing microprocessors was for me. I did design a 27
> instructions, 4 bit microprocessor with microcode, so I get what
> firmware is.
It depends,
I'm talking about the synthesized image of the microprocessor (for the
xlinux, altera, etc). I'm not talking about if you emulated it on
solaris to check your processor (CS courses often do processor
projects of that sort). I'm also not talking uboot/coreboot like
firmware or psos-like things (also firmware but they _do_ have source
code).
If you did synthesize it, you might not have even "seen" it if you put
it on a cpld. Then you might have just thought you were "programming"
the chip. No; you were just writing it to flash. Thus bypassing the
dilemma. If you build a product and don't want to pay to have the
extra chip onboard (common on cheap low end parts) then you have to
load it via software. Thus the firmware blob. And yes, for the 50th
time: THERE IS NOT SOURCE CODE. There can not be source code, it
didn't start as source code. You can't "compile" it because there
isn't a compiler. It's not instructions for a microprocessor -- in
your case -- it is the microprocessor itself. That's right, lets say
that again, the firmware blob is your 4 bit microprocessor.
So this whole free 4 bit microprocessor you just made, you can publish
the source and everything (see also: openrisc & opensparc). But, to
run it, you have to give people a firmware blob so they can run it.
Perhaps you can't even make an installer for it because you can't
initialize the chip in the installer because you can't put the fimware
you need in the installer. So you can only support hardware where you
can flash the firmware on the motherboard. Also not ideal because you
might have a version out of sync with the kernel device driver you
wrote. Great, thanks a lot freedom.
So yes, I think most people aren't going to "get" the issue unless
they may have been firmware engineers.
Reply to: