Re: The firmware matter

2008-10-12 Thread Joel Rees

On 平成 20/10/12, at 4:14, Rafael Almeida wrote:


Hello,

From time to time I see people debating about blobs on kernels.


Random noise from an old fogey newbie --

Forty years ago, you pretty much expected a decent schematic inside  
the back panel of appliances. That meant that, even if you lived way  
out in the sticks where service technicians never came, you had a  
hope of fixing something that broke if you could read a schematic and  
had some basic tools.


Society has changed since then. There aren't as many places in the  
world that are more than a day away from a decent service center. If  
you're running a "mainstream" OS. If you are in a non-3rd-world area.


In other words, the big companies think they have a good excuse for  
(1) cutting the expense of providing schematics and for (2) competing  
by keeping their competitors from knowing what they are up to.


It used to be enough that it was against the law to adjust broadcast  
equipment in such a way as to interfere with other, legally operating  
broadcast equipment. That was more-or-less reasonable. But now it's  
against the law to adjust the equipment period, unless you have an  
engineering license from some organization that is not overseen by  
the government and is often either in the pocket of some big company  
or consortium, or directly financed or owned by the same. (I think of  
this as competing in the lobbies.)


It is true that putting the entire schematic and source code inside  
the back panel is not really all that possible any more. But putting  
them on the web is not impossible.


It is true that putting the manufacturing masks of integrated  
controllers on the web provides useful information only to those who  
can afford certain kinds of electron microscopes. I'm not sure what  
I'd do with a mask set, or the definition files (I forget what they  
are called) that are more commonly used these days, since we usually  
don't build masks by hand.


Which kind of begs a question: How, exactly, does competition by  
secrets really benefit anyone? What evil does it actually prevent?  
You'll always be vulnerable to disgruntled ex-employees, and without  
the ex-employee, your competitor usually is using such a different  
set of tools that trying to use your secret technology is not going  
to be significantly cheaper than developing their own wonderful  
solutions. When they are using the same tools, they'll eventually  
find your secret on their own, and in the process develop something  
better than whatever it is you're busy protecting.


I tend to think it's more like cutting off one's nose to spite one's  
face. For every competitor you frustrate, you frustrate at least ten  
users. And cut off opportunities to let users help you refine your  
devices. Take about hubris -- who can really think they can produce  
such a perfect design that they don't need user feedback? That's the  
same class of thinking that leads people to try to become dictators.


Anyway, APIs are useful to many more people, and even those tend not  
to be published.


And then there are field-reprogrammable logic arrays. It's easy for  
management to consider the gate definition files the same as the  
manufacturing masks. But you could also say they are missing an  
opportunity to open another dialog with their user community.


The contents of micro-controller ROMs would seem about as useful as  
the manufacturing masks, but does the same apply when the ROMs are  
actually flash, and can be patched in the field? Or how about when  
they are RAM, loaded at boot by the host OS?


This idea of always loading the micro-controller code from outside  
the device is seriously bent thinking. It's just plain wrong. It  
absolutely leaves the hardware fatally dependent on the host OS. Not  
just the brand and version, but the stability of the host. If the  
speed advantages of RAM are so great, the original (at time of  
manufacture) version of the controller code should still be loaded  
from a ROM on the device, and part of the API should be code that  
allows the controller code to be patched, or wiped and replaced, if  
the run-time issues of patching a running device are too complicated  
for the manufacturer to handle under its choice of real-time  
controller system.


And, again, where are the APIs?

The blob issues kind of exposes the ultimate way to pervert the GPL,  
but it also exposes the sheer idiocy of trying to trade in secrets.  
You can't eat a secret. You can try, but you will be like that guy  
Isaiah said, eating a banquet in your dreams, eventually waking up to  
the real reality that you've gained no nutrition thereby. Even very  
large "fortunes" disappear overnight. And bankrupted companies  
generally tend to take their secrets with them to the grave.


Source and schematics published openly, however, can survive serious  
economic troubles. Like eighty years ago serious. Since even people  
often survive after companies a

Re: The firmware matter

2008-10-11 Thread Jesus Sanchez

Rafael Almeida escribis:

Hello,

>From time to time I see people debating about blobs on kernels. I have
some understanding of the issue, but it seems that everytime some
issue comes out that I was not aware of. Not too recently I've seen a
discussion regarding intel wireless device, people from linux seem to
say it doesn't require blobs, though some openbsd users sugested
otherwise. Linux people even refered to some sourceforge link, I think
http://ipw2100.sourceforge.net/firmware.php was it. I believe there
are some problems when it comes to firmware. In that sense, is there
even wireless hardware that have no need for any kind of blob?

A while ago I've seen theo slides about how hardware vendors do not
suply the customer with documentation needed for him to operate the
hardware any way he wants. That is a major problem because it does not
let the user chose which operating system he will use. Now, couldn't
the firmware be considered part of the hardware? Why need it be free?
You can program the hardware without knowing about it, right?

Is there some hardware manufacturer that's actually concerned with the
customer's freedom? I know some of them eventually release some
documentation, but are there any hardware vendor which has providing
documentation as one of its goals?

I know this is not enterily on topic, but I was looking for a mature
open source comunity that's willing to discuss those matters with me.
I hope I have found such comunity and I hope not to see too many (or
not at all) aswers like 'linux just sucks' and the like (unless the
phrase comes with proper justification, of course :-)).
  

I'm also interested about open/closed firmwares. I think that if a
hardware vendor decides to NOT open firmware (wich could be considered
as part of the product) it should advise the customer really clear. When
I buy hardware I like to use it with OpenBSD and don't want to be
looking for compatibility/firmware provider lists before.

-Jesus



Re: The firmware matter

2008-10-11 Thread Pereresus ne Vlezaet Buggy
B qnnayemhh nr 11 njrap 2008 c. Rafael Almeida m`ohq`k(a):
> Hello,
>
> From time to time I see people debating about blobs on kernels. I have
> some understanding of the issue, but it seems that everytime some
> issue comes out that I was not aware of. Not too recently I've seen a
> discussion regarding intel wireless device, people from linux seem to
> say it doesn't require blobs, though some openbsd users sugested
> otherwise. Linux people even refered to some sourceforge link, I think
> http://ipw2100.sourceforge.net/firmware.php was it. I believe there
> are some problems when it comes to firmware. In that sense, is there
> even wireless hardware that have no need for any kind of blob?
>
> A while ago I've seen theo slides about how hardware vendors do not
> suply the customer with documentation needed for him to operate the
> hardware any way he wants. That is a major problem because it does not
> let the user chose which operating system he will use. Now, couldn't
> the firmware be considered part of the hardware? Why need it be free?
> You can program the hardware without knowing about it, right?

Yes. OpenBSD accepts firmware blobs. But also OpenBSD requires that
firmware is freely _redistributable_. See the Intel wireless firmware
license, and you'll see this point.

> Is there some hardware manufacturer that's actually concerned with the
> customer's freedom? I know some of them eventually release some
> documentation, but are there any hardware vendor which has providing
> documentation as one of its goals?

Ralink?

> I know this is not enterily on topic, but I was looking for a mature
> open source comunity that's willing to discuss those matters with me.
> I hope I have found such comunity and I hope not to see too many (or
> not at all) aswers like 'linux just sucks' and the like (unless the
> phrase comes with proper justification, of course :-)).

Linux is good. OpenBSD is just somewhat better ;)

--
  WBR,
Pereresus ne Vlezaet Buggy