| |||||||||||||
gNewSensegNewSensePosted Sep 20, 2007 17:47 UTC (Thu) by JoeBuck (subscriber, #2330)In reply to: gNewSense by proski Parent article: MadWifi developers move to ath5k My guess is that the inclusion of spectrum_cs is a bug. Still, there's a problem in the strict GNUist attitude toward firmware. While I respect their principles, they argue that a device that allows firmware to be loaded is somehow "less free" than a device whose firmware is in ROM and is therefore cannot be updated, if the firmware is not free software. It seems to me that the reverse is true, since there is hope that someday the device can be loaded with free software (e.g. by a project like RockBox or the like).
(Log in to post comments)
gNewSense Posted Sep 20, 2007 18:07 UTC (Thu) by epa (subscriber, #39769) [Link] I think the idea is of equal treatment: if the manufacturer can create firmware updates and distribute them, then owners of the device should also be able to change the firmware and share it with others. The same principle applies to Tivo.
gNewSense Posted Sep 21, 2007 2:48 UTC (Fri) by gdt (subscriber, #6284) [Link] I reserve my opinion because we haven't seen the obstacles a vendor who did choose to do the Right Thing would face. For example, how long would it take to get the code for the proprietary "CPU" into the gcc tool chain? I can quite understand why a vendor might choose not to be the first one down that path.
gcc ports Posted Sep 21, 2007 6:19 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] Oh, come on. It's standard practice for vendors of new CPU architectures to work on a gcc port very early, and the gcc team is happy to cooperate with such efforts, and offer assistance (or point people to qualified consultants who will do the port for pay). You wouldn't be first down a path, you'd be on a well-travelled road.
gcc ports Posted Sep 27, 2007 18:29 UTC (Thu) by iabervon (subscriber, #722) [Link] A lot of microcontrollers embedded in existing devices use architectures that GCC doesn't support. A lot of them actually use an architecture that's been around for 27 years and has never gotten a GCC port: the 8051. GCC also doesn't support PIC microcontrollers. Then there are FPGA-based systems, which need an entirely different firmware design. In fact, most embedded platforms that GCC targets will have embedded flash, meaning that firmware wouldn't be part of drivers anyway; the hardware would come with a version installed, and any changes would be released by the vendor as a download that users can install at their leisure.
gcc ports Posted Sep 27, 2007 19:38 UTC (Thu) by zlynx (subscriber, #2285) [Link] Many of these microcontrollers really are micro. When a programmer only has a few KB of instruction space, he does not want to write code in C. Assembly is the only way to go, and it isn't so bad.
You know the saying that C is portable assembly. Well, a good assembler makes it as easy to write as C, it just isn't portable.
gNewSense Posted Sep 27, 2007 20:06 UTC (Thu) by moxfyre (subscriber, #13847) [Link] Doing the "Right Thing" doesn't necessarily mean that the vendor has to do all the extra work. Sure, it'd be nice if device vendors would release firmware source code that could be modified and rebuilt with the standard toolchain.But that's not necessary. All they really need to do to be Linux-friendly is release the source code under GPL in *some form*. Maybe it's assembler code. Maybe it's C code. SDCC is a Free software compiler targeting 8-bit microcontroller architectures, including 8051, Z80, and even PIC (which has the worst instruction set imaginable for C compilers). GCC is aimed at 32/64-bit architectures, and I think that SDCC is a REALLY valuable complement to it for the low-end embedded space. When hardware vendors provide basic device information and initial code, the Free software community can usually run with it. For example, Linksys released the code for its Linux-based routers... and now there are several polished and powerful distros for those routers. ATI has just released programming information--not even code, really--for their GPUs, and suddenly there's a veritable blizzard of open-source display driver development. As Greg K-H pointed out, "if you release specs, the Linux community will produce drivers"... often, they'll be better than the proprietary drivers!
equal treatment, or equally bad treatment Posted Sep 21, 2007 6:11 UTC (Fri) by JoeBuck (subscriber, #2330) [Link] The "equal treatment" argument reminds me of the joke about the Russian peasant back in the Soviet days, who contacted his local Party official and complained: "My neighbor has two cows, and I only have one. Kill one of my neighbor's cows!"You are asking for equally bad treatment, subtracting a capability if that capability is only useful to a proprietary software developer. Free firmware would be great, but replaceable firmware beats a device that cannot be fixed at all if it has a flaw.
equal treatment, or equally bad treatment Posted Sep 21, 2007 13:59 UTC (Fri) by epa (subscriber, #39769) [Link] You are right that in any individual case it is better to have a device that someone can upgrade rather than enforce equally bad treatment on everyone. However, applying the rule of equal treatment to all cases creates an incentive for device makers to do the right thing, if their choice is between making the firmware updatable by the device's owner or not at all.
This 'all or nothing' rule is characteristic of the GPL (version 1 applied it to copyright, v2 to patent licences, and v3 to allowing updated versions to run). I think it has had some success in getting more free software and is worth continuing.
Bad analogy time: in many countries with forest fires it is illegal to build on land that has been cleared by burning, even if the fire was entirely natural. Clearly in any individual case this benefits nobody - it would be better to use the land rather than waste it. But as a general rule it helps to discourage people from starting fires deliberately.
|
|||||||||||||