Ich frage mich schon immer warum die Hardwarehersteller so ein Aufhebens um die Geheimhaltung der Treiber machen. Waehre ich ein Hersteller von Hardware waehre mein Ziel doch, mehr Hardware zu verkaufen als die Konkurrenz, und dabei noch pro verkaufter Einheit einen moeglichst hohen Profit zu machen. Ob da jemand meinen Treiber Millionenfach kopiert und weiterverteilt ist doch vollkommen egal, ohne die dazugehoerige Hardware ist der Treiber doch nutzlos, und die laesst sich nicht softwaremaessig kopieren. Noch ein Vorteil eines GPL - lizenzierten Treibers: Jeder kann das Ding debuggen, das heisst ich muss selbst die Erstversion erstellen, ein bisschen selbst debuggen und zunehmend bekomme ich Probleme von der Community geloest. Wenn ein Konkurrent den Treiber oder Teile davon fuer sein Produkt hernimmt muss er den Quellcode ja ebenfalls freigeben, das heisst der Taktische Status quo waehre ebenfalls wieder hergestellt. Irgendwie kommt mir vor, die Firmenbosse checkens net.
> Ob da jemand meinen Treiber Millionenfach kopiert und weiterverteilt ist doch vollkommen egal, ohne die dazugehoerige Hardware ist der Treiber doch nutzlos, und die laesst sich nicht softwaremaessig kopieren.
Das Problem ist, daß man anhand des Treibers u.U. Rückschlüsse ziehen kann, wie die Hardware arbeitet und eben diese Informationen will man nicht preis geben.
> Das Problem ist, daß man anhand des Treibers u.U. Rückschlüsse ziehen kann, > wie die Hardware arbeitet und eben diese Informationen will man nicht preis geben.
bei grifikkarten, bei denen man durch effizente alogrithmen ein paar wichige prozente herraus holen kann, kann ich dass noch verstehen.
doch dass "wie die hardware arbeitet" ist ein billiges argument der hardwarehersteller.
1. dürfte viele hardware, für welche keine treiber oder spezifikationen veröffentlicht werden, alles andere als technologisch wertvoll sein. so ist z.b. das innenleben vieler hardware (billig scanner, webcams, ...) im großen und ganzen geich, weil sowieso zugekaufte billig komponenten verwendet werden.
2. z.b. wollte intel lange keinen OSS treiber für das ipw2100 wlan-modul veröffentlichen (auch mit dem argument die arbeitsweise der hardware zu schützen). mittlerweile gibt es den treiber, und ich denke nicht dass sich an dem problem der arbeitsweise was geändert hat, höchstens was in den köpfen der manager.
3. gibt es aussagen von treiber entwicklern, nach denen man durch reverse engineering weit aus mehr über die HW herrausfindet, als wenn man nach offenen spezifikationen arbeitet.
Von Patrick Stuckenberger am Sa, 28. August 2004 um 11:20 #
Naja, die NDA für Neosoft hat seine Gründe, der wichtigste in jenem Fall:
-Komprimierung des USB Datenstreams, Philips hat hier eben viel auf die Hostseite gebracht und möchte verständlicherweise hier andere Parteien nicht einladen.
Ob die ganze Diskussion dem eigentlichen Ziel, "..liebe Hersteller, macht bitet gpl code.." näher kommt, bezweifle ich; es wird genau das Gegenteil erreichen, ein negatives Signal wird gsetzt.
Anhand des kleinen pwcX Beispiel zeigt sich aber auch, wieviel "Ausfsehen" jene Grundsatz Diskussion erzeugt hat.
Bei Grafikkarten z.B. sind oft gleiche Chipsätze drauf, die teilweise enormen Leistungsunterschiede resultieren aber aus den unterschiedlichen Treibern. Richtig gute Treiber sind also nicht selten das Kapital, weswegen die Karte von Firma A bessere Leistung bringt als die von Firma B. Und es steckt viel know how drin. Ein Treiber ist ja eine Art Minibetriebssystem. Und es gibt halt bessere und schlechter programmierte Betriebssysteme Algorithmen, die ich im Treiber implementiere können teure Hardware emulieren, auch da lassen sich Firmen nicht gerne in die Karten schaun.
Das Thema ist komplexer, als es manch einer wahr haben will. Ich mag auch OS-Treiber, aber ich weiß auch, daß OS nicht immer wirklich funktioniert.
Mit dem Code aus dem Treiber läßt sich der Aufgau eines Gerätes klären und der Nachbau ist einfacher.Da viele Herstellr Betriebsinterne Bezeichnungen auf den Chip schreiben.
Das weiter kann der der Nachbaut den Treiber verwenden und spart sich enorme Kosten bei der Softwareentwicklung und beu geräten die weit aus teurer sind als so eien Webcam macht sich das beid er Entwicklung bemerck bar. Das soll jetzt nicht heißen, dass ich gegen open source bin. Ich bin dafür. Ich kann halt Firmen in solchen Bereichn verstehen, den da geht es um Millionen im Entwicklungsbereich was so eine Entwicklung kostet.
>Mit dem Code aus dem Treiber läßt sich der Aufgau eines Gerätes klären und der Nachbau ist einfacher.
und ohne dem Quellcode des Treibers wird er Hacker gezwungen die Hardware zu untersuchen wie sie funktioniert und dabei kommt nicht selten mehr an die Öffentlichkeit als wenn man einfach die Treiber Informationen veröffentlicht hätte
>Das weiter kann der der Nachbaut den Treiber verwenden und spart sich enorme Kosten bei der Softwareentwicklung
1. baurcht der Hersteller seinen neuen Chip nur patentieren und schon baut es niemand mehr einfach so nach 2. Wegen den Kosten der Treiberentwicklung, wenn der Treiber der 1. Firma eine copyleft Lizenz hat, dann wird er auch wieder an das Ergebniss der 2. Firma kommen und so selber wieder Geld sparen...
>und ohne dem Quellcode des Treibers wird >er Hacker gezwungen die Hardware zu >untersuchen wie sie funktioniert und dabei >kommt nicht selten mehr an die >Öffentlichkeit als wenn man einfach die >Treiber Informationen veröffentlicht hätte
So einfach ist es nicht einfach einen Chip zu untersuchen ohne Pinbelegung. Geschweigeden den Schaltplan aus dem Layout zu entwerfen. Ich hab das mal bei einer Schaltung mi 3 ICs die jeweils 16 Pins haben. Das ist nicht gerade einfach und jetzt hab mal eine Platine mit 40-50 ICs da geht mal ohne Schatplan nichts mehr. ich Repariere solche Platinen und selbst mit Layout und Schaltplan mußt du da kämpfen dass du ein Leiterbahn verfolgen kannst. Aber dafür gibt es Programme die dir die Lage der Leiterbahn zeihgen, hlat nur wenn du das Layout auf dem PC hast.
>1. baurcht der Hersteller seinen neuen >Chip nur patentieren und schon baut es >niemand mehr einfach so nach >2. Wegen den Kosten der >Treiberentwicklung, wenn der Treiber der >1. Firma eine copyleft Lizenz hat, dann >wird er auch wieder an das Ergebniss der >2. Firma kommen und so selber wieder Geld >sparen...
Da wird dann mal ein paars Sachen verändert und gut ist und schon ist nichts mehr mit Lizenz.
Udn nicht jeder der Geräte netwickelt entwirft auch den Chip dazu, der wird meißtes eingekauft udn somit kann jeder den Chip kaufen.
Ich verwende den angesprochenen Treiber für meine Logitech Quickcam 3000. Das Problem ist hier, dass Phillips ein Kompressionsverfahren nutzt, um die Daten komprimiert über den USB Bus zu schicken. Das spart Bandbreite und erlaubt auch mit USB 1.1 das Videostreaming mit mehreren Cams gleichzeitig. Diese Kompressionsverfahren und noch andere Bildoptimierungsroutinen will Phillips nicht herausgeben, weil sie es als Entwicklungsvorsprung sehen. Deshalb durfte der Autor nur nach Unterzeichnung eines NDA einen Binärtreiber entwickeln, aber keine Sourcen rausgeben. Die Cam ist aber mit dem GPL-Modul allein nutzbar, allerdings nur in Minimalauflösung, die man z.B. um Fotos für ne eBay Auktion zu machen schon kaum noch nutzen kann. Nur wenn man das Binary-Modul dazu lädt, kann man die volle 640x480 einstellen und die Bildqualität verbessert sich. Übrigens gab es damals eine heftige Auseinandersetzung mit Alan Cox (irgendwo auf der Website des Autors ist der Thread abgedruckt), weil der bestimmte Videofunktionalitäten vom Kernel- in den Userspace schieben wollte, das aber viel zu umständlich gewesen wäre und rein religiöse Gründe gehabt hätte.
> weil der bestimmte Videofunktionalitäten vom Kernel- in den Userspace schieben wollte, das aber viel zu umständlich gewesen wäre und rein religiöse Gründe gehabt hätte.
Nix religiöse Gründe, sowas gehört nunmal in den Usermode. Grundsätzlich sollte nur das allernotwendigste im Kernelmode laufen, vfs, scheduler, pager und ipc, der Rest kann in den Usermode. Und was binäre Treiber angeht: Ich lehne sie ab, schon aus Sicherheitsgründen. Auch in der Firma gibt es das nicht, wenn Hersteller nicht kooperieren, kommt die Konkurrenz zu Zug -- sowas nennt sich freie Marktwirtschaft. Niemand kann gezwungen werden, freie Treiber für seine Produkte zu entwickeln bzw. deren Entwicklung zu ermöglichen, aber dann sollen sich die Betreffenden bitte auch nicht beschweren, wenn niemand ihre Produkte kauft.
100% ACK, ausnahmsweise. Bei unfreien Treibern könnte man sich z.B. folgendes Szenario vorstellen: In bestimmten Frequenzbereichen der Karte schickt der Treiber gezielt Informationen aus dem Speicherbereich des Prozesses, der das Paket abgeschickt hat. Natürlich verschlüsselt. Wie lange es wohl dauert, bis einer dahinterkommt, wenn der Bereich außerhalb des normalen Empfangsspektrums einer Netzwerkkarte ist?
Ehrlich gesagt, mich als Privatmann interessiert es nicht, ob der Treiber binär oder im Quellcode vorliegt, ich will meine Webcam benutzen, und das geht ohne den pwcx Treiber nunmal nicht richtig.
Genau solche Unsicherheiten und schnellschuss Entscheidungen halten sicher viele von Linux fern.
Als ich damals die Webcam gekauft hatte, waren die Philips Cams die einzigen unter Linux vernünftig unterstützten. Nennt mir doch bitte einige gute Alternativen
Sonst kommt hier gleich wieder der Eindruck auf, diese bösen Open Source fundies würden alles, was mit closed source Treibern zu tun hat sabotieren.
Das spezielle Problem bei diesem Treiber scheint, wenn ich das richtig verstanden habe, dass er im Kernel selber etwas braucht dessen einziger Daseinszweck es ist das Laden eines Closed Source Moduls zu ermöglichen. Dies aber ist nach Ansicht der Kernel Maintainer eine Verletzung der GPL. Eine kurze Anmerkung am Rande, andere closed source Module, zum Beispiel die von Nvidia benötigen so etwas nicht.
Es handelt sich also um kein ideologisches, sondern um ein rechtliches Problem.
Wer genaueres wissen will, sollte sich folgende Diskussion zu Gemüte führen: http://lkml.org/lkml/2004/8/24/278
Korrekt erkannt hast Du das. Ausserdem wie auch bei Heise nachzulesen war wurde vom Kernelmaintainer der Hook der das nachladen von closedsource Treibern entfernt. Auch diesen Schritt halte ich für korrekt, denn ansonsten könnte Code den man sicherlich nicht haben möchte einfach in den Kernel geschleusst werden. Das es bestimmte Kreise gibt denen das gefallen würde den Linuxkernel zu unterwandern ist wohl nicht von der Hand zu weisen.
Die Rückforderung von seinem GPL Code, die der Treiber Coder verlangte, ist allerdings nicht GPL Konform. Damit zeigt sich das der Knabe keine Ahnung von der GPL hat. Zu guter letzt kommt man dann auch auf das Themea man sollte eben nur Produkte kaufen, die pro Linux eingestellt sind.
Auch Du solltest Dich erstmal mit der GPL beschäftigen bevor Du was sinnfreies von Dir gibst. Das Linus dem entfernen des Codes zustimmt ist eine Goodwill Aktion. Er könnte genauso drauf bestehen das der Code der Allgemeinheit nach wie vor zur Verfügung steht.
> Er könnte genauso drauf bestehen das der Code der Allgemeinheit nach wie vor zur Verfügung steht.
könnte er, aber wie du und CE bereits gesagt haben, zeigen sich die kernel-entwickler grosszügig und gewähren ihm die bitte, obwohl sie es natürlich nicht müssten.
> Das spezielle Problem bei diesem Treiber scheint, wenn ich das richtig verstanden habe, dass er im Kernel selber etwas braucht dessen einziger Daseinszweck es ist das Laden eines Closed Source Moduls zu ermöglichen.
Der Treiber bestand aus den Moduln pwc und pwcx; ersterer ist open-source, letzterer nicht. "Was der Treiber braucht" ist ein Hook in pwc, um pwcx laden zu können. Der Treiber als Gesamtheit von pwc und pwcx braucht nichts externes im kernel.
Für mich ist der Sachverhalt so, daß ich vor ein paar Monaten eine solche Webcam gekauft habe, in Kenntnis der Treibersitution, also daß das gerät mit pwc alleine in geringerer Auflösung und mit dem closed-source pwcx in voller Auflösung läuft. Von dem Hook, der die jetzige Malaise ausgelöst hat, wußte ich nichts. Für mich kommt aus heiterem Himmel, daß ein seit Jahren existierender Treiber, den ich brauche, ab sofort eingestellt ist. Soll ich mich bei der Hardwareauswahl auch noch um irgendwelche kindergartenpolitische Dämlichkeiten kümmern, die hinter den Kulissen ablaufen und möglicherweise irgendwann aufbrechen? Das ist einfach SCHEISSE, und ich bin zum ersten Mal richtig sauer auf Linux, weil hier eine Auseinandersetzung auf dem Rücken der Benutzer abgeladen wird. Zusammen mit der komischen Ankündigung, in Zukunft die Stabilität der Kernel den Distributoren zu überlassen, und meinen Erinnerungen an das, was diverse Distributoren so alles herumgepatcht haben, muß ich konstatieren, daß Linux auf dem Weg in den Abgrund ist.
> Eine kurze Anmerkung am Rande, andere closed source Module, zum Beispiel die von Nvidia benötigen so etwas nicht.
Ach ja? Kann man sich da so sicher sein? Und wer sagt, daß nicht morgen irgendein andersgeartetes "rechtliches problem" mit dem Nvidia-treiber auftaucht?
Kroah-Hartmann schreibt an der von dir angegebenen Stelle: > Actually, in thinking about this even more, I just realized that I have > to rip this hook out. I say this because we are allowing a change to > the kernel that is needed _only_ for a closed source module. See > Linus's comments about "if a change is needed to be made to the kernel > in order to get a closed source module to work, that module must be made > opensource" or something close to that. > > So, I'll rip this out with the next round of USB patches that I send off > to Linus. > > Nemosoft, any thoughts?
Wenn also Linus einen Kommentar abgibt, müssen die Benutzer zukünftig auf ihre Hardware verzichten. Wenn man das Kriterium von Kroah-Hartmann zugrunde legt, hätte der betreffende Treiber überhaupt nie in den kernel aufgenommen werden dürfen. Dann hätte Nemosoft ihn entweder als kernel-externes Projekt betrieben, oder auch nicht, es wäre aber nicht zur jetzigen Malaise gekommen. Und nochmal, der Punkt ist: MAN KANN MIT DEN BENUTZERN NICHT SO UMSPRINGEN. Das ist genau die Art von Unsicherheit, die Microsoft gegen Open-source-Software ins Feld führt. Anscheinend hat Microsoft recht.
Ich verstehe ja deine Verärgerung, dennoch finde ich, du solltest die Sache ein bischen gelassener sehen.
Wie schon gesagt ist es bei diesem Treiber eine spezielle Situation eben weil er, wie du richtig bemerkt hast, einen Hook im Kernel brauchte. Nun bin ich kein Anwalt, kann also nicht wirklich einschätzen inwieweit die Einschätzung von Linus und Kroah-Hartmann richtig ist, dass dies eine Verletzung der GPL ist, unproblematisch ist es aber sicherlich nicht. Und wie nvidia zeigt geht es ja wohl auch anders.
Was mich an der ganzen Sache wirklich stört ist, dass ich das Gefühl habe wir haben es hier vor allem mit einem Ego Problem aller beteiligten zu tun.
Du hast natürlich recht, dass der Treiber so eigentlich nie in den Kernel hineingedurft hätte, aber wenn man einen Fehler gemacht hat, dann heißt das doch nicht, dass man ihn nie mehr korrigieren darf. Allerdings finde ich die Art und Weise (Ich schmeiß das raus, was sagst du dazu?) nicht wiklich gelungen. Das kann man eleganter lösen.
Gleiches gilt aber auch für Nemosoft. Anstatt über Alternativen nachzudenken, die es ja zu Hauf gibt, einfach alles hinzuschmeissen und die beleidigte Leberwurst zu spielen zeugt nun nicht gerade von großer Reife.
Da ein Teil des Codes nun aber mal GPL ist und da es sicherlich ein recht großes Interesse von Seiten der Nutzer gibt ihre Hardware auch mit neueren Kernelversionen weiter zu nutzen, wird es aber glaube ich nicht lange dauern, bis eine vernünftige Lösung gefunden ist, die sowohl den imho berechtigten Bedenken der Kernel Maintainer, als auch den Wünschen der User gerecht wird.
Genau das dachte ich mir auch. Ich hab nix gegen Binary Treiber unter Windows bekomme ich ja auch nix anderes, wenn die Qualität wie bei Nvidia stimmt, ist das okay für mich.
Wozu braucht man zum Teufel eine Webcam? Interessiert doch keinen. Bildschirmtelefon hat sich auch nie durchgesetzt. Was soll das Geschrei hier also? Ist doch unnötig.
Man brauch z.B. 'ne Webcam, die aller X Sekunden ein Bild schiesst und dieses dann auf einen externen Server läd. So hat man z.B. eine recht günstige Überwachungskamera. Hätte ich vor 8 Monaten so eine Kombi gehabt, würde ich jetzt wissen, wer bei mir eingebrochen hat. Andere Anwendungsbeispiele sind z.B. Beobachtung eines Vogelnestes oder den Fortschritt eines Gebäudes ( Sanierung, Neubau...). Also wie du siehst es gibt neben der Bildtelefonie durchaus auch noch andere sinnvolle Anwendungen und das Bildtelefon hat sich nie durchgesetzt, weil die Qualität schlecht war. Es gibt nix besseres, als bei einem Firmenmeeting via Bild dabei zu sein, um z.B. einem Vortrag mit Visualisierung oder Vorführung von Prototypen besser folgen zu können. Naja dafür nimmt man wohl noch bessere Kameras. phixom
Ist das nicht so das ein Treiber, um die MS Zertifizierung erhalten zu können, nicht offen sein darf? Und wenn ein Treiber keine MS Zertifizierung hat geht ja bei Windows immer ein grosses Warnfenster auf und der MS user ist verunsichert. So kann MS Druck machen das es keine Treiber für Linux gibt.
Mag vieleicht sein (was ich kaum glauben kann - ich glaube Du verwechselst das mit den Nutzungsbedingungen von MS Programmen).
Aber selbst wenn, kann man immer noch die Spek für die Schnittstelle offenlegen und schon kann OOS sich darum kümmern einen offenen Treiber zu entwickeln.
Von Einer der ebenfalls Treiber sc am Fr, 27. August 2004 um 15:06 #
Nein, das stimmt nicht. Man muss sogar MS die Quellen zukommen lassen, damit ein Treiber eine MS Zertifizierung erhalten kann. Kann Deine Behauptung deshalb aus eigenen Quellen entkräften, denn unsere Treiber stehen unter der GPL- und/oder der BSD-Lizenz. Bekanntlich steht die Lizenz immer in den Quellen und diese gehen an MS. Beschwert hat sich deshlab bei uns noch keiner und MS hat uns noch nie eine Zertifizierung verweigert. Im Gegenteil, die nutzen uns als Referenz
Von Manfred Tremmel am Sa, 28. August 2004 um 18:53 #
Hm, dann ist das unter Linux und Windows ja ähnlich, man stellt den Quellcode zur Zertifizierung dem Hersteller zur Verfügung. Bei Windows ist das Microsoft und bei Linux die OS-Community. ;-) Ansonsten kann ich mir ehrlich auch nicht vorstellen, dass MS was zu sagen hat, was ein Hersteller für ein anderes OS schreibt. Die können vielleicht unterbinden, dass für Windows Treiber die als OpenSource freigegeben werden, eine Zertifizierung erteilt wird, aber ein parallel zum Windows-ClosedSource herausgegebener Linux-OpenSource Treiber geht die wohl wirklich nichts an.
Von Der, der schon einige Treiber am Fr, 27. August 2004 um 14:22 #
Würden die Kernelmaintainer endlich mal einsehen dass eine offene Schnittstelle wichtiger ist als der Source würden auch mehr Hersteller einen Treiber für Linux anbieten. Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische wird das eben weiterhin so bleiben dass es kaum Treiber geben wird.
Von Einer der ebenfalls Treiber sc am Fr, 27. August 2004 um 15:00 #
Da muss ich Dir in Deiner Kritik leider Recht geben. Die überhebliche Art und Weise der Maintainer mancher Kernel-Zweige ist kaum auszuhalten und wird Linux irgendwann zum Verhängnis. Ich kann es verstehen, dass sie auf Qualität einen besonderen Wert legen müssen, aber das Elite-Gehabe geht mir ziemlich auf die Nerven. Ein Beispiel: Einer unseren Treiber wurde nicht in den Kernel aufgenommen, weil der Maintainer des alten Treibers zufällig auch der Meintainer des Subsystems war. Da er nicht seinen alten Treiber löschen wollte hat er von uns verlangt, dass wir die komplette Funktionalität unseres Treibers an seinen Treiber anpassen. Erklärungen, dass wir es nicht können, weil wir auch Treiber für andere Systeme schreiben (BSD, MacOS X, Solaris, HP, Windows) und deshalb Common-Code haben, haben ihn nicht interessiert.
Das Resultet: Das Management hat die Linux-Quellen unter eine proprietäre Lizenz gestellt und lediglich die BSD-Quellen unter der BSD-Lizenz veröffentlicht. Seit dem ist unser Treiber in allen BSD-Distris aber nicht mehr in Linux erhalten. Wir planen auch nicht mehr den Treiber in den Kernel einzubauen und bieten allen Kunden auf unserer CD und unserem FTP Linux-Treiber zum Download an.
Interessanterweise hat sich der Maintainer des Subsystems bei uns ein halbes Jahr später gemeldet und um Erlaubnis gefragt unseren Treiber in den Kernel einzubauen. Dazu müssten wir nur die Lizenz ändern und den Rest würde er übernehmen. Da war leider schon der Zug abgefahren, denn so groß ist der Linux-Markt auch nicht, dass wir uns von so einem brüskieren lassen müssen, nur weil er ein massives Problem mit seinem Ego hat (Zitat: "Solange ich der Maintainer bin, werdet ihr mit eurem Treiber nie in den Kernel kommen.").
Von Kevin Krammer am Fr, 27. August 2004 um 21:10 #
Wir planen auch nicht mehr den Treiber in den Kernel einzubauen und bieten allen Kunden auf unserer CD und unserem FTP Linux-Treiber zum Download an.
Ist das nicht bedeutend mehr Aufwand? Immerhin muss man dann für zig verschiedene Kernel und Distributionen Treiberpakete erstellen, testen und bereitstellen, einfach in den Kernel Source Tree klingt nach weniger Arbeit.
Da war leider schon der Zug abgefahren
Da haben sich die richtigen zwei gefunden. Zuerst das will das Ego des ersten nicht und jetzt schmollt das Ego des zweiten
zu dem Spiel gehören aber 2. Du bzw. deine Firma ist mindestens genauso auf einem Ego-Trip wie der Kernelmaintainer, somit wirst du den ersten Stein ohne frei von Schuld zu sein.
Von Jörg W Mittag am Fr, 27. August 2004 um 18:17 #
> Würden die Kernelmaintainer endlich mal einsehen dass eine offene Schnittstelle wichtiger ist als der Source würden auch mehr Hersteller einen Treiber für Linux anbieten.
Würden die Treiberschreiber endlich mal einsehen, dass die LKML keine Sklavenhorde ist, dann gäbe es eine solche Schnittstelle schon längst. Ich habe in den letzten Jahren mehrere dieser Treiber-ABI-Diskussionen auf LKML verfolgt, und der Standpunkt ist eigentlich klar: die Kernel-Maintainer halten eine solche ABI für überflüssig, nicht wartbar und nicht durchführbar. Und zumindest mit ersterem haben sie von ihrem Standpunkt aus definitiv recht. Sie haben aber auch klargemacht, dass sie eine solche ABI akzeptieren würden, sofern sie die üblichen Anforderungen erfüllt, sprich dem CodingStyle entspricht, gewartet wird, den Review-Prozess übersteht u.ä.. An diesem Punkt verschwanden in fast allen Fällen diejenigen, die noch kurz zuvor sich darüber beschwert hatten, dass sich die Kernel-Maintainer gegen eine solche ABI sperren würden und wurden nie wieder gesehen.
Also scheint es offenbar keinen großen Bedarf zu geben.
Abgesehen davon finde ich deine Kritik etwas unterspezifiziert. Es gibt Dutzende von Linuxen mit Dutzenden von Maintainern und Dutzenden von Entwicklungsmodellen. Vielleicht hast du deine Patches für die Implementierung einer Treiber-ABI einfach noch nicht an den richtigen geschickt?
> Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische
Ich kann nicht erkennen, was an: "Ihr wollt ein Feature, also schreibt eins oder bezahlt uns dafür." religiös sein soll. Linux ist freie Software, jeder kann es so modifizieren wie er möchte. Unter anderem kann er Linux eine Treiber-ABI verpassen und diese sich in der Praxis bewährt, sauber entworfen und implementiert ist und unter einer GPL-kompatiblen Lizenz steht, dann wird sie auch ihren Weg in den einen oder anderen Kernel finden.
> wird das eben weiterhin so bleiben dass es kaum Treiber geben wird.
In meinen Kernelquellen gibt es eine ganze Menge Treiber.
> In meinen Kernelquellen gibt es eine ganze Menge Treiber.
wobei man sich hier die frage stellen sollte, ob linux auch irgendwann für den desktopmarkt interessant werden will. wenn ja, werden da ganz andere als die in deinen jetzigen kernelquellen vorhandenen treiber benötigt werden. bei der ganzen sache darf man auch nicht vergessen, dass viele hardwarehersteller aus rechtlichen gründen keine spezifikationen herausgeben können, weil sie ihrerseits vertraglich gebunden sind (beispiel: hp-scanner mit realtek chipsatz). es ist also nicht so einfach, nur den hardwareherstellern die schuld zu geben. aber linux sollte vorerst das bleiben, was es ist, ein brauchbares serverbetriebssystem.
Würden die Kernelmaintainer endlich mal einsehen dass eine offene Schnittstelle wichtiger ist als der Source würden auch mehr Hersteller einen Treiber für Linux anbieten.
Wichtiger wofür?
Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische wird das eben weiterhin so bleiben dass es kaum Treiber geben wird.
Das was du "vermurkstes Konzept" nennst, ist für GPL-Freie Software wie Linux die Existenzgrundlage und Existenzsinn. Wenn du es ind den jetzt bereits 13 Jahren nicht gemerkt haben solltest, ging es den Entwicklern _nie_ darum den Propriäteren einen großen Marktanteil abzuringen indem sie sich deren propriäterer Mittel bedienen. Stattdessen ging es darum Software zu schreiben die frei ist und frei bleibt, und sie möglichst gut zu machen.
Wenn bei deinen Prioritäten die Freiheit nicht unangefochten an erster Stelle steht, dann bist du hier falsch.
Der Hersteller gibt seine Prinzipien nicht frei um mit Freier Software möglichst reibungslos zu funktionieren, wieso sollten Entwickler Freier Software ihre aufgeben um mit den Produkten dieses Herstellers möglichst gut zu funktionieren?
Damit du, dem nichts heilig ist, alles umsonst bekommst??
Das was du "vermurkstes Konzept" nennst, ist für GPL-Freie Software wie Linux die Existenzgrundlage und Existenzsinn. Das Konzept wie unter Linux Hardware abstrahiert wird ist vermurkst, das ist eine technische Frage keine Frage der Lizenz. In jedem anderen OS gibt es ein Interface dafür, nur unter dem ach so modernen Linux wird gerade in dem Bereich herumgeflickt wie vor 25 Jahren. Das ist einfach unakzeptabel und ich würde als Kernelentwickler einen roten Kopf bekommen wenn ich das Konzept verteidigen müsste oder gar die Worte 'modern' und 'Linux' in den Mund nehmen würde. Schau dir mal an was Apple als erstes in MacOSX eingebaut haben: eine saubere Hardwareschnittstelle. Die hat sich bis heute nicht geändert wurde nur ergänzt. Hardware wird sauber abstrahiert wie man das heute erwartet und weil es einfach selbstverständlich ist und nur Vorteile gegenüber dem monolithischen Gebastel bringt.
Wenn du es ind den jetzt bereits 13 Jahren nicht gemerkt haben solltest, ging es den Entwicklern _nie_ darum den Propriäteren einen großen Marktanteil abzuringen Ach Gott nicht wieder die Tour. Als ob da alle Entwickler der gleichen Meinung wären. Wenn Linux irgendwo kommerziell eingesetzt wird tanzen die Linuxfreaks im Kreis vor Freude aber wenn es Kritik hagelt kommt immer diese Ausrede. Linux steht schon mit einem Bein im kommerziellen Umfeld und da erwartet man einfach gewisse Dinge die selbstverständlich sind, das sollte auch den Kernelentwicklern einleuchten aber das tut dem angeknacksten Kernelentwicklerego nicht sonderlich gut wenn man zugeben müsste dass im Kernel manche Dinge einfach völliger Murks sind. Vielleicht sind sie auch nicht in der Lage sowas hinzubekommen und man redet sich mit fadenscheinigen Ausreden raus, so hört sich das für mich an. Dass die dieses kaputte Treibermodell unter Linux nichts taugt erkennt jeder der sich mal andere Platformen angeschaut hat. Aber wenn man Linux natürlich für das tollste hält und von World Domination faselt da helfen Argumente wenig. Komisch dass sich die World Domination konträr zu dem obigen Argument verhält dass man den Kommerziellen keine Marktanteile wegnehmen will.
indem sie sich deren propriäterer Mittel bedienen. Stattdessen ging es darum Software zu schreiben die frei ist und frei bleibt, und sie möglichst gut zu machen. 'Gut' ist was anderes als diese Bastelei bei den Treibern unter Linux.
Von Manfred Tremmel am Sa, 28. August 2004 um 20:40 #
Und was gewinnen wir damit? Schau Dir doch die Entwicklung von XFree an, seit die mit der Version 4 ein entsprechendes Treiberkonzept umgesetzt haben. Wie hat sich die Sache entwickelt. Bei Matrox gibts keine Specs und freien Treiber mehr für die neueren Karten, bei ATI gibts für neue Chips keine Specs und freien Treiber mehr für neuere Karten und bei NVidia gibts keine Specs und freien Treiber mehr. Alle drei Hersteller haben vorher freie Treiber bereitgestellt oder die freien Entwickler mit Specs unterstützt. Ich für meinen Teil mag Linux, weil es frei ist, nicht weil ich es für am technisch weitesten fortgeschritten halte (da würde ich im Desktopbereich wohl MacOS X einsetzen), ich finde die Unterwanderung im Grafikkartentreiberbereich schon schlimm genug und bete darum, dass man uns das nicht auch noch beim Kernel einbrockt, auf die Heise-/ProLinux-Meldungen von "nach Hause telefonierenden" Linux-Treibern würde ich liebend gerne verzichten..
Was erwarten die Linux Maintainer eigentlich? Das alle hardwarehersteller ihre specs,treiber sources und nen paar firmengeheimnisse offenlegen um linuxtreiber zu haben? FreeBSD bruestet sich sogar mit einer stabilen ABI fuer binaertreiber aber Linux scheint dazu zu fanatisch. Welcher hardwarehersteller hat den schon opensource treiber selber herausgegeben? Alle open sourceTreiber die ich nutze sind von dritten geschrieben. Klar es gibt den weg mit kernel stubs die quelloffen sind und dann eine stabile ABI fuer nen binaermodul liefern, aber das bringt auch keine open source treiber und verkompliziert die treiberentwicklung nur und schreckt vll Hersteller ab.
"Welcher hardwarehersteller hat den schon opensource treiber selber herausgegeben?"
Nvidia z.B., dabei meine ich jetzt nicht den Grafikkartentreiber sondern z.B. Patches für IDE, Sata Controller etc, lese ja immer mit auf der IDE Mailingliste und regelmäßig submitted da jemand von nvidia sourcen, die dann von JeffGarzik beispielsweise in sein Module einbaut.
Was erwarten die Linux Maintainer eigentlich? Das alle hardwarehersteller ihre specs,treiber sources und nen paar firmengeheimnisse offenlegen um linuxtreiber zu haben?
Exakt.
Linux' wichtigste Eigenschaft, und die Eigenschaft die ihn zu dem gemacht hat was er heute ist, ist die strikte GPL-Konformität. Wenn man auf GPL-Ideale eh pfeift, kann man auf die pragmatischeren BDSs umsteigen, oder gleich bei den propriäteren Lizenzverkäufern bleiben.
Das Existenzziel von Linux und anderer Freien Software ist es nicht möglichst vielen Hardwareherstellern dorthin zu kriechen wo die Sonne nicht scheint, sondern frei zu sein und frei zu bleiben.
Es scheint aber so dass für dich und dir ähnliche, das einzig wichtige an Linux seine kostenlose Natur ist. Schnorrer halt. Beteilige dich als hier lieber an so ner HartzIV-Demo, dann bist du wenigstens unter deinesgleichen.
Der Punkt ist, daß der pwc-Treiber bereits im Kernel enthalten war, und nun nachträglich beschlosen wird, ihn aus Gründen politischer Korrektheit wieder herauszuwerfen. Daß daran zwei -soll man sagen Kindsköpfe?- beteiligt sind, ist richtig, Nemosoft hätte nicht tabula rasa machen müssen, aber man stelle sich den Extremfall vor: Jemand hat gestern gecheckt, daß eine Webcam unter Linux unterstützt wird, kauft sich heute das Gerät, und stellt fest, daß über Nacht die Treiber verschwunden sind. Super. Und wer bitte sagt, daß nicht irgendwo im kernel irgendeine Funktion steckt, die zufälligerweise nur vom Nvidia-Treiber benützt wird, und die deshalb morgen herausgerupft wird? Oder die Sedlbauer-Speedfax-ISDN-Karte, die ich deshalb habe, weil es zeitweise die einzige preislich annehmbare Faxmöglichkeit mit ISDN unter Linux war, und die bei der Initialisierung eine Firmware lädt? Kommt demnächst jemand auf die Idee, daß das wegen irgendwelcher Lizenzprobleme nicht sein darf, und die Karte nicht mehr unterstützt wird? Muß man zukünftig nicht nur eruieren, ob eine Hardwarekomponente von Linux unterstützt wird, sondern muß man auch noch den Treiber auf politische Korrektheit überprüfen? Das kann es ja wohl nicht sein. Notabene, ich plädiere nicht für closed-source-Treiber, ich setze sie nolens volens ein, soweit sie nicht grundlegende Systemfunktionalität betreffen, ich möchte kein Treiber-ABI für Linux, und es geht mir nicht um Freibier.
Von Captn Difool am Mo, 30. August 2004 um 12:00 #
Richtig. Alle wünschen sich und begrüßen es, wenn Linux auch kommerziell, sprich in Firmen und Behörden eingesetzt wird. Gleichzeitig werden aber "heilige Kriege" vom Zaun gebrochen, wenn ein propritärer Firmentreiber verwendet werden soll.
Philips hat aus Problemen, das Kompressionsverfahren zu patentieren (was auch viel Verwaltungsaufwand und Kosten nach sich zieht) die Geheimhaltung bevorzugt. Bei einem Linuxmarktanteil auf Desktops von unter 5% kann es dem Großkonzern ziemlich Schnuppe sein, ob Linux unterstützt wird oder nicht. Aber man tat es trotzdem und ich war froh die Kamera benutzen zu können. Die Kamera (740k) taugt u.a. sehr gut für Astronomie wegen ihre guten Lichtempfindlichkeit, was kein Konkurrenzmodell bietet. Daher meine Entscheidung für die PWC.
Wesentliche Kernelfunktionen müssen frei sein und bleiben, ganz meine Meinung. Aber es sollten Schnittstellen da sein, wo propritäre Hardware per Modul eingebunden werden kann. Was ist nun dabei? In letzter Konsequenz müßte dann auch die Hardware frei sein, was das Ende solcher Hardware wäre. Also Leute, bitte mal auf dem Teppich bleiben und nicht zum GPL-Ayatollah mutieren. Wenn Linux für alle da sein soll, muß man ihm auch genügend Luft zum atmen lassen.
Hinzu kommt natürlich der Marktdruck von M$ (wo keiner der Treiber offen sein muß). Daran wird sich bei allem Wunschdenken auch nicht viel ändern. Die Hardwarehersteller müssen erstmal diesen Markt bedienen und man kann dankbar sein, wenn die Treiber auch für Linux zur Verfügung stehen. BTW. Der Webcamtreiber von Nemosoft war um einiges bedienungsfreundlicher und stabiler als der Windoofstreiber von Philips. Daher fände ich es nur gut, wenn sich weiter begabte Hacker um Linuxtreiber mit Herstellersupport kümmern dürfen, anstatt ihnen unnötig Knüppel in die Beine zu werfen. Wer von den selbsternannten GPL-Ayatollahs schreibt denn die offenen Treiber um? Wer von den vielen Schreihälsen hat denn den Quellcode auf der Platte und versteht ihn? (ganz zu schweigen, daß er den Treiber verbessern kann...)
Daher kann ich weiter oben auch nur zustimmen, daß manche Maintainer ziemlich arrogant daherkommen, dieses Auftreten treffe ich ohnehin auffallend häufig in der EDV-Branche an....
> Das alle hardwarehersteller ihre specs,treiber sources und nen paar firmengeheimnisse offenlegen um linuxtreiber zu haben?
nein das erwarten sie sich nicht (wenn es ihnen auch lieber wäre). das problem ist dass der opensource-treiber (der unter der gpl steht, und im kernel enthalten war), diesen nicht gpl treiber nächläd, somit wäre danach der binär treiber dann einen teil des gpl treibers.
ob das nun richtig, falsch oder kleinlich ist kann ich nicht beurteilen, ich bin kein rechtsexperte und kenne der GPL zu wenig.
doch meiner meinung ist auch die reaktion des treiberentwicklers etwas übertrieben. wo wäre dass problem wenn man den GPL treiber die möglichkeit des nachladens entfernen würde, und den binärtreiber als komplettes komplettes extra-modul anbieten würde, bei dem dann halt eine meldung kommt dass es nicht unter der GPL steht.
Wenn man mit einem etwa briefmarkengroßen Bild zufrieden ist, kann man auf den Binärtreiber verzichten. Der Binärtreiber muß überhaupt nicht geladen werden, und schon gar nicht wird er vom GPL-Teil automatisch geladen. Das Ganze spielt sich in /usr/src/linux/drivers/usb/pwc-uncompress.* ab. Der GPL-Treiber hat eine Funktion zum Registrieren von "Dekompressoren". Je nach den registrierten Dekompressoren wird die Kamera in einen bestimmten Arbeitsmodus eingestellt. Die Dekompressoren selbst sind in dem Binärmodul enthalten. Nun könnte man sich eine hypothetische Webcam vorstellen, die entsprechend dem GPL-pwc-Treiber funktioniert, und ihre Bilddaten mit einem bekannten Algorithmus A komprimiert, und dann für A einen GPL-Dekompressor schreiben. Nur real gibt es eine solche Webcam nicht. Die Kompressionsalgorithmen, die von den real existierenden Webcams verwendet werden, werden vom Hersteller nicht verraten, und entsprechend gibt es keine Open-Source-Dekompressoren. Das heißt aber, wie gesagt, nicht, daß der Open-Source-Teil nur in Kombination mit closed-source-Komponenten verwendbar wäre; so, wie ich das nach oberflächlicher Durchsicht sehe, trifft das nicht einmal auf die inkriminierte Registrierungsfunktion für die Dekompressoren zu. Das wiederum bedeutet, daß der kritische Punkt das Laden des Binärmoduls ist, und zwar deshalb, weil dabei non-GPL-Code zu GPL-Code hinzugebunden wird. Nur: Innerhalb der Kernelquellen, im Zweig drivers/usb/pwc*, ist nichts, was gegen die GPL verstoßen könnte (wohlgemerkt, nach oberflächlicher Durchsicht). Deshalb halte ich die Aktion von Greg Kroah-Hartmann auch sachlich für falsch.
> Das wiederum bedeutet, daß der kritische Punkt das Laden des Binärmoduls ist, und zwar deshalb, weil dabei non-GPL-Code > zu GPL-Code hinzugebunden wird. Nur: Innerhalb der Kernelquellen, im Zweig drivers/usb/pwc*, ist nichts, was gegen die > GPL verstoßen könnte (wohlgemerkt, nach oberflächlicher Durchsicht). Deshalb halte ich die Aktion von Greg > Kroah-Hartmann auch sachlich für falsch.
was anderes habe ich ja auch nicht gesagt.
die frage ist nun ob es laut GPL erlaubt ist nachträglich den nicht gpl code zu laden, und zu verwenden.
wie ich schon sagte will ich darüber aber auch kein urteil abgeben ob dass nun richtichtig oder falsch ist. doch offensichtlich fällt es zumindest in eine rechtliche grauzone die geklärt werden muss, der eine behauptet ist erlaubt, und der andere sagt es ist nicht erlaubt.
also warum nicht einfach einen klare grenze zwischen nicht gpl treiber, und gpl treiber ziehen? wenn der gpl treiber keine möglichkeit hätte nachträglich code zu laden, gäbe es auch kein problem damit. leute die volle auflösung wollen, können sich von jemand dritten einen 100% nicht gpl treiber besorgen (wie es z.b. bei nvidia ist).
Ich finde das Verhalten der beiden beteiligten (Treiberentwickler und USB Maintainer) irgendwie extrem Kindisch. Den Hook zu entfernen kann ich ja noch nachvollziehen, der Lizenzprobleme wegen. Aber dann gleich den Märthyrrer machen und den GPL konformen Code mit entfernen zu lassen ist eine Frechheit gegenüber allen Linux Usern, die seit langem eine Philips Webcam ihr eigen nennen. Damit ist meine Philips 2UCam nun ein Anwärter für die nächste Ebay Auktion. Danke für nix!
Ja was mir gleich satt aufgestoßen ist, war der Wunsch des Nemosofties, dass jetzt sein GPL Code aus dem Kernel muss, das ist schon ein Witz, wenn man was unter GPL stellt, dann ist das unter GPL, hätte er sich vorher überlegen sollen.
Nun, eventuell wird sich dann irgendwo im Netz ein entsprechender Patch finden. Tortzdem: die letzten Jahre konnte man sich zumindest bei dieser Cam auf einen im Kernel vorhandenen Treiber stützen.
Mein Tip an alle, die jetzt evtl. auch nach einer neuen WebCam suchen: die Aiptek HyperVcam Mobile tut's auch und ist nicht ganz so kostspielig...
was soll die panik? die großen distributoren werden doch eh entsprechend gepatchte kernel rausbringen, womit die kamera genauso laufen wird wie vorher. wenn du allerdings die offiziellen kernel verwendest: viel spaß beim patchen
und jetzt wird der Treiber nicht weiterentwickelt? Kann schon allein wegen ständig auftauchender Sicherheitslöcher im Kernel nicht ewig bei Kernel 2.6.7 mit pwcx9.0beta2 bleiben. Mit Kernel 2.4.2x hatte ich immer Kerneloopses mit anschliessendem Totalcrash, wennś zu oft oder im falschen Speicherbereich dazu kam. pwc.o und snd-usb-audio durfte ich nie zusammen verwenden. Jetzt geht das alles, aber ich will, dass das Projekt weitergeführt wird.
Werd meine Logitech Quickcam 4000 Pro nicht wegwerfen. Ich hoffe, hier kommen noch dutzende Webcam-Nutzer zusammen und bewirken, dass wir einen neuen Maintainer finden.
Schon schade, hatte selbst mal so eine Phillips-Webcam und der Treiber war ziemlich gut. Allerdings bin ich mittlerweile froh nicht mehr so ein dämliches Ding auf dem Monitor zur haben Vielleicht findet sich ja noch ein neuer Maintainer, ansonsten werden dann halt Linuxer in Zukunft keine Webcams dieser Firma mehr benutzen können - ist zwar traurig, ist aber so.
der kack an binären treibern ist, dass sie plattformabhängig sind. hey, die welt besteht nicht nur aus x86!
ein paar links, die jemand auf heise gepostet hat: http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1453.html http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1460.html http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1475.html
'Whenever somebody says "accept the driver to help users", they are missing the big picture. A binary driver SCREWS OVER users on other architectures. It pretty much guarantees that those other architectures will never be supported.'
Von Jörg W Mittag am Sa, 28. August 2004 um 05:50 #
Korrekt. Nehmen wir mal das Beispiel nVidia, weil diese noch eines der positivsten Beispiele sind. Alleine der Linux-Kernel von Linus Torvalds läuft auf ca. 20 Architekturen. Dazu kommen noch eine ganze Menge anderer Linux-Kernel von größeren (z.B. µClinux, 5 zusätzliche Architekturen) oder kleineren (z.B. Linux/VAX, 1 Architektur) Entwicklergruppen und es gibt auch noch den einen oder anderen Embedded-Hersteller, der Linux auf seine proprietäre Architektur portiert hat, diese Portierung aber nicht in einen der großen Kernel einfließen lassen will. Alles in allem würde ich mich nicht wundern, wenn Linux auf etwa 30 Architekturen liefe.
Von diesen haben, grob geschätzt, mindestens ein Dutzend PCI, das heißt ein Dutzend könnte potenziell auch AGP haben (AGP ist ja mit PCI stark verwandt). Davon hat schätzungsweise ein halbes Dutzend tatsächlich AGP. nVidia veröffentlich seine Treiber aber gerade mal für drei Architekturen, also die Hälfte derjenigen, die derzeit AGP haben, ein Viertel derjenigen, die jederzeit AGP bekommen könnten und gerade mal ein Zehntel aller Architekturen. Die anderen schauen in die Röhre.
Wie oben schon geschrieben, stellt nVidia mit drei unterstützten Architekturen, zwei Kernelserien und zwei(?) X Servern tatsächlich noch ein Positivbeispiel dar, andere unterstützen nur eine Architektur, eine Kernelserie und nur bestimmte veraltete Versionen eines bestimmten X Servers (um mal beim Beispiel von Grafikkarten zu bleiben). Ein anderer funktioniert nicht mit Grsecurity, wieder andere funktionieren nicht mit CONFIG_4KSTACKS=y oder funktionieren nur auf bestimmten Versionen bestimmter Distributionen.
Daher ist stimme ich dem o.g. Zitat zu: zwar behaupten die Hersteller, dass Binary-Only-Treiber gut für Linux-Nutzer seien, weil sie es ihnen ermöglichen, ein Gerät zu nutzen, das sie sonst nicht nutzen könnten, wenn es keinen Treiber gäbe. Tatsächlich ist es aber so, dass Binary-Only-Treiber schlecht für Linux-Nutzer sind, die die "falsche" Architektur nutzen, da sie es ihnen unmöglich machen, ein Gerät zu nutzen, welches sie sonst nutzen könnten, wenn es einen freien Treiber gäbe. Dieses Argument ist natürlich hinfällig, wenn ein Hersteller seine Treiber für alle 30 Architekturen, für alle 4 derzeit noch aktiven Kernel-Serien (2.0, 2.2, 2.4, 2.6), für alle Kobinationen von Konfigurationsoptionen aller Varianten von Linux (-mm, -aa, SuSE, Fedora, Debian, Mandrake, Grsecurity, -mcp, FOLK, -tiny, -ck, -np, ...) anbietet. Aber solange die Hersteller das nicht tun, kann man einen Binary-Only-Treiber eigentlich nicht akzeptieren. (Es gibt natürlich andere Aspekte, wie z.B. Aspekte der Computersicherheit, betriebswirtschaftliche Aspekte (z.B. Investitionssicherheit) o.ä., die da auch noch mit hinein spielen.)
Das ist wohl die logischste und kosequenteste Auslegung. Hm, ich würde mich als Besitzer einer Philips Webcam wohl ärgern, aber wahrscheinlich hätte ich mich schon vorher geärgert, dass der Treiber doch nur unter ganz bestimmten Voraussetzungen läuft.
Insofern nutze ich lieber eine Hardware gar nicht als mir von der Hardware vorschreiben zu lassen, was ich für Software benutze.
Ja das ist _WIRKLICH_ ein Problem. Vorallem wenn man bedenkt das es auch Nvidia-Karten auf PCI(!) Basis gibt. Somit kannst du deine Abstraktion über AGP weglassen. Es sind ALLE Systeme Betroffen die einen PCI-Bus haben.
Momentan hab ich das Problem. Meine AXi würde sich über etwas schickeres als die momentane Mach64 freuen. Aber ich kann mich nicht durchringen, eine Karte mit 64MB+ zu kaufen, wohl wissend, das ich die 3D Fähigkeiten nie nutzen werde können. Also bleibt die Mach64 drin und ich ärgere mich weiter über Nvidia, ATI und Co.
PS: ebenfalls ein Ärgernis sind übrigens WLAN-Karten, aber auch Soundkarten.
Hol dir doch einfach ne etwas ältere ATI. Ich habe hier ne Radeon 7500 unter FreeBSD mit dem freien Standard-Treiber laufen. OpenGL mit Hardware-Beschleunigung ist kein Problem, wenn der Treiber auch nicht das Letzte aus der Karte herausholt. Soweit ich weiß sind für alle ATI Chipsätze kleiner als Radion 9500 zumindest rudimentäre Specs vorhanden. Ist auf jeden Fall um Welten besser als ne Mach64
Genau, für viele ATI-Grafikkarten gibt es eine quelloffene DRI-Lösung, die ab und zu mal Darstellungsfehler hat oder bei der Perfomance in bestimmten Punkten einbricht, aber insgesamt sollte sich die Leistung gegenüber deiner alten Karte erhöhen lassen.
Bei einer 20EUR-gebraucht-Karte würde ich das hinnehmen, bei einer Radeon X800 XT würde ich nie einen Treiber akzeptieren, der einen Teil der Leistung nicht abrufen kann. Immerhin zahlt man im Enthusiasten-Segment für die letzten 10% mehr (hardwareseitig vorhandene) Leistung für's Topmodell locker über 100EUR mehr. Wer eiert den Windowsern denn gern 20-30% hinterher, wenn er dasselbe dafür bezahlt hat?
Kein Wunder, dass die Petition für bessere ATI-Treiber die 10000er-Marke längst überschritten hat ;-)
http://www.petitiononline.com/atipet/
Für ATI wären 10000 Kunden aus der Linuxecke aber gerade mal eine 7stellige Summer mehr Umsatz und wahrscheinlich geht es denen derzeit gut genug, so dass sie sich um diese Summe zur Zeit nicht kümmern müssen.
Von Manfred Tremmel am So, 29. August 2004 um 02:35 #
Ich möchte mich dem gesagten anschließen und noch einen weiteren Punkt hinzufügen: Investitionssicherheit. Wenn ein Hardwarehersteller pleite geht, aufgekauft wird, oder die Führungsriege einfach mal entscheidet, Linux nicht mehr zu unterstützen, dann steht man mit einem Binary-Only Treiber immer vor dem Problem, dass das "gute" Teil eben nicht weitergepflegt wird. Bei API Änderungen im Kernel (oder X wenns ein Grafikkartentreiber ist), kann man das Teil dann vergessen, oder ewig auf der alten Version sitzenbleiben, bis man von Würmern, Viren und Hackern zerpflückt wird. Bei freien Treibern hat man immer noch die Möglichkeit die anzupassen oder anpassen zu lassen.
Zu den Architekturen, ich finde sowas kommt gerade bei Ankündigungen viel zu kurz. Da heißt es immer "Firma XYZ bringt eine Linux-Version von Programm XXX heraus", wenn man dann aber hinschaut, gibts in aller Regel ne IA32 Version und das wars, mit nem PowerPC, MIPS, ARM, ... steht man da im Regen. Finde ich sehr schade sowas.
Open Source Treiber sind natürlich besser als Binäer-Treiber. Aber es ist auch Mist einfach mal die Schnittstelle zum Betriebsystem zu ändern. Das hätten die sich für den Kernel 2.8 aufheben sollen. Wenn die Scnittstellen ständig geändert werden helfen OS-Treiber auch nicht viel, da diese dann ständig angepasst werden müssen.
| Wenn die Scnittstellen ständig geändert werden helfen OS-Treiber auch nicht viel, da | diese dann ständig angepasst werden müssen.
Aber immerhin gibt es die Möglichkeit, diese anzupassen. Stattdessen ist man auf die Gut- mütigkeit des Herstellers angewiesen, die notwendige Anpassung vorzunehmen oder es eben nicht zu tun.
Aber was zur Hölle geht eigentlich bei den Herstellern vor? Wieso kommen die auf die Idee, immer mehr "Wissen" in die Treiber zu verlagern statt ihr Know How in der Hardware selber oder in deren Firmware unter zu bringen? Das ist das eigentliche Problem, was die Endan- wender daran hindert, ein Betriebssystem nach Wahl einzusetzen, ohne dabei gravierende Qualitätverluste hinzunehmen bzw. ganz auf Unterstützung zu verzichten. Ganz besonders kann man das am Beispiel Drucker und Scanner sehen. Meine beiden Epson-Geräte funktionieren zwar auch mit OS-Treibern, aber sowohl Geschwindigkeit als auch Qualität sind gegenüber den CS-Treibern beinahe katastrophal. Wer schon mal mit CUPS und gimp-print auf einem Epson Stylus C8x in höchster Qualität auf Folie ausgedruckt hat, weiss, dass man dabei mehr als nur eine Tasse Kaffee trinken gehen kann. Die Qualität ist allerdings brauchbar. Mit den Turboprint-Treibern dagegen ist die Qualiät nochmal besser, die Geschwindgkeit ist aber wohl um den Faktor 3 bis 4 höher. Das selbe gilt für den Vergleich Epson-Scanner und xscanimage gegen Epson-Scanner und iscan. Die iscan-Qualität schlägt xscanimage um LÄNGEN.
Statt die Hersteller diese Treiber-Features irgendwo in der Hardware (auf einem Chip, in der Firmware) unterbringen und von aussen nur den nackten Befehlssatz benötigen, gehen Sie den meiner Meinung nach umständlicheren Weg. Auf der Strecke bleiben Benutzer, die eben kein Betriebssystem nutzen, das dem Hersteller in den Kram passt. Wobei eine Werbung ala "Funktioniert unter ALLEN Betriebssystem mit gleicher Geschwindgkeit/Qualität" sich doch deutlich besser machen würde als "Systemvoraussetzung: Win2000 oder neuer, Mac OS X". Und wegen dieses Schwachsinns ist man dann auch gleich noch gezwungen, für einen schnöden Print-Server im Netz teurere Hardware anzuschaffen, als für die eigentliche Aufgabe nötig ist. Zum Kotzen!
Was zahlt MS den ganzen Peripherie-Herstellern eigentlich dafür, dass sie die Endanwender derart verarschen?
Waehre ich ein Hersteller von Hardware waehre mein Ziel doch, mehr Hardware zu verkaufen als die Konkurrenz, und dabei noch pro verkaufter Einheit einen moeglichst hohen Profit zu machen. Ob da jemand meinen Treiber Millionenfach kopiert und weiterverteilt ist doch vollkommen egal, ohne die dazugehoerige Hardware ist der Treiber doch nutzlos, und die laesst sich nicht softwaremaessig kopieren.
Noch ein Vorteil eines GPL - lizenzierten Treibers: Jeder kann das Ding debuggen, das heisst ich muss selbst die Erstversion erstellen, ein bisschen selbst debuggen und zunehmend bekomme ich Probleme von der Community geloest. Wenn ein Konkurrent den Treiber oder Teile davon fuer sein Produkt hernimmt muss er den Quellcode ja ebenfalls freigeben, das heisst der Taktische Status quo waehre ebenfalls wieder hergestellt.
Irgendwie kommt mir vor, die Firmenbosse checkens net.
Geri
Das Problem ist, daß man anhand des Treibers u.U. Rückschlüsse ziehen kann, wie die Hardware arbeitet und eben diese Informationen will man nicht preis geben.
dann is das geheimniss ja auch weg!
Jajaja! es gibt auch "verschlüsselte" binaries, aber das sind doch ausnahmen. es geht doch nur um copyrights und patente.
> wie die Hardware arbeitet und eben diese Informationen will man nicht preis geben.
bei grifikkarten, bei denen man durch effizente alogrithmen ein paar wichige prozente herraus holen kann, kann ich dass noch verstehen.
doch dass "wie die hardware arbeitet" ist ein billiges argument der hardwarehersteller.
1. dürfte viele hardware, für welche keine treiber oder spezifikationen veröffentlicht werden, alles andere als technologisch wertvoll sein. so ist z.b. das innenleben vieler hardware (billig scanner, webcams, ...) im großen und ganzen geich, weil sowieso zugekaufte billig komponenten verwendet werden.
2. z.b. wollte intel lange keinen OSS treiber für das ipw2100 wlan-modul veröffentlichen (auch mit dem argument die arbeitsweise der hardware zu schützen). mittlerweile gibt es den treiber, und ich denke nicht dass sich an dem problem der arbeitsweise was geändert hat, höchstens was in den köpfen der manager.
3. gibt es aussagen von treiber entwicklern, nach denen man durch reverse engineering weit aus mehr über die HW herrausfindet, als wenn man nach offenen spezifikationen arbeitet.
-Komprimierung des USB Datenstreams, Philips hat hier eben viel auf die Hostseite gebracht und möchte verständlicherweise hier andere Parteien nicht einladen.
Ob die ganze Diskussion dem eigentlichen Ziel, "..liebe Hersteller, macht bitet gpl code.." näher kommt, bezweifle ich; es wird genau das Gegenteil erreichen, ein negatives Signal wird gsetzt.
Anhand des kleinen pwcX Beispiel zeigt sich aber auch, wieviel "Ausfsehen" jene Grundsatz Diskussion erzeugt hat.
so long,
Patrick
Ein Treiber ist ja eine Art Minibetriebssystem. Und es gibt halt bessere und schlechter programmierte Betriebssysteme
Das Thema ist komplexer, als es manch einer wahr haben will. Ich mag auch OS-Treiber, aber ich weiß auch, daß OS nicht immer wirklich funktioniert.
Das weiter kann der der Nachbaut den Treiber verwenden und spart sich enorme Kosten bei der Softwareentwicklung und beu geräten die weit aus teurer sind als so eien Webcam macht sich das beid er Entwicklung bemerck bar.
Das soll jetzt nicht heißen, dass ich gegen open source bin. Ich bin dafür. Ich kann halt Firmen in solchen Bereichn verstehen, den da geht es um Millionen im Entwicklungsbereich was so eine Entwicklung kostet.
und ohne dem Quellcode des Treibers wird er Hacker gezwungen die Hardware zu untersuchen wie sie funktioniert und dabei kommt nicht selten mehr an die Öffentlichkeit als wenn man einfach die Treiber Informationen veröffentlicht hätte
>Das weiter kann der der Nachbaut den Treiber verwenden und spart sich enorme Kosten bei der Softwareentwicklung
1. baurcht der Hersteller seinen neuen Chip nur patentieren und schon baut es niemand mehr einfach so nach
2. Wegen den Kosten der Treiberentwicklung, wenn der Treiber der 1. Firma eine copyleft Lizenz hat, dann wird er auch wieder an das Ergebniss der 2. Firma kommen und so selber wieder Geld sparen...
So einfach ist es nicht einfach einen Chip zu untersuchen ohne Pinbelegung. Geschweigeden den Schaltplan aus dem Layout zu entwerfen.
Ich hab das mal bei einer Schaltung mi 3 ICs die jeweils 16 Pins haben. Das ist nicht gerade einfach und jetzt hab mal eine Platine mit 40-50 ICs da geht mal ohne Schatplan nichts mehr. ich Repariere solche Platinen und selbst mit Layout und Schaltplan mußt du da kämpfen dass du ein Leiterbahn verfolgen kannst.
Aber dafür gibt es Programme die dir die Lage der Leiterbahn zeihgen, hlat nur wenn du das Layout auf dem PC hast.
>1. baurcht der Hersteller seinen neuen >Chip nur patentieren und schon baut es >niemand mehr einfach so nach
>2. Wegen den Kosten der >Treiberentwicklung, wenn der Treiber der >1. Firma eine copyleft Lizenz hat, dann >wird er auch wieder an das Ergebniss der >2. Firma kommen und so selber wieder Geld >sparen...
Da wird dann mal ein paars Sachen verändert und gut ist und schon ist nichts mehr mit Lizenz.
Udn nicht jeder der Geräte netwickelt entwirft auch den Chip dazu, der wird meißtes eingekauft udn somit kann jeder den Chip kaufen.
Diese Kompressionsverfahren und noch andere Bildoptimierungsroutinen will Phillips nicht herausgeben, weil sie es als Entwicklungsvorsprung sehen. Deshalb durfte der Autor nur nach Unterzeichnung eines NDA einen Binärtreiber entwickeln, aber keine Sourcen rausgeben.
Die Cam ist aber mit dem GPL-Modul allein nutzbar, allerdings nur in Minimalauflösung, die man z.B. um Fotos für ne eBay Auktion zu machen schon kaum noch nutzen kann. Nur wenn man das Binary-Modul dazu lädt, kann man die volle 640x480 einstellen und die Bildqualität verbessert sich.
Übrigens gab es damals eine heftige Auseinandersetzung mit Alan Cox (irgendwo auf der Website des Autors ist der Thread abgedruckt), weil der bestimmte Videofunktionalitäten vom Kernel- in den Userspace schieben wollte, das aber viel zu umständlich gewesen wäre und rein religiöse Gründe gehabt hätte.
Nix religiöse Gründe, sowas gehört nunmal in den Usermode. Grundsätzlich sollte nur das allernotwendigste im Kernelmode laufen, vfs, scheduler, pager und ipc, der Rest kann in den Usermode.
Und was binäre Treiber angeht: Ich lehne sie ab, schon aus Sicherheitsgründen. Auch in der Firma gibt es das nicht, wenn Hersteller nicht kooperieren, kommt die Konkurrenz zu Zug -- sowas nennt sich freie Marktwirtschaft. Niemand kann gezwungen werden, freie Treiber für seine Produkte zu entwickeln bzw. deren Entwicklung zu ermöglichen, aber dann sollen sich die Betreffenden bitte auch nicht beschweren, wenn niemand ihre Produkte kauft.
Bei unfreien Treibern könnte man sich z.B. folgendes Szenario vorstellen: In bestimmten Frequenzbereichen der Karte schickt der Treiber gezielt Informationen aus dem Speicherbereich des Prozesses, der das Paket abgeschickt hat. Natürlich verschlüsselt. Wie lange es wohl dauert, bis einer dahinterkommt, wenn der Bereich außerhalb des normalen Empfangsspektrums einer Netzwerkkarte ist?
Genau solche Unsicherheiten und schnellschuss Entscheidungen halten sicher viele von Linux fern.
Als ich damals die Webcam gekauft hatte, waren die Philips Cams die einzigen unter Linux vernünftig unterstützten. Nennt mir doch bitte einige gute Alternativen
Das spezielle Problem bei diesem Treiber scheint, wenn ich das richtig verstanden habe, dass er im Kernel selber etwas braucht dessen einziger Daseinszweck es ist das Laden eines Closed Source Moduls zu ermöglichen. Dies aber ist nach Ansicht der Kernel Maintainer eine Verletzung der GPL.
Eine kurze Anmerkung am Rande, andere closed source Module, zum Beispiel die von Nvidia benötigen so etwas nicht.
Es handelt sich also um kein ideologisches, sondern um ein rechtliches Problem.
Wer genaueres wissen will, sollte sich folgende Diskussion zu Gemüte führen: http://lkml.org/lkml/2004/8/24/278
Die Rückforderung von seinem GPL Code, die der Treiber Coder verlangte, ist allerdings nicht GPL Konform. Damit zeigt sich das der Knabe keine Ahnung von der GPL hat. Zu guter letzt kommt man dann auch auf das Themea man sollte eben nur Produkte kaufen, die pro Linux eingestellt sind.
Er hat darum gebeten, und aus Gründen des Anstands gewährt man ihm die Bitte (also zumindest, wenn es nach Linus geht).
könnte er, aber wie du und CE bereits gesagt haben, zeigen sich die kernel-entwickler grosszügig und gewähren ihm die bitte, obwohl sie es natürlich nicht müssten.
Der Treiber bestand aus den Moduln pwc und pwcx; ersterer ist open-source, letzterer nicht. "Was der Treiber braucht" ist ein Hook in pwc, um pwcx laden zu können. Der Treiber als Gesamtheit von pwc und pwcx braucht nichts externes im kernel.
Für mich ist der Sachverhalt so, daß ich vor ein paar Monaten eine solche Webcam gekauft habe, in Kenntnis der Treibersitution, also daß das gerät mit pwc alleine in geringerer Auflösung und mit dem closed-source pwcx in voller Auflösung läuft. Von dem Hook, der die jetzige Malaise ausgelöst hat, wußte ich nichts. Für mich kommt aus heiterem Himmel, daß ein seit Jahren existierender Treiber, den ich brauche, ab sofort eingestellt ist. Soll ich mich bei der Hardwareauswahl auch noch um irgendwelche kindergartenpolitische Dämlichkeiten kümmern, die hinter den Kulissen ablaufen und möglicherweise irgendwann aufbrechen? Das ist einfach SCHEISSE, und ich bin zum ersten Mal richtig sauer auf Linux, weil hier eine Auseinandersetzung auf dem Rücken der Benutzer abgeladen wird. Zusammen mit der komischen Ankündigung, in Zukunft die Stabilität der Kernel den Distributoren zu überlassen, und meinen Erinnerungen an das, was diverse Distributoren so alles herumgepatcht haben, muß ich konstatieren, daß Linux auf dem Weg in den Abgrund ist.
> Eine kurze Anmerkung am Rande, andere closed source Module, zum Beispiel die von Nvidia benötigen so etwas nicht.
Ach ja? Kann man sich da so sicher sein? Und wer sagt, daß nicht morgen irgendein andersgeartetes "rechtliches problem" mit dem Nvidia-treiber auftaucht?
Kroah-Hartmann schreibt an der von dir angegebenen Stelle:
> Actually, in thinking about this even more, I just realized that I have
> to rip this hook out. I say this because we are allowing a change to
> the kernel that is needed _only_ for a closed source module. See
> Linus's comments about "if a change is needed to be made to the kernel
> in order to get a closed source module to work, that module must be made
> opensource" or something close to that.
>
> So, I'll rip this out with the next round of USB patches that I send off
> to Linus.
>
> Nemosoft, any thoughts?
Wenn also Linus einen Kommentar abgibt, müssen die Benutzer zukünftig auf ihre Hardware verzichten. Wenn man das Kriterium von Kroah-Hartmann zugrunde legt, hätte der betreffende Treiber überhaupt nie in den kernel aufgenommen werden dürfen. Dann hätte Nemosoft ihn entweder als kernel-externes Projekt betrieben, oder auch nicht, es wäre aber nicht zur jetzigen Malaise gekommen. Und nochmal, der Punkt ist: MAN KANN MIT DEN BENUTZERN NICHT SO UMSPRINGEN. Das ist genau die Art von Unsicherheit, die Microsoft gegen Open-source-Software ins Feld führt. Anscheinend hat Microsoft recht.
Wie schon gesagt ist es bei diesem Treiber eine spezielle Situation eben weil er, wie du richtig bemerkt hast, einen Hook im Kernel brauchte. Nun bin ich kein Anwalt, kann also nicht wirklich einschätzen inwieweit die Einschätzung von Linus und Kroah-Hartmann richtig ist, dass dies eine Verletzung der GPL ist, unproblematisch ist es aber sicherlich nicht. Und wie nvidia zeigt geht es ja wohl auch anders.
Was mich an der ganzen Sache wirklich stört ist, dass ich das Gefühl habe wir haben es hier vor allem mit einem Ego Problem aller beteiligten zu tun.
Du hast natürlich recht, dass der Treiber so eigentlich nie in den Kernel hineingedurft hätte, aber wenn man einen Fehler gemacht hat, dann heißt das doch nicht, dass man ihn nie mehr korrigieren darf. Allerdings finde ich die Art und Weise (Ich schmeiß das raus, was sagst du dazu?) nicht wiklich gelungen. Das kann man eleganter lösen.
Gleiches gilt aber auch für Nemosoft. Anstatt über Alternativen nachzudenken, die es ja zu Hauf gibt, einfach alles hinzuschmeissen und die beleidigte Leberwurst zu spielen zeugt nun nicht gerade von großer Reife.
Da ein Teil des Codes nun aber mal GPL ist und da es sicherlich ein recht großes Interesse von Seiten der Nutzer gibt ihre Hardware auch mit neueren Kernelversionen weiter zu nutzen, wird es aber glaube ich nicht lange dauern, bis eine vernünftige Lösung gefunden ist, die sowohl den imho berechtigten Bedenken der Kernel Maintainer, als auch den Wünschen der User gerecht wird.
Welche Cam(s) kann man denn noch unter Linux betreiben?
in meiner billigen WebCam aus dem Aldi steckt so einer drin und sie funktioniert - seit Jahren - wunderbar unter Linux
neben einer OV-511 Webcam habe ich noch eine Connectix Quickcam B/W, funzt seit Ewigkeiten mit dem Modul bw-qcam.
Absolut top diese uralte Kamera, wenn auch nur schwarz/weiss.
Interessiert doch keinen. Bildschirmtelefon
hat sich auch nie durchgesetzt. Was soll
das Geschrei hier also? Ist doch unnötig.
Andere Anwendungsbeispiele sind z.B. Beobachtung eines Vogelnestes oder den Fortschritt eines Gebäudes ( Sanierung, Neubau...). Also wie du siehst es gibt neben der Bildtelefonie durchaus auch noch andere sinnvolle Anwendungen und das Bildtelefon hat sich nie durchgesetzt, weil die Qualität schlecht war. Es gibt nix besseres, als bei einem Firmenmeeting via Bild dabei zu sein, um z.B. einem Vortrag mit Visualisierung oder Vorführung von Prototypen besser folgen zu können. Naja dafür nimmt man wohl noch bessere Kameras.
phixom
Es gibt noch andere. Sind übrigens unglaublich schöne Fotos (v.a. von Jupiter und Saturn)
Und wenn ein Treiber keine MS Zertifizierung hat geht ja bei Windows immer ein grosses Warnfenster auf und der MS user ist verunsichert.
So kann MS Druck machen das es keine Treiber für Linux gibt.
Aber selbst wenn, kann man immer noch die Spek für die Schnittstelle offenlegen und schon kann OOS sich darum kümmern einen offenen Treiber zu entwickeln.
Ansonsten kann ich mir ehrlich auch nicht vorstellen, dass MS was zu sagen hat, was ein Hersteller für ein anderes OS schreibt. Die können vielleicht unterbinden, dass für Windows Treiber die als OpenSource freigegeben werden, eine Zertifizierung erteilt wird, aber ein parallel zum Windows-ClosedSource herausgegebener Linux-OpenSource Treiber geht die wohl wirklich nichts an.
Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische wird
das eben weiterhin so bleiben dass es kaum Treiber geben wird.
Das Resultet: Das Management hat die Linux-Quellen unter eine proprietäre Lizenz gestellt und lediglich die BSD-Quellen unter der BSD-Lizenz veröffentlicht. Seit dem ist unser Treiber in allen BSD-Distris aber nicht mehr in Linux erhalten. Wir planen auch nicht mehr den Treiber in den Kernel einzubauen und bieten allen Kunden auf unserer CD und unserem FTP Linux-Treiber zum Download an.
Interessanterweise hat sich der Maintainer des Subsystems bei uns ein halbes Jahr später gemeldet und um Erlaubnis gefragt unseren Treiber in den Kernel einzubauen. Dazu müssten wir nur die Lizenz ändern und den Rest würde er übernehmen. Da war leider schon der Zug abgefahren, denn so groß ist der Linux-Markt auch nicht, dass wir uns von so einem brüskieren lassen müssen, nur weil er ein massives Problem mit seinem Ego hat (Zitat: "Solange ich der Maintainer bin, werdet ihr mit eurem Treiber nie in den Kernel kommen.").
Ist das nicht bedeutend mehr Aufwand?
Immerhin muss man dann für zig verschiedene Kernel und Distributionen Treiberpakete erstellen, testen und bereitstellen, einfach in den Kernel Source Tree klingt nach weniger Arbeit.
Da war leider schon der Zug abgefahren
Da haben sich die richtigen zwei gefunden.
Zuerst das will das Ego des ersten nicht und jetzt schmollt das Ego des zweiten
Denk mal drüber nach !
Würden die Treiberschreiber endlich mal einsehen, dass die LKML keine Sklavenhorde ist, dann gäbe es eine solche Schnittstelle schon längst. Ich habe in den letzten Jahren mehrere dieser Treiber-ABI-Diskussionen auf LKML verfolgt, und der Standpunkt ist eigentlich klar: die Kernel-Maintainer halten eine solche ABI für überflüssig, nicht wartbar und nicht durchführbar. Und zumindest mit ersterem haben sie von ihrem Standpunkt aus definitiv recht. Sie haben aber auch klargemacht, dass sie eine solche ABI akzeptieren würden, sofern sie die üblichen Anforderungen erfüllt, sprich dem CodingStyle entspricht, gewartet wird, den Review-Prozess übersteht u.ä.. An diesem Punkt verschwanden in fast allen Fällen diejenigen, die noch kurz zuvor sich darüber beschwert hatten, dass sich die Kernel-Maintainer gegen eine solche ABI sperren würden und wurden nie wieder gesehen.
Also scheint es offenbar keinen großen Bedarf zu geben.
Abgesehen davon finde ich deine Kritik etwas unterspezifiziert. Es gibt Dutzende von Linuxen mit Dutzenden von Maintainern und Dutzenden von Entwicklungsmodellen. Vielleicht hast du deine Patches für die Implementierung einer Treiber-ABI einfach noch nicht an den richtigen geschickt?
> Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische
Ich kann nicht erkennen, was an: "Ihr wollt ein Feature, also schreibt eins oder bezahlt uns dafür." religiös sein soll. Linux ist freie Software, jeder kann es so modifizieren wie er möchte. Unter anderem kann er Linux eine Treiber-ABI verpassen und diese sich in der Praxis bewährt, sauber entworfen und implementiert ist und unter einer GPL-kompatiblen Lizenz steht, dann wird sie auch ihren Weg in den einen oder anderen Kernel finden.
> wird das eben weiterhin so bleiben dass es kaum Treiber geben wird.
In meinen Kernelquellen gibt es eine ganze Menge Treiber.
jwm
wobei man sich hier die frage stellen sollte, ob linux auch irgendwann für den desktopmarkt interessant werden will. wenn ja, werden da ganz andere als die in deinen jetzigen kernelquellen vorhandenen treiber benötigt werden. bei der ganzen sache darf man auch nicht vergessen, dass viele hardwarehersteller aus rechtlichen gründen keine spezifikationen herausgeben können, weil sie ihrerseits vertraglich gebunden sind (beispiel: hp-scanner mit realtek chipsatz). es ist also nicht so einfach, nur den hardwareherstellern die schuld zu geben. aber linux sollte vorerst das bleiben, was es ist, ein brauchbares serverbetriebssystem.
Das Feature war ja da, es wurde nur entfernt, und das ist dann schon religioes.
Das pwc-Modul wurde auf expliziten Wunsch des Autors entfernt. Was ist daran religiös?
Wichtiger wofür?
Aber da unter diesem vermurksten Konzept religiöse Dinge wichtiger sind als praktische wird das eben weiterhin so bleiben dass es kaum Treiber geben wird.
Das was du "vermurkstes Konzept" nennst, ist für GPL-Freie Software wie Linux die Existenzgrundlage und Existenzsinn. Wenn du es ind den jetzt bereits 13 Jahren nicht gemerkt haben solltest, ging es den Entwicklern _nie_ darum den Propriäteren einen großen Marktanteil abzuringen indem sie sich deren propriäterer Mittel bedienen. Stattdessen ging es darum Software zu schreiben die frei ist und frei bleibt, und sie möglichst gut zu machen.
Wenn bei deinen Prioritäten die Freiheit nicht unangefochten an erster Stelle steht, dann bist du hier falsch.
Der Hersteller gibt seine Prinzipien nicht frei um mit Freier Software möglichst reibungslos zu funktionieren, wieso sollten Entwickler Freier Software ihre aufgeben um mit den Produkten dieses Herstellers möglichst gut zu funktionieren?
Damit du, dem nichts heilig ist, alles umsonst bekommst??
Das Konzept wie unter Linux Hardware abstrahiert wird ist vermurkst, das ist eine technische
Frage keine Frage der Lizenz. In jedem anderen OS gibt es ein Interface dafür, nur unter dem ach so modernen Linux wird gerade in dem Bereich herumgeflickt wie vor 25 Jahren. Das ist einfach unakzeptabel und ich würde als Kernelentwickler einen roten Kopf bekommen wenn ich das Konzept verteidigen müsste oder gar die Worte 'modern' und 'Linux' in den Mund nehmen würde. Schau dir mal an was Apple als erstes in MacOSX eingebaut haben: eine saubere Hardwareschnittstelle. Die hat sich bis heute nicht geändert wurde nur ergänzt. Hardware wird sauber abstrahiert wie man das heute erwartet und weil es einfach selbstverständlich ist und nur Vorteile gegenüber
dem monolithischen Gebastel bringt.
Wenn du es ind den jetzt bereits 13 Jahren nicht gemerkt haben solltest, ging es den Entwicklern _nie_ darum den Propriäteren einen großen Marktanteil abzuringen
Ach Gott nicht wieder die Tour. Als ob da alle Entwickler der gleichen Meinung wären. Wenn Linux irgendwo kommerziell eingesetzt wird tanzen die Linuxfreaks im Kreis vor Freude aber wenn es Kritik hagelt kommt immer diese Ausrede. Linux steht schon mit einem Bein im kommerziellen Umfeld und da erwartet man einfach gewisse Dinge die selbstverständlich sind, das sollte auch den Kernelentwicklern einleuchten aber das tut dem angeknacksten Kernelentwicklerego nicht sonderlich gut wenn man zugeben müsste dass im Kernel manche Dinge einfach völliger Murks sind.
Vielleicht sind sie auch nicht in der Lage sowas hinzubekommen und man redet sich mit fadenscheinigen Ausreden raus, so hört sich das für mich an.
Dass die dieses kaputte Treibermodell unter Linux nichts taugt erkennt jeder der sich mal andere Platformen angeschaut hat. Aber wenn man Linux natürlich für das tollste hält und von World Domination faselt da helfen Argumente wenig. Komisch dass sich die World Domination konträr zu dem obigen Argument verhält dass man den Kommerziellen keine Marktanteile wegnehmen will.
indem sie sich deren propriäterer Mittel bedienen. Stattdessen ging es darum Software zu schreiben die frei ist und frei bleibt, und sie möglichst gut zu machen.
'Gut' ist was anderes als diese Bastelei bei den Treibern unter Linux.
Alle drei Hersteller haben vorher freie Treiber bereitgestellt oder die freien Entwickler mit Specs unterstützt.
Ich für meinen Teil mag Linux, weil es frei ist, nicht weil ich es für am technisch weitesten fortgeschritten halte (da würde ich im Desktopbereich wohl MacOS X einsetzen), ich finde die Unterwanderung im Grafikkartentreiberbereich schon schlimm genug und bete darum, dass man uns das nicht auch noch beim Kernel einbrockt, auf die Heise-/ProLinux-Meldungen von "nach Hause telefonierenden" Linux-Treibern würde ich liebend gerne verzichten..
Nvidia z.B., dabei meine ich jetzt nicht den Grafikkartentreiber sondern z.B. Patches für IDE, Sata Controller etc, lese ja immer mit auf der IDE Mailingliste und regelmäßig submitted da jemand von nvidia sourcen, die dann von JeffGarzik beispielsweise in sein Module einbaut.
Exakt.
Linux' wichtigste Eigenschaft, und die Eigenschaft die ihn zu dem gemacht hat was er heute ist, ist die strikte GPL-Konformität. Wenn man auf GPL-Ideale eh pfeift, kann man auf die pragmatischeren BDSs umsteigen, oder gleich bei den propriäteren Lizenzverkäufern bleiben.
Das Existenzziel von Linux und anderer Freien Software ist es nicht möglichst vielen Hardwareherstellern dorthin zu kriechen wo die Sonne nicht scheint, sondern frei zu sein und frei zu bleiben.
Es scheint aber so dass für dich und dir ähnliche, das einzig wichtige an Linux seine kostenlose Natur ist. Schnorrer halt. Beteilige dich als hier lieber an so ner HartzIV-Demo, dann bist du wenigstens unter deinesgleichen.
Philips hat aus Problemen, das Kompressionsverfahren zu patentieren (was auch viel Verwaltungsaufwand und Kosten nach sich zieht) die Geheimhaltung bevorzugt. Bei einem Linuxmarktanteil auf Desktops von unter 5% kann es dem Großkonzern ziemlich Schnuppe sein, ob Linux unterstützt wird oder nicht. Aber man tat es trotzdem und ich war froh die Kamera benutzen zu können. Die Kamera (740k) taugt u.a. sehr gut für Astronomie wegen ihre guten Lichtempfindlichkeit, was kein Konkurrenzmodell bietet. Daher meine Entscheidung für die PWC.
Wesentliche Kernelfunktionen müssen frei sein und bleiben, ganz meine Meinung. Aber es sollten Schnittstellen da sein, wo propritäre Hardware per Modul eingebunden werden kann. Was ist nun dabei? In letzter Konsequenz müßte dann auch die Hardware frei sein, was das Ende solcher Hardware wäre. Also Leute, bitte mal auf dem Teppich bleiben und nicht zum GPL-Ayatollah mutieren. Wenn Linux für alle da sein soll, muß man ihm auch genügend Luft zum atmen lassen.
Hinzu kommt natürlich der Marktdruck von M$ (wo keiner der Treiber offen sein muß). Daran wird sich bei allem Wunschdenken auch nicht viel ändern. Die Hardwarehersteller müssen erstmal diesen Markt bedienen und man kann dankbar sein, wenn die Treiber auch für Linux zur Verfügung stehen. BTW. Der Webcamtreiber von Nemosoft war um einiges bedienungsfreundlicher und stabiler als der Windoofstreiber von Philips. Daher fände ich es nur gut, wenn sich weiter begabte Hacker um Linuxtreiber mit Herstellersupport kümmern dürfen, anstatt ihnen unnötig Knüppel in die Beine zu werfen. Wer von den selbsternannten GPL-Ayatollahs schreibt denn die offenen Treiber um? Wer von den vielen Schreihälsen hat denn den Quellcode auf der Platte und versteht ihn? (ganz zu schweigen, daß er den Treiber verbessern kann...)
Daher kann ich weiter oben auch nur zustimmen, daß manche Maintainer ziemlich arrogant daherkommen, dieses Auftreten treffe ich ohnehin auffallend häufig in der EDV-Branche an....
nein das erwarten sie sich nicht (wenn es ihnen auch lieber wäre).
das problem ist dass der opensource-treiber (der unter der gpl steht, und im kernel enthalten war), diesen nicht gpl treiber nächläd, somit wäre danach der binär treiber dann einen teil des gpl treibers.
ob das nun richtig, falsch oder kleinlich ist kann ich nicht beurteilen, ich bin kein rechtsexperte und kenne der GPL zu wenig.
doch meiner meinung ist auch die reaktion des treiberentwicklers etwas übertrieben.
wo wäre dass problem wenn man den GPL treiber die möglichkeit des nachladens entfernen würde, und den binärtreiber als komplettes komplettes extra-modul anbieten würde, bei dem dann halt eine meldung kommt dass es nicht unter der GPL steht.
> zu GPL-Code hinzugebunden wird. Nur: Innerhalb der Kernelquellen, im Zweig drivers/usb/pwc*, ist nichts, was gegen die
> GPL verstoßen könnte (wohlgemerkt, nach oberflächlicher Durchsicht). Deshalb halte ich die Aktion von Greg
> Kroah-Hartmann auch sachlich für falsch.
was anderes habe ich ja auch nicht gesagt.
die frage ist nun ob es laut GPL erlaubt ist nachträglich den nicht gpl code zu laden, und zu verwenden.
wie ich schon sagte will ich darüber aber auch kein urteil abgeben ob dass nun richtichtig oder falsch ist. doch offensichtlich fällt es zumindest in eine rechtliche grauzone die geklärt werden muss, der eine behauptet ist erlaubt, und der andere sagt es ist nicht erlaubt.
also warum nicht einfach einen klare grenze zwischen nicht gpl treiber, und gpl treiber ziehen? wenn der gpl treiber keine möglichkeit hätte nachträglich code zu laden, gäbe es auch kein problem damit. leute die volle auflösung wollen, können sich von jemand dritten einen 100% nicht gpl treiber besorgen (wie es z.b. bei nvidia ist).
Spontan fallen mir da 2 ein: Realtek und QLogic.
P.S.: ich hasse Dogmatiker!
Mein Tip an alle, die jetzt evtl. auch nach einer neuen WebCam suchen: die Aiptek HyperVcam Mobile tut's auch und ist nicht ganz so kostspielig...
tu ich eh regelmässig (acpi, bluetooth, bootsplash...)
das kanns doch nicht wirklich sein?
Mit Kernel 2.4.2x hatte ich immer Kerneloopses mit anschliessendem Totalcrash, wennś zu oft oder im falschen Speicherbereich dazu kam. pwc.o und snd-usb-audio durfte ich nie zusammen verwenden. Jetzt geht das alles, aber ich will, dass das Projekt weitergeführt wird.
Werd meine Logitech Quickcam 4000 Pro nicht wegwerfen. Ich hoffe, hier kommen noch dutzende Webcam-Nutzer zusammen und bewirken, dass wir einen neuen Maintainer finden.
MfG
Allerdings bin ich mittlerweile froh nicht mehr so ein dämliches Ding auf dem Monitor zur haben
Vielleicht findet sich ja noch ein neuer Maintainer, ansonsten werden dann halt Linuxer in Zukunft keine Webcams dieser Firma mehr benutzen können - ist zwar traurig, ist aber so.
ein paar links, die jemand auf heise gepostet hat:
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1453.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1460.html
http://www.ussg.iu.edu/hypermail/linux/kernel/0408.3/1475.html
'Whenever somebody says "accept the driver to help users", they are missing
the big picture. A binary driver SCREWS OVER users on other architectures.
It pretty much guarantees that those other architectures will never be
supported.'
Von diesen haben, grob geschätzt, mindestens ein Dutzend PCI, das heißt ein Dutzend könnte potenziell auch AGP haben (AGP ist ja mit PCI stark verwandt). Davon hat schätzungsweise ein halbes Dutzend tatsächlich AGP. nVidia veröffentlich seine Treiber aber gerade mal für drei Architekturen, also die Hälfte derjenigen, die derzeit AGP haben, ein Viertel derjenigen, die jederzeit AGP bekommen könnten und gerade mal ein Zehntel aller Architekturen. Die anderen schauen in die Röhre.
Wie oben schon geschrieben, stellt nVidia mit drei unterstützten Architekturen, zwei Kernelserien und zwei(?) X Servern tatsächlich noch ein Positivbeispiel dar, andere unterstützen nur eine Architektur, eine Kernelserie und nur bestimmte veraltete Versionen eines bestimmten X Servers (um mal beim Beispiel von Grafikkarten zu bleiben). Ein anderer funktioniert nicht mit Grsecurity, wieder andere funktionieren nicht mit CONFIG_4KSTACKS=y oder funktionieren nur auf bestimmten Versionen bestimmter Distributionen.
Daher ist stimme ich dem o.g. Zitat zu: zwar behaupten die Hersteller, dass Binary-Only-Treiber gut für Linux-Nutzer seien, weil sie es ihnen ermöglichen, ein Gerät zu nutzen, das sie sonst nicht nutzen könnten, wenn es keinen Treiber gäbe. Tatsächlich ist es aber so, dass Binary-Only-Treiber schlecht für Linux-Nutzer sind, die die "falsche" Architektur nutzen, da sie es ihnen unmöglich machen, ein Gerät zu nutzen, welches sie sonst nutzen könnten, wenn es einen freien Treiber gäbe. Dieses Argument ist natürlich hinfällig, wenn ein Hersteller seine Treiber für alle 30 Architekturen, für alle 4 derzeit noch aktiven Kernel-Serien (2.0, 2.2, 2.4, 2.6), für alle Kobinationen von Konfigurationsoptionen aller Varianten von Linux (-mm, -aa, SuSE, Fedora, Debian, Mandrake, Grsecurity, -mcp, FOLK, -tiny, -ck, -np, ...) anbietet. Aber solange die Hersteller das nicht tun, kann man einen Binary-Only-Treiber eigentlich nicht akzeptieren. (Es gibt natürlich andere Aspekte, wie z.B. Aspekte der Computersicherheit, betriebswirtschaftliche Aspekte (z.B. Investitionssicherheit) o.ä., die da auch noch mit hinein spielen.)
jwm
Hm, ich würde mich als Besitzer einer Philips Webcam wohl ärgern, aber wahrscheinlich hätte ich mich schon vorher geärgert, dass der Treiber doch nur unter ganz bestimmten Voraussetzungen läuft.
Insofern nutze ich lieber eine Hardware gar nicht als mir von der Hardware vorschreiben zu lassen, was ich für Software benutze.
Gruss
Cornelius
Momentan hab ich das Problem. Meine AXi würde sich über etwas schickeres als die momentane Mach64 freuen. Aber ich kann mich nicht durchringen, eine Karte mit 64MB+ zu kaufen, wohl wissend, das ich die 3D Fähigkeiten nie nutzen werde können. Also bleibt die Mach64 drin und ich ärgere mich weiter über Nvidia, ATI und Co.
PS: ebenfalls ein Ärgernis sind übrigens WLAN-Karten, aber auch Soundkarten.
Bei einer 20EUR-gebraucht-Karte würde ich das hinnehmen, bei einer Radeon X800 XT würde ich nie einen Treiber akzeptieren, der einen Teil der Leistung nicht abrufen kann. Immerhin zahlt man im Enthusiasten-Segment für die letzten 10% mehr (hardwareseitig vorhandene) Leistung für's Topmodell locker über 100EUR mehr. Wer eiert den Windowsern denn gern 20-30% hinterher, wenn er dasselbe dafür bezahlt hat?
Kein Wunder, dass die Petition für bessere ATI-Treiber die 10000er-Marke längst überschritten hat ;-)
http://www.petitiononline.com/atipet/
Für ATI wären 10000 Kunden aus der Linuxecke aber gerade mal eine 7stellige Summer mehr Umsatz und wahrscheinlich geht es denen derzeit gut genug, so dass sie sich um diese Summe zur Zeit nicht kümmern müssen.
Mehr Unterzeichner schaden jedenfalls nicht.
MfG
bin sogar unter den ersten 1000... ich glaub 600-irgendwas. Aber egal.
Zu den Architekturen, ich finde sowas kommt gerade bei Ankündigungen viel zu kurz. Da heißt es immer "Firma XYZ bringt eine Linux-Version von Programm XXX heraus", wenn man dann aber hinschaut, gibts in aller Regel ne IA32 Version und das wars, mit nem PowerPC, MIPS, ARM, ... steht man da im Regen. Finde ich sehr schade sowas.
| diese dann ständig angepasst werden müssen.
Aber immerhin gibt es die Möglichkeit, diese anzupassen. Stattdessen ist man auf die Gut-
mütigkeit des Herstellers angewiesen, die notwendige Anpassung vorzunehmen oder es eben
nicht zu tun.
Aber was zur Hölle geht eigentlich bei den Herstellern vor? Wieso kommen die auf die Idee,
immer mehr "Wissen" in die Treiber zu verlagern statt ihr Know How in der Hardware selber
oder in deren Firmware unter zu bringen? Das ist das eigentliche Problem, was die Endan-
wender daran hindert, ein Betriebssystem nach Wahl einzusetzen, ohne dabei gravierende
Qualitätverluste hinzunehmen bzw. ganz auf Unterstützung zu verzichten. Ganz besonders kann
man das am Beispiel Drucker und Scanner sehen. Meine beiden Epson-Geräte funktionieren zwar
auch mit OS-Treibern, aber sowohl Geschwindigkeit als auch Qualität sind gegenüber den
CS-Treibern beinahe katastrophal. Wer schon mal mit CUPS und gimp-print auf einem Epson
Stylus C8x in höchster Qualität auf Folie ausgedruckt hat, weiss, dass man dabei mehr als
nur eine Tasse Kaffee trinken gehen kann. Die Qualität ist allerdings brauchbar. Mit den
Turboprint-Treibern dagegen ist die Qualiät nochmal besser, die Geschwindgkeit ist aber
wohl um den Faktor 3 bis 4 höher. Das selbe gilt für den Vergleich Epson-Scanner und
xscanimage gegen Epson-Scanner und iscan. Die iscan-Qualität schlägt xscanimage um LÄNGEN.
Statt die Hersteller diese Treiber-Features irgendwo in der Hardware (auf einem Chip, in
der Firmware) unterbringen und von aussen nur den nackten Befehlssatz benötigen, gehen Sie
den meiner Meinung nach umständlicheren Weg. Auf der Strecke bleiben Benutzer, die eben
kein Betriebssystem nutzen, das dem Hersteller in den Kram passt. Wobei eine Werbung ala
"Funktioniert unter ALLEN Betriebssystem mit gleicher Geschwindgkeit/Qualität" sich doch
deutlich besser machen würde als "Systemvoraussetzung: Win2000 oder neuer, Mac OS X". Und
wegen dieses Schwachsinns ist man dann auch gleich noch gezwungen, für einen schnöden
Print-Server im Netz teurere Hardware anzuschaffen, als für die eigentliche Aufgabe
nötig ist. Zum Kotzen!
Was zahlt MS den ganzen Peripherie-Herstellern eigentlich dafür, dass sie die Endanwender
derart verarschen?
A.
http://www.saillard.org/linux/pwc/
funktioniert bestens mit linux 2.6.x
tt4l