Re: Falsches Treiberkonzept? - USB-Cams: Der K(r)ampf mit der GPL

27. August 2004 16:15

27. August 2004 16:04
>
> > ... vergiss nicht, dass es weitaus weniger Varianten von Windows und
> > unterstützte Plattformen in dem Zusammenhang geht. Und APIs sind auch
> > noch kein Garant für funktionierende Treiber, wie ich an meiner
> > TV-Karte merken durfte - da war der open source Ansatz eine
> > wohltuende Alternative.
>
> Hmm, was ist wohl besser: Eine intolerante Auslegung der GPL und das
> Nichtvorhandensein von Treibern? Oder ein standardisiertes
> Treiber-API, das es den Herstellern in ihrer (in meinen Augen
> verblödeten) Geheimhaltungspsychose ermöglicht,
> Implementierungsdetails in Binärtreibern zu verstecken?

... es steht Philips und anderen beteiligten ja frei, es mit
Binärtreibern zu versuchen, man muss ja nicht über den (entfernten)
USB-Hook gehen. Ob's bei all den Kernel-Versionen in der freien
Wildbahn funktioniert, wird man sehen. Persönlich halte ich von den
binary only Treibern ziemlich wenig, die Gefahr, dass sie genau auf
der von mir verwendeten Plattform nicht funktionieren, ist gegeben -
im Gegensatz zu anderer Hardware, wo ich dann eben entsprechenden
Support habe. Ist einer der Gründe, warum ich mich auch ein wenig
über die nvidia-Treiber ärgere - nach jedem Kernel-Upgrade muss ich
diese auch wieder einbinden. Und standardisiertes Treiber-API und
Hersteller-Unfähigkeit zusammen ergeben dann "Paperweights", sprich
nicht verwendbare HW. Ist mir bei meiner TV-Karte passiert - weder
von MS noch vom Hersteller Support, dank Linux und open source BTxxx
Treiber läuft's seit Jahren klaglos.

> Und so
> zumindest Zugriff auf die Geräte zu haben - bis der Punkt erreicht
> ist, wo genügend potentielle User eine Open-Source-Implementation
> interessant werden läßt?

... ich denke, der Punkt ist schon erreicht - aber wenn Philips nicht
will, von mir aus, mittlerweile habe ich eine Philips Kamera diesen
Typs wieder aussortiert (HW-Defekt) und bin auf Logitech Quickcam
umgestiegen.

> Sicher sind APIs noch kein Garant für funktionierende Treiber - und
> speziell bei Crypto-Hardware ist das Vorliegen des Treibers als OSS
> in meinen Augen unvermeidbar (Code-Review).

... Zustimmung.

> Aber wenn man die Wahl
> hat zwischen "nicht unterstützt" oder "nur Binärcode-Treiber" sollte
> der User nicht wegen Lizenzextremisten auf der Strecke bleiben. Ein
> Binärtreiber verhindert ja nicht die Reimplementation als OSS.

... stimmt, aber ohne Spezifikationen muss sich hier nichts bewegen.
Einer der Gründe, warum ich zB keinen Drucker kaufe, der gar nicht
oder nur von binary only Treibern des Herstellers getrieben wird -
das hat unter Linux einfach keine Zukunft.

cd