1. Foren
  2. Kommentare
  3. OpenSource-Forum
  4. Alle Kommentare zum Artikel
  5. › Linus Torvalds: "Externe…

Aber schon 6 Wochen alte Kerneltreiber...

  1. Thema
  1. 1
  2. 2

Neues Thema


  1. Aber schon 6 Wochen alte Kerneltreiber...

    Autor: /mecki78 04.09.12 - 12:48

    ...laufen manchmal nicht mehr. Ich denke bei Schnittstellen ging es darum, dass Windows und OS X feste Schnittstellen zwischen dem eigentlichen Kernel und den Gerätetreibern bzw. virtuellen Treibern (z.B. Dateisysteme, die ja nicht wirklich an ein Gerät gebunden sind) anbietet, Linux jedoch nicht. Sicher, auch Windows und OS X haben diese Schnittstelle im Laufe der Zeit öfters mal erweitert und teilweise sogar komplett umgebaut... aber das geschieht dann einmal alle 2-4 Jahre (und wenn es geschieht, dann auch nicht zwangsweise immer für alle Schnittstellen, denn letztlich gibt es nicht DIE eine Schnittstelle, es gibt einen ganzen Satz unterschiedlicher Schnittstellen).

    Der Linux Kernel sieht vor, dass jedes mal, wenn ein neuer Kernel gebaut wird, auch alle Treiber neu gebaut werden. Das ist nicht nur zum einen lästig (es kostet sehr viel Zeit, wenn man den Kernel selber bauen will), es ist auch oft völlig unnötig und macht es Herstellern fast unmöglich Treiber in bereits "gebauter" Form auszuliefern (also eben nicht im Source). Das ist der Grund, warum so viel Hardware unter Linux nicht läuft: Der Hersteller hat keinen Bock alle paar Wochen neue Treiber online zu stellen auf seiner Seite (was er bei anderen Systeme alle paar Jahre machen muss, wenn überhaupt).

    Also läuft eben nur Hardware, dessen Treiber OpenSource ist (was aber viele Hersteller nicht wollen, nicht können oder rechtlich nicht dürfen), wenn jemand anderes einen Treiber ohne Spec (Reverse Engineering) als OpenSource veröffentlicht (diese Treiber sind dann aber meistens instabil und beherrschen nur einen deutlich eingeschränkteren Featureumfang) oder wenn ein Hersteller die Zeit und Resourcen hat seine Treiber entweder selber alle paar Wochen zu erneuern oder sich ein eigenes festes Kernelinterface zu basteln (das ist teuer und aufwendig; das können sich große Firmen wie NVidia, AMD und Intel leisten, kleine aber nicht).

    Ein Grund warum es solange dauert, bis HTC, Samsung, etc. Android Updates für ihre Geräte veröffentlichen, wenn sie es überhaupt machen, ist laut dieser Hersteller der enorme Aufwand ihre Treiber an das neue System (das auch einen neuen Kernel hat) anzupassen. Gäbe es feste Schnittstellen, dann wäre da nichts anzupassen.

    /Mecki

  2. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: xmaniac 04.09.12 - 18:19

    Nach "aussen" ist ja sogar Windows weitgehend POSIX-Kompatibel. Linus macht sich die Sache halt immer sehr einfach. Die aussenliegenden Kernelschnittstellen sind auch relativ zweitrangig, solange jeder Furz der Hardware anspricht in den Kernel MUSS. Und dort ändert er die ABI im 3 Tages Rythmus - was noch zu verkraften wäre, gäbe es wenigstens dazu eine saubere und stets aktuelle Dokumentation. So aber endet das schreiben von Kernelmodulen stets in Reverseengineering, und Firmen wie nVidia bewegen sich mit Ihren Binary-Blobs mit ABI-Wrapper am Rande der Legalität. Naja, der Typ hat einfach zu viel Ego, plus Herrscharen von Möchtegerns mit null Ahnung die jeden Müll glauben den Linus erzählt. Da Reflektiert jeder Radikale seine aussagen Tiefer und setzt sich mehr mit den betreffenden Thematiken auseinander als der übliche Linux-Fanboy...

  3. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: /mecki78 04.09.12 - 18:34

    xmaniac schrieb:
    --------------------------------------------------------------------------------
    > Naja, der Typ hat einfach zu viel Ego, plus Herrscharen von Möchtegerns
    > mit null Ahnung die jeden Müll glauben den Linus erzählt.

    An wen erinnert mich diese Aussage... da war doch jemand... ach ja, richtig, Steve Jobs :-P

    /Mecki

  4. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 04.09.12 - 21:04

    xmaniac schrieb:
    --------------------------------------------------------------------------------
    > ... und Firmen wie nVidia bewegen
    > sich mit Ihren Binary-Blobs mit ABI-Wrapper am Rande der Legalität.
    Es ist, positiv ausgedrückt, eine sehr elegante Lösung, wie ich finde, wieso sollte es am Rande der Legalität sein? Es sind doch proprietäre (nicht-quelloffene) Treiber (d.h. externe Module für den Linux-Kernel) prinzipiell erlaubt, oder nicht?
    Ich meine, entweder es ist erlaubt oder nicht, oder?
    Oder ist die GPL2 etwa 'schwammig' formuliert? Ich denke nicht.

  5. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: Anonymer Nutzer 05.09.12 - 04:28

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das ist der Grund, warum so viel Hardware unter Linux nicht läuft:
    > Der Hersteller hat keinen Bock alle paar Wochen neue Treiber online zu
    > stellen auf seiner Seite (was er bei anderen Systeme alle paar Jahre machen
    > muss, wenn überhaupt).

    Müssen sie zwar nicht, macht weder Nvidia noch AMD etc pp

    > Also läuft eben nur Hardware, dessen Treiber OpenSource ist (was aber viele
    > Hersteller nicht wollen, nicht können oder rechtlich nicht dürfen), wenn
    > jemand anderes einen Treiber ohne Spec (Reverse Engineering) als OpenSource
    > veröffentlicht (diese Treiber sind dann aber meistens instabil und
    > beherrschen nur einen deutlich eingeschränkteren Featureumfang) oder wenn
    > ein Hersteller die Zeit und Resourcen hat seine Treiber entweder selber
    > alle paar Wochen zu erneuern oder sich ein eigenes festes Kernelinterface
    > zu basteln (das ist teuer und aufwendig; das können sich große Firmen wie
    > NVidia, AMD und Intel leisten, kleine aber nicht).

    1) Ach was, jetzt funktioniert es oder wie?

    2) Ach was, die bauen sich ein eigenes Kernel-Interface? Quark, die bauen einen Layer!

    3) Schon mal die Readme von z.B. Nvidia gelesen?
    Was du compilierst ist nur, ein Layer"-Modul", das an dem Kernel-Interface andockt und wiederum als Zwischenschritt/schicht dient um die BLOB zu nutzen.
    Ganz einfach weil Nvidia und Co. die BLOB nicht freigeben wollen.

    Da die Lösung über mehrere Kernel-Versionen problemlos läuft bzw sich compilieren lässt, ist das Problem gar nicht so gravierend, denn jedes mal wenn sich die Kernel-Schnittstelle ändert muss einfach nur der Layer angepasst werden und nicht der Treiber.

    4) Bei Intel sind die meisten Treiber als Open Source verfügbar :)

    > Ein Grund warum es solange dauert, bis HTC, Samsung, etc. Android Updates
    > für ihre Geräte veröffentlichen, wenn sie es überhaupt machen, ist laut
    > dieser Hersteller der enorme Aufwand ihre Treiber an das neue System (das
    > auch einen neuen Kernel hat) anzupassen. Gäbe es feste Schnittstellen, dann
    > wäre da nichts anzupassen.

    Nein, der Hauptgrund ist das diese Firmen ein Smartphone nach dem anderen rauswerfen und gar nicht gewillt sind diese mit Updates/Upgrades zu versorgen!

    Das Paradebeispiel war ja wohl die Ausrede mit dem HTC Desire HD!
    Die US Version bekommt ein Upgrade auf 4.0, aber alle anderen nicht... ;)



    1 mal bearbeitet, zuletzt am 05.09.12 04:30 durch PyCoder.

  6. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: Flying Circus 05.09.12 - 11:46

    PyCoder schrieb:
    --------------------------------------------------------------------------------
    > 4) Bei Intel sind die meisten Treiber als Open Source verfügbar :)

    +1

    > Nein, der Hauptgrund ist das diese Firmen ein Smartphone nach dem anderen
    > rauswerfen und gar nicht gewillt sind diese mit Updates/Upgrades zu
    > versorgen!

    Natürlich. Eine neue Android-Version ist ja durchaus ein Kaufgrund. Und dazu kommt noch, daß die Brüder unbedingt ihren eigenen Mist obendrauf klatschen müssen (wie heißt der Dreck bei Motorola doch gleich noch?). Dann hat man natürlich Gefummel. Ist aber eigenes Verschulden.

  7. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: Flying Circus 05.09.12 - 11:50

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > Das ist der Grund, warum so viel Hardware unter Linux nicht läuft

    Wieviel Hardware läuft denn nicht, mal von Grafikkarten abgesehen? Ernsthaft.

    > Ein Grund warum es solange dauert, bis HTC, Samsung, etc. Android Updates
    > für ihre Geräte veröffentlichen, wenn sie es überhaupt machen, ist laut
    > dieser Hersteller
    der enorme Aufwand ihre Treiber an das neue System (das
    > auch einen neuen Kernel hat) anzupassen.

    Hervorhebung von mir. Hey, klar, ist ja auch ein Riesenaufriss, z.B. für das Defy Android 2.3 zu bauen - ääääh, das Defy+ ist zwar fast baugleich und hat das auch, aber hey, das ist was vöööööllig anderes. Nein, ist klar. Verkäufer sagen immer die Wahrheit!! ;-)

    > Gäbe es feste Schnittstellen, dann wäre da nichts anzupassen.

    Und natürlich bekäme man dann Updates für ältere Smartphones, damit weniger Leute die neuen Modelle kaufen. Glaub' ich nicht.

  8. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: /mecki78 05.09.12 - 11:55

    PyCoder schrieb:
    --------------------------------------------------------------------------------
    > 2) Ach was, die bauen sich ein eigenes Kernel-Interface? Quark, die bauen
    > einen Layer!

    Eine Layer, die auf der einen Seite mit dem dynamischen Interface arbeitet und auf der anderen Seite ein festes Interface besitzt, damit der gleiche BLOB (wie du so schön meintest... bei dem es sich eigentlich einfach nur um ein Binary handelt, so wie es ein Linker ausspuckt) problemlos funktioniert, dann ist diese Layer praktisch nichts weiter als ein festes Kernelinterface. Würden die Kernelentwickler selber so eine Layer als Teil des Kernels anbieten, dann hätte Linux das, was man unter Windows und OS X das Kernelinterface für Treiber nennt (denn auch bei diesen Systemen sind Kernelinterfaces nicht fest, lediglich die Layer über die man Treiber anbindet ist fest; zumindest über einen gewissen Zeitraum).

    > Was du compilierst ist nur, ein Layer"-Modul", das an dem Kernel-Interface
    > andockt und wiederum als Zwischenschritt/schicht dient um die BLOB zu
    > nutzen.

    Richtig und so eine Zwischenschicht nennt man in anderen Systemen Kernelinterface. Und hätte der Linuxkernel so etwas, dann könnten alle anderen Firmen auch dieses Interface nutzen, statt sich jeweils ein eigenes basteln zu müssen und wo diese Interfaces untereinander inkompatibel sind. Dann könnten alle Firmen Treiber als BLOB veröffentlichen (so wie unter Windows und MacOS X auch) und dieser BLOB würde dann so lange funktionieren, so lange sich dieses Interface (aka die Layer) nicht ändert (was bei Windows und MacOS X nur alle paar Jahre mal der Fall ist; interne Änderungen am Kernel werden einfach nach außen hin abstrahiert oder gekapselt, d.h. davon kriegen Treiberentwickler gar nichts mit).

    > Nein, der Hauptgrund ist das diese Firmen ein Smartphone nach dem anderen
    > rauswerfen und gar nicht gewillt sind diese mit Updates/Upgrades zu
    > versorgen!

    Die Firmen wären gewillt Updates zu liefern, wenn sie dafür nur auf einen "Bau mal" Button drücken müssten und der dann automatisch nach einigen Stunden ein fertiges Image rauswirft; was auf einem System mit festen Interfaces kein Problem ist, solange sich keines davon geändert hat. So aber müssen die Firmen anpassen, patchen, umbauen, etc. Viel Arbeit für Null Gewinn... "dann eben nicht" denken sich dabei die meisten. Denn Android Geräte haben massig viele solche BLOBS, da sie in der Regel Chips einsetzen, für die keine OpenSource Treiber existieren.

    /Mecki

  9. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: /mecki78 05.09.12 - 12:21

    Flying Circus schrieb:
    --------------------------------------------------------------------------------
    > Wieviel Hardware läuft denn nicht, mal von Grafikkarten abgesehen?
    > Ernsthaft.

    Du musst schon zwischen "laufen" und "voll funktionstüchtig" unterscheiden. Um mal ein paar "massentaugliche" Beispiele zu bringen (wir lassen mal sehr spezielle Hardware außen vor): Was nicht läuft sind diverse WLAN Karten (und auch USB Sticks), vor allem die ganz neuen (zeig mir mal ein 802.11n Dual Band Gerät mit 3x3 MIMO 450 MBit/s das unter Linux läuft; und das man auch in Deutschland kaufen kann; für Windows kann ich dir hier mehr als Dutzend aufzählen), diverse DVB-T/S/C Karten und Sticks (es laufen viele, aber es gibt eine ganze Menge die nicht läuft) und so ziemlich alle Noname Hardware, die man z.B. bei Pearl bestellen kann (denn selbst wenn diese Dinger einen Chip verwenden, den der Linux Kernel beherrscht, kennt er die Geräte nicht und weiß deswegen auch nicht, welcher Chip das ist).

    Zum Thema "voll funktionstüchtig", klar laufen die meisten (nicht alle!) PCIe Soundkarten unter Linux.... als einfache Stereosoundkarten. Soundkarten die definitiv mehr können, die sogar komplexe 3D Effekte in Hardware berechnen können, können nichts dergleichen (d.h. du zahlst 200 Euro für die Karte, sie kann aber so viel wie dein On-Board Chip, der kostenlos war; ganz tolle Wurst!). Oder nimm eine Gamer Maus von Logitech. Ja, sie läuft als einfache 3 Tasten Maus - man kann aber die Modi nicht umschalten, die Knöpfe nicht (um)programmieren, die "Hardware DPI" ändern (die Empfindlichkeit in den Nutzereinstellungen ändert nur die Interpretation der DPI in Software), usw. Du kaufst also eine Maus für 80+ Euro und sie kann so viel wie eine Maus für unter 10 Euro; Wahnsinn. Oder du kaufst dir eine Tastatur von SmartFish, spezielle Ergonomic Tastatur ($149 + Porto + Zoll), die sich per Motor selber verstellt und das ganze macht der Treiber; klar läuft die als normale Tastatur, so wie die aus dem Supermarkt für unter 10 Euro, mehr aber auch nicht.

    Die meisten Hersteller hätten kein Problem damit auch einen Linuxtreiber für ihre Geräte zu schreiben, der dann zusammen mit Userspace Tools es ermöglicht den VOLLEN FUNKTIONSUMFANG ihrer Geräte zu nutzen, wenn sie

    1) den Quelltext nicht offen legen müssen für ihre Software; sie wollen nur in binärer Form ausliefern.

    2) es garantiert ist, dass ihre Software über einen längeren Zeitraum funktioniert, ohne neu gebaut zu werden; was nur dann möglich ist, wenn die Schnittstellen zwischen ihrer Software und dem restlichen System über einen längeren Zeitraum (relativ) fest sind.

    Zu (1) habe ich noch eine Anmerkung: Bei vieler Hardware steckt die wahre Magie im Treiber. Die Hardware verbaut oft einfache Chips, die offen Dokumentiert sind und die jeder Idiot in eigener Hardware verbauen kann. Der Grund warum ihr Gerät etwas kann und die Konkurrenz nicht (obwohl sie exakt den gleichen Chip benutzt!) liegt oft einzig am Treiber. So und jetzt rate mal warum solche Firmen kein Interesse haben, den Quelltext ihrer Treiber offen zu legen; du hast 3 Versuche.

    > Verkäufer sagen immer die Wahrheit!! ;-)

    Es geht hier nicht darum was Verkäufer sagen, sondern darum was die Firmen sagen, die diese Images bauen müssen. Sie sind nicht gewillt Zeit und Geld dafür zu investieren, da es ihnen Null Mehrwert bringt. D.h. der Prozess so ein Update zu erzeugen, muss automatisiert und völlig ohne manuelles Eingreifen geschehen... und davon ist Android weit entfernt. Wobei das nicht die Schuld von Android ist, denn Linux an sich ist von so etwas weit entfernt.

    Werde doch mal Maintainer eines Kernelmoduls... hui ist das ein Spaß. Obwohl ich nur Co-Maintainer war (einer von mehreren Leuten, wohlgemerkt) hat mich das nach nur 6 Monaten so angekotzt, dass ich da nur noch wieder weg wollte. Ständig irgendwas patchen, ständig irgendwas anpassen und umbauen, ständig versuchen aus dem Mio Code Updates im Monat die für das Modul relevanten herauszufiltern. Nein Danke.

    Ich war auch schon Maintainer (nicht Co, sondern Haupt) von Windows und MacOS X Treibern (bzw. bin es teilweise immer noch). Piece of Cake! 99% der Zeit muss man gar nichts macht, läuft der Treiber einmal, dann läuft er auch in Zukunft. Und nur mit jedem neuen Major Release muss man einmal schauen ob der Treiber immer noch funktioniert, wenn nicht ihm im einfachsten Fall nur neu bauen (da das Interface an sich gleich geblieben ist) und nur wenn das fehlschlägt, dann muss man vielleicht mal schauen, was sich so am Interface geändert hat und ein paar minimale Änderungen durchführen. Die Zeit, die ich in die Wartung aller Windows+OS X Treiber über Jahre(!) hin investieren musste, damit diese Treiber brav weiter funktionieren mit jeder neuen Version liegt unter der Zeit, die als Co-Maintainer in dieses Dreckskernel Modul in einem halben Jahr stecken musste.

    /Mecki



    1 mal bearbeitet, zuletzt am 05.09.12 12:21 durch /mecki78.

  10. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 12:41

    Dem Beitrag kann man nur zustimmen.

    Bin dieses Gefummel mit lsusb und /proc/usb, lspci usw. auch manchmal so leid. Hab auch noch ein paar Beispiele:

    Da steckt man ne SunFire mit 4 Ethernet-Ports ins Rack und auf jeder zu installierenden Maschine belegt der Kernel/Treiber einen anderen Port - und kein Schwein weiss erstmal, warum.

    Da kauft man ne Markenwebcam, hat vorher geschaut ob sie mit Linux läuft und dann schliesst man die an und hat nur Bildrauschen. Okay, das versteht man also unter "geht", denn Bildrauschen ist ja auch ein Bild.

  11. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 05.09.12 - 14:06

    d-tail schrieb:
    --------------------------------------------------------------------------------
    > Da kauft man ne Markenwebcam, hat vorher geschaut ob sie mit Linux läuft
    > und dann schliesst man die an und hat nur Bildrauschen. Okay, das versteht
    > man also unter "geht", denn Bildrauschen ist ja auch ein Bild.
    Das ist aber wohl dem schlechten Linux-Support anzulasten, also dem anbietenden Unternehmen, und nicht Linux?

  12. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 05.09.12 - 14:23

    /mecki78 schrieb:
    --------------------------------------------------------------------------------
    > 1) den Quelltext nicht offen legen müssen für ihre Software; sie wollen nur
    > in binärer Form ausliefern.
    Und das können Sie nicht? (ja, theoretisch)

    > 2) es garantiert ist, dass ihre Software über einen längeren Zeitraum
    > funktioniert, ohne neu gebaut zu werden; was nur dann möglich ist, wenn die
    > Schnittstellen zwischen ihrer Software und dem restlichen System über einen
    > längeren Zeitraum (relativ) fest sind.
    Und könnte das Linux auch wirklich bewerkstelligen und wenn ja, warum machen sie es nicht? Reiner Idealismus? Nach Linus' Statement ist das für mich jetzt eher unwahrscheinlich.

    > Werde doch mal Maintainer eines Kernelmoduls... hui ist das ein Spaß.
    > Obwohl ich nur Co-Maintainer war (einer von mehreren Leuten, wohlgemerkt)
    > hat mich das nach nur 6 Monaten so angekotzt, dass ich da nur noch wieder
    > weg wollte. Ständig irgendwas patchen, ständig irgendwas anpassen und
    > umbauen, ständig versuchen aus dem Mio Code Updates im Monat die für das
    > Modul relevanten herauszufiltern. Nein Danke.
    >
    > Ich war auch schon Maintainer (nicht Co, sondern Haupt) von Windows und
    > MacOS X Treibern (bzw. bin es teilweise immer noch). Piece of Cake! 99% der
    > Zeit muss man gar nichts macht, läuft der Treiber einmal, dann läuft er
    > auch in Zukunft. Und nur mit jedem neuen Major Release muss man einmal
    > schauen ob der Treiber immer noch funktioniert, wenn nicht ihm im
    > einfachsten Fall nur neu bauen (da das Interface an sich gleich geblieben
    > ist) und nur wenn das fehlschlägt, dann muss man vielleicht mal schauen,
    > was sich so am Interface geändert hat und ein paar minimale Änderungen
    > durchführen. Die Zeit, die ich in die Wartung aller Windows+OS X Treiber
    > über Jahre(!) hin investieren musste, damit diese Treiber brav weiter
    > funktionieren mit jeder neuen Version liegt unter der Zeit, die als
    > Co-Maintainer in dieses Dreckskernel Modul in einem halben Jahr stecken
    > musste.
    OK, ich nehme einmal an, dass deine Arbeit bei Linux und Windows ziemlich ähnlich gewesen ist (Änderungen an den Treiber-Schnittstellen ausfindig machen und Patches schreiben) und dass du bei Microsoft auch ausreichend beschäftigt gewesen bist.
    Also musst du uns doch irgendetwas verschweigen, wenn du bei beiden Tätigkeiten das Gleiche gemacht hast und doch bei Microsoft zufriedener warst, oder hattest du da einfach mehr Abwechslung?

  13. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 14:31

    SSD schrieb:
    --------------------------------------------------------------------------------
    > d-tail schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Da kauft man ne Markenwebcam, hat vorher geschaut ob sie mit Linux läuft
    > > und dann schliesst man die an und hat nur Bildrauschen. Okay, das
    > versteht
    > > man also unter "geht", denn Bildrauschen ist ja auch ein Bild.
    > Das ist aber wohl dem schlechten Linux-Support anzulasten, also dem
    > anbietenden Unternehmen, und nicht Linux?

    Bitte meinen zitierten Absatz noch mal lesen und (hoffentlich) verstehen. Danke!

  14. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 05.09.12 - 14:44

    d-tail schrieb:
    --------------------------------------------------------------------------------
    > SSD schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > d-tail schrieb:
    > >
    > ---------------------------------------------------------------------------
    >
    > > -----
    > > > Da kauft man ne Markenwebcam, hat vorher geschaut ob sie mit Linux
    > läuft
    > > > und dann schliesst man die an und hat nur Bildrauschen. Okay, das
    > > versteht
    > > > man also unter "geht", denn Bildrauschen ist ja auch ein Bild.
    > > Das ist aber wohl dem schlechten Linux-Support anzulasten, also dem
    > > anbietenden Unternehmen, und nicht Linux?
    >
    > Bitte meinen zitierten Absatz noch mal lesen und (hoffentlich) verstehen.
    > Danke!
    Was verstehst du denn unter 'schauen, ob's geht'? Nicht, dass es Support gibt?
    Oder sprichst du von Kernel-Treibern?

  15. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 15:23

    SSD schrieb:
    --------------------------------------------------------------------------------
    > Was verstehst du denn unter 'schauen, ob's geht'? Nicht, dass es Support
    > gibt?

    Na, halt schauen ob es geht, kurze Internetrecherche nach der Modellnummer, der Kernelversion usw.
    Support (vom Hersteller) ist mir egal, ich arbeite seit Jahren privat und beruflich mit verschiedensten Linuxen, wenn ich das da nicht selber (bzw. nach Anleitung) hinkriegen täte, könnte ich mich ja im Spiegel nimmer anschauen. ;-)

    > Oder sprichst du von Kernel-Treibern?

    Ja, von was denn sonst? Wenn es ein Kernel-Modul für eine Hardware gibt, erwarte ich, dass sie funktioniert. Tut sie es nicht, wohingegen unter Windows schon, dann ist doch klar, wo die Baustelle sitzt. Is mir schon vorgekommen, dass ein Kernel-Modul nur mit einer bestimmten Kernelversion läuft. Und allein der manchmal hardkodierte Mist in Makefiles... ach...

  16. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 15:37

    SSD schrieb:
    --------------------------------------------------------------------------------
    > > Schnittstellen zwischen ihrer Software und dem restlichen System über
    > einen
    > > längeren Zeitraum (relativ) fest sind.
    > Und könnte das Linux auch wirklich bewerkstelligen und wenn ja, warum
    > machen sie es nicht? Reiner Idealismus? Nach Linus' Statement ist das für
    > mich jetzt eher unwahrscheinlich.

    Das haben wir auch weniger Linus zu verdanken (er sagt immerhin, dass er die Verantwortung für Binärtreiber ablehnt) sondern den Querköpfen Richard M. Stallmann und Greg Kroah Hartmann, die keine (propietären) Binärtreiber an "ihren" heiligen Kernel ranlassen wollen und berufen sich dabei immer wieder auf ihre "heilige" GPL.

    Siehe dazu:
    http://en.wikipedia.org/wiki/Graphics_hardware_and_FOSS

    Abschnitt "Problems with binary drivers"

    Erstaunlich, dass es solche Befürchtungen bei Windows und MacOS eben nicht gibt.

  17. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 05.09.12 - 15:55

    d-tail schrieb:
    --------------------------------------------------------------------------------
    > SSD schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Was verstehst du denn unter 'schauen, ob's geht'? Nicht, dass es Support
    > > gibt?
    >
    > Na, halt schauen ob es geht, kurze Internetrecherche nach der Modellnummer,
    > der Kernelversion usw.
    > Support (vom Hersteller) ist mir egal, ich arbeite seit Jahren privat und
    > beruflich mit verschiedensten Linuxen, wenn ich das da nicht selber (bzw.
    > nach Anleitung) hinkriegen täte, könnte ich mich ja im Spiegel nimmer
    > anschauen. ;-)
    Das war dann also ein kleines Missverständnis.
    Ich würde erst von einer Hardware erwarten, dass sie vollständig funktioniert, wenn sie Hersteller-Support hat, nicht unbedingt auch bei Kernel-Only-Support, so wie du das gemeint hast.
    Es sind diese 'kleinen' Unterschiede in der Erwartungshaltung, die den User verunsichern, mach das doch bitte nicht mehr, auch wenn ich da vll. etwas empfindlich bin.

  18. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 16:26

    SSD schrieb:
    --------------------------------------------------------------------------------
    > Das war dann also ein kleines Missverständnis.
    > Ich würde erst von einer Hardware erwarten, dass sie vollständig
    > funktioniert, wenn sie Hersteller-Support hat, nicht unbedingt auch bei
    > Kernel-Only-Support, so wie du das gemeint hast.

    Privat ist mir das ehrlich gesagt völligst egal woher ein Modul kommt. Beruflich kompiliere ich es notfalls auch. Aber privat will einen Computer einfach nur benutzen.

    > Es sind diese 'kleinen' Unterschiede in der Erwartungshaltung, die den User
    > verunsichern, mach das doch bitte nicht mehr, auch wenn ich da vll. etwas
    > empfindlich bin.

    Hä? Wieso verunsichern? Wenn unter Linux was nicht funktioniert oder erst nach Bastelei, dann werden die User schon ihre Entscheidung treffen. Und siehe da, Erfahrungswerte gibt es ja schliesslich und auch noch genug.

  19. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: SSD 05.09.12 - 17:27

    d-tail schrieb:
    --------------------------------------------------------------------------------
    > > Es sind diese 'kleinen' Unterschiede in der Erwartungshaltung, die den
    > User
    > > verunsichern, mach das doch bitte nicht mehr, auch wenn ich da vll.
    > etwas
    > > empfindlich bin.
    >
    > Hä? Wieso verunsichern? Wenn unter Linux was nicht funktioniert oder erst
    > nach Bastelei, dann werden die User schon ihre Entscheidung treffen. Und
    > siehe da, Erfahrungswerte gibt es ja schliesslich und auch noch genug.
    Ich meine, dass du dich etwas unmissverständlicher ausdrücken solltest (also hier erwähnen, dass du dich auf den Kernel- und User-Support beziehst, stimmt doch, oder?).
    Und lenk nicht vom Thema ab.

  20. Re: Aber schon 6 Wochen alte Kerneltreiber...

    Autor: d-tail 05.09.12 - 21:44

    SSD schrieb:
    --------------------------------------------------------------------------------
    > d-tail schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > Es sind diese 'kleinen' Unterschiede in der Erwartungshaltung, die den
    > > User
    > > > verunsichern, mach das doch bitte nicht mehr, auch wenn ich da vll.
    > > etwas
    > > > empfindlich bin.
    > >
    > > Hä? Wieso verunsichern? Wenn unter Linux was nicht funktioniert oder
    > erst
    > > nach Bastelei, dann werden die User schon ihre Entscheidung treffen. Und
    > > siehe da, Erfahrungswerte gibt es ja schliesslich und auch noch genug.
    > Ich meine, dass du dich etwas unmissverständlicher ausdrücken solltest
    > (also hier erwähnen, dass du dich auf den Kernel- und User-Support
    > beziehst, stimmt doch, oder?).

    Dass ich den Usersupport kaum benötige, hatte ich ja schon geschrieben. Im Übrigen muss ein Treiber letztendlich IMMER mit dem Kernel kommunizieren. Insofern ist das ohnehin völlig Peng woher ein Treiber kommt, ob vom Hersteller oder von den Kernel-Entwicklern. Wenn was nicht funktioniert, was woanders funktioniert, dann ... aber das schrieb ich ja bereits.

    > Und lenk nicht vom Thema ab.

    Ach? Wo tue ich das denn?

  1. Thema
  1. 1
  2. 2

Neues Thema


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. Software Engineer Quality Assurance (m/w/d)
    Trox GmbH, Neukirchen-Vluyn
  2. DevOps - Engineer BMC Helix ITSM - Remedy (m/w/div)
    Deutsche Rentenversicherung Bund, Berlin
  3. Application Manager:in (m/w/d)
    STRABAG BRVZ GMBH & CO.KG, Köln
  4. Scrum Master (m/w/d)
    Trox GmbH, Neukirchen-Vluyn

Detailsuche


Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Spiele-Angebote
  1. basierend auf Verkaufszahlen
  2. 219,99€ (mit Vorbesteller-Preisgarantie)


Haben wir etwas übersehen?

E-Mail an news@golem.de