|
Diese Diskussion wurde archiviert.
Es können keine neuen Kommentare abgegeben werden.
|
 |
|
|
|
|
|
|
|
Ich verstehe das nicht. Warum sollte man closed source Treiber verbieten? Das man sie nicht standardmässig mit dem Kernel vertreibt, finde ich ok, resp. dass soll auch so sein. Jedoch glaube ich, dass solche Patches ein grosser Rückschritt für linux ist. Viele Firmen sind nämlich langsam bereit, zu ihrer Hardware Treiber für die doch immer noch kleine Linux Gemeinde (zu der ich mich auch dazuzähle) zu entwickeln. Was sie aber jetzt dafür erhalten haben ist alles andere als Dank. Klar, wenn ich die Auswahl habe zwischen gpl-treiber und closed source Treiber, dann werde ich, sofern beide auf dem gleichen standm den freien Treiber wählen. Jedoch kann es immer mal wieder ein Stück Hardware geben, wo der Treiber der Herstellerfirma viel besser oder der einzige ist.
Meiner Meinung sollten wir die Entwicklung solcher Treiber fördern. Evt. beginnen die Firmen dann irgendwann von selbst die Sourcen zu veröffentlichen, weil sie Verbesserungen durch die Comunity wünschen.
Gruss
13. Apostel
|
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 14:25 MEW (#2)
|
|
|
|
|
meistens machen diese Closed Source Komponenten das System instabil. Ein device driver hat eine wichtige Aufgabe und sollte nicht buggy sein.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
>meistens machen diese Closed Source Komponenten das System instabil.
beispiele ? ...und kein hörensagen !
>Ein device driver hat eine wichtige Aufgabe und sollte nicht buggy sein.
Stabilität hat mit open/closed source nur sehr wenig zu tun. Das ist eine tatsache die von den GPL-fundamentalisten gerne übersehen wird.
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 18:41 MEW (#15)
|
|
|
|
|
Jo, aber ohne Moeglichkeit zum Code-Audit und Patchen bist du auf den Hersteller angewiesen, den seine Hardware spaetestens am Ende es Marketing-Zyklus nicht mehr interessiert. Die Hersteller selbst wuerden vom dem Feedback sicher auch profitieren, da es immer etwas zu lernen gibt, auch fuer Profis.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 19:29 MEW (#16)
|
|
|
|
|
> beispiele ? ...und kein hörensagen !
* Kernelmodul von ATI
* cisco_ipsec
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 14:53 MEW (#4)
|
|
|
|
|
Immer wird ueber die Freiheit von Software diskutiert. Beginnt die Freiheit aber nicht dort, wo ich entscheiden kann ob ich einen proprietaeren Treiber oder (wenn vorhanden) den OpenSource-Treiber einsetzen will?
Ich moechte jedenfalls meine nvidia-Module nicht missen...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 15:41 MEW (#5)
|
|
|
|
|
Die Freiheit beginnt erstmal beim Urheber. Du musst Linux nicht nutzen. Auch das ist Freiheit.
|
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 18:18 MEW (#10)
|
|
|
|
|
Sorry, ich sage sowas nicht gern und auch nicht oft, aber Du hast die letzten paar Jahre geschlafen, was Multimedia und Linux anbelangt. Sowohl in SuSE oder Ubuntu (und bestimmt in vielen andern Distries auch) reicht es das Installationspaket mit dem automatischen Updatetool aus dem Internet herunterladen und installieren zu lassen. ZWEI Mausklicks. Kein Configgewuerge, nichts. So einfach gehts nichtmal in Windows.
Bitte zukuenftig nicht mehr solche Geruechte in die Welt setzen.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 18:23 MEW (#12)
|
|
|
|
|
Och, unter Windows reicht oft schon ein einziger Klick auf OK und du brauchst dich um gar nichts mehr kuemmern.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 21:01 MEW (#20)
|
|
|
|
|
bei verteiltem /usr/X11R6?
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 22:58 MEW (#22)
|
|
|
|
|
Es klang nicht danach als nutze er ein Tuetenlinux. Ich glaube, ihr redet einfach aneinander vorbei.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 20:59 MEW (#19)
|
|
|
|
|
wie im artikel bezeichnet, ist die aktion ein warnschuss. tatsache ist naemlich, dass der freiheitskampf der gpl tagtaeglich weitergefuehrt wird. und das ist auch gut so, auch wenn man sich ueber den nutzen einzelner massnahmen streiten kann. solange man naemlich auf closed-source-treiber angewiesen ist, kann es immer passieren, dass aus wirtschaftlichen interessen heraus oder einfach aus mangelnder erfahrung mit den entsprechenden schnittstellen fuer bestimmte betriebssysteme ein schlechterer treiber verbreitet wird als fuer andere.
|
|
|
|
|
|
|
|
|
|
|
|
|
ich wäre für einen userspace wrapper. Damit kann das stabile Interface nicht abstürzen durch einen instabilen treiber.
wenn man jeden mist in den kernel läd, muss man sich über instabilität nicht wundern.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 18:16 MEW (#9)
|
|
|
|
|
Na ja, wenn die Userspace-Sachen dann root-Rechte brauchen, wird das Otto-Normal nicht jucken und kann genauso viel Schaden anrichten. Im Kernel ist es natuerlich notorisch ein Problem, das stimmt schon. Ein schlanker Kernel ist ja nicht nur wegen closed-source Zusaetzen sinnvoll. Andererseits ist das teilweise schon problematisch fuer die Performanz. Zumindest fuer meinen 486er liegen zwischen pppd und in-kernel pppoe Welten und das bei gerade mal 1 MBit ADSL. Ich glaube 10 MBit/s DSL wuerde der ueber pppd nicht mitmachen.
Die Sache mit den ATI/nVidia-Treibern kann ich persoenlich nicht nachvollziehen. Ich glaube aber, die Masse der User kann darauf verzichten, da die open-source Treiber in X.org oder XFree86 voellig ausreichend sind. Dass es Binaer-Treiber dann in der Regel sowieso nur fuer Linux/x86 gibt, finde ich sowieso diskriminierend. Der Aufwand dieselben Treiber auch fuer andere Plattformen zu kompilieren
duerfte aeusserst gering sein.
|
|
|
|
|
|
|
|
|
|
|
|
|
Der Aufwand dieselben Treiber auch fuer andere Plattformen zu kompilieren
duerfte aeusserst gering sein.
Der aufwand die hardware unter anderen plattformen zum laufen zu bekommen ist alles andere als gering. Ein devicetreiber ist was anderes als ein hello_world.cc...
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 18:36 MEW (#14)
|
|
|
|
|
Ah sorry. Ich bin leider nur professioneller hello_world.c-Schreiber. Vielleicht habe ich ja keine Ahnung.
Komischerweise funktionieren die Open-Source Treiber in X.org/XFree86 so ziemlich ueberall. Mir ist wohl klar, dass es Specifica gibt, die nicht ueberall funktionieren oder fuer die erst ein Interface implementieren muesste. Ausnahmen bestaetigen wie immer die Regel.
Und selbst wenn ich Scheisse labere, gibt es immer noch keinen Grund fuer x86-only obwohl die meiste Hardware genauso in einem anderen PCI/AGP-Slot funktioniert.
|
|
|
|
|
|
|
|
|
|
|
|
|
Deine Professionalitaet in Ehren.. aber ich glaube auch, dass hochoptimierte 3D-Treiber der aktuellen Generation etwas voellig anderes als 'normale' 2D-Treiber sind.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 20:33 MEW (#18)
|
|
|
|
|
Klar, aber der meiste Code ist wohl ueberhaupt nicht system-spezifisch. Das einzig spezifische duerfte DMA/Bus-Handling sein, was auch jetzt schon von 2D-Treibern genutzt wird. AFAIK sind die 3D-Treiber nur so fett, weil sie OpenGL fuer die Grafikhardware uebersetzen. Der Code ist nicht Linux-spezifisch, sondern basiert auf X11.
Ich behaupte, der Hauptgrund fuer Binaertreiber ist zu verhindern, dass die Konkurrenz billige Clones auf den Markt schmeissen kann und die womoeglich auch noch mit einem nVidia/ATI-Label versieht.
|
|
|
|
|
|
|
|
|
|
|
|
|
"Klar, aber der meiste Code ist wohl ueberhaupt nicht system-spezifisch."
Die heutigen Hochleistungstreiber sind extrem aufs OS abgestimmt und nutzen sehr viel Magie. Die Linux und Windowstreiber haben praktisch keinen identischen Code. Such dir mal die diversen (unabhaengigen) Interviews des Nvidia Linux-Teams raus.
"Ich behaupte, der Hauptgrund fuer Binaertreiber ist zu verhindern, dass die Konkurrenz billige Clones auf den Markt schmeissen kann"
Nicht dass die heutigen 3D-Karten triviale Hardware waeren, im Gegenteil.. aber da die Konkurenten ebenfalls sehr fortgeschrittene Hardware hat und die Unterschiede nur marginal sind, sind die tatsaechlichen Unterschiede in den Treibern - und darum werden die nicht geoeffnet.
Leider sind die Grafikkartenhersteller der Ansicht, dass sie bei einer Offenlegung der Treiber ihren Technologie und damit Wettbewerbsvorteil verlieren wuerden. Ich /persoenlich/ bin der Meinung, dass das nicht marktrelevant ist: die Produktzyklen sind viel zu kurz, als dass die Konkurenz mit der Entwicklung mithalten koennte. Aber das ist halt Ansichtssache, und genau weis man das ja nicht..
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 23:02 MEW (#23)
|
|
|
|
|
Windows habe ich absichtlich nicht erwaehnt, sondern darauf hingewiesen, dass ich von X11 und OpenGL spreche. Allein Direct3D zu implementieren duerfte ja einige Mannmonate verschlingen. Zumindest ab einem gewissen Layer sollten die Treiber dafuer identisch sein. Ich lese auch gern die Interviews, wenn ich sie denn finde.
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 23:28 MEW (#24)
|
|
|
|
|
Also das einzige Interview, das ich auf die schnelle finden konnte, behauptet das Gegenteil:
"Due to the unified driver infrastructure, we share a common driver base between multiple operating systems (like Linux, Windows, Linux64, Win64, MacOS, Solaris)."
http://www.linuxquestions.org/questions/t253027.html
|
|
|
|
|
|
|
|
|
|
|
|
|
Ein Slot in dem die karte mechanisch platz hat und ein blech zum festschrauben sind nicht die einzigen voraussetzungen damit eine karte in einem nicht-intel system laeuft.
Da ist schon etwas mehr notwendig: mindestens ein angepasstes (karten-)bios (das auch gewartet werden will), manchmal eine zertifizierung vom rechner-hersteller damit er nicht einfach auflegt wenn jemand beim support anruft und sagt "mein rechner bootet nicht! warum ?"
... und noch manches mehr.
Dass die hersteller für solche corner-cases kein geld ausgeben wollen versteh' ich. Waere ich hersteller würde ich auch genauestens kalkulieren ob ich für eine anwendergruppe im sub-promillebereich solch einen aufwand treiben kann.
Letztendlich alles eine frage von geld & gier.
Real C programmers never die, they cast to void...
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Monday 06. February 2006, 23:50 MEW (#25)
|
|
|
|
|
1.)
die grossen Distris werden über Gregh lachen,
und es mit eiskalt rauspatchen.
2.)
es wird in kurzer Zeit ein Patchset entstehen,
mit dem man diesen Schwachsinn auch aus dem Vanillakernel rauswerfen kann, ohne einen
distrispezifischen Kernel nutzen zu müssen.
3.)
ja mich stören Closed-Source-LKMs auch,
aber es ist im grossen und ganzen wichtiger, besonders bei USB-Geräten, Heimnutzer freundlich
und kompatibel zu bleiben.
4.)
Ich geh zu BSD, und mach mich Free ;)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<rant>Genau.. FreeBSD, die sogar Binary-only Kernel-Module in ihrem Vanilla haben (highpoint). </rant>
*seufz*
|
|
|
|
|
|
|
|
|
Von Anonymer Feigling am Tuesday 07. February 2006, 19:41 MEW (#27)
|
|
|
|
|
<realität>Und funktioniert es etwa nicht :) !?</realität>
|
|
|
|
|
