On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote:
> On 12/25/06, David Schwartz <davids@xxxxxxxxxxxxx> wrote:
>
> > If I bought the car from the manufacturer, it also must
> > include any rights the manufacturer might have to the car's use.
> > That includes using the car to violate emission control measures.
> > If I didn't buy the right to use the car that way (insofar as
> > that right was owned by the car manufacturer), I didn't
> > buy the whole care -- just *some* of the rights to use it.
>
> just to be dense - what makes you think that the car manufacturer has
> any legal right to violate emission control measures? What an utter
> nonsense (sorry).
>
> So, lets stop the stupid car comparisons. They are no being funny any
> more.
Let's summarize the current situation:
1) Hardware vendors don't have to tell us how to program their products,
as long as they provide some way to use it (i.e. binary blob driver).
2) Hardware vendors don't want to tell us how to program their products,
because they think this information is their secret sauce (or maybe
their competitor's secret sauce).
3) Hardware vendors don't tell us how to program their products, because
they know about (1) and they believe (2).
4) We need products with datasheets because of our development model.
5) We want products with capabilities that these vendors advertise.
6) Products that satisfy both (4) and (5) are often scarce or
non-existent.
So far, the suggestions I've seen to resolve the above conflict fall
into three categories:
a) Force vendors to provide datasheets.
b) Entice vendors to provide datasheets.
c) Reverse engineer the hardware and write our own datasheets.
Solution (a) involves denial of point (1), mostly through the use of
analogy and allegory. Alternatively, one can try to change the law
through government channels.
Solution (b) requires market pressure, charity, or visionary management.
We can't exert enough market pressure currently to make much difference.
Charity sometimes gives us datasheets for old hardware. Visionary
management is the future.
Solution (c) is what we do now, with varying degrees of success. A good
example is the R300 support in the radeon DRM module.
Did I miss anything?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
