Druck auf Hardware-Hersteller

Marc Stürmer Feb. 14, 2006, 2:15 p.m.

Achwas... ich halte es da mit Torvalds: was ein Nutzer macht, kann niemals dumm sein.

Gewisse Sachen wird es eben leider niemals als Opensourcetreiber geben, da die Hersteller selber da einfach viel Zeug selber nur lizenzieren, und wenn ein proprietärer Treiber seinen Dienst zuverlässig versieht - wieso nicht?

Besser so ein Treiber als gar nichts. Der Schritt von Suse wird die Nutzer entweder zu eigenständigen Basteleien verleiten oder gleich zum Wechsel der Distribution, mehr auch nicht.

Ich kann daher die Forderung nach einem stabilen Treiber-API im Kernel von Seiten der Industrie nur unterstützen und das auch nachvollziehen.

hugo Feb. 14, 2006, 2:21 p.m.

Nope, sehe ich anders. Die proprietären Treiber machen immer wieder Ärger, weil sie eben nicht machen was sie sollen - wie zum Beispiel mit der Kernelversion zu arbeiten, mit der man arbeiten will (z.B. weil man spezielle Patches im Kernel haben will). Proprietäre Treiber sind häufig gleichbedeutend mit "gar nichts".

Hardware-Treiber sind eh nur mit der Hardware zusammen sinnvoll, von daher ist die Closed-Source-Mentalität der Hersteller albern - ihr Ziel sollte der Verkauf von Hardware sein, nicht die Behinderung von Treiberimplementierungen.

Es gibt schlichtweg keinen sinnvollen Grund dafür, das z.B. Grafikkartenhersteller oder ISDN-Karten-Hersteller ihre Treiber nicht im Source offenlegen.

Marc Stürmer Feb. 14, 2006, 2:28 p.m.

Das liegt dann an einer schlampigen Programmierung (und evtl. dem fehlenden, stabilen API), aber nicht an der Tatsache, dass sie Closed Source sind.

hugo Feb. 14, 2006, 2:50 p.m.

Das ich da nicht eingreifen kann liegt aber daran, das es Closed Source ist. Es hilft mir ausgesprochen wenig bei Problemen mit z.B. Kernelkompatibilität eines Treibers, wenn ich mir sagen kann, das die Treiberprogrammierer scheisse sind. Was ich in dem Moment brauche sind schlicht und einfach die Sourcen, um das Problem zu beheben.

Und ja, ich patche durchaus häufiger Kernel oder Treiber oder andere Sourcen. Bei _jeder_ Closed-Source-Software bin ich früher oder später in der Situation, das ich mit verfügbarem Source das Problem beheben könnte, aber eben wegen fehlendem Source dastehe und nur auf die Programmierer fluchen kann.

Gerade das ist ja einer der gravierenden Vorteile der Open Source - entweder man selber kann ändern, oder man kann sich jemanden holen der ändert. Bei Closed Source ist man auf den Goodwill der Hersteller angewiesen, und der ist schlichtweg bei den meisten Herstellern nicht existent.

Marc Stürmer Feb. 21, 2006, 11:56 p.m.

Und ich bin nach wie vor ein Anhänger eines stabilen APIs für Treiber.

Warum? Wer es wissen will, der sollte sich mal diesen wirklich interessanten Artikel aus dem Heiseforum durchlesen.

Die Welt ist nicht nur gut und böse, es gibt auch viele Grautöne und für viele auch wirklich gute Gründe, warum sie so etwas haben wollen.

Mit der Blauäugigkeit, die die Kernelentwickler da an den Tag legen, schneiden sie sich am Ende nur ins eigene Fleisch.

hugo Feb. 22, 2006, 12:27 a.m.

Komisch das immer wieder Leute erzählen warum Open Source und angebliche Blauäugigkeit nicht funktionieren würde - aber komischerweise genau in der Open Source Welt - gerade bei den angeblich "blauäugigen" - die grösste Bewegung herrscht. Die Grautöne reichen da völlig in den vielen Spielarten von Freier Software - es gibt überhaupt keinen Grund sich mit den paar wenigen Schwarztönen aus dem kommerziellen Lager abzugeben.

Sorry, aber es gibt schon lange stabile Interfaces im Kernel - das diese dann von Major-Release zu Major-Release Überarbeitungen erfahren, liegt in der Natur der Sache. Genauso wie die Tatsache, das es eben keine Binärinterfaces sind - was bei einem ständig im Source verfügbaren Produkt ja auch eher dämlich wäre.

Und Probleme haben komischerweise eben nur die Firmen mit ihren proprietären Treibern - bei Open Source Treibern findet sich immer jemand, der die Anpassungsarbeiten macht, auch wenn der ursprüngliche Programmierer keinen Bock mehr hat und die Anpassung mal mehr als reine Rekompilierung ist.

Von daher interessiert mich die Meinung von irgendwelchen Closed-Source-Treiber-Programmierern nicht die Bohne, denn es wird früher oder später immer eine freie Alternative geben - und sei es nur, weil ein anderer Hardwarehersteller schlauer ans Werk geht.

Ich hab schon viel zu oft das Gerede von Firmen und ihren Programmierern (wieso die immer das Hirn an der Gardarobe abgeben wenn sie sich äußern weiss ich allerdings nicht) gelesen, die mir auf mannigfaltige Weise erklären wollten, warum Open Source Software die kommerziellen Ergüsse mit berücksichtigen muss, weil es sonst ja auf Dauer keinen Stand im Markt behalten könnte. Und alle derartigen Erzählungen haben sich als kompletter Bullshit herausgestellt.

Übrigens gilt das auch für den von dir zitierten Artikel. Ich nehm die "Argumente" mal auseinander:

1. er vertritt die Kundenbindung über die APIs. Genau das ist aber der zentrale Kritikpunkt der jeder Form von Freier Software (wie in Freier Rede) zuwiderläuft. Warum sollte also ein Open Source Vertreter so ein Argument ernst nehmen? Warum sollte ein Kunde daran interesse haben, sich binden zu lassen, wenn es Alternativen gibt?

2. die Veränderbarkeit von Treibern ist für ihn nicht gewünscht. Ach. Aber genau das ist ein zentraler Punkt aller Open Source Lager - selbst des BSD-Lagers. Warum sollte also jemand Interesse haben, seine Rechte beschneiden zu lassen, nur weil es der Hersteller will?

3. Open Source Community funktioniert. Wie er merken würde, wenn er die Augen mal aufmachen würde. Gerade in Special-Interest Bereichen haben Kunden selber ein Interesse daran Patches zu machen - genauso wie Anwender dieser Bereiche. Natürlich kann man einfach behaupten das wäre nicht so - darf aber dann nicht erwarten, ernst genommen zu werden.

4. die Code-Qualität des Linux-Kernels ist nicht schlechter oder besser als anderer Code - wie er eben so ist, wenn er von vielen Menschen unterschiedlicher Qualifikation geschrieben wird. Aber bei Open Source können die guten Programmierer auf die Codes anderer gucken - bei Closed Source nicht. Warum sollen wir alle glauben das die Hersteller-Programmierer die Weisheit mit Löffeln gefressen haben?

5. er möchte nicht, das APIs erweitert werden - aber vielleicht möchten es die Anwender? Wessen Wollen ist wohl für den Anwender interessanter - das des Herstellers, oder das des Anwenders selber?

6. Sourcen unter NDA sind kein Open Source und deshalb auch in keiner Weise vergleichbar - Open Source lebt gerade davon, das der Support durchaus auch mal "nein" sagen kann, ohne das ein Vertrag ihm das verbietet. Wer Source unter NDA mit Open Source gleichsetzt, hat wesentliche Grundzüge von Open Source nicht kapiert.

7. wird Software durch closed-source zwangsläufig besser? Wohl kaum - ich arbeite selber seit 20 Jahren in der Softwareentwicklung und ich bin absolut sicher, das die durch Open Source breitere Basis die Qualität besser gesichert werden kann als in der in der Regel engeren Basis der Closed Source Entwicklung. Gerade bei Spezialthemen - denn da sind die Firmen in der Regel Klitschen, und die haben ausser einem übersteigertem Selbstbewusstsein oft nicht viel vorzuweisen ...

8. Kunden in der Industrie wollen System nicht updaten, weil ein funktionierendes System weniger Risiken hat als ein neues System, bei dem die Probleme nicht bekannt sind. Gerade deshalb finden die es echt klasse, wenn sie Probleme in alten Versionen beheben können, weil der Source verfügbar ist - und nicht zwangsupdaten müssen, weil der Hersteller die alte Version nicht mehr supportet. Offener Source bietet dem Kunden mehr Flexibilität - ob er sie nutzt und wie er sie nutzt ist seine Sache.

9. armes Puschel - seine Kunden fordern Linux und er heult rum. Sorry, aber mehr kann man zu dem Punkt wirklich nicht sagen. Hersteller, die sich für Kundenwünsche so wenig interessieren gehören bestraft. Was glaubt er wohl, warum Firmen Linux fordern? Nur wegen der geringeren Lizenzkosten? Da macht er es sich deutlich zu einfach. Abgesehen davon, das genau in der Open Source Community ja potentielle Kunden stecken, die er gerade mal beleidigt hat.

10. Natürlich sieht er nur die Kunden die bei ihm nachfragen, da es ja keine Open Source Version der Treiber gibt. Klassisches Problem der Engstirnigkeit: war schon immer so, wird immer so sein, weil ich nix anderes sehe - was aber einfach daran liegt, das nix anderes zu sehen ist. Ich weiss aus eigener Praxis, das oft Patches und Anpassungen bei Open Source Projekten eben nicht zwingend vom Projekt kommen, sondern von anderen, die halt ihren Itch scratchen. Ich selber machs auch so.

Sorry, aber der ganze Beitrag im Heise-Forum ist schlichtweg lächerlich und albern. Da ist kein einziger Punkt drin, der bedenkenswert wäre - das ist reines Rumgeheule eines Closed-Source-Vertreters der fürchtet, das er nicht mitspielen darf.

Und wegen so einer Heulsuse soll ich meine Haltung gegenüber closed-source-Treibern im Linux-Kernel ändern? Das meinst du nicht wirklich ernst ...

Marc Stürmer Feb. 22, 2006, 4:33 p.m.

Mit Verlaub, ich sehe das immer noch anders (wen wunderts bei meinen vorherigen Artikeln ;).

Sicher, mir sind Opensourcetreiber von etwas lieber. Nur gibt es sie leider nicht immer und wird es sie auch nicht immer aus diversen Gründen geben.

Ich persönlich bin da - und viele andere Nutzer sicherlich auch - in erster Linie Pragmatiker. Mich interessieren eigentlich diese ganzen Kriege der LKML gar nicht, ob nun Interface oder nicht. Ich will einfach, dass meine Hardware zufriedenstellend läuft. Ob es dann nun mit einem Opensourcetreiber läuft oder Closedsourcetreiber, ist mir herzlich egal, Hauptsache, es läuft.

Ich selber nutze Linux seit der Kernelversion 0.99pl14 (Slackware damals), bin inzwischen begeisterter Gentoonutzer und habe während meiner Linuxlaufbahn schon so einiges an Hardware unter Linux genutzt.

Dabei habe ich mit beiden Treibervarianten gemischte Erfahrungen gemacht, mal gute, mal schlechte.

Zum Beispiel: meine erste WLAN-Karte hatte den 8180-L-Chipsatz von Realtek. Das wird vom Vanilla-Kernel nicht unterstützt, man muss sich ein Binary only bei Realtek holen und dann hoffen, dass es funktioniert (oder auch nicht). Zu meiner Zeit damals mit Kernel 2.4 war das eher nicht - ich durfte schon froh sein, wenn das Teil mal zum WLAN-Router eine Verbindung fand, meistens stürzte der Kernel gnadenlos mit einem OOPS ab. An ein Arbeiten war mit dem Ding nicht zu denken, also flogs auch recht bald raus und wurde von mir durch eine Netgear MA311 ersetzt. Den Treiber dafür (Orinoco PCI) gibts im Kernel, und oh Wunder, ich hatte mit dieser Karte bis heute keinerlei Probleme, sie versieht ohne zu Murren zuverlässig mit dem Treiber aus dem Vanillakernel ihren Dienst.

Aber ich habe auch entgegengesetzte Erfahrungen gemacht. Ich nutze schon seit längerem eine Geforce 52xx. Ich arbeite viel mit X11, es gibt da auch einen nv-Treiber, der diese Karte anspricht. Der läuft auch, soweit, so gut. Nur: die Hardwarebeschleunigung dieses Treibers ist unter aller Kanone. Wenn ich damit GL-Sachen am Laufen habe, ruckelts, dass es eine wahre Freude ist. Das mag mitunter sicher auch daran liegen, dass nVidia da nicht mit allen Sachen rausrückt, aber das ist mir eigentlich egal.

Daher installiere ich - wie viele andere Linuxnutzer auch - eben den Binary Only Treiber, den es direkt von nVidia gibt. Der funktioniert bei mir problemlos, ich hatte damit noch nie irgendwelche Schwierigkeiten, OpenGL ist damit eine wahre Freude und ich bin zufrieden.

Meine Erfahrung ist: nur, weil etwas als Open Source vorliegt, ist es noch lange nicht automatisch deshalb gut und nur, weil etwas Closed Source ist, ist es damit automatisch schlecht.

Programmieridioten gibt es überall.

Linux hat für mich als Betriebssystem nach wie vor ein gewaltiges Potential. Bisher ist es - nicht zu Unrecht - im Serverbereich stark vertreten und ich setze mich durchaus auch mal länger hin an meinem Gentoo und versuche Sachen wie Suspend2 zum Laufen zu bringen. Sachen, die andere Betriebssysteme wie Windows oder OS X von sich aus ohne Probleme können.

Die Frage ist: wo will Linux eigentlich hin? Wenn es nach wie vor sich auf den Serverbereich beschränken will, dann reicht der momentane Kurs der Community nach wie vor aus.

Wenn es aber wirklich auf den Desktop will und eine ernstzunehmende Konkurrenz zu Windows sein will, dann wird die Community mit dem jetzigen Kurs grandios baden gehen.

Konkurrenz meine ich in der Hinsicht nicht technisch. Technisch gesehen dürfte Linux nach wie vor Windows das Wasser abgraben, aber face it: spätestens seit Windows 2000 kann man auch mit Windows recht stabil und komfortabel arbeiten, die Zeiten von Bluescreenorgien wie unter Windows 98 sind schon lange vorbei.

Baden gehen meine ich in dem Fall in der Hinsicht von Treiberunterstützung. Wenn Linux wirklich auf den Desktop will, dann muß die Treiberunterstützung besser werden und vor allem kann man es sich dann nicht leisten, Firmen und Personen, die Treiber schreiben wollen, zu vergraulen.

Man kann es einem 08/15-Windowsnutzer, der gerade meinetwegen die neueste Hyperduperturbosoundkarte gekauft hat, wieso die dann unter Linux nur in einem älteren Modus läuft und nur Windows alle Charakteristika der Karte vollstens ausschöpft.

Der Kernel ist für mich auch immer Brennpunkt sozialer Interaktion, und da wird gestritten und da treten verschiedene Projekte gegeneinander an, irgendwann gewinnt wohl das Beste und wird aufgenommen usw. Alles schön und gut.

Ich weiß auch, die Forderung nach einem stabilen Binär-API für Treiber (oder wie man das Kind auch nennen will) ist ein Dauerbrenner auf der LKML und beileibe nicht neu. Nicht ohne Grund gibts in den Kernelsourcen die Datei Documentation/stable_api_nonsense.txt, deren Thesen ich übrigens nicht teile.

Nicht ohne Grund gibt es immer wieder Initiativen - die bisher erfolglos verlaufen sind - gerade solch eine Schnittstelle zu etablieren. Und ehrlich gesagt: dem normalen Anwender wird es dabei herzlich egal sein, ob der Treiber im Kernel dann GPL ist oder nicht, Hauptsache, sein Zeug läuft.

Nicht ohne Grund gibt es unter Linux im Wifi-Bereich ein Projekt namens NdisWrapper, dass das Windows (!) Kernel API und NDIS API nachbildet, damit man eine bessere Treiberunterstützung in dem Bereich hat. Nicht ohne Grund gibt es ein kommerzielles Produkt namens Linuxant, dass dasselbe Ziel hat.

Ich verstehe einfach in der ganzen Debatte nicht, wieso sich da die Entwickler nicht auf den Standpunkt "Leben und leben lassen" stellen, sprich, beides ermöglichen. Letztendlich würde das Linux - sofern richtig gemacht - einen gewaltigen Schub bereiten.

So aber bleibt Linux eben nach wie vor in Sachen Hardwaretreibern hinterherhinkend, auch wenn die Situation eindeutig besser ist als früher. Aber nach wie vor erscheinen viele Treiber zuerst für Windows und teilweise nur für Windows.

Etwas weniger Ideologie und mehr Sinn fürs Praktische würde da meines Erachtens dem Kernel gut tun.

Vor allem, wenn man sich anschaut, wer diese Initiativen (wie beim OSDL Japan) unterstützt, gibt es noch eine weitere Gefahr: die eines Kernelforks.

Linux ist Opensource unter der GPL, das ist auch gut. Allerdings kann sich dann natürlich auch eine der Firmen, die das gerne hätte, dann selber hinsetzen und eine entsprechende Schnittstelle implementieren. Mich würde es nicht wundern, wenn das auch früher oder später passiert, denn die kritische Masse dafür dürfte durchaus da sein.

Dann gibts also den Standardkernel und dieses API-Projekt irgendwann. Wenn sich dann die Meinung der Kernelhacker in Bezug darauf nicht ändern sollte und es nicht in den Standardkernel einfliessen sollte, hindert niemand die Firma daran, den Kernel endgültig zu forken und dieses Produkt dann zu forcieren.

Klar, der neue Kernelzweig wäre auch weiterhin unter der GPL, er würde sicherlich nicht mehr unter dem Namen Linux laufen, aber er wäre existent. Und ein Fork war bisher immer etwas, was das Linuxlager vermeiden wollte.

Und dann würden dieser Fork und der Standardkernel in Konkurrenz zueinander stehen und vermutlich würde der Fork, sobald da die Treiberunterstützung besser ist, etliche Nutzer aus dem bisherigen Linuxlager anziehen.

Die Frage ist erlaubt: ist es das, was das Linuxlager will oder wie würde es in einem solchen Fall reagieren?

hugo Feb. 22, 2006, 5:37 p.m.

Auch du bringst keinen konkreten Grund, warum Linux - speziell der Kernel - auf die closed-source Treiber angewiesen ist. Für alle Beispiele gibt es Alternativen in der Hardware. Die Hersteller können sich binäre Module bauen wie sie wollen - es geht darum, ob der Kernel eine Verpflichtung oder Notwendigkeit hat für binäre Module eine Schnittstelle zu bieten, die im Kernelspace läuft.

Einfachster Weg aus dem Dilemma ist in der Regel ein unter GPL stehendes Kernel-Modul mit Interface zu einem Userspace-Daemon. Darüber lassen sich heute schon viele vergleichbare Situationen lösen. Oftmals reichen sogar schon die vorhandenen Kernel-Schnittstellen für den Userspace-Daemon aus. Wenn letzteres der Fall ist, erspart man dem User sogar das Patchen der Kernelsourcen - oder man liefert eben passend vorcompilierte Modulebinaries mit. Denn wenn die unter GPL stehen, gibts auch keine Probleme mit der Lizenz.

Die Benutzer haben einfache Mittel um Hersteller ohne vernünftige Treiber (sei es komplett GPL Treiber oder obige Kombination aus GPL-Modul und Userspace-Treiber) zu treten: Beschwerden schicken und andere Hardware kaufen. Das ist ganz simpel - und bei der Durchdringung von Linux mitlerweile auch in sehr vielen Bereichen durchaus praktikabel. Auch das NDISWrapper-Projekt ist nicht zwingend für den Betrieb eines Linux-Rechners, es finden sich für viele Fälle einfache Hardwarealternativen.

Das Gerede von "Wenn Linux auf den Desktop will muss es [insert beliebige Forderung]" zieht nicht - Linux ist schon längst auf dem Desktop. Die Hardwarevielfalt die Linux unterstützt ist um ein vielfaches grösser als die Hardwarespannbreite eines klassischen PC-Herstellers. Auch unter OS X gibt es beileibe nicht für jede mögliche Hardware einen Treiber von Apple, trotztdem heult niemand rum das Apple da was machen muss, wenn sie auf den Desktop wollen ...

Natürlich besteht beim Kernel wie bei jedem Open Source Projekt die Möglichkeit für einen Fork. Aber die Existenz der Möglichkeit eines Forks ist kein Grund irgendwelche Entscheidungen zu treffen. Es ist umgekehrt: wem die Entscheidungen im Kernel nicht passen, der kann einen Fork machen. Wo sind denn die Firmen mit ihren angeblich so tollen Resourcen und Möglichkeiten, die einen Fork des Kernels in der Support-Tiefe bieten, wie es der ursprüngliche Kernel anbietet? Das ist nur ein Scheinargument.

Wenn ein Fork das Leben für die Firmen einfacher machen würde - glaubst du wirklich, das IBM, SGI und HP und andere Firmen sich die Mühe gemacht hätten, ihre Sachen unter Open Source Lizenz zu stellen? IBM hätte garantiert alleine die Möglichkeit einen Fork zu machen, die Resourcen habe sie. Das Know-How über Betriebssysteme auch. Trotzdem haben sie sich entschieden, nicht ganz unwesentliche Teile ihrer eigenen Arbeit unter die GPL zu stellen.

Dabei gänzlich ignoriert bleibt die Tatsache, das auch ein Fork von Linux weiter der Lizenz der GPL unterläge - und viele closed-source Experimente schlicht und einfach mit der Lizenz nicht kompatibel sind.

Also nochmal: warum sollte es die Linux Kernel Entwickler scheren, was die Hardwarehersteller wollen? Was würde der Kernel gewinnen, wenn er den eingeschlagenen Weg verlässt? Es gibt Möglichkeiten externe non-GPL-Elemente zu integrieren. Und zwar über die oben angesprochenen Userspace-Daemonen. Warum soll der Kernel non-GPL-Elemente zu first-class-Citizens machen? Was wird damit gewonnen?

Bisher habe ich dafür keinerlei brauchbaren Grund gesehen. Denn wie gesagt - wenn die Hersteller ein ernsthaftes Interesse hätten und wirklich darauf angewiesen wären, Teile unter propreitären Lizenzen zu verteilen, dann hätten sie schon längst die Möglichkeiten gehabt. Warum tun sie es dann nicht?

Ich halte die Haltung der Kernel-Programmierer für extrem pragmatisch in dieser Frage.

hugo Feb. 22, 2006, 6:28 p.m.

Oh, und übrigens das mit OSDL Japan: das war ein Irrtum, die haben schon längst ihr Proposal geändert, es geht definitiv nicht mehr um die Unterstützung von closed source Treibern. Das Problem war hauptsächlich durch dusseliges Management beim OSDL entstanden, die schlichtweg falsch kommuniziert haben. Bei kroah.com kann man dazu ein paar mehr Details finden.

hugo Feb. 23, 2006, 10:07 a.m.

Und noch ein Nachtrag: Wasabi Systems - ein Embedded-Systeme Hersteller - hat eine recht gute Aufstellung, was die GPL für Firmen bedeutet. Und ein eigenes Kapitel über binäre Treiber da drin - und wieso diese geduldete GPL-Verletzungen darstellen, die ein Konkurrent durchaus als Angriffspunkt nehmen kann. Ein weiterer Grund keine closed-source Treiber zu schreiben - und vor allem ein sehr klarer Grund für die Kernel-Entwickler, eben diese Schiene nicht weiter zu fördern.

Marc Stürmer Feb. 24, 2006, 12:14 p.m.

Tja, also zu den Kommentaren:

1. Habe ich nie gesagt, dass der Kernel darauf angewiesen ist.
2. Habe ich allerdings durchaus gesagt, dass sich damit Linux einiges an Potential selber beraubt, da es so niemals die Treiberunterstützung bekommen wird wie Windows sie hat.
3. Linux ist für mich nach wie vor nicht wirklich auf dem Desktop angekommen. Es ist auf dem Weg dahin, ja. Aber bis es da wirklich landet, müssen noch einige Steine aus dem Weg geräumt werden.

Sicher, es gibt inzwischen sehr schön komfortable Distributionen wie Ubuntu. Die habe ich auch einige Zeit laufen gehabt, es ist kein Wunder, dass sie als sie erschien wie aus dem Nichts aus dem Stand heraus eine der beliebtesten Distributionen überhaupt geworden ist.

In einer idealen Welt hätten wir für alles und jedes Opensourcetreiber und wären zufrieden; nur leider leben wir nicht in einer idealen Welt.

Übrigens ist Mac OS X in dem Punkt überhaupt nicht mit Linux vergleichbar, denn:

1. unterliegt der eigentliche Kernel von OS X (Darwin) nicht der GPL wie Linux, sondern der Apple Public Source License v 2.0 (APSL2), nachzulesen hier, vereinzelte Teile stehen vielleicht auch noch unter einer BSD-Lizenz. GPL - Fehlanzeige.
2. Treiberprogrammierung unter OS X läuft normalerweise über das I/O-Kit, eine Abstraktionsschicht, die Apple extra dafür eingezogen hat. Also im Prinzip ein festes API für Treiber. Infos dazu gibt es hier.

Sprich: es gibt unter OS X das, was manche Treiberprogrammierer im Linuxkernel gerne hätten.

Um auf die letzten Fragen zu antworten: natürlich müssen die Kernelentwickler sich nicht darum scheren, was die Hardwarehersteller wollen.

Im Umkehrschluss kann man allerdings auch sagen, dass sich die Hardwarehersteller nicht darum kümmern müssen, was die Kernelentwickler gerne wollen (Offenlegung von Spezifikationen usw.) und diese ebenso im Regen stehen lassen können.

Was man gewonnen hätte, wenn man auf die Forderungen der HW-Hersteller eingehen würde, wäre eine durchweg breitere Treiberunterstützung und damit eine potentiell grössere Benutzerbasis. Nicht mehr, nicht weniger.

Wenn man das nicht ermöglicht ist es auch kein Problem, nur müssen sich dann manche Linuxevangelisten auch nicht wundern, dass Linux nach wie vor nicht die Rolle spielt, die es längst spielen könnte auf dem Desktop.

Interessant in dem Zusammenhang finde ich dazu auch den Artikel "Luftbuchungen der freien Softwareszene" aus der Telepolis.

Marc Stürmer Feb. 24, 2006, 12:15 p.m.

Nachtrag dazu:

Nochmal der Link zum I/O-Kit, weil es den im obigen Kommentar verhauen hat.

hugo Feb. 24, 2006, 12:46 p.m.

Man würde nichts gewinnen wenn man auf die Forderung der HW-Hersteller einginge. Im Gegenteil, die Hersteller würden dann eher dazu tendieren binäre Treiber zu erstellen als Open Source Treiber zu erstellen, so wie es jetzt immer häufiger der Fall ist. Durch die Haltung der Kernel-Programmierer haben Hardware-Hersteller einen direkten Anreiz ihre Treiber als Source verfügbar zu machen - denn nur so kommen sie in den Kernel-Tree rein, nur so haben sie die ganzen Vorteile die sich daraus ergeben.

Dazu kommt das Problem, welches in meinen obigen Links ja auch konkret diskutiert wird, dass ein festgelegtes binäres Interface für Treiber die Kernel-Entwicklung blockiert. Desweiteren der Punkt, dass binäre non-GPL-Treiber die GPL des Kernels verletzten.

Ich wüsste nicht wo da irgendwo was zu gewinnen wäre für den Linux Kernel.

Marcus hat in seinem Artikel bei Telepolis natürlich Recht - es gibt einige ziemlich krasse Misstöne zwischen den Aktionen und angeblichen Zielen mancher OSS-Vertreter (Marcus' Artikel lese ich eh immer wieder gerne, da er eben die Technizität deutlich aussen vor lässt und sich mehr auf die sozialen Komponenten konzentriert). Kommt einfach daher, das sich die OSS-Gemeinde sehr stark aus Technikern zusammensetzt, deren Weltbild oftmals etwas sehr seltsam ist - Technik als seelig machenden Religionsersatz finde ich genauso spinnert wie "normale" Religionen.

Allerdings ist eben die no-binary-drivers Richtung des Linux Kernels absolut nicht mit Spinnerei oder ähnlichem gleichzusetzen, sondern mit ganz simplem Kalkül: die Nachteile eines binären Interfaces überwiegen deutlich, wärend die möglichen Vorteile der stärkeren Blockade von non-GPL-Treibern deutlich überwiegen.