On Sat, Oct 25, 2008 at 07:21, Manoj Srivastava <[EMAIL PROTECTED]> 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
