Von schmidicom am Di, 13. September 2016 um 12:40 #
Das "zu Groß?" kommt daher das mir (ich benutze Gentoo und konfiguriere/baue meinen Kernel daher selbst) schon oft aufgefallen ist das viele Bereiche im Kernel (hauptsächlich Geräte-Treiber welche für den bootvorgang eher unwichtig sind und/oder auch selten zum Einsatz kommen) nur deshalb angefasst wurden weil sich eine Abhängigkeit von ihnen leicht verändert hat. Und gerade solche Sachen finde ich sollte man auslagern und über eine API, welche über mehrere Versionen hinweg kompatibel bleibt, mit dem Kernel verbinden.
EDIT: So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
EDIT2: Auch so ein Beispiel wäre der WLAN-Treiber (broadcom-sta), jene die auf diesen Treiber angewiesen sind müssen bei fast jedem Kernel-Update befürchten das er sich plötzlich nicht mehr bauen lässt. Natürlich wäre es viel besser wenn solche Geschichten als OpenSource vorliegen würden aber wie sich zeigt ist das kaum zu erzwingen und ein Kampf den man nicht auf dem Rücken der User austragen sollte.
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 13. Sep 2016 um 12:52.
Von Sie haben vergessen, Ihren Nam am Di, 13. September 2016 um 13:42 #
> EDIT: > So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
Nein.
> EDIT2: [...]
Selbst wenn die ganze Lizenz- und Sicherheitsthematik nicht wäre, möchte ich keine kommerziell entwickelten Treiber. Heutzutage ist selbst die Qualität der Treiber unter Windows z. T. miserabel. Wenn solche Hersteller dann noch Alibi-Treiber für Linux schreiben...
Schau dir mal die kommerziell entwickelte Linux-Firmware von z.B. NAS oder Routern an. Da bekommt man das kalte Grauen. FHS? Fehlanzeige. Ein Skriptverhau den keine mehr durchblickt, mit z. T. seitenweise auskommentiertem Code. In der Firmware meines alten Dlink-NAS wurde der Zugriff auf die GPIOs der Prozessors in den Ethernet-Treiber hineingebastelt. Kein Scherz.
Das "zu Groß?" kommt daher das mir (ich benutze Gentoo und konfiguriere/baue meinen Kernel daher selbst) schon oft aufgefallen ist das viele Bereiche im Kernel (hauptsächlich Geräte-Treiber welche für den bootvorgang eher unwichtig sind und/oder auch selten zum Einsatz kommen) nur deshalb angefasst wurden weil sich eine Abhängigkeit von ihnen leicht verändert hat. Und gerade solche Sachen finde ich sollte man auslagern und über eine API, welche über mehrere Versionen hinweg kompatibel bleibt, mit dem Kernel verbinden.
EDIT:
So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
EDIT2:
Dieser Beitrag wurde 3 mal editiert. Zuletzt am 13. Sep 2016 um 12:52.Auch so ein Beispiel wäre der WLAN-Treiber (broadcom-sta), jene die auf diesen Treiber angewiesen sind müssen bei fast jedem Kernel-Update befürchten das er sich plötzlich nicht mehr bauen lässt. Natürlich wäre es viel besser wenn solche Geschichten als OpenSource vorliegen würden aber wie sich zeigt ist das kaum zu erzwingen und ein Kampf den man nicht auf dem Rücken der User austragen sollte.
> EDIT:
> So etwas hätte, z.B. bei den Smartphones, vielleicht auch geholfen Kernel-Updates zügiger auszuliefern.
Nein.
> EDIT2: [...]
Selbst wenn die ganze Lizenz- und Sicherheitsthematik nicht wäre, möchte ich keine kommerziell entwickelten Treiber. Heutzutage ist selbst die Qualität der Treiber unter Windows z. T. miserabel. Wenn solche Hersteller dann noch Alibi-Treiber für Linux schreiben...
Schau dir mal die kommerziell entwickelte Linux-Firmware von z.B. NAS oder Routern an. Da bekommt man das kalte Grauen. FHS? Fehlanzeige. Ein Skriptverhau den keine mehr durchblickt, mit z. T. seitenweise auskommentiertem Code. In der Firmware meines alten Dlink-NAS wurde der Zugriff auf die GPIOs der Prozessors in den Ethernet-Treiber hineingebastelt. Kein Scherz.