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 and countries die, you're just safer
publishing what you build.
Those blobs are like big holes missing out of the schematics,
supposedly justified by various pseudo-logic derived from current
"economic and political" pseudo-realities. Technical truisms.
Manufacturers abusing themselves by proxy for short-term gains.
Ideally, we want the source to those blobs. Practically, just being
able to copy the blobs legally could be a step in the right
direction. If the blobs are stable and the devices have published
APIs, using them may be better than attempting to shut down the
entire industry until manufacturers come to their senses.
Maybe.
Joel Rees
(venting a spleen or two today)
