Wenn jetzt noch die DEB- und RPM-Welt aufspringt dann sind wir der Shuttleworthschen Vereinheitlichung der Basis ein grosses Stück näher.
Ich nehme mal an daß Standard-Libs auch unter die Standardisierung fallen werden.
Ich fänds toll wenn ich mal ohne Sorgen, Bauchweh und Dornen ein SuSE-RPM unter Ubuntu zum Laufen bekäme und es einen einheitlichen NVidia-Treiber von NVidia gäbe der überall läuft.
...und was bringt das? Der Hauptgrund, warum die Hersteller Ihren Kernel nicht wechseln, ist doch nicht, dass sie zu dumm sind, einen neuen zu bauen. Vielmehr stecken da doch meistens spezielle Patches und Anpassungen für die eigene Hardware drin. Und DAS Problem kann so ein Standardkernel auch nicht lösen. Auch wenn Sony jetzt einen Kernel als Standard vorschreibt, hat der diese Patches deswegen dann noch lange nicht.
Der Hersteller macht sich allerdings strafbar, wenn er seine Änderungen am Kernel nicht öffentlich zugänglich macht (GPL). Da das publizieren dieser Patches (imho) für viele Hersteller ein sehr großes Problem darstellt, schient es mit einfacher die Patches, zu rZufriedenheit der Kernelentwickler, in den Standartkernel einzupflegen.
Natürlich mit etwas mehr Begeisterung als Googles Android-Treiber.
> Der Hersteller macht sich allerdings strafbar, wenn er seine Änderungen am Kernel nicht öffentlich zugänglich > macht (GPL).
Was ist denn das für ein Quark? Wenn jemand einen frei verfügbaren Kernel mit ebenso frei verfügbaren Patches verändert und auf seine Bedürfnisse anpasst, dann muss er da gar nix veröffentlichen. Arbeit und Aufwand steckt deswegen dann aber trotzdem drin.
Doch das muss er. Es ist dabei unerheblich ob lediglich Patches von anderen integriert wurden oder nicht. Das Ergebnis muss zugänglich gemacht werden. Wie das geschieht, z.B. durch Verlinkung auf kernel.org und die angewendeten Patches, ist eine andere Sache.
Ich dachte immer, der Quellcode muss nur an diejenigen gegeben werden, denen man das entsprechende Prog./Kernel zur Verfügung stellt - ob das die Öffentlichkeit oder ein einzelner Kunde ist. Ist es nur für den "Eigenbedarf", muss auch nichts veröffentlicht werden.
Wenn man das Gerät, wo dieser Kernel eingebettet ist, zum Verkauf anbietet, dann veröffentlicht man damit auch den Kernel. Genau darum geht es auch bei fast allen GPL-Durchsetzungen.
Eigenbedarf ist es nur, wenn man das Gerät nur für sich selber macht, was wohl eher selten vorkommt.
Von theBohemian am Di, 16. November 2010 um 11:48 #
> Der Hauptgrund, warum die Hersteller Ihren Kernel nicht wechseln, ist doch nicht, dass sie zu dumm sind, einen neuen zu bauen. Der Hauptgrund ist, dass es teuer (Zeit + Geld) ist einen Entwickler für 1-2 Wochen abzustellen um das Gesamtprodukt mit Linux als Kern auf eine neue Kernelversion zu aktualisieren. Außerdem stellt sich die Frage der Rechtfertigung der Kosten? Wenn das Produkt mit Kernel X funktioniert, warum soll auf Version X+1 aktualisiert werden? Ein Kernelupgrade allein gibt noch keine neuen Features. Man muss auch die Userland-Software erweitern bzw. anpassen.
Btw: Auch Projekte wie OpenWRT sind dem offiziellen Kernel etwas hinterher, weil das einfach aufwändig ist.
Und natürlich wissen wir alle, dass ein neuerer Kernel machmal Dinge mitbringt, die jenen Benutzer, die ihre (embedded) Systeme selber warten gerne hätten. Und genau jenen wird mit der jetzt eingeschlagenen Strategie besser in die Hände gespielt, weil die Kosten zum Aktualisieren des Kernels für jeden einzelnen Hersteller sinken.
> Und natürlich wissen wir alle, dass ein neuerer Kernel machmal Dinge mitbringt, die jenen Benutzer, die ihre (embedded) > Systeme selber warten gerne hätten. Und genau jenen wird mit der jetzt eingeschlagenen Strategie besser in die Hände > gespielt, weil die Kosten zum Aktualisieren des Kernels für jeden einzelnen Hersteller sinken.
Und wo ist der Unterschied zur jetzigen Situation? Wenn ich einen Spezialkernel habe (was bei >80% der Embedded-Systeme der Fall sein dürfte), der Anpassungen enthält, welche mir weder kernel.org noch Sony von Haus aus liefern, dann ist es vollkommen egal, ob ich ein Kernelupdate mit den Sourcen von kernel.org oder denen von Sony mache - der Updateaufwand bleibt bestehen.
Wenn du die Hersteller-Version als stabile LTS-Bais siehst, so besteht durchaus ein Unterschied gerade wenn du etwas weiter als ein paar Monate bis zum nächsten Kernel-release denkst.
Von DriverDevel am Di, 16. November 2010 um 10:05 #
Ich frag mich auch ein bisschen, warum man ausgerechnet 2.6.35 nehmen will, wenn das kein -stable long-term kernel ist. Zumal 2.6.35 IIRC Probleme mit exzessiv hohen Wakeup-Raten hat, was besonders im Embedded-Bereich Gift ist. OK, dieses eine Problem ist durch einen mehr oder weniger aufwendigen Backport sicher leicht gelöst, aber Fragen bleiben dennoch.
Das beste wäre dann wohl, nachträglich 2.6.35 ganz offiziell doch noch als long-term-Version auszuerwählen, aber das dürften manche Distributionen, die sich an den bisherigen Versionen orientiert haben, nicht so toll finden.
Von theBohemian am Di, 16. November 2010 um 11:39 #
Im englischen Artikeln ist von einer Flag-Version die Rede. Das bezieht sich darauf, dass der gewünschte Effekt jener ist, dass sich alle Hersteller verstärkt um diese Kernelversion scharen (vom englischen Sprichwort: 'rally around the flag'). Es geht nicht um Bibliotheken oder Paketierungsformate und auch nicht um Distributionen.
Wenn jetzt noch die DEB- und RPM-Welt aufspringt dann sind wir der Shuttleworthschen Vereinheitlichung der Basis ein grosses Stück näher.
Ich nehme mal an daß Standard-Libs auch unter die Standardisierung fallen werden.
Ich fänds toll wenn ich mal ohne Sorgen, Bauchweh und Dornen ein SuSE-RPM unter Ubuntu zum Laufen bekäme und es einen einheitlichen NVidia-Treiber von NVidia gäbe der überall läuft.
Wenn du wegen der Qualität SuSE-RPM Pakete verwenden willst, könntest du auch einfach auf SuSE umsteigen
"und es einen einheitlichen NVidia-Treiber von NVidia gäbe der überall läuft"
Den gibt es doch schon, NVidia bietet ihn immer zum Download an. NVidia hat diesen proprietären Treiber vor Jahren selbst vereinheitlicht.
...und was bringt das? Der Hauptgrund, warum die Hersteller Ihren Kernel nicht wechseln, ist doch nicht, dass sie zu dumm sind, einen neuen zu bauen. Vielmehr stecken da doch meistens spezielle Patches und Anpassungen für die eigene Hardware drin. Und DAS Problem kann so ein Standardkernel auch nicht lösen. Auch wenn Sony jetzt einen Kernel als Standard vorschreibt, hat der diese Patches deswegen dann noch lange nicht.
Der Hersteller macht sich allerdings strafbar, wenn er seine Änderungen am Kernel nicht öffentlich zugänglich macht (GPL).
Da das publizieren dieser Patches (imho) für viele Hersteller ein sehr großes Problem darstellt, schient es mit einfacher die Patches, zu rZufriedenheit der Kernelentwickler, in den Standartkernel einzupflegen.
Natürlich mit etwas mehr Begeisterung als Googles Android-Treiber.
http://www.pro-linux.de/news/1/15393/android-code-soll-in-den-linux-kernel-zurueck.html
> Der Hersteller macht sich allerdings strafbar, wenn er seine Änderungen am Kernel nicht öffentlich zugänglich
> macht (GPL).
Was ist denn das für ein Quark? Wenn jemand einen frei verfügbaren Kernel mit ebenso frei verfügbaren Patches verändert und auf seine Bedürfnisse anpasst, dann muss er da gar nix veröffentlichen. Arbeit und Aufwand steckt deswegen dann aber trotzdem drin.
Doch das muss er. Es ist dabei unerheblich ob lediglich Patches von anderen integriert wurden oder nicht. Das Ergebnis muss zugänglich gemacht werden. Wie das geschieht, z.B. durch Verlinkung auf kernel.org und die angewendeten Patches, ist eine andere Sache.
Ich dachte immer, der Quellcode muss nur an diejenigen gegeben werden, denen man das entsprechende Prog./Kernel zur Verfügung stellt - ob das die Öffentlichkeit oder ein einzelner Kunde ist. Ist es nur für den "Eigenbedarf", muss auch nichts veröffentlicht werden.
Wenn man das Gerät, wo dieser Kernel eingebettet ist, zum Verkauf anbietet, dann veröffentlicht man damit auch den Kernel.
Genau darum geht es auch bei fast allen GPL-Durchsetzungen.
Eigenbedarf ist es nur, wenn man das Gerät nur für sich selber macht, was wohl eher selten vorkommt.
Die GPL hat mit dem Strafrecht wenig am Peter Huth.
> Der Hauptgrund, warum die Hersteller Ihren Kernel nicht wechseln, ist doch nicht, dass sie zu dumm sind, einen neuen zu bauen.
Der Hauptgrund ist, dass es teuer (Zeit + Geld) ist einen Entwickler für 1-2 Wochen abzustellen um das Gesamtprodukt mit Linux als Kern auf eine neue Kernelversion zu aktualisieren. Außerdem stellt sich die Frage der Rechtfertigung der Kosten? Wenn das Produkt mit Kernel X funktioniert, warum soll auf Version X+1 aktualisiert werden? Ein Kernelupgrade allein gibt noch keine neuen Features. Man muss auch die Userland-Software erweitern bzw. anpassen.
Btw: Auch Projekte wie OpenWRT sind dem offiziellen Kernel etwas hinterher, weil das einfach aufwändig ist.
Und natürlich wissen wir alle, dass ein neuerer Kernel machmal Dinge mitbringt, die jenen Benutzer, die ihre (embedded) Systeme selber warten gerne hätten. Und genau jenen wird mit der jetzt eingeschlagenen Strategie besser in die Hände gespielt, weil die Kosten zum Aktualisieren des Kernels für jeden einzelnen Hersteller sinken.
> Und natürlich wissen wir alle, dass ein neuerer Kernel machmal Dinge mitbringt, die jenen Benutzer, die ihre (embedded)
> Systeme selber warten gerne hätten. Und genau jenen wird mit der jetzt eingeschlagenen Strategie besser in die Hände
> gespielt, weil die Kosten zum Aktualisieren des Kernels für jeden einzelnen Hersteller sinken.
Und wo ist der Unterschied zur jetzigen Situation? Wenn ich einen Spezialkernel habe (was bei >80% der Embedded-Systeme der Fall sein dürfte), der Anpassungen enthält, welche mir weder kernel.org noch Sony von Haus aus liefern, dann ist es vollkommen egal, ob ich ein Kernelupdate mit den Sourcen von kernel.org oder denen von Sony mache - der Updateaufwand bleibt bestehen.
Wenn du die Hersteller-Version als stabile LTS-Bais siehst, so besteht durchaus ein Unterschied gerade wenn du etwas weiter als ein paar Monate bis zum nächsten Kernel-release denkst.
Hm, hätte man da nicht besser den Kernel nehmen sollen, der auch von den Kernelentwicklern offiziell länger gepflegt wird, also aktuell 2.6.32?
Ich frag mich auch ein bisschen, warum man ausgerechnet 2.6.35 nehmen will, wenn das kein -stable long-term kernel ist.
Zumal 2.6.35 IIRC Probleme mit exzessiv hohen Wakeup-Raten hat, was besonders im Embedded-Bereich Gift ist. OK, dieses eine Problem ist durch einen mehr oder weniger aufwendigen Backport sicher leicht gelöst, aber Fragen bleiben dennoch.
Das beste wäre dann wohl, nachträglich 2.6.35 ganz offiziell doch noch als long-term-Version auszuerwählen, aber das dürften manche Distributionen, die sich an den bisherigen Versionen orientiert haben, nicht so toll finden.
Im englischen Artikeln ist von einer Flag-Version die Rede. Das bezieht sich darauf, dass der gewünschte Effekt jener ist, dass sich alle Hersteller verstärkt um diese Kernelversion scharen (vom englischen Sprichwort: 'rally around the flag'). Es geht nicht um Bibliotheken oder Paketierungsformate und auch nicht um Distributionen.