Moin,
ehe jetzt die Hasstiraden losgehen und Ihr mich in der Luft
zerrewißt, möchte ich doch erstmal eines klarstellen:
Mit "stabilem Kernel-API" ist ein binärfestes API gemeint, daß
scheint einem Teil der postenden nicht so ganz klar zu sein. Es geht
nicht um das Einfrieren des Kernel-APIs.
Zu meiner Herkunft:
Die Firma, in der ich arbeite, entwickelt Hardware und Software im
industriellen Umfeld. Wir bieten die Hardware mit Treibern für
Windows, Linux, vxWorks, QNX, RTX, WindowsCE, Solaris, RTOS-UH, IRIX,
NetOS und viele weitere an. Ich persönliche schreibe an den
Linux-Treibern und arbeite mit an den WindowsCE und vxWorks-Sourcen.
Warum entwickelt die Firma, in der ich arbeite, Treiber closed
source?
1.
Wir bieten ein einheitliches API zu unserer HW über alle Systeme und
Karten.
Und ja, wir binden unsere Kunden mittels dieses APIs an uns. Wir
wollen nicht, daß ein Mitbewerber unser API auf seine Karten anpaßt.
Das mag vielen hier im Forum nicht schmecken, aber sorry, wir leben
davon, daß Kunden unsere Karten (und nicht unsere Treiber) kaufen.
Und die Treiberentwicklung kostet eine Stange Geld. Die Linux
Entwicklung mit Abstand am meisten (vor allem aufgrund des Supports).
2.
Wir möchten nicht, daß jemand unsere Treiber verändert. Wer einmal
Kunden (ihrerseits Applikationsprogrammierer) mit Problemen supportet
hat, der kann sich grob vorstellen, was abgeht, wenn man nicht mal
mehr im Ansatz nachvollziehen kann, mit welcher Treiberversion der
Kunde herumfuhrwerkt.
Sowas kostet richtig Zeit und damit Geld. Und es tut mir leid, auch
ich bin Star Trek Anhänger, aber von der geldlosen Gesellschaft sind
wir noch ein paar Jahrtausende und etliche George Ws entfernt.
3.
Das Argument: Die OS-Community würde ja unsere Treiber warten.
Mal im Ernst, wie groß glaubt Ihr ist die Community in unserem
Umfeld? Und glaubt Ihr wirklich, wir hätten die Zeit zu warten, bis
Herr Linus geneigt ist, sich einen evtl. Patch zu Gemüte zu führen
und ihn in den Kernel aufzunehmen.
Die Berichte von zig Entwicklern, die Versuchen Patches in den
offiziellen Kernel zu bringen, sprechen für sich. So viel zu Eurer
viel gepriesenen Freiheit.
4.
Der Linux-Source ist voll von Beweisen, wo "begnadete" Programmierer
glaubten zu wissen, was ein Interrupt ist und wie man sich zu
synchronisieren hat. Wir haben keine Lust, nach solchen Fehlern beim
Kunden suchen zu müssen. Die Bugs, die wir selber bauen, sind schlimm
genug.
5.
Wir möchten nicht, daß jemand ohne unsere Kontrolle unser API
erweitert. Wir stehen Erweiterungen durchaus offen gegenüber (und
implementieren diese auf Kudenwunsch), aber auch hier müssen wir
gezwungenermassen immer die Kosten mit ein kalkulieren.
6.
Wir haben durchaus Versuche gehabt, wo Kunden unseren Source gegen
NDA selbst weiterentwickeln und warten wollten. Das Ergebnis in
_allen_ Fällen: Der Support Aufwand für diese Kunden stand in keinem
Verhältnis zu den Kosten, die wir gehabt hätten, wenn wir die
Weiterentwicklung selbst übernommen hätten.
7.
OS-Source Code ist besser und die Entwicklung geht schneller voran.
Letzteres mag stimmen, aber wird der Code oder das System dadurch
wirklich zwangsläufig besser? Wie ist es dann zu erklären, daß die
Context-Switches und Interrupt-Latenzen im Kernel 2.6 zumindest für
x86 und PPC um sovieles höher liegen, als im 2.4er Kernel?
8.
Kunden im industriellen Umfeld neigen dazu ihre Systeme einzufrieren.
Ergebnis für uns: Wir können keine Treiber brauchen, die ständig an
das neueste API angepaßt werden. Wir brauchen Treiber die unter Linux
laufen. Folge: Tausende von Codezweigen, die auf die diversen APIs
seit Kernel 2.2 Rücksicht nehemen. Manchmal muß ich gestehen, beneide
ich den Kollegen, der die Windows-Treiber entwickelt, um seinen
klaren, sauberen Code (und wenn einer so etwas über einen
Windows-Source sagt, will das wohl was heissen).
9.
Nicht wir haben uns für Linux entschieden. Sondern Kunden haben es
von uns gefordert. Sollen wir ernsthaft unsere Codebasis für 15
weitere Betriebssysteme offenlegen, weil es der Linux-Community Spaß
macht. Nochmal: Die ideale Welt, die Ihr glaubt zu haben, hätte ich
auch gern, aber sie existiert nicht.
10.
Kunden, die Probleme mit ihrem System haben, kommen eh zu uns und
belästigen keine OS-Programmierer, auch wenn die Fehler durchaus des
öfteren bei letzteren zu suchen sind. So sind Kunden aber leider
nunmal.
Ich glaube, ich hätte da noch ein paar mehr Punkte, aber leider fehlt
im Moment die Zeit.
Was uns helfen würde (und definitiv auch der Stabilität und dem
Ansehen von Linux etwas bringen würde), wäre ein _binärfestes_
Kernel-API. Viele Kunden möchten gern einen Treiber als Binary von
Rechner A zu Rechner B schaufeln. Geht unter Linux leider nicht, wenn
Rechner A und Rechner B nicht die gleiche Distribution oder die
gleiche Kernel-Version verwenden :(
Viel Kunden haben nichtmal den Kernel-Source (in korrekter
Konfiguration) zu Ihrem laufenden Kernel...
Und nochwas: Wer mal ein schönes, stabiles und binärfestes Kernel-API
sehen möchte, der kann sich ja mal bei QNX umschauen.
Verbleibe freundlich,
Andreas Block
ehe jetzt die Hasstiraden losgehen und Ihr mich in der Luft
zerrewißt, möchte ich doch erstmal eines klarstellen:
Mit "stabilem Kernel-API" ist ein binärfestes API gemeint, daß
scheint einem Teil der postenden nicht so ganz klar zu sein. Es geht
nicht um das Einfrieren des Kernel-APIs.
Zu meiner Herkunft:
Die Firma, in der ich arbeite, entwickelt Hardware und Software im
industriellen Umfeld. Wir bieten die Hardware mit Treibern für
Windows, Linux, vxWorks, QNX, RTX, WindowsCE, Solaris, RTOS-UH, IRIX,
NetOS und viele weitere an. Ich persönliche schreibe an den
Linux-Treibern und arbeite mit an den WindowsCE und vxWorks-Sourcen.
Warum entwickelt die Firma, in der ich arbeite, Treiber closed
source?
1.
Wir bieten ein einheitliches API zu unserer HW über alle Systeme und
Karten.
Und ja, wir binden unsere Kunden mittels dieses APIs an uns. Wir
wollen nicht, daß ein Mitbewerber unser API auf seine Karten anpaßt.
Das mag vielen hier im Forum nicht schmecken, aber sorry, wir leben
davon, daß Kunden unsere Karten (und nicht unsere Treiber) kaufen.
Und die Treiberentwicklung kostet eine Stange Geld. Die Linux
Entwicklung mit Abstand am meisten (vor allem aufgrund des Supports).
2.
Wir möchten nicht, daß jemand unsere Treiber verändert. Wer einmal
Kunden (ihrerseits Applikationsprogrammierer) mit Problemen supportet
hat, der kann sich grob vorstellen, was abgeht, wenn man nicht mal
mehr im Ansatz nachvollziehen kann, mit welcher Treiberversion der
Kunde herumfuhrwerkt.
Sowas kostet richtig Zeit und damit Geld. Und es tut mir leid, auch
ich bin Star Trek Anhänger, aber von der geldlosen Gesellschaft sind
wir noch ein paar Jahrtausende und etliche George Ws entfernt.
3.
Das Argument: Die OS-Community würde ja unsere Treiber warten.
Mal im Ernst, wie groß glaubt Ihr ist die Community in unserem
Umfeld? Und glaubt Ihr wirklich, wir hätten die Zeit zu warten, bis
Herr Linus geneigt ist, sich einen evtl. Patch zu Gemüte zu führen
und ihn in den Kernel aufzunehmen.
Die Berichte von zig Entwicklern, die Versuchen Patches in den
offiziellen Kernel zu bringen, sprechen für sich. So viel zu Eurer
viel gepriesenen Freiheit.
4.
Der Linux-Source ist voll von Beweisen, wo "begnadete" Programmierer
glaubten zu wissen, was ein Interrupt ist und wie man sich zu
synchronisieren hat. Wir haben keine Lust, nach solchen Fehlern beim
Kunden suchen zu müssen. Die Bugs, die wir selber bauen, sind schlimm
genug.
5.
Wir möchten nicht, daß jemand ohne unsere Kontrolle unser API
erweitert. Wir stehen Erweiterungen durchaus offen gegenüber (und
implementieren diese auf Kudenwunsch), aber auch hier müssen wir
gezwungenermassen immer die Kosten mit ein kalkulieren.
6.
Wir haben durchaus Versuche gehabt, wo Kunden unseren Source gegen
NDA selbst weiterentwickeln und warten wollten. Das Ergebnis in
_allen_ Fällen: Der Support Aufwand für diese Kunden stand in keinem
Verhältnis zu den Kosten, die wir gehabt hätten, wenn wir die
Weiterentwicklung selbst übernommen hätten.
7.
OS-Source Code ist besser und die Entwicklung geht schneller voran.
Letzteres mag stimmen, aber wird der Code oder das System dadurch
wirklich zwangsläufig besser? Wie ist es dann zu erklären, daß die
Context-Switches und Interrupt-Latenzen im Kernel 2.6 zumindest für
x86 und PPC um sovieles höher liegen, als im 2.4er Kernel?
8.
Kunden im industriellen Umfeld neigen dazu ihre Systeme einzufrieren.
Ergebnis für uns: Wir können keine Treiber brauchen, die ständig an
das neueste API angepaßt werden. Wir brauchen Treiber die unter Linux
laufen. Folge: Tausende von Codezweigen, die auf die diversen APIs
seit Kernel 2.2 Rücksicht nehemen. Manchmal muß ich gestehen, beneide
ich den Kollegen, der die Windows-Treiber entwickelt, um seinen
klaren, sauberen Code (und wenn einer so etwas über einen
Windows-Source sagt, will das wohl was heissen).
9.
Nicht wir haben uns für Linux entschieden. Sondern Kunden haben es
von uns gefordert. Sollen wir ernsthaft unsere Codebasis für 15
weitere Betriebssysteme offenlegen, weil es der Linux-Community Spaß
macht. Nochmal: Die ideale Welt, die Ihr glaubt zu haben, hätte ich
auch gern, aber sie existiert nicht.
10.
Kunden, die Probleme mit ihrem System haben, kommen eh zu uns und
belästigen keine OS-Programmierer, auch wenn die Fehler durchaus des
öfteren bei letzteren zu suchen sind. So sind Kunden aber leider
nunmal.
Ich glaube, ich hätte da noch ein paar mehr Punkte, aber leider fehlt
im Moment die Zeit.
Was uns helfen würde (und definitiv auch der Stabilität und dem
Ansehen von Linux etwas bringen würde), wäre ein _binärfestes_
Kernel-API. Viele Kunden möchten gern einen Treiber als Binary von
Rechner A zu Rechner B schaufeln. Geht unter Linux leider nicht, wenn
Rechner A und Rechner B nicht die gleiche Distribution oder die
gleiche Kernel-Version verwenden :(
Viel Kunden haben nichtmal den Kernel-Source (in korrekter
Konfiguration) zu Ihrem laufenden Kernel...
Und nochwas: Wer mal ein schönes, stabiles und binärfestes Kernel-API
sehen möchte, der kann sich ja mal bei QNX umschauen.
Verbleibe freundlich,
Andreas Block