[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Anton Ertl
Subject: Re: [gforth] setting up a linux system so to learn gfroth and GNU/linux
Date: Wed, 20 Aug 2014 10:46:37 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Aug 17, 2014 at 09:16:52PM +0200, Bernd Paysan wrote:
> 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.

Yes, I wrote that it was the driver.  Whether the software runs on the
CPU of the computer or on some peripheral processor makes little
difference as far as freedom is concerned.  There were very useful
programs that ran on the controller of the Commodore 1541 floppy disk

> 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.

If the printer maker wants to "outsource" the storage device to an
FSF-approved distribution, and want that OS to upload the software to
the printer, it has to use free software (e.g., Ghostscript) for the
printer.  Or it does not outsource and pay extra for flash; that's
then part of the cost of using proprietary software.

> These 
> embedded devices are single-purpose things, and as a copyrighted entity, all 
> their implementation details (including the firmware) is IMHO just one work.

Actually the fact that the software only works on that particular
hardware should make it more attractive for the manufacturer to
provide the software part as free software.  Other manufacturers
cannot profit directly from the software.

Not sure what the "one work" thing is about.  AFAIK that's not
anything from copyright law.

> > > 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:

The first sentence on this page is

|While we aim for a 100% free boot process, recent developments (and
|general unwillingness by some hardware companies to provide
|specifications) make it hard to achieve.

That's very different from the position that you seem to take here,
which is that we should not aim to avoid proprietary blobs.

And according to that page, you may be able to boot a recent AMD board
without blobs.

> 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.

Then the hardware manufacturer then incurred a cost and (in a
competetive market) reduced its profit by using proprietary firmware.

Also, things are done in software that are not done in firmware.
Software not ready for prime time?  Ship the hardware anyway, we will
update the software later, maybe automatically.  Now that our
proprietary software phones home, what else can we do with it ...

> 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.

Sure, free firmware and free hardware would be great.  But even if we
don't have that, that's no reason to ignore proprietary software blobs
when it comes to declaring an OS "100% free software".

And while the difference between software (dealt with by the OS) and
firmware (stored on the peripheral) may appear negligible to hardware
people like you, from a practical point of view it's a big difference:
In general you cannot even tell for sure if a peripheral has firmware
(and what it consists of), while the software blob is something the OS
has to deal with explicitly.

Anyway, for the original poster: This is more of a philosophical
discussion.  If you find a 100% free distribution that works
satisfactorily with your hardware, good for you, otherwise just use a
distribution like Debian, Fedora or OpenSuse that includes proprietary
blobs, and be aware of the issue (and look at the recommendations)
when you buy new hardware.

- anton

reply via email to

[Prev in Thread] Current Thread [Next in Thread]