Der Bericht ist *sehr* subjektiv und einseitig geschrieben. Formulierungen wie "... nahm nach eigenem Gutdünken zahlreiche Modifikationen vor" verurteilen ganz klar Google, ohne dass das Problem genauer erklärt wird.
Bitte Leute, schreibt einfache News-Meldungen wie diese etwas objektiver. Ich würde auch einen sachlichen Artikel begrüßen, der das Problem beschreibt, aber dann bitte auch mit Quellen und unterschiedlichen Meinungen.
Die in der Vergangenheit manchmal angewandte Strategie, "eigenen" Code im Kernel unterzubringen, um ihn dann nachher von den Kernelmaintainern pflegen zu lassen, funktioniert halt nicht mehr. Nicht gepflegter Code fliegt raus, gewissermaßen auf den virtuellen Müllplatz. Dass Google erst in ein paar Jahren seine Nicht-Linux-Kernel-Android-Fork mit dem offiziellen Kernel zusammenführen möchte, ist eine gute Nachricht. Von mit aus können sie damit auch bis zum 22. Jahrhundert warten. :-) Zeitdruck scheint Google auch selbst wohl eher nicht zu verspüren, das "Google-Gequake" ist IMHO reine PR, man möchte für ein angenehmes Diskussionsklima mit der Linux-Community sorgen, schließlich braucht man sie ganz bestimmt noch.
Die in der Vergangenheit manchmal angewandte Strategie, "eigenen" Code im Kernel unterzubringen, um ihn dann nachher von den Kernelmaintainern pflegen zu lassen, funktioniert halt nicht mehr.
Es geht um den staging-Kernel.
Korrigiert mich, aber bei Code, der in den Kernel gelangt ist, übernehmen die Kernel-Entwickler doch die weitere Pflege? Aber dafür muß der Code erstmal so weit kommen. Und das ist dann doch eher die Aufgabe derjeniger, die ihn unsprünglich "verbrochen" haben.
Ja, das beschränkt sich aber in der Regel darauf, ihn am kompilieren zu halten, wen er dabei irgendwann kaputt geht und sich lange genug keiner mehr darum kümmert, kann er auch wieder rausfliegen.
> Von mit aus können sie damit auch bis zum 22. > Jahrhundert warten. Irgendwie verstehe ich Dein Problem nicht. Wenn Google schlechten Code schreibt, dann bleibt er eben draußen. Offenbar scheint der Kernel ja bislang zumindest prima ohne Googles Patches auszukommen - gerade darum dreht sich doch der Artikel.
> schließlich braucht man sie ganz bestimmt noch Wozu? Die relevanten freien Lizenzen haben keine Diskriminierungsklausel. Wenn Google diesen Code verwenden will, kann sie niemand auf der Welt daran hindern. Es kann ja auch niemand Nordkorea hindern, eine eigene Linux-Distribution zu erstellen.
Ich finde es hoch anständig von Google, dass sie ihre Änderungen (wenn auch langfristig) integrieren wollen. Niemand zwingt sie zu diesem Schritt, bereits der Pragmatismus unter Entwicklern gebietet diesen Schritt, wenn man auf der einen Seite Arbeit sparen und andererseits Vielfalt auf der eigenen Plattform (und damit hohe Verbreitung der Plattform selbst) sicherstellen will.
Ich denke nicht, dass schlechter Code - falls es sich überhaupt um solchen Code gehandelt hat - ein grundlegendes Problem wäre. Dir ist bestimmt klar, warum der betreffende Google-Android-Code aus dem Kernel geflogen ist.
Wörter wie "hochanständig" haben hier im übrigen keine Berechtigung, Google ist schließlich eine kapitalistische US-Firma wie jede andere, kein menschliches Wesen. Das siehst Du alleine schon an Googles globaler Vorratsdatenspeicherung und dem hocheffektiven Einsatz der so gewonnenen Nutzerdaten zum Lancieren und Vermarkten von gut bezahlter Werbung.
Effektiver wäre es IMHO gewesen, die betreffenden Treiber im Kernel gleich von Anfang an zu pflegen.
Manche Leute werden in drei Jahren vielleicht in einem Segelschiff um die Welt fahren, andere werden vielleicht versuchen, Code zum Kernel beizusteuern. Und? Das sind erst einmal lediglich nette Absichtserklärungen, nichts weiter.
Google ist in seinem Elan dabei, so ziemlich jedes Stück freie Software im Rahmen seiner Softwareentwicklungen zu forken. Das ist o.k., solange sie das resultierende Codezeug auch selber warten. Siehe Kernelrausschmiss.
Ich glaube das ist das grundsätzliche Vorgehen bei Google und generell in der Softwareentwicklung.
Wenn man Änderungen macht, die den derzeitigen Stand im Trunk betreffen und andere Entwickler behindern können, mancht man einen Branch und arbeitet da weiter. Am Ende gibt es dann nen Merge, der alle Sachen wieder im Trunk zusammenführt.
Das macht Google halt im großen Stil, aber es gibt genug Projekte, wo auch wirklich wieder was zurückgeflossen ist. Und es hält ja auch niemanden davon ab, Googles eigene OS-Projekte zu nutzen und Änderungen rückzuportieren, wenn es nicht schnell genug geht.
> Dir ist bestimmt klar, warum der betreffende Google-Android-Code aus > dem Kernel geflogen ist. Logisch. Deshalb habe ich es ja auch als Grund angeführt, warum man vor dem Merge von Android-Code keine Bedenken haben muss, weil die Qualitätskontrolle funktioniert.
> Wörter wie "hochanständig" haben hier im übrigen keine Berechtigung Linux steht unter der GPL. Die GPL erlaubt die freie Weitergabe und Modifikation von Code und regelt keinerlei Rückfluss. Wer das trotzdem macht, übererfüllt also die GPL. Das verdient meine Anerkennung.
> Effektiver wäre es IMHO gewesen, die betreffenden Treiber im Kernel > gleich von Anfang an zu pflegen. Und drei Jahre länger zu brauchen, weil man eigentlich überall schrauben muss und im Anschluss eine gefühlte Ewigkeit auf die Aufnahme von Code wartet. Androids Kernel-Fork war gewissermaßen die "Quick and Dirty"-Sandbox, zurück fließen dann nur noch abgeklopfte Dinge. Das ist doch in Ordnung.
> Das sind erst einmal lediglich nette Absichtserklärungen, nichts weiter. Und? Wenn sie ihren Worten Taten folgen lassen, finde ich das (wie gesagt) hoch anständig. Wo ist da für Dich der Widerspruch?
> Google ist in seinem Elan dabei, so ziemlich jedes Stück freie Software > im Rahmen seiner Softwareentwicklungen zu forken. Lass sie doch, jede der relevanten Lizenzen erlaubt dies explizit.
Die Fork-Problematik, die ich oben angerissen habe, hätte durchaus eine ernsthaftere Diskussion verdient. Siehe u.a.: http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html Der folgende Text mit starkem Bezug zu Chromium ist in dieser Hinsicht auch sehr interessant: http://spot.livejournal.com/312320.html
> http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html Ich greife mal die Kernbotschaft des Bloggers auf: Google ist groß genug, um Forks für immer zu maintainen.
Das ist richtig. Sie sind aber trotz ihrer Größe dem ökonomischen Umgang mit ihren Ressourcen verpflichtet, so wie jedes andere Unternehmen. Insofern liegt es gar nicht in ihrem Interesse, einen Fork jahrelang nachzuziehen. Vor allem dann nicht, wenn sie einmal die Manpower investieren könnten, um ihren Code in den Upstream zu bekommen.
Daraus, dass sie aktuell einen Fork haben, würde ich jedenfalls nicht schließen, dass sie das für immer so machen werden. Die Begründung, dass man am Anfang viel zu viel auf einmal über den Haufen werfen muss, um es "richtig zu machen", ist eben durchaus plausibel. Das Linux-Kernelprojekt hat auf der einen Seite strenge Richtlinien und Qualitätsprüfungen, auf der anderen Seite hatte man bei Google nur begrenzt Zeit, wenn man das Produkt als Konkurrenten zu aktuellen Systemen platzieren wollte. Diese beiden Dinge widersprechen sich auf bestimmte Zeit, aber mit Sicherheit nicht für ewig.
> http://spot.livejournal.com/312320.html Es ist nicht immer so einfach, wie dieser Blogger sich die Welt ausmalt. Ich hatte selbst schon einmal das Problem, ein freies Softwareprojekt für meine proprietäre Software forken zu müssen.
Glücklicherweise war es ein relativ überschaubares Projekt. Das Problem war, dass ihr Code auf UNIX-Systemen funktionierte, auf Windows jedoch nicht, was bei mir eine Voraussetzung war. Meine Anpassungen nahmen sie nicht an, weil ihre Zielplattform UNIX war und sie sich ein paar #ifdefs sparen wollten.
Das und die Tatsache, dass der Upstream manchmal Deine Codequalität nicht akzeptiert, nicht schnell genug Änderungen von Dir übernimmt o.ä. sind Gründe, die Dich (auf gewisse Zeit) zum Fork zwingen.
>Dass Google erst in ein paar Jahren seine Nicht-Linux-Kernel-Android-Fork mit dem offiziellen Kernel zusammenführen möchte, ist eine gute Nachricht. Von mit aus können sie damit auch bis zum 22. Jahrhundert warten.
Ich nehme auch gerne guten Code von Microsoft (sofern die keine Falle bauen). Mir ist das doch erstmal egal, wo der Code herkommt, solange der gut ist. Linux ist nun mal auch nicht perfekt, weshalb daran gearbeitet wird. Jedes System hat seine Vor- und Nachteile. Wenn ich Treiber im privaten Bereich nur mal anführen darf, dann ist man doch weit von Plug and Play entfernt. Da Google auch noch Chrome macht, erhoffe ich mir da ein bisschen was. Deshalb muss ich noch lange kein Googlefan werden. Aber die haben nun mal gute Leute deren Arbeit nicht die schlechteste ist.
"Google such nun offenbar doch wieder" es heisst doch sicherlich "sucht", typo in der ersten zeile
Der Bericht ist *sehr* subjektiv und einseitig geschrieben. Formulierungen wie "... nahm nach eigenem Gutdünken zahlreiche Modifikationen vor" verurteilen ganz klar Google, ohne dass das Problem genauer erklärt wird.
Bitte Leute, schreibt einfache News-Meldungen wie diese etwas objektiver. Ich würde auch einen sachlichen Artikel begrüßen, der das Problem beschreibt, aber dann bitte auch mit Quellen und unterschiedlichen Meinungen.
Die Probleme wurde bereits in vorherigen Newmeldungen erwähnt:
http://www.pro-linux.de/NB3/news/1/15118/1,linux-2633-ohne-android-treiber.html
Die in der Vergangenheit manchmal angewandte Strategie, "eigenen" Code im Kernel unterzubringen, um ihn dann nachher von den Kernelmaintainern pflegen zu lassen, funktioniert halt nicht mehr. Nicht gepflegter Code fliegt raus, gewissermaßen auf den virtuellen Müllplatz.
Dass Google erst in ein paar Jahren seine Nicht-Linux-Kernel-Android-Fork mit dem offiziellen Kernel zusammenführen möchte, ist eine gute Nachricht. Von mit aus können sie damit auch bis zum 22. Jahrhundert warten. :-)
Zeitdruck scheint Google auch selbst wohl eher nicht zu verspüren, das "Google-Gequake" ist IMHO reine PR, man möchte für ein angenehmes Diskussionsklima mit der Linux-Community sorgen, schließlich braucht man sie ganz bestimmt noch.
Die in der Vergangenheit manchmal angewandte Strategie, "eigenen" Code im Kernel unterzubringen, um ihn dann nachher von den Kernelmaintainern pflegen zu lassen, funktioniert halt nicht mehr.
Es geht um den staging-Kernel.
Korrigiert mich, aber bei Code, der in den Kernel gelangt ist, übernehmen die Kernel-Entwickler doch die weitere Pflege? Aber dafür muß der Code erstmal so weit kommen. Und das ist dann doch eher die Aufgabe derjeniger, die ihn unsprünglich "verbrochen" haben.
Ja, das beschränkt sich aber in der Regel darauf, ihn am kompilieren zu halten, wen er dabei irgendwann kaputt geht und sich lange genug keiner mehr darum kümmert, kann er auch wieder rausfliegen.
> Von mit aus können sie damit auch bis zum 22.
> Jahrhundert warten.
Irgendwie verstehe ich Dein Problem nicht. Wenn Google schlechten Code schreibt, dann bleibt er eben draußen. Offenbar scheint der Kernel ja bislang zumindest prima ohne Googles Patches auszukommen - gerade darum dreht sich doch der Artikel.
> schließlich braucht man sie ganz bestimmt noch
Wozu? Die relevanten freien Lizenzen haben keine Diskriminierungsklausel. Wenn Google diesen Code verwenden will, kann sie niemand auf der Welt daran hindern. Es kann ja auch niemand Nordkorea hindern, eine eigene Linux-Distribution zu erstellen.
Ich finde es hoch anständig von Google, dass sie ihre Änderungen (wenn auch langfristig) integrieren wollen. Niemand zwingt sie zu diesem Schritt, bereits der Pragmatismus unter Entwicklern gebietet diesen Schritt, wenn man auf der einen Seite Arbeit sparen und andererseits Vielfalt auf der eigenen Plattform (und damit hohe Verbreitung der Plattform selbst) sicherstellen will.
lg
Erik
Ich denke nicht, dass schlechter Code - falls es sich überhaupt um solchen Code gehandelt hat - ein grundlegendes Problem wäre.
Dir ist bestimmt klar, warum der betreffende Google-Android-Code aus dem Kernel geflogen ist.
Wörter wie "hochanständig" haben hier im übrigen keine Berechtigung, Google ist schließlich eine kapitalistische US-Firma wie jede andere, kein menschliches Wesen. Das siehst Du alleine schon an Googles globaler Vorratsdatenspeicherung und dem hocheffektiven Einsatz der so gewonnenen Nutzerdaten zum Lancieren und Vermarkten von gut bezahlter Werbung.
Effektiver wäre es IMHO gewesen, die betreffenden Treiber im Kernel gleich von Anfang an zu pflegen.
Manche Leute werden in drei Jahren vielleicht in einem Segelschiff um die Welt fahren, andere werden vielleicht versuchen, Code zum Kernel beizusteuern.
Und?
Das sind erst einmal lediglich nette Absichtserklärungen, nichts weiter.
Google ist in seinem Elan dabei, so ziemlich jedes Stück freie Software im Rahmen seiner Softwareentwicklungen zu forken. Das ist o.k., solange sie das resultierende Codezeug auch selber warten. Siehe Kernelrausschmiss.
Ich glaube das ist das grundsätzliche Vorgehen bei Google und generell in der Softwareentwicklung.
Wenn man Änderungen macht, die den derzeitigen Stand im Trunk betreffen und andere Entwickler behindern können, mancht man einen Branch und arbeitet da weiter. Am Ende gibt es dann nen Merge, der alle Sachen wieder im Trunk zusammenführt.
Das macht Google halt im großen Stil, aber es gibt genug Projekte, wo auch wirklich wieder was zurückgeflossen ist. Und es hält ja auch niemanden davon ab, Googles eigene OS-Projekte zu nutzen und Änderungen rückzuportieren, wenn es nicht schnell genug geht.
> Dir ist bestimmt klar, warum der betreffende Google-Android-Code aus
> dem Kernel geflogen ist.
Logisch. Deshalb habe ich es ja auch als Grund angeführt, warum man vor dem Merge von Android-Code keine Bedenken haben muss, weil die Qualitätskontrolle funktioniert.
> Wörter wie "hochanständig" haben hier im übrigen keine Berechtigung
Linux steht unter der GPL. Die GPL erlaubt die freie Weitergabe und Modifikation von Code und regelt keinerlei Rückfluss. Wer das trotzdem macht, übererfüllt also die GPL. Das verdient meine Anerkennung.
> Effektiver wäre es IMHO gewesen, die betreffenden Treiber im Kernel
> gleich von Anfang an zu pflegen.
Und drei Jahre länger zu brauchen, weil man eigentlich überall schrauben muss und im Anschluss eine gefühlte Ewigkeit auf die Aufnahme von Code wartet. Androids Kernel-Fork war gewissermaßen die "Quick and Dirty"-Sandbox, zurück fließen dann nur noch abgeklopfte Dinge. Das ist doch in Ordnung.
> Das sind erst einmal lediglich nette Absichtserklärungen, nichts weiter.
Und? Wenn sie ihren Worten Taten folgen lassen, finde ich das (wie gesagt) hoch anständig. Wo ist da für Dich der Widerspruch?
> Google ist in seinem Elan dabei, so ziemlich jedes Stück freie Software
> im Rahmen seiner Softwareentwicklungen zu forken.
Lass sie doch, jede der relevanten Lizenzen erlaubt dies explizit.
lg
Erik
Die Fork-Problematik, die ich oben angerissen habe, hätte durchaus eine ernsthaftere Diskussion verdient.
Siehe u.a.:
http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html
Der folgende Text mit starkem Bezug zu Chromium ist in dieser Hinsicht auch sehr interessant:
http://spot.livejournal.com/312320.html
> http://ebb.org/bkuhn/blog/2010/02/08/android-linux-google.html
Ich greife mal die Kernbotschaft des Bloggers auf: Google ist groß genug, um Forks für immer zu maintainen.
Das ist richtig. Sie sind aber trotz ihrer Größe dem ökonomischen Umgang mit ihren Ressourcen verpflichtet, so wie jedes andere Unternehmen. Insofern liegt es gar nicht in ihrem Interesse, einen Fork jahrelang nachzuziehen. Vor allem dann nicht, wenn sie einmal die Manpower investieren könnten, um ihren Code in den Upstream zu bekommen.
Daraus, dass sie aktuell einen Fork haben, würde ich jedenfalls nicht schließen, dass sie das für immer so machen werden. Die Begründung, dass man am Anfang viel zu viel auf einmal über den Haufen werfen muss, um es "richtig zu machen", ist eben durchaus plausibel. Das Linux-Kernelprojekt hat auf der einen Seite strenge Richtlinien und Qualitätsprüfungen, auf der anderen Seite hatte man bei Google nur begrenzt Zeit, wenn man das Produkt als Konkurrenten zu aktuellen Systemen platzieren wollte. Diese beiden Dinge widersprechen sich auf bestimmte Zeit, aber mit Sicherheit nicht für ewig.
> http://spot.livejournal.com/312320.html
Es ist nicht immer so einfach, wie dieser Blogger sich die Welt ausmalt. Ich hatte selbst schon einmal das Problem, ein freies Softwareprojekt für meine proprietäre Software forken zu müssen.
Glücklicherweise war es ein relativ überschaubares Projekt. Das Problem war, dass ihr Code auf UNIX-Systemen funktionierte, auf Windows jedoch nicht, was bei mir eine Voraussetzung war. Meine Anpassungen nahmen sie nicht an, weil ihre Zielplattform UNIX war und sie sich ein paar #ifdefs sparen wollten.
Das und die Tatsache, dass der Upstream manchmal Deine Codequalität nicht akzeptiert, nicht schnell genug Änderungen von Dir übernimmt o.ä. sind Gründe, die Dich (auf gewisse Zeit) zum Fork zwingen.
lg
Erik
>Dass Google erst in ein paar Jahren seine Nicht-Linux-Kernel-Android-Fork mit dem offiziellen Kernel zusammenführen möchte, ist eine gute Nachricht. Von mit aus können sie damit auch bis zum 22. Jahrhundert warten.
Ich nehme auch gerne guten Code von Microsoft (sofern die keine Falle bauen). Mir ist das doch erstmal egal, wo der Code herkommt, solange der gut ist. Linux ist nun mal auch nicht perfekt, weshalb daran gearbeitet wird. Jedes System hat seine Vor- und Nachteile. Wenn ich Treiber im privaten Bereich nur mal anführen darf, dann ist man doch weit von Plug and Play entfernt. Da Google auch noch Chrome macht, erhoffe ich mir da ein bisschen was. Deshalb muss ich noch lange kein Googlefan werden. Aber die haben nun mal gute Leute deren Arbeit nicht die schlechteste ist.