"... Er weist nochmals darauf hin, dass die GPL lediglich die Weitergabe, nicht die Benutzung von Code regelt. Das Laden eines Binärmoduls sei eine Benutzung und dabei dürfe den Benutzern keinerlei Einschränkung auferlegt werden. ... ... Auch wenn proprietäre Module weiterhin möglich sind, sind sie bei den meisten Entwicklern - auch Torvalds selbst - unbeliebt. Die Kernel-Hacker und ihre Firmen werden daher weiterhin Druck auf die Hersteller ausüben, ihre Treiber und Spezifikationen vollständig zu öffnen, und Anstrengungen fördern, freie Alternativen zu unfreien Treibern zu entwickeln."
Damit hat sich Linus klar dazu positioniert, daß er proprietäre Module auch nicht mag, eine Verletzung der GPL im bisherigen Verfahren aber nicht vorhanden ist. Damit ist für mich klar, das sich vorerst nicht viel ändert, aber die Bemühungen zu freien Treibern weitergeführt werden. Hört sich für mich nicht nur schlüssig, sondern (derzeit) auch als vernünftigste Möglichkeit an.
Von ultimasephrioth am Fr, 15. Dezember 2006 um 09:37 #
Ich würde es begrüssen, dass proprietäre Module im Userspace laufen. Nicht aus Angst vor einer GPL-Verletzung, sondern weil ich nicht gerne unkontrollierbaren Code in Kernelspace sehe. Deswegen wäre es gut, wenn die Schnittstelle aufgenommen wird, aber niemand dazu gezwungen wird, sie zu verwenden. Ich denke die meisten Hardware-Entwickler werden diese trotzdem nutzen, da es für sie einfacher wird.
Was soll das bringen ? Die Userspace Treiber müssen praktisch vollen Zugriff auf die Hardware haben, dann bringen sie das System eben nicht durch einen (fehlerhaften) direkten Speicherzugriff durcheinander sondern durch entsprechende Aufrufe der Interface-Routinen.
Die Userspace Treiber müssen praktisch vollen Zugriff auf die Hardware haben, dann bringen sie das System eben nicht durch einen (fehlerhaften) direkten Speicherzugriff durcheinander sondern durch entsprechende Aufrufe der Interface-Routinen.
Von Hansi Glaser am Fr, 15. Dezember 2006 um 14:33 #
Ganz genau. Eine zweite Möglichkeit, Hardware-Treiber zu schreiben, würde auch ich sehr begrüßen. Da die meisten Treiber sowieso nur Memory- und IO-Zugriffe sowie (manchmal) Interrupts brauchen, kann die Schnittstelle zwischen Kernel und Treiber-Userspace-Programm sehr dünn gehalten werden. Es genügen dann nämlich einfache registrier-Routinen (wie ioperm() heute schon verfügbar ist). Wichtig wäre aber auch, dass die Programme zusätzlich noch Timer usw. zur Verfügung haben.
Bleibt die Frage, wie die Kommunikation zwischen Treiber und der Anwendung stattfindet. Soll ein eigenständiges Treiber-Programm gemacht werden, das dann mit Anwendung via IPC, d-bus, ... kommuniziert? Oder genügt eine Library, gegen die von der Anwendung direkt gelinkt wird und die "Kommunikation" einfache Function-Calls sind? Letzters funktioniert natürlich nur bei Hardware, die von einer einzigen Anwendung genutzt wird.
Seis wies sei, für Hardware-Entwickler täten sich mit den User-Space-Treibern ganz neue Welten auf. I2C, Sound, Eval-Boards für Embedded Systems und FPGAs, ... Einfach ohne Treiber-Installation die neueste Entwicklungsumgebung für ein µC-Board in Betrieb nehmen und schon los-Debuggen. *träum*
Bye Hansi
PS: Mir fällt gerade ein, dass mit libusb die Userspace-Treiber schon längst realisiert sind, allerdings halt nur für USB.
Mir schwebt da ein Deamon vor, bei dem sich Treiber im Userspace anmelden und im von Deamon reservierten Speicher laufen können, dabei würde es sich bei diesem deamon um ein art Pseudokernel handeln, der eine, möglicherweise, feste API/ABI hat und mit dem eigendlichen Kernel kommuniziert. Mit dem dev-deamon sollte es möglich sein die Devices dieses Pseudokernels nutzbar zu machen. Damit wäre aus meiner Sicht allen geholfen, auch Entwicklern, die beim Entwickeln ihrer Kerneltreiber nicht gerne das ganze System geferden möchten.
Von Hans Mauwurf am Fr, 15. Dezember 2006 um 10:15 #
...grad' noch gelesen, dass Treiber im User-Space
1. ...sich einfacher entwickeln lassen (Schnittstelle beständiger und unabhängig von Kernel-Headers). 2. ...sich einfacher installieren lassen. 3. ...in den meisten Bereichen performanter sind.
Denk mal nach, ich würde sagen Win ist ein schönes Beispiel dafür, bisher hat der Kernel keine fest Schnittstellen, hätte er eine würde er Altlaste mit sich herrumschleppen und könnte nicht mehr die beste Lösung nehmen sondern nur die kompatibelste. Zudem würde es dazu führen das man dann ähnlich wie bei Win nach der Linux Installation die Treiberinstallation macht, wer will das wirklich? Ich nicht! Ich finde es sehr angenehm das ich nicht von X-Herstellern Treiber laden muss, sondern alles von einer Distro bekomme.
Win Vista ist ein Moloch der sicher besser und bugärmer und früher da sein hätte können wenn sie die Abwärtskompatibilität geopfert hätten.
Ich finde auch dass Treiber offen sein sollen, damit ich als Hardware-käufer sicher sein kann, dass meine Hardware in 10 Jahren immer noch betrieben werden kann.
Ich warte auch schon sehnsüchtig auf die OGC (Open Grafics Card) oder wie auch immer sie das Produkt dann nennen. Damit brauche ich mir nie wieder Sorgen über die korrekte Erkennung und Einrichtung der Grafikkarte machen. Diese Sicherheit ist mir sogar 50 Mehrkosten bei schlechterer Performanz gegenüber ATI und NVIDIA wert.
Von theBohemian am Fr, 15. Dezember 2006 um 12:03 #
> Diese Sicherheit ist mir sogar 50 Mehrkosten bei schlechterer Performanz gegenüber ATI und NVIDIA wert. Mir auch.
Ich finde es aber auch prima, dass ich wenn ich irgendwann mal einen ARM- oder MIPS-basierten Computer mit PCI bzw. AGP-Slot finde, diese Karte da rein stecken kann und sie wird genauso funzen wie auf dem x86-PC. Das gleiche gilt, wenn ich mich irgendwann mal entscheiden sollte lieber *BSD, OpenSolaris, Syllable oder JNode einzusetzen.
Von Hans Maulwurf am Fr, 15. Dezember 2006 um 13:45 #
Zudem würde es dazu führen das man dann ähnlich wie bei Win nach der Linux Installation die Treiberinstallation macht, wer will das wirklich? Ich nicht! Ich finde es sehr angenehm das ich nicht von X-Herstellern Treiber laden muss, sondern alles von einer Distro bekomme.
Heutzutage laufen proprietäre Treiber nicht im Userspace und müssen trotzdem nachinstalliert werden. Das ist also kein wirkliches Argument.
3. ...in den meisten Bereichen performanter sind. Das ist blos ne Behauptung ohne jeglichen Beweis. Ein Userspace-Treiber kann max. genauso schnell sein. Performanter geht nicht, nur möglicherweise in den Fällen wo der Kerneltreiber schlechter programmiert ist als der Userspacetreiber. Oder was soll im Userspace weniger Rechenleistung kosten als im Kernelspace?
Laut dem Pro-Linux-Bericht vom 14.12.2006: Wie Thomas Gleixner erklärte, genügt diese Schnittstelle zumindest den Anforderungen vieler industrieller Geräte, für die bisher proprietäre Kernel-Treiber entwickelt wurden. Viele dieser Geräte bestehen lediglich aus Dual-Port-Speicher, auf den über Memory-Mapped I/O zugegriffen werden kann, und einem Interrupt-Anschluss. Seinen Angaben zufolge ist die Performance einer angepassten Anwendung in Kombination mit der neuen Schnittstelle bis zu 20% höher als bei einem reinen Kernel-Treiber.
1. ...sich einfacher entwickeln lassen (Schnittstelle beständiger und unabhängig von Kernel-Headers). Klar sind die Schnittstellen beständiger, dadurch werden sie aber nicht immer einfacher in der Entwicklung. Man kann ja im Userspace nicht auf alles direkt zugreifen und muß daher durch bestimmte "Nadelöhre", was es wiederum komplexer macht. Kommt halt auf den Treiber selbst an, ein Grafiktreiber ist hier halt erheblich komplexer als ein USB-Irgendwas-Treiber.
2. ...sich einfacher installieren lassen. Naja, kann schon sein, wenn die glibc, der Compiler und der Kernel selbst paßt (z.B. größer oder gleich Version x.y.z), aber so den Bringer halte ich es auch nicht.
3. ...in den meisten Bereichen performanter sind. Das ist blos ne Behauptung ohne jeglichen Beweis. Ein Userspace-Treiber kann max. genauso schnell sein. Performanter geht nicht, nur möglicherweise in den Fällen wo der Kerneltreiber schlechter programmiert ist als der Userspacetreiber. Oder was soll im Userspace weniger Rechenleistung kosten als im Kernelspace?
Performance ist ein umstrittenes Thema! Speziell ohne entsprechende Tests und Benchmarks sind die Aussagen lediglich Schätzungen, welche bei echten Praxistests komplett anders aussehen können. Auch hängt hier viel vom Treiberdesign selbst ab.
Obwohl Du im Augenblick nur die Vorteile sehen magst, so gibt es durchaus auch Nachteile wodurch folgende Dinge nicht mehr erfüllt werden:
1. Stabilität 2. Langzeitsupport 3. Optimierung und Performance 4. einfaches Debugging 5. bessere Erkennung von Hardware- und Firmwarefehlern (welche durch prop. Treiber gerne kaschiert werden)
Gutes Beispiel dafür ist zum Beispiel der BT878/879 Treiber, von welchem Teile sogar nach Windows portiert wurden (um auch hier einen freien Treiber zu verwirklichen). Viele Hersteller hatten hier die Treiberunterstützung nach 1,5 Jahren eingeschränkt (hohe Auflösungen nicht mehr zugelassen, etc...). Außerdem waren einige der Treiber niemals wirklich stabil und kommunizierten über eine propritären Schnittstelle mit der eigenen Software (damit waren einige Features nur mit der eigenen Software möglich).
Nächstes Beispiel ist z.B. der Nvidia Treiber. Hier war der freie nv Treiber von Anfang an stabiler und in den letzten Versionen sogar um etliches schneller (bei 2D Operationen).
Bei ATI gilt selbiges. -> Probleme beim Umschalten zwischen X und Konsole, Suspend Mode, etc.. Mein Notebook verwendet den freien Treiber, welcher sogar 3D unterstützt und funktioniert ohne erkennbare Probleme.
WLAN, etc..
Natürlich gibt es auch Berichte in welchen der Herstellertreiber stabiler und besser funktioniert.
Aber auf längere Zeit gesehen, habe sich die freien Treiber meist durchgesetzt. Auch sind diese Treiber ein wichtiger Grund wieso man zu Linux benutzt.
Es gibt genügend andere Betriebssysteme welche Closed Source Treiber unterstützen. Wieso muß man ausgerechnet einem freien System diese Bürde aufhalsen?
Von Sebastian Schlüter am Fr, 15. Dezember 2006 um 12:36 #
Ich kann die Haltung von Torvalds nachvollziehen, aber ich möchte ganz kurz auf einen Aspekt eingehen, der noch nicht genannt worden ist.
Bei sicherheitsrelevanten Systemen ist es meiner Ansicht nach extrem wichtig, quelloffene und transparente Treiber zu haben.
(Es geht mir dabei explizit nicht um proprietäre Treiber für 3D-Grafikkarten. Ich persönlich brauche keine solchen Treiber, finde es aber nicht sooo dramatisch, wenn alle Benutzer, die Wert auf die schnellste 3D-Performance oder die volle 3D-Feature-Unterstüzung ihrer Karte legen, dafür einen proprietären Treiber benötigen -- solange ein gewisser Basis-Feature-Satz auch mit einem quelloffenen Treiber möglich ist.)
Bei sicherheitsrelevanten Systemen sehe ich das aber sehr eng. Treiber, die bei einem solchen System benötigt werden (also beispielsweise für Netzwerkinterfaces und IDE/SATA/SCSI-(Raid)-Controller usw.) müssen meiner Ansicht nach quelloffen und transparent sein. (Transparent soll in diesem Zusammenhang bedeuten, dass der Code auch verständlich sein muss, schließlich könnte man sonst einen binären Blob auch hexadezimal kodiert im Quelltext unterbringen - dann wäre der Treiber zwar rein formal quelloffenen, aber trotzdem völlig unverständlich).
Und angesichts der sich zurzeit extrem verschärfenden Treiber-Situation -- wie man am Beispiel von WLAN-Karten unschwer erkennen kann -- halte ich die harte Linie, wie sich beispielsweise von den OpenBSD-Leuten verfolgt wird, für sehr richtig. Im übrigen zeigt gerade das OpenBSD-Projekt zurzeit eindrucksvoll, dass man mit so einer harten Linie auch durchaus erfolgreich sein kann.
Im Vergleich zu OpenBSD habe ich bei Linux immer den Eindruck, dass "Popularität" an erster Stelle steht, gefolgt von "Hardware-Unterstüzung mit allen Mitteln", gefolgt von "Latenz bzw. Durchsatz". Danach kommt lange nichts. Dann kommt "Stabilität" und irgendwann tatsächlich sogar "Sicherheit".
Ich habe den Eindruck, dass eine Entscheidung, die den Linux-Kernel so richtig unattraktiv für Firmen machen würde, egal wie sehr eine solche Entscheidung sachlich begründbar wäre, niemals durchkommen würde, denn die Kernel-Entwickler würden fast alles tun, um ihre #1-Priorität "Popularität" nicht zu gefährden.
Full Ack. Auf Servern und Internet-Gateways (also allen Rechnern die direkt mit dem Internet kommunizieren) würde ich proprietäre Treiber niemals akzeptieren. Und alle proprietäre Software darf, wenn überhaupt, nur über Proxies, Filter und IDS mit dem Internet reden.
Wer es gewohnt ist proprietäre Software wie z.B. Windows oder Mac OS zu nutzen findet das sicherlich albern und paranoid. Aber wenn man sich ein bischen mit Sicherheit, Spyware, Hintertüren, Key Escrow, Nach-Hause-Telefonieren etc. beschäftigt, wird klar daß die Hersteller proprietärer Software und ihre Regierungen ihren Spanner- und Kontroll-Gelüsten einfach nicht widerstehen können.
Bekannt wurden z.B. Versionen des M$ Media-Player, die heimlich an M$-Server senden was man sich so alles ansieht; Versionen vom Internet-Explorer die heimlich die ganze Registry an M$-Server senden; Platinen-Layout-Programme die heimlich eine Liste aller auf dem Rechner installierten Software an den Hersteller senden; Windows-Versionen mit Fernwartungs-Usern für M$ die man als Administrator nicht deaktivieren kann; ein Office-Paket von Apple das bei jedem Aufruf den Apple-Browser Safari eine Apple-URL aufrufen läßt (und sich so die Proxy-Einstellung vom Systemdialog zunutze macht); Versionen von M$ Outlook die bei jeder S/MIME-verschlüsselten Mail den Session-Key gleich 2x mit dem Public-Key verschlüsseln (was vermutlich das Knacken vereinfacht); andere Crypto-Software die ihre Export-Genehmigung von den US-Behörden nur erhielt weil sie Schlüsselbits leckte (also besonders leicht zu knacken war).
Und erinnert sich noch jemand daran wie ein Unbekannter den Account des Kernel-Entwicklers Dave Miller mißbrauchte um eine Hintertür in den Kernel-Source zu schmuggeln? Aus "if (uid == 0)" (ein Test ob der User root ist) wurde "if (uid = 0)" (der User wird zu root). Zugegeben, das ist plump, und flog sofort auf als ein anderer Bitkeeper-User die Änderungen routinemäßig las. Aber wer ist so scharf auf so eine Hintertür daß er das Risiko einer Entdeckung eingeht, und hat genug Ressourcen um an die Schlüssel von Dave Miller zu kommen ohne entdeckt zu werden? Da fallen mir nur gewisse 3-Buchstaben-Behörden ein.
Bedenke: Paranoia bedeutet "krankhafter, weil unbegründeter Verfolgungswahn". Da wir tatsächlich digital verfolgt werden, ist unsere Vorsicht aber nicht unbegründet und schon gar kein Wahn. Oder würdet Ihr es "paranoid" nennen wenn sich eine Maus vor einer Katze versteckt?
Warum wird nicht neben dem proprietären Treiber (der wohl seine Existenzberechtigung haben mag) eine Art "Light"-Version herausgegeben, die wenigstens die Basisfunktionen zur Verfügung stellt?
Stattdessen weigert man sich sogar bereits von anderen Entwicklern programmierte Treiber freizugeben. Das verstehe ich nicht ganz.
Warum wird nicht neben dem proprietären Treiber (der wohl seine Existenzberechtigung haben mag) eine Art "Light"-Version herausgegeben, die wenigstens die Basisfunktionen zur Verfügung stellt? Das ist doch der Fall. Was glaubst du, wer hinter der Entwicklung von "nv" steckt?
Mag sein, dass du recht hast, aber kannst du mir bitte einen Link dazu schicken? Und ist das bei ATI genauso, da habe ich schon ziemlich gegenteiliges gehört?
Ich sehe hier kein Problem, nichttriviale Funktionsaufrufe im Kernel müssen eben nach und nach per EXPORT_SYMBOL_GPL() geschützt werden. Dann besteht auch keine Gefahr das proprietäre Module in den Verdacht geraten eine "derived work" zu sein.
Von Kai F. Lahmann am Fr, 15. Dezember 2006 um 21:54 #
damit wäre das Thema wohl (hoffentlich) erstmal wieder vom Tisch - diese Treiber werden also geduldet, aber nicht gefördert. Imho die praktikabelste Lösung, solange Linux am Markt so unwichtig ist, dass man froh sein kann, wenn ein Hersteller überhaupt (!) auch nur schlechte solche anbietet.
Da Grafikkarten eines der meistgenannten Probleme beim Thema proprietäre Treiber sind hier ein Link zu einem Projekt, das an der Entwicklung einer offenen Grafikkarte arbeitet:
... Auch wenn proprietäre Module weiterhin möglich sind, sind sie bei den meisten Entwicklern - auch Torvalds selbst - unbeliebt. Die Kernel-Hacker und ihre Firmen werden daher weiterhin Druck auf die Hersteller ausüben, ihre Treiber und Spezifikationen vollständig zu öffnen, und Anstrengungen fördern, freie Alternativen zu unfreien Treibern zu entwickeln."
Damit hat sich Linus klar dazu positioniert, daß er proprietäre Module auch nicht mag, eine Verletzung der GPL im bisherigen Verfahren aber nicht vorhanden ist.
Damit ist für mich klar, das sich vorerst nicht viel ändert, aber die Bemühungen zu freien Treibern weitergeführt werden.
Hört sich für mich nicht nur schlüssig, sondern (derzeit) auch als vernünftigste Möglichkeit an.
Wirklich viel gewonnen hat man da nicht.
Nein, müssen sie nicht (siehe µ-Kernel).
Bleibt die Frage, wie die Kommunikation zwischen Treiber und der Anwendung stattfindet. Soll ein eigenständiges Treiber-Programm gemacht werden, das dann mit Anwendung via IPC, d-bus, ... kommuniziert? Oder genügt eine Library, gegen die von der Anwendung direkt gelinkt wird und die "Kommunikation" einfache Function-Calls sind? Letzters funktioniert natürlich nur bei Hardware, die von einer einzigen Anwendung genutzt wird.
Seis wies sei, für Hardware-Entwickler täten sich mit den User-Space-Treibern ganz neue Welten auf. I2C, Sound, Eval-Boards für Embedded Systems und FPGAs, ... Einfach ohne Treiber-Installation die neueste Entwicklungsumgebung für ein µC-Board in Betrieb nehmen und schon los-Debuggen. *träum*
Bye
Hansi
PS: Mir fällt gerade ein, dass mit libusb die Userspace-Treiber schon längst realisiert sind, allerdings halt nur für USB.
Damit wäre aus meiner Sicht allen geholfen, auch Entwicklern, die beim Entwickeln ihrer Kerneltreiber nicht gerne das ganze System geferden möchten.
1. ...sich einfacher entwickeln lassen (Schnittstelle beständiger und unabhängig von Kernel-Headers).
2. ...sich einfacher installieren lassen.
3. ...in den meisten Bereichen performanter sind.
Im Moment sehe ich da nur Vorteile.
Was spricht eigentlich dagegen?
Zudem würde es dazu führen das man dann ähnlich wie bei Win nach der Linux Installation die Treiberinstallation macht, wer will das wirklich? Ich nicht! Ich finde es sehr angenehm das ich nicht von X-Herstellern Treiber laden muss, sondern alles von einer Distro bekomme.
Ich finde auch dass Treiber offen sein sollen, damit ich als Hardware-käufer sicher sein kann, dass meine Hardware in 10 Jahren immer noch betrieben werden kann.
Ich warte auch schon sehnsüchtig auf die OGC (Open Grafics Card) oder wie auch immer sie das Produkt dann nennen. Damit brauche ich mir nie wieder Sorgen über die korrekte Erkennung und Einrichtung der Grafikkarte machen. Diese Sicherheit ist mir sogar 50 Mehrkosten bei schlechterer Performanz gegenüber ATI und NVIDIA wert.
Läuft da eigentlich noch was? Man hört da so wenig von. Und dabei würde ich schon einige Kunden kennen.
Mir auch.
Ich finde es aber auch prima, dass ich wenn ich irgendwann mal einen ARM- oder MIPS-basierten Computer mit PCI bzw. AGP-Slot finde, diese Karte da rein stecken kann und sie wird genauso funzen wie auf dem x86-PC. Das gleiche gilt, wenn ich mich irgendwann mal entscheiden sollte lieber *BSD, OpenSolaris, Syllable oder JNode einzusetzen.
Heutzutage laufen proprietäre Treiber nicht im Userspace und müssen trotzdem nachinstalliert werden. Das ist also kein wirkliches Argument.
3. ...in den meisten Bereichen performanter sind.
Das ist blos ne Behauptung ohne jeglichen Beweis. Ein Userspace-Treiber kann max. genauso schnell sein. Performanter geht nicht, nur möglicherweise in den Fällen wo der Kerneltreiber schlechter programmiert ist als der Userspacetreiber.
Oder was soll im Userspace weniger Rechenleistung kosten als im Kernelspace?
Laut dem Pro-Linux-Bericht vom 14.12.2006:
Wie Thomas Gleixner erklärte, genügt diese Schnittstelle zumindest den Anforderungen vieler industrieller Geräte, für die bisher proprietäre Kernel-Treiber entwickelt wurden. Viele dieser Geräte bestehen lediglich aus Dual-Port-Speicher, auf den über Memory-Mapped I/O zugegriffen werden kann, und einem Interrupt-Anschluss. Seinen Angaben zufolge ist die Performance einer angepassten Anwendung in Kombination mit der neuen Schnittstelle bis zu 20% höher als bei einem reinen Kernel-Treiber.
Klar sind die Schnittstellen beständiger, dadurch werden sie aber nicht immer einfacher in der Entwicklung. Man kann ja im Userspace nicht auf alles direkt zugreifen und muß daher durch bestimmte "Nadelöhre", was es wiederum komplexer macht.
Kommt halt auf den Treiber selbst an, ein Grafiktreiber ist hier halt erheblich komplexer als ein USB-Irgendwas-Treiber.
2. ...sich einfacher installieren lassen.
Naja, kann schon sein, wenn die glibc, der Compiler und der Kernel selbst paßt (z.B. größer oder gleich Version x.y.z), aber so den Bringer halte ich es auch nicht.
3. ...in den meisten Bereichen performanter sind.
Das ist blos ne Behauptung ohne jeglichen Beweis. Ein Userspace-Treiber kann max. genauso schnell sein. Performanter geht nicht, nur möglicherweise in den Fällen wo der Kerneltreiber schlechter programmiert ist als der Userspacetreiber.
Oder was soll im Userspace weniger Rechenleistung kosten als im Kernelspace?
Obwohl Du im Augenblick nur die Vorteile sehen magst, so gibt es durchaus auch Nachteile wodurch folgende Dinge nicht mehr erfüllt werden:
1. Stabilität
2. Langzeitsupport
3. Optimierung und Performance
4. einfaches Debugging
5. bessere Erkennung von Hardware- und Firmwarefehlern (welche durch prop. Treiber gerne kaschiert werden)
Gutes Beispiel dafür ist zum Beispiel der BT878/879 Treiber, von welchem Teile sogar nach Windows portiert wurden (um auch hier einen freien Treiber zu verwirklichen). Viele Hersteller hatten hier die Treiberunterstützung nach 1,5 Jahren eingeschränkt (hohe Auflösungen nicht mehr zugelassen, etc...). Außerdem waren einige der Treiber niemals wirklich stabil und kommunizierten über eine propritären Schnittstelle mit der eigenen Software (damit waren einige Features nur mit der eigenen Software möglich).
Nächstes Beispiel ist z.B. der Nvidia Treiber. Hier war der freie nv Treiber von Anfang an stabiler und in den letzten Versionen sogar um etliches schneller (bei 2D Operationen).
Bei ATI gilt selbiges. -> Probleme beim Umschalten zwischen X und Konsole, Suspend Mode, etc..
Mein Notebook verwendet den freien Treiber, welcher sogar 3D unterstützt und funktioniert ohne erkennbare Probleme.
WLAN, etc..
Natürlich gibt es auch Berichte in welchen der Herstellertreiber stabiler und besser funktioniert.
Aber auf längere Zeit gesehen, habe sich die freien Treiber meist durchgesetzt. Auch sind diese Treiber ein wichtiger Grund wieso man zu Linux benutzt.
Es gibt genügend andere Betriebssysteme welche Closed Source Treiber unterstützen. Wieso muß man ausgerechnet einem freien System diese Bürde aufhalsen?
mfg unreal
Es geht also doch, daß Du Dich äußerst, ohne gleich jemanden zu beleidigen...
Möge dies Dir in Zununft noch viele Male gelingen!
Danke Linus!
Bei sicherheitsrelevanten Systemen ist es meiner Ansicht nach extrem wichtig, quelloffene und transparente Treiber zu haben.
(Es geht mir dabei explizit nicht um proprietäre Treiber für 3D-Grafikkarten. Ich persönlich brauche keine solchen Treiber, finde es aber nicht sooo dramatisch, wenn alle Benutzer, die Wert auf die schnellste 3D-Performance oder die volle 3D-Feature-Unterstüzung ihrer Karte legen, dafür einen proprietären Treiber benötigen -- solange ein gewisser Basis-Feature-Satz auch mit einem quelloffenen Treiber möglich ist.)
Bei sicherheitsrelevanten Systemen sehe ich das aber sehr eng. Treiber, die bei einem solchen System benötigt werden (also beispielsweise für Netzwerkinterfaces und IDE/SATA/SCSI-(Raid)-Controller usw.) müssen meiner Ansicht nach quelloffen und transparent sein. (Transparent soll in diesem Zusammenhang bedeuten, dass der Code auch verständlich sein muss, schließlich könnte man sonst einen binären Blob auch hexadezimal kodiert im Quelltext unterbringen - dann wäre der Treiber zwar rein formal quelloffenen, aber trotzdem völlig unverständlich).
Und angesichts der sich zurzeit extrem verschärfenden Treiber-Situation -- wie man am Beispiel von WLAN-Karten unschwer erkennen kann -- halte ich die harte Linie, wie sich beispielsweise von den OpenBSD-Leuten verfolgt wird, für sehr richtig. Im übrigen zeigt gerade das OpenBSD-Projekt zurzeit eindrucksvoll, dass man mit so einer harten Linie auch durchaus erfolgreich sein kann.
Im Vergleich zu OpenBSD habe ich bei Linux immer den Eindruck, dass "Popularität" an erster Stelle steht, gefolgt von "Hardware-Unterstüzung mit allen Mitteln", gefolgt von "Latenz bzw. Durchsatz". Danach kommt lange nichts. Dann kommt "Stabilität" und irgendwann tatsächlich sogar "Sicherheit".
Ich habe den Eindruck, dass eine Entscheidung, die den Linux-Kernel so richtig unattraktiv für Firmen machen würde, egal wie sehr eine solche Entscheidung sachlich begründbar wäre, niemals durchkommen würde, denn die Kernel-Entwickler würden fast alles tun, um ihre #1-Priorität "Popularität" nicht zu gefährden.
Wer es gewohnt ist proprietäre Software wie z.B. Windows oder Mac OS zu nutzen findet das sicherlich albern und paranoid. Aber wenn man sich ein bischen mit Sicherheit, Spyware, Hintertüren, Key Escrow, Nach-Hause-Telefonieren etc. beschäftigt, wird klar daß die Hersteller proprietärer Software und ihre Regierungen ihren Spanner- und Kontroll-Gelüsten einfach nicht widerstehen können.
Bekannt wurden z.B. Versionen des M$ Media-Player, die heimlich an M$-Server senden was man sich so alles ansieht; Versionen vom Internet-Explorer die heimlich die ganze Registry an M$-Server senden; Platinen-Layout-Programme die heimlich eine Liste aller auf dem Rechner installierten Software an den Hersteller senden; Windows-Versionen mit Fernwartungs-Usern für M$ die man als Administrator nicht deaktivieren kann; ein Office-Paket von Apple das bei jedem Aufruf den Apple-Browser Safari eine Apple-URL aufrufen läßt (und sich so die Proxy-Einstellung vom Systemdialog zunutze macht); Versionen von M$ Outlook die bei jeder S/MIME-verschlüsselten Mail den Session-Key gleich 2x mit dem Public-Key verschlüsseln (was vermutlich das Knacken vereinfacht); andere Crypto-Software die ihre Export-Genehmigung von den US-Behörden nur erhielt weil sie Schlüsselbits leckte (also besonders leicht zu knacken war).
Und erinnert sich noch jemand daran wie ein Unbekannter den Account des Kernel-Entwicklers Dave Miller mißbrauchte um eine Hintertür in den Kernel-Source zu schmuggeln? Aus "if (uid == 0)" (ein Test ob der User root ist) wurde "if (uid = 0)" (der User wird zu root). Zugegeben, das ist plump, und flog sofort auf als ein anderer Bitkeeper-User die Änderungen routinemäßig las. Aber wer ist so scharf auf so eine Hintertür daß er das Risiko einer Entdeckung eingeht, und hat genug Ressourcen um an die Schlüssel von Dave Miller zu kommen ohne entdeckt zu werden? Da fallen mir nur gewisse 3-Buchstaben-Behörden ein.
Bedenke: Paranoia bedeutet "krankhafter, weil unbegründeter Verfolgungswahn". Da wir tatsächlich digital verfolgt werden, ist unsere Vorsicht aber nicht unbegründet und schon gar kein Wahn. Oder würdet Ihr es "paranoid" nennen wenn sich eine Maus vor einer Katze versteckt?
Welche ist das?
Es interessiert mich weil ich selbst eine Originalversion des Herstellers von Eagle benutze.
Schöne Grüße
Mark
Stattdessen weigert man sich sogar bereits von anderen Entwicklern programmierte Treiber freizugeben. Das verstehe ich nicht ganz.
Das ist doch der Fall. Was glaubst du, wer hinter der Entwicklung von "nv" steckt?
http://wiki.duskglow.com/tiki-index.php?page=Open-Graphics