--- James C Georgas <[EMAIL PROTECTED]> wrote: > On Tue, 2006-26-12 at 03:20 -0800, Martin Knoblauch wrote: > > On 12/25/06, David Schwartz <[EMAIL PROTECTED]> 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). >
Correct, as far as I can tell. > 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). > - or they are ashamed to show the world what kind of crap they sell - or they have lost (never had) the documentation themselves. I tend to no believe this > 3) Hardware vendors don't tell us how to program their products, > because they know about (1) and they believe (2). > - or they are just ignorant > 4) We need products with datasheets because of our development model. > - correct > 5) We want products with capabilities that these vendors advertise. > we want open-spec products that meet the performance of the high-end closed-spec products > 6) Products that satisfy both (4) and (5) are often scarce or > non-existent. > unfortunatelly > > 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. > good luck > 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. > - Old hardware is not interesting in most markets - Visionary mamangement is rare > Solution (c) is what we do now, with varying degrees of success. A > good example is the R300 support in the radeon DRM module. > But the R300 does not meet 5) Cheers Martin ------------------------------------------------------ Martin Knoblauch email: k n o b i AT knobisoft DOT de www: http://www.knobisoft.de - 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/
