Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux

[Bernd Paysan]

Am Samstag, 16. August 2014, 13:28:22 schrieb Anton Ertl:
> On Sat, Aug 16, 2014 at 12:52:00AM +0200, Bernd Paysan wrote:
> > FSF's issue with OpenSuSE are the firmware blobs.  I'm not convinced of
> > that issue: This is just technical, the manufacturers of these chips use
> > RAMs to store the firmware so that they can develop that stuff without
> > many long turnarounds.
> 
> That would also be possible with flash.  They probably do it because
> it saves them money, e.g., by using lower standards for the
> development, because bugs are cheaper to fix in the field.
> 
> In any case, that does not matter for the question of free software.
> This is not immutable hardware, this is plain software.  All the
> arguments for freedom of software apply.  Indeed, the FSF started with
> something quite close to these things: with a proprietary printer
> driver.

Nope, it wasn't the printer firmware, it was the driver which ran on the 
general purpose computer, talking to the printer.  The problem could have 
equally been solved by changing the firmware of the printer, and making it 
compatible with some other printer which was supported by free software.   
What you request is that your printer runs Ghostscript, and not some Adobe 
PostScript license.  Modern printers have a complete operating system with 
everything (often even a web server), and of course the firmware is nowhere 
immutable.  They just remember their firmware, so you don't have to upload it 
every time they boot.

The controllers around your main CPU (and indeed, also your main CPU) rely on 
the main CPU to keep their firmware when they are off.  That's just 
outsourcing the storage device.

> > Therefore, you upload the firmware by the OS.  This is state of
> > the art;
> 
> So is other proprietary software.

No, "ordinary" proprietary software runs on a general purpose computer.  These 
embedded devices are single-purpose things, and as a copyrighted entity, all 
their implementation details (including the firmware) is IMHO just one work.

> > If you use a system that is free in the FSF sense, you will have troubles
> > with many hardware components, except those already initialized by the
> > BIOS (which does the blob uploading for you then).
> 
> Yes, so if you want to run a 100% free software system like gNewSense,
> you will have to select the hardware even more carefully than otherwise.

You didn't get it: If you stop ignoring the blobs your BIOS uploads, your set 
of possible selections goes down to zero today.  You can't even get a CPU that 
works without a binary blob.  If you replace your BIOS with Coreboot, you get 
all those blobs inside Coreboot.  Coreboot sees the situation just as I do: 
critical:

http://www.coreboot.org/Binary_situation

Intel and AMD even protect their microcode with a 2048 bit RSA signature; the 
format is mostly reverse engineered, but DRM-protected.  Essentially, you 
might get away sometimes if you don't need to update your microcode (they 
still have mostly working microcode in the CPU, and don't fully rely on 
uploading the microcode, but that might change).

Since people stopped trusting hardware, there are now some more efforts under 
the way to make free hardware happen, where all and everything, including the 
hardware description is licensed like free software.  That's the way to go.  
Buying proprietary hardware and complaining about the binary firmware blob is 
simply hypocrisy, it's like complaining that the butter on the non-free bread 
is also non-free, with the argument that the bread is hard and the butter is 
soft.  If you want to be absolutely free, don't buy proprietary hardware.  If 
your hardware vendor spent the money to store the firmware on flash (it still 
can be updated that way!), instead of uploading a blob every time you boot, 
what did you gain in freedom?  Yes: exactly nothing.

Since the development of ReRAM is making good progress, it's likely that non-
volatile memory for all these devices will be available cheaply soon, so you 
might have a working system without blobs soon.  But the stuff is still there, 
the firmware blobs are still inside the devices.  I don't see how that 
improves the situation at all.  You get a black box, and you need some magic 
incantation to start it, or you get a black box and the magic incantation is 
inside (still software, not in a ROM).  It's still a black box.

-- 
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://bernd-paysan.de/

signature.asc
Description: This is a digitally signed message part.