Hardwaretreiber: Open-Source oder Third-Party?

[gnu]

Hallo,

Windows kann bekanntermaßen auf eine sehr umfangreiche Treiberdatenbank zurückgreifen, wodurch so gut wie jede Hardware unterstützt wird.

Aber auch für Ubuntu und Linux Mint sind mittlerweile viele Dritterherstellertreiber verfügbar.
Bisher betrachtete ich dies als Vorteil von Ubuntu und Linux Mint gegenüber Debian.

Andrew S. Tanenbaum behauptete im Jahr 2010 2006, dass 85 % der Abstürze von Windows auf Third-Party-Treiber zurückzuführen sind.
(Quellen: http://www.osnews.com/story/15960/Intro ... to-MINIX-3, https://en.wikipedia.org/wiki/Device_dr ... ite_note-1)

Deshalb frage ich mich nun:
1. Wie "gut" sind die für Ubuntu und Linux Mint zur Verfügung stehenden Third-Party-Treiber?
2. Muss man durch das Verwenden eines Open-Source-Treibers (für CPU, GPU und Arbeitsspeicher) mit Leistungseinbußen rechnen?

(Von Abstürzen des Windows-Betriebssystems, die durch Third-Party-Treiber verursacht wurden, kann ich aus eigener Erfahrung berichten.)
(Mir ist bewusst, dass beim Nutzen von Closed-Source-Treibern das Problem besteht, dass - außer dem Hersteller - niemand den Quellcode des Treibers einsehen kann.)
(Tags für die Forensuche: 3rd-Party, Dritterherstellertreiber, non-free, proprietär, Hardwareunterstützung)

Was denkt ihr?

[eggy]

Ganz klare Antwort: "kommt drauf an".

Teilweise hast Du keine Wahl, und ohne closed Hersteller-Treiber läuft gar nichts.
Teilweise bist Du mit dem freien Treiber besser dran, oder es gibt nur diese.

Teilweise hat der Programmierer wirklich Ahnung was er da tut und das Zeug läuft auch noch sauber.
Teilweise ist es übel zusammengeworfener Krams, bei dem man glücklich sein kann, wenn einem nicht schon das Makefile die Platte putzt.
Die letzten Punkte auch unabhängig davon, unter welcher Lizenz der Code steht, oder ob der Source mitgeliefert wurde oder ob Hersteller oder jemand anders den Code geschrieben haben.


Ps das Thema ist doch eher was für "Smalltalk"

[hikaru]

Bei mir laufen in der Regel nur die freien Treiber. Wenn man proprietäre Firmwares wie für's WLAN oder CPU-Microcodes nicht mitzählt, dann ist der einzige unfreie Treiber der auf meinen Systemen läuft der Nvidia-Grafiktreiber auf dem HTPC meiner Eltern, der da aus Leistungsgründen gebraucht wird. Aber auch das wird sich in absehbarer Zeit mit einem neuen HTPC ändern.

Teil meiner Entscheidung für Debian war der Social Contract [1], und da ist es nur konsequent, so weit wie möglich auf freie Treiber zu setzen. Meiner Erfahrung nach funktionieren die im Schnitt auch reibungsloser als proprietäre Treiber, wenn auch vielleicht nicht immer mit vollem Funktionsumfang. Ob eine Hardware mit freien Treibern läuft ist für mich ein wesentliches Kaufargument.


[1] https://www.debian.org/social_contract

[pangu]

Kann mich da nur eggy anschließen: es kommt immer auf den Einzelfall an.

Nehme mal als Beispiel die Grafikkartentreiber AMD/ATI unter Debian. Du hast verschiedene Auswahlmöglichkeiten:

(a) du nimmst den freien Treiber
(b) du nimmst den proprietären Treiber von den Debian-Paketquellen, der also bereits paketiert wurde damit er in Debian-Systemen funktioniert. Oder ....
(c) du nimmst den proprietären Treiber direkt von der AMD-Supportwebseite (Linux) und kämpfst dich selbst durch alles notwendige bereitzustellen (nicht ratsam!)

Die beste Performance mit den aktuellsten Treibern wirst du mit der Auswahl (c) haben.
Die beste Performance mit den aktuellen Treibern wirst du mit der Auswahl (b) haben.
Mit den freien Treibern unter Auswahl (a) wirst du evtl. glücklich denn es kommt ganz darauf an, inwieweit die vielfältigen Technologien in der Treiberunterstützung durch die OpenSource-Programmierer dieses Treibers umgesetzt wurden. Du musst dir das so vorstellen: den 100% Durchblick mit wirklich ALLEN infos haben natürlich nur der Hersteller und der versucht so wenig wie möglich darüber in die Öffentlichkeit bekanntzugeben. Die OpenSource-Programmierer die den freien Treiber (a) programmieren können zwar so ziemlich viel abbilden und das notwendigste zum Laufen kriegen, aber sie werden (meiner ganz persönlichen Meinung nach) niemals alle Hochleistungstechniken rauskitzeln können aus der Karte, weil sie einfach nicht die notwendigen Hintergrundinformationen hierzu besitzen können. Das heißt sie können vielleicht auf bestimmte Techniken und Ressourcen der Grafikkarte nicht zurückgreifen, um sie 100% auszunutzen und so das Potential dieser GraKa zu entfalten. Das vor allem im Bereich "Hardware-/3D Beschleunigung".

Es gibt jedoch sicherlich auch Modelle, wo der Unterschied zwischen (a) und (b) nicht groß sein wird, und wenn wir von Desktop-Betrieb reden sowieso nicht. Hauptsächlich geht's dann um Performance-Sachen im 3D-Bereich.

An dem Beispiel solltest du hoffentlich erkennen, dass es immer ganz individuell ist und vom Einsatzzweck als auch vom Gerätetyp abhängt für den du einen Treiber installieren möchtest. Ich für meinen Teil kann sagen, dass ich immer open-source, also den freien Treiber bevorzuge, und wenn der meine Zwecke erfüllt dann nehme ich den. Sollte der freie Treiber für meinen geforderten Einsatzzweck nicht ausreichen versuche ich den proprietären Treiber. Dabei nehme ich immer möglichst den, der bereits von den Debian-Managern paketiert wurde und somit in den Debian-Repositorys verfügbar ist (oder notfalls eben als .deb Paket zum Download bereitgestellt wird). Also quasi die Reihenfolge (A) --> (B) --> (C)

Hoffe das hat ein klein wenig zum Verständnis beigetragen.

Viel Erfolg
Pangu

[catdog2]

Mit den freien Treibern unter Auswahl (a) wirst du evtl. glücklich denn es kommt ganz darauf an, inwieweit die vielfältigen Technologien in der Treiberunterstützung durch die OpenSource-Programmierer dieses Treibers umgesetzt wurden. Du musst dir das so vorstellen: den 100% Durchblick mit wirklich ALLEN infos haben natürlich nur der Hersteller und der versucht so wenig wie möglich darüber in die Öffentlichkeit bekanntzugeben. Die OpenSource-Programmierer die den freien Treiber (a) programmieren können zwar so ziemlich viel abbilden und das notwendigste zum Laufen kriegen, aber sie werden (meiner ganz persönlichen Meinung nach) niemals alle Hochleistungstechniken rauskitzeln können aus der Karte, weil sie einfach nicht die notwendigen Hintergrundinformationen hierzu besitzen können. Das heißt sie können vielleicht auf bestimmte Techniken und Ressourcen der Grafikkarte nicht zurückgreifen, um sie 100% auszunutzen und so das Potential dieser GraKa zu entfalten. Das vor allem im Bereich "Hardware-/3D Beschleunigung".

Man muss im konkreten Beispiel aber hinzufügen, dass die meisten derer für den Hersteller arbeiten.

[pangu]

Das hast du ja somit nachgeholt. Danke

Da frage ich mich dann andererseits ==> wieso weist der marktstark-gierige und proprietär-ausgerichtete Hersteller X seine Treiberprogrammierer an, Treiber für ihr Produkt Y zu erstellen und diesen geschlossen (closed-source/proprietary) zu halten, während die Programmierer auch quelloffene (open-source) Treiber für dasselbe Produkt entwickeln? Der proprietär-ausgerichtete Hersteller hat sicherlich keine Interesse daran, dass irgendjemand einen "alternativen" Treiber für sein Produkt Y erstellt und erst recht nicht wenn das etwas quelloffenes ist. Demnach wird Hersteller X versuchen wichtige/markante Infos soweit wie möglich vor seinen Treiberprogrammierern zu "verstecken" oder so weit wie möglich zu "vermindern", sei es durch Form von Informationsstreuung oder Team-Management mit gegenseitigem Ausschluss von Informationen.

Das gilt übrigens für alle kommerziellen Softwareanbieter. Nimm doch mal Microsoft als Beispiel. Für M$ programmieren sicherlich nicht wenige Leute. Trotzdem steuert der Riese diese Entwicklung so, damit der Code nicht in die Öffentlichkeit gelangen kann. Mitarbeiter kommen und gehen, andere sind angepisst und verlassen das Unternehmen. Diejenigen sind dann Gefahr für das Unternehmen. Trotzdem gibt es Möglichkeiten das zu steuern.

Ich denke in diesem Beispiel hat AMD kein Interesse daran, dass quelloffene Treiber für ihr Produkt existieren, die mindestens exakt dieselbe Performance liefern wie ihre eigenen proprietären. Warum auch?

Ich möchte betonen, dass dies meine subjektive Meinung ist. Lasse mich aber gerne korrigieren, falsch ich falsch liegen sollte

Just my 2 cents
Pangu

[hikaru]

Der proprietär-ausgerichtete Hersteller hat sicherlich keine Interesse daran, dass irgendjemand einen "alternativen" Treiber für sein Produkt Y erstellt und erst recht nicht wenn das etwas quelloffenes ist.

Der Hersteller hat in erster Linie Interesse daran, seine Produkte zu verkaufen. Ob seine Treiber frei oder unfrei sind interessiert ihn nur indirekt, nämlich dann wenn die Freiheit oder Unfreiheit seine Verkaufszahlen beeinflusst.
Dabei bewegt er sich in einem Spannungsfeld, denn mit offenen Treibern kann er mehr Kunden gewinnen (z.B. mich), was aber relativ wenige sind. Andererseits könnten sich von offenen Treibern auch Konkurrenten etwas abschauen, was eher für geschlossene Treiber spräche. Die FLOSS-Szene ist in diesen Szenario kein Konkurrent sondern ein Partner, allerdings ein sehr schwacher.
Als Kompromiss gibt der Hersteller dann gerade so viel frei, um einen ordentlich laufenden offenen Treiber zu erstellen, hält aber die wirklich interessanten Teile zurück, die die Konkurrenz nicht eh schon kennt. Das Ergebnis ist dann das, was wir in freier Wildbahn sehen:
Offene Treiber die zwar gut funktionieren, aber nicht das Letzte aus der Hardware kitzeln UND geschlossene Treiber mit maximaler Performance für die selbe Hardware.

Mitarbeiter kommen und gehen, andere sind angepisst und verlassen das Unternehmen. Diejenigen sind dann Gefahr für das Unternehmen.

Das hat aber nichts mit den offenen Treibern an sich zu tun. Nur weil ich den Code eines Stücks Software kenne (Leak) kann ich ihn noch lange nicht in einen offenen Treiber gießen. Dem stehen Patente und Lizenzen entgegen, auf die ein Entwickler offener Treiber Rücksicht nehmen muss. Niemand in der FLOSS-Szene hat Lust darauf, wegen Lizenz- oder Patentrechtsverstößen von der Anwaltsmeute eines Herstellers vor Gericht gezerrt zu werden.
Bei Konkurrenten KÖNNTE das anders aussehen. Im Vergleich zu offenen Treibern ist es bei geschlossenen schwieriger, Codeklau nachzuweisen. Wenn ein Konkurrent ein Stück Code in die Finger kriegt und feststellt, dass es ihm hilft, dann könnte er abwägen ob es das Risiko damit erwischt zu werden wert ist um selbst ein besseres Produkt auf den Markt bringen zu können. Das läuft dann möglicherweise auf die Frage hinaus ob die eigenen Anwälte gegen die des Gegners vor Gericht ein Ergebnis erzielen können, das unterm Strich den Codeklau immer noch lukrativ macht (z.B. nach Abzug von Strafzahlungen und folgenden Lizenzgebühren).

[gnu]

Zuerst einmal danke für eure (wie immer) sehr detaillierten und hilfreichen Antworten.

@eggy: Da du von sehr großen Qualitätsschwankungen sprichst, wäre eine Plattform zur Bewertung einzelner Treiber vielleicht eine gute Idee. Auch, da das Testen mittles Benchmarks recht einfach umgesetzt werden könnte.
Allerdings haben solche Datenbanken auch Nachteile (auch wenn es hier direkt um Hardware ging): viewtopic.php?f=15&t=155036&start=15#p1040024

@hikaru:

Teil meiner Entscheidung für Debian war der Social Contract [1]

Da Grafik, Videoschnitt, 3D-Modelling u. dank Steam auch anspruchsvolle 3D-Spiele unter Linux kein Hindernis mehr sind, wird (für mich) auch eine optimale Hardwareausnutzung immer wichtiger, wenn mit freien Treibern aber beides geht, ist es natürlich ideal.

Ob eine Hardware mit freien Treibern läuft ist für mich ein wesentliches Kaufargument.

Sehe ich genauso, leider nicht immer leicht herauszufinden, aber die Faustregel "je verbreiteter die Hardware, umso besser" scheint sich erfreulicherweise zu bewahrheiten.

@pangu: Danke für die ausführliche Antwort, die "abc-Methode" werde ich beherzigen. Zudem war mir nicht klar, dass auch proprietäre Treiber in die offiziellen Debian-Paketquellen aufgenommen werden.

Viele Suchergebnisse auf anderen Seiten waren ~ 5 Jahre alt, aber einige aktuelle Artikel habe ich dann doch noch gefunden, als Ergänzung hier die Links:

http://www.pcworld.com/article/2911459/ ... aming.html
(17.4.2015) Zusammenfassung: Nvidia: schlechteste Open-Source-Treiber-Unterstützung, dafür die besten proprietären Treiber.
Bei Intel und AMD ist es laut Verfasser umgekehrt. Sie unterstützen zwar die Entwicklung von Open-Source-Treibern, bzw. entwickeln diese selbst, können aber weder mit diesen, noch mit den proprietären Treibern von Nvidia mithalten.

Der Artikel nimmt auch Bezug auf diese Benchmarsk:

http://www.phoronix.com/scan.php?page=a ... view&num=3
(20.3.2015) Zusammenfassung: Während unter Windows mit vergleichbaren Grafikkarten von AMD und Nvidia vergleichbare Ergebnisse erzielt werden können, schneiden unter Linux die Nvidia-Modelle deutlich besser ab.

http://askubuntu.com/questions/530257/a ... rtain-appl
(22.1.2015) Zusammenfassung: das was eggy sagt ("kommt drauf an"), mit folgender Ergänzung:

"If you have a nVidia card with Optimus, you should either install the open source driver from the Bumblebee Project, or any nVidia proprietary driver, but not the Xorg driver, as it currently doesn't support discrete graphics.
If you want to use CUDA (nVidia's stuff for executing functions on the GPU), you should use the proprietary driver.
If you have a AMD APU (Accelerated Processing Unit), you should install the proprietary driver fglrx, even if you don't use the embedded graphics chip. Else, the APU would stay at its lowest frequency.
If you want to use OpenCL (something like CUDA, developped by Khronos), you have to use the proprietary driver."

"My understanding is that the nVidia drivers are significantly better at 3D acceleration and shading, but are about the same as the open source drivers for 2D applications.

"Proprietary (usually) beats open source in terms of performance. That being said, upgrading is significantly easier and more streamlined using the open source."

Maketecheasier stellt ebenfalls Vor- u. Nachteile gegenüber:
https://www.maketecheasier.com/propriet ... ver-linux/
(21.5.2015) Zusammenfassung: Nur wer das Maximum an Leistung benötigt, soll die proprietären Treiber installieren, ansonsten reichen die OpenSource-Treiber vollkommen aus.

[pangu]

@pangu: Danke für die ausführliche Antwort, die "abc-Methode" werde ich beherzigen. Zudem war mir nicht klar, dass auch proprietäre Treiber in die offiziellen Debian-Paketquellen aufgenommen werden.

die findet man nicht in den "default" Debian-Repositorys, das ist klar weil es sich ja um unfreie Software handelt. Für das von mir hergezogene Beispiel mit der Grafikkarte, müsstest du also vorher in deiner /etc/apt/sources.list "contrib" und "non-free" hinzufügen wie auch in dieser Beschreibung passend zum Beispiel erklärt.

Proprietary (usually) beats open source in terms of performance. That being said, upgrading is significantly easier and more streamlined using the open source."

+1 (sehe ich genauso)

https://www.maketecheasier.com/propriet ... ver-linux/
(21.5.2015) Zusammenfassung: Nur wer das Maximum an Leistung benötigt, soll die proprietären Treiber installieren, ansonsten reichen die OpenSource-Treiber vollkommen aus.

+1 das bringt es auf den Punkt

Grüße,
Pangu

[eggy]

@eggy: Da du von sehr großen Qualitätsschwankungen sprichst, wäre eine Plattform zur Bewertung einzelner Treiber vielleicht eine gute Idee. Auch, da das Testen mittles Benchmarks recht einfach umgesetzt werden könnte.

Halte ich persönlich für überflüssig. [*]
Datenbanken muss man warten, sonst haben sie keinen Wert.
Mit jeder kleinen Änderung am Kernel (oder anderen nötigen Systemkomponenten) kann das Verhalten wieder ganz anders ausfallen.

Dazu kommt, für die "breite Masse" sind eh nur die Grafikkarten interessant. Und bereits hier wirst Du es nicht schaffen die "kritische Masse" zusammen zu bekommen, dass genug (aktuelle) Einträge vorhanden sind. Bei Geräten wie "super exotischer SCSI-Controller" oder "Spacemouse erster Generation" wirst Du eher gar keine Einträge bekommen. Und falls doch, wage ich zu bezweifeln, dass die irgendeine Aussagekraft haben. "Kompiliert an einem Montag bei Vollmond mit clang in Version x.y", "läuft, solange nichts im linken USB-Port steckt", "mag Keyboards der Marke abc nicht", "libfoobar muss in Version größer als 3.2.058a, aber kleiner als 3.2.12b, und auf garkeinen Fall 2.3.4 vorliegen"... viel zu viele Faktoren die man einfach nicht unter einen Hut bringen kann.

[*]: Ausnahmen gibt es natürlich, siehe http://www.openprinting.org/printers , aber zwischen ppd für Drucker und Kernelmodul für Grafikkarte ist schon nen merklicher Unterschied was die "Anfälligkeit bezüglich Systemänderungen" angeht

[gnu]

Für das von mir hergezogene Beispiel mit der Grafikkarte, müsstest du also vorher in deiner /etc/apt/sources.list "contrib" und "non-free" hinzufügen wie auch in dieser Beschreibung passend zum Beispiel erklärt.

alles klar,

Datenbanken muss man warten, sonst haben sie keinen Wert.
Mit jeder kleinen Änderung am Kernel (oder anderen nötigen Systemkomponenten) kann das Verhalten wieder ganz anders ausfallen.

Aber könnte man das nicht automatisieren? z.B. so:

Code: Alles auswählen

wenn Kernel-Release-Datum > Datum des Treiberdatenbank-Eintrages zeige Nachricht: "veralteter Eintrag!"

Dazu kommt, für die "breite Masse" sind eh nur die Grafikkarten interessant. Und bereits hier wirst Du es nicht schaffen die "kritische Masse" zusammen zu bekommen, dass genug (aktuelle) Einträge vorhanden sind. Bei Geräten wie "super exotischer SCSI-Controller" oder "Spacemouse erster Generation" wirst Du eher gar keine Einträge bekommen.

Da hast du recht. Aber es wäre dennoch besser als nichts, oder nicht?

[owl102]

Andrew S. Tanenbaum behauptete im Jahr 2010, dass 85 % der Abstürze von Windows auf Third-Party-Treiber zurückzuführen sind.
(Quelle: https://www.youtube.com/watch?v=bx3KuE7UjGA)

An welchem Zeitstempel etwa?

[gnu]

An welchem Zeitstempel etwa?

Konnte es auf die Schnelle nicht finden, ich bin mir auch nicht ganz sicher, ob ich das richtige Video verlinkt habe...
Hier dafür seine Aussage in schriftlicher Form (war bereits im Jahr 2006): http://www.osnews.com/story/15960/Intro ... to-MINIX-3
(im 2. Absatz des "Rebirth"-Kapitels)

(Hab es im Beitrag entspr. geändert.)

[owl102]

Hier dafür seine Aussage in schriftlicher Form: http://www.osnews.com/story/15960/Intro ... to-MINIX-3
(im 2. Absatz des "Rebirth"-Kapitels)

Hmmm, da steht leider auch nur "Various studies", ohne Quellenangabe. Wenigstens eine davon hätte er ja mal angeben können, denn schließlich bauen einige seiner Folgen auf. So hat das ein wenig FUD-Charakter, schade. Ob er es einem seiner Studenten wohl durchgehenlassen würde, wenn als Quelle in einer Arbeit nur "Various studies" steht?

BTW: Verschiedene Studien haben ergeben, daß Keks gesünder ist als Apfel.

[gnu]

Hmmm, da steht leider auch nur "Various studies", ohne Quellenangabe. Wenigstens eine davon hätte er ja mal angeben können. So hat das ein wenig FUD-Charakter, schade.

Das stimmt.

Der Ursprung ist wohl "Archana Ganapathi, Viji Ganapathi and David Patterson. "Windows XP kernel crash analysis". In Proceedings of the 2006 Large Installation System Administration Conference, 2006":
https://en.wikipedia.org/wiki/Device_dr ... ite_note-1

[owl102]

Der Ursprung ist wohl "Archana Ganapathi, Viji Ganapathi and David Patterson. "Windows XP kernel crash analysis". In Proceedings of the 2006 Large Installation System Administration Conference, 2006":
https://en.wikipedia.org/wiki/Device_dr ... ite_note-1

Danke für den Nachtrag! Dieses Paper ist problemlos im Internet zu finden, z.B. hier: https://www.usenix.org/legacy/event/lis ... apathi.pdf

Ich werde mir das heute Nachmittag mal zu Gemüte führen (jetzt muß ich erst einmal einkaufen usw.); mich interessiert, ob die auch Hypothesen haben, warum das so ist. Ich habe da nämlich so meine eigenen, und die lassen sich überhaupt nicht auf die Linux-Welt anwenden, und deswegen stört mich der Punkt, daß von einem Problem von Windows XP einfach mal so auf Linux rückgeschlossen wird, d.h. die Annahme gemacht wird, Linux-Treiber von Drittherstellern hätten die gleichen oder zumindest ähnliche Probleme.

[gnu]

gerne, wenn du möchtest kannst du ja hier kurz schreiben, ob der Vergleich berechtigt ist oder nicht

[owl102]

[tl;dr] Nein, ich denke nicht, daß sich das von Windows XP auf Linux übertragen läßt. Ich denke nicht einmal, daß sich das nur eingeschränkt von Windows XP auf Windows Vista/7/8/10 übertragen läßt.

Langfassung:

Spontan fallen mir folgende Probleme bei Windows-Treibern bis einschließlich XP ein:

• Die Dokumentation des DDKs [1] war lausig. Da die darunterliegenden Funktionen nicht Open Source sind, konnte man sich nicht dadurch retten, daß man in den Quellen nachschauen kann. Es gab Bücher, aber deren Nährwert schwankte naturgemäß zwischen sinnfrei, viel falsches und brauchbar.
• Die Beispieltreiber von MS waren lausig. Der Bulk-USB-Treiber, auf den wohl jede Firma aufgesetzt hat, die ein USB-Device anbinden wollte, welches USB Bulk Transfer verwendet (= der gängiste USB-Übertragungsmodus), hat wohl auf diesem Treiber aufgesetzt. Die Modularität und Erweiterbarkeit des Beispieltreibers ließ jedoch arg zu wünschen übrig, eigentlich musste man den Treiber erst einmal Refakturieren, bevor es weiter ging, aber das hat wohl kaum eine Firma getan. Hinzu kommt, daß der Treiber Fehler besaß.
• Die Treiberinstallation war lausig dokumentiert. Hier waren die INF-Dateien quasi Open Source, aber das hat einen nicht gerettet, sondern nur noch mehr verwirrt. Es gab von MS ein Perl Script, welches INF-Dateien auf ihre Korrektheit überprüfen konnte, aber das wurde offensichtlich nicht einmal von MS durchgängig verwendet, denn es war überhaupt gar kein Problem, mit dem Tool Fehler in INF-Dateien von MS zu finden, sowohl bei den Beispieltreibern als auch bei ausgelieferten Treibern, die Bestandteil von XP waren.
• Die Entwicklerszene war sehr geschlossen, was Know-How angeht. In der passende Newsgruppe wurde zum Beispiel lediglich ausgetauscht, wieviele Fehler man in welchen Beispieltreibern gefunden habe, quasi als Art Schwanzvergleich. Wenn man jedoch mal konkret nachgefragt hat, was denn wo gefunden wurde, herrschte Schweigen im Walde. Ebensowenig gab es gute Entwicklerblogs oder ähnliches.
• Die Beispiele und die Dokumentationen waren thematisch recht eng gefasst. Sobald man jedoch ein Gerätetreiber entwickeln wurde, der zum Beispiel mehr war als eine nackte Netzwerkkarte oder ähnliches, mußte man sehr kreativ werden. Dies war in der Vergangenheit ok, in der Gegenwart gab es jedoch immer mehr Multi-Purpose-Geräte, oft via USB angeschlossen.
• Die meisten Treiber sind wohl von Windows 95/98 portierte WDM-Treiber gewesen. [2] WDM war aber nur auf dem Papier unter Windows 9x und 2000/XP gleich, in der Praxis war Windows 9x unendlich viel lascher im Umgang mit Fehlern. IRQ-Level waren zum Beispiel fast egal, Dinge, die unter 2000/XP lediglich im Dispatch-Level oder Passive-Level erlaubt waren, konnte man problemlos unter Windows 9x machen, unter Windows 2000/XP gab es hingegen entweder Blue Screens ("IRQ not less or equal") oder merkwürdiges Verhalten. Die sinnvollere Vorgehensweise wäre also gewesen, die Treiber erst unter Windows 2000 zu entwickeln, und dann liefen sie in der Regel auch ohne (größere) Anpassungen unter Windows 9x. Nur: Windows 95 war vor Windows 2000 da, daher hat die Zeitlinie leider die umgekehrte Herangehensweise vorgezeichnet, was sich nicht positiv auf die Stabilität der Treiber unter Windows 2000 ausgewirkt hat, im Gegenteil.
• Das Design von PnP und Power Management war unter Windows 2000/XP grausig. Vermutlich wurde es zuerst unter Windows 9x von MS entwickelt, und dann mit der Brechstange nach Windows 2000 portiert.

Und das sind nur die Dinge, die mir so spontan einfallen, wenn ich noch länger zurückdenke, fällt mir bestimmt noch mehr ein.

Wie man sieht, sind das alles Punkte, die für Linux nicht zutreffen. Sie treffen sogar nur bedingt für Windows Vista/7/8 zu, denn ab Vista hat MS einiges getan:

• Es gab eine neue übergeordnete Dokumentation von MS, die sogar gar nicht so schlecht war.
• Es gab eine neue Bibliothek von MS, auf die man als Treiberentwickler zurückgreifen konnte, und die durchschaubare Schnittstellen zu PnP und Power-Management besaß.
• Es gab die Möglichkeit, bestimmte Treiber nun im Userland laufen zu lassen, die früher zwangsweise im Kernel-Modus laufen mußten.
• Es gab mehr und besser dokumentierte Beispieltreiber.
• Es gab keine dokumentierte und brauchbare Schnittstelle, um auf Treiberebene IP zu machen. (Vorher gab es nur eine recht unbrauchbare und undokumentierte Schnittstelle, aber was sollte man machen, wollte man IP nutzen, mußte man sie trotzdem verwenden.)

Allerdings ist die Frage, wieviele Firmen wann auf diese Neuerungen zurückgegriffen haben. Ältere, bereits vorhandene Treiber wurden sicherlich lediglich "portiert" und nicht neu geschrieben oder umgestellt, und waren daher genauso buggy wie vorher. Dennoch denke ich, daß diese Schritte von MS dazu beigetragen haben, daß Windows-Treiber beginnend mit Vista langsam aber sicher stabiler wurden.

Nun noch einige lose Gedanken zu dem Script:

• Mich hat überrascht, daß die Situation nicht viel besser unter XP gewesen wäre, wenn MS alle Treiber programmiert hätte. (Siehe Seite 153) Denn immerhin hatte MS ganz andere Möglichkeiten: Die Entwickler im Hause, Zugriff auf Quelltexte von Windows usw. Offenbar hatte MS unter Zeitdruck mit ähnlichen Problemen zu kämpfen wie die Dritthersteller.
• Mich hat nicht überrascht, daß mit großen Abstand "IRQ not less or equal" der häufigste Blue Screen war. (Siehe Seite 155) Das deckt sich nicht nur mit meinen eigenen Erfahrungen als Anwender, sondern auch mit meiner These, daß sehr viel von Windows 9x nach NT/2000/XP portiert wurde. Denn wenn man einen Treiber unter Windows NT/2000/XP neu schreibt, darf es das Problem eigentlich gar nicht geben, zumindest solange man wenigstens halbwegs sorgfältig arbeitet.
• Mich wundert die Schlussfolgerung "The most notable reality is that the Windows operating system is not responsible for a majority of PC crashes in our data set. Poorly-written device drivers contribute most of the crashes in our data." Zum einen sehe ich Microsoft als Firma mit in der Schuld (siehe meine Punkte oben), und zum anderen zähle ich die von Microsoft entwickelten Treiber mit zum Betriebssystem, und die Studie sagt, daß die Qualität dieser Treiber zwar besser ist, aber nicht überragend viel besser, zumindest lese ich das dort hinaus. Sie hätten daher IMHO bei obriger Aussage nicht "Windows operating system", sondern "Windows operating system kernel" schreiben müssen, damit sie richtig wird.

[1] DDK = Device Driver Kit, das Entwicklungskit für die Treiberentwicklung von Microsoft.
[2] WDM = Windows Driver Model. Im Prinzip wurde alles an Treiberschnittstelle von NT nach Windows 9x portiert, was MS mit Ach-und-Krach irgendwie portiert bekommen hatte, oder von dem MS meinte, es würde für die Treiberentwicklung im wesentlichen ausreichen, es ist also quasi ein Subset der NT-Treiberschnittstelle. Das ganze garniert mit PnP und Power Management, was es ja damals unter NT 4.0 noch nicht gab. WDM war also der Versuch, eine gemeinsame Treiberschnittstelle für Windows 9x und NT 4/2000 zu schaffen, zumindest für PnP-Treiber. (Alle anderen Treiber mußten nach-wie-vor separat entwickelt werden, unter Verwendung von unterschiedlichen Treiberschnittstellen. Ausnahme: NDIS-Treiber, das war wieder eine andere Treiberschnittstelle.)

[gnu]

Danke für deine sehr ausführliche Antwort

unter Windows 2000/XP gab es hingegen entweder Blue Screens ("IRQ not less or equal")

Das gibt es auch noch in Windows 8.1, habe ich etwa alle 3-4 Wochen, am Anfang, vor alle optionalen Updates installiert waren deutlich häufiger.

[tl;dr] Nein, ich denke nicht, daß sich das von Windows XP auf Linux übertragen läßt. Ich denke nicht einmal, daß sich das nur eingeschränkt von Windows XP auf Windows Vista/7/8/10 übertragen läßt.

Die Frage ist natürlich auch von wem die Studie in Auftrag gegeben wurde, bzw. wer sie finanziert hat (z.B. Usenix https://en.wikipedia.org/wiki/USENIX, wo sie veröffetnlicht wurde), oder ob sie nur von der University of California, Berkeley ausging.

über David A. Patterson:

Past chair of the Computer Science Department at U.C. Berkeley and the Computing Research Association, he was elected President of the Association for Computing Machinery (ACM) for 2004 to 2006 and served on the Information Technology Advisory Committee for the U.S. President (PITAC) from 2003 to 2005.

[owl102]

Das gibt es auch noch in Windows 8.1

Natürlich, welcher Treiberhersteller sagt sich schon "So, jetzt mache ich den Treiber aber lieber neu!", stattdessen wird der alte Treiber an die aktuelle Hardware angepasst. Und so haben wir auch unter Windows 8.1 immer noch das Erbe von Windows 9x in vielen wenn nicht sogar den meisten Treibern. "IRQ not less or equal" kann man eigentlich mit "Treiber, ursprünglich unter Windows 9x entwickelt und danach solange schlecht befrickelt, bis er auch unter Windows 2000 lief" übersetzen. Und das macht laut Bericht ca. 50% der Treiberfehler unter Windows XP aus. (Leider ist es nur als "Num Crashes" angegeben und nicht in Prozent, daher habe ich den Prozentwert hier sehr grob geschätzt.) Und so lassen sich schon einmal diese 50% definitiv nicht auf Linux übertragen.

BTW: Mich würde mal interessieren, wieviele Treiber von Windows 8 oder 10 diejenigen Treiberschnittstellen nutzen, die Microsoft ab Vista neu geschaffen hat. Vermutlich sind das weitaus weniger als gut wäre.

[gnu]

Ich hoffe, dass genug Spendengelder in die Entwicklung von Open-Source-Treibern fließen.

stattdessen wird der alte Treiber an die aktuelle Hardware angepasst.

Mit Sicherheit. Manche machen noch nicht mal das: Canon bietet z.B. für ältere Drucker die Treiber nur noch für Windows7 und niedriger an.
Wer nicht weiß, dass man den Windows7-Trebier auch für Windows8 verwenden kann, könnte denken "ich muss wohl einen neuen Drucker kaufen."

[owl102]

Manche machen noch nicht mal das: Canon bietet z.B. für ältere Drucker die Treiber nur noch für Windows7 und niedriger an.

Was ich meinte: Selbst Treiber für aktuelle Geräte wird Canon bestimmt nicht neu entwickeln, sondern bestehenden Code für ältere Geräte an die aktuellen Geräte anpassen. Und so sind auch viele Treiber für brandaktuelle Produkte welche, die ursprünglich mal für Windows 9x entwickelt wurden.

[gnu]

Was ich meinte: Selbst Treiber für aktuelle Geräte wird Canon bestimmt nicht neu entwickeln, sondern bestehenden Code für ältere Geräte an die aktuellen Geräte anpassen.

und da man das scheinbar nicht nur schwer in den Griff bekommen kann, wurde Minix entwickelt,
wird aber vermutlich nicht auf Linux u. BSD übertragen, weil Minix vermutlich auch Nachteile hat
https://en.wikipedia.org/wiki/Tanenbaum ... lds_debate

[owl102]

und da man das scheinbar nicht nur schwer in den Griff bekommen kann

Natürlich bekommt man das nur schwer in den Griff, denn Firmen kleben an altem Code wie ein Schiffbrüchiger an der Planke. Es ist egal, wie alt und buggy der Code ist, es ist egal, wie lange man für jede Erweiterung/Anpassung braucht, mal eben ein paar Wochen oder gar Monate zu investieren, um etwas zu überarbeiten, was es schon gibt, dafür bekommt man als Entwickler nur dann Resourcen, wenn man zum Hulk wird und/oder mit Kündigung droht. Jeder PM bekommt Krämpfe in der Hand, wenn er diesen Entwicklungsauftrag unterschreiben soll, zumal er ja auch eine Wirtschaftlichkeitsrechnung dazu anfertigen muß. Und selbst wenn es tatsächlich soweit ist, muß man ja handlungsfähig bleiben, und so müssen noch diverse Wünsche in den alten Code eingepflegt werden, und weil dies den neuen Code zeitlich verzögert, müssen mehr Wünsche als ursprünglich geplant in den alten Code statt in den neuen Code eingepflegt werden usw.

[owl102]

So, nun war das nächste Paper aus https://en.wikipedia.org/wiki/Device_dr ... rification an der Reihe. Während sich ja das erste auf Windows XP bezogen hat und eine reine Statistikauswertung ist, dort also keinerlei Mutmaßungen oder gar Untersuchungen vorhanden sind, warum die Zustände so sind wie sie sind, beschäftigt sich das zweite mit Linux und OpenBSD, und es enthält Mutmaßungen:

First, drivers in Linux and other systems are developed by a wide range of programmers who tend to be more familiar with the device rather than the OS the driver is embedded in. These developers are more likely to make mistakes using OS interfaces they do not fully understand. Second, most drivers are not as heavily tested as the rest of the kernel.

Beide halte ich für schlüssig.

Was mir aber an dem Paper fehlt ist der Vergleich mit der Praxis. Sie behandeln lediglich potentielle Fehler, automatisiert gefunden in den Quelltexten. Das Hauptproblem sind fehlende Abfragen auf Null-Pointer als Rückgabewert. Nun, wenn ich beim Laden des Treibers 1k Speicher alloziiere, wie relevant ist dann in der Praxis, daß ich den Rückgabewert nicht auf NULL abfrage? Wieviele Funktionen geben niemals einen NULL-Pointer zurück, so daß es lediglich ein Schönheitsfehler des Codes ist, den Rückgabewert nicht diesbezüglich abzufragen?

In dem Paper wird auf andere, praxisorientiertere Auswertungsmethoden von Linux-Treibern verwiesen, ich schaue mal, was man davon im Netz finden kann. Bisher zumindest sind diese beiden Studien nicht vergleichbar, man kann auch keine Aussage treffen, ob nun Windows- oder Linux-Treiber im Schnitt besser sind, und auch nicht, ob denn nun proprietäre Treiber oder Open Source Treiber von Linux besser sind oder nicht.

gnu, hast du da schon weiter gelesen als ich?