Die Linuxdistributionen ergreifen ja schon langsam Gegenmaßnahmen und stellen mehr und mehr Anwendungen auf das leichter zu pflegende Webkit um.
Dass in älteren Distros bis zu 200 Pakete von Firefox bzw. Firefoxbestandteilen abhingen, wird bestimmt nicht mehr vorkommen. Es ist besser, wenn z.B. Yelp Webkit benutzt und nicht Xulrunner, dessen Version sich aufgrund des "Updatezwanges" ja zwangslaüfig ändern wird. Nur so lässt sich verhindern, dass Abhängigkeiten von älteren Xulrunnerversionen Anwendungen im Extremfall sogar unbrauchbar machen, wenn ein "Zwangsupdate" erforderlich werden sollte.
Alternativ kann man natürlich das alte System beibehalten und alles selbst fixen.
Damals war den Distro-Machern noch nicht wirklich bewusst, wie kurz der Mozilla-Support für Firefox- bzw. Xulrunnervesionen in Zukunft sein würde.
Wenn man zukünftig Firefox praktisch nur noch als statisches Paket mit eigenem "Firefox-Xulrunner" ausliefern kann, um beim dann notwendigen Updaten auf neuere Versionen andere Anwendungen nicht in Mitleidenschaft zu ziehen, dann ist Firefox/Xulrunner für viele Distros nicht mehr brauchbar. Das Aufbauprinzip von Linuxdistributionen richtet sich nun einmal nicht nach einem einzelnen Hersteller.
Eine Linuxdistribution nimmt eben nicht drei Webbrowser und zwanzig weitere Anwendungen, die alle das gleiche Xulrunner-Paket benötigen, und baut das gleiche Xulrunner-Paket dann dreiundzwanzigmal in dreiundzwanzig verschiedene Programme ein, um im Fehlerfall dann gleich dreiundzwanzigmal statt einmal patchen und gleich dreiundzwanzig Pakete neu bauen zu müssen.
Wichtige Webkitbrowser wie Epiphany-Webkit müssen allerdings vorher noch etwas aufholen. In ein bis zwei Jahren dürfte es aber so weit sein.
Die Auswirkungen solcher Xulrunner-Updates in Linuxdistributionen kann man sehr gut an Ubuntu nachvollziehen: https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list Für die Zukunft hilft da wohl nur Verzicht.
Im Vergleich zu Gecko (das in Xulrunner enthalten ist), ist Webkit klarer dokumentiert, leichter patchbar (die sog. „Hackability“ ist besser) und leichter in andere Anwendungen implementierbar, da es von vornherein auf dieses „Embedded-Dasein“ ausgelegt wurde. Der Gecko/Xulrunner-"Monstercode“ ist in dieser Hinsicht weitaus schwieriger zu handhaben. Das wird selbst im "Kleinen" offenbar: Während Du sofort eine hervorragende Webkitseite für Entwickler findest, ist bei Gecko so gut wie Fehlanzeige.
Gecko war m Gegensatz zu Webkit anscheinend nie als eigenes Projekt gedacht, sondern war und ist für Mozilla immer nur etwas, was u.a. in Firefox und Thunderbird drin ist und fertig. Das macht das Arbeiten damit schwieriger und zeitaufwendiger, vor allem dann, wenn der Support für die verwendete Xulrunner-/Gecko-Version viel zu früh ausläuft und man alles selber patchen muß.
Schau Dir dazu das aktuelle Ubuntu 8.04 an: Normalerweise zerlegt man Programme derart in einzelne Bibliotheken, dass man häufige, von vielen Programmen gemeinsam benutzte Bibliotheken nur einmal im System vorhält. Also sagen wir einmal, 20 Programme hängen von Webkit ab, 20 Programme von Xulrunner, dann ist es ideal, dass alle Programme, die Webkit benötigen, nur von einer Webkit-Lib abhängen, und alle Programme, die Xulrunner/Gecko benötigen, ebenfalls nur von einer Xulrunner-Lib. Im Falle von Sicherheitsupdates muß man so nur eine Bibliothek fixen und alle darauf aufsetzenden 20 Programme sind automatisch mitgefixt. Bei Webkit ist das problemlos möglich (auch wenn Ubuntu hier die gleiche Webkit-Lib in eine GTK- und ein QT4-Webkit-Lib aufteilt, um die Anzahl der nachgezogenen desktopspezifischen Abhängigkeiten kleiner zu halten), bei Xulrunner steht einem die "Natur" der mozillaeigenen Anwendungen im Weg.
Infolge des Updatechaos und der allzu frühen Supporteinstellung u.a. von Firefox- bzw. Xulrunner-Versionen zeigt mir Ubuntus Synaptic folgende Xulrunner-Libs an, die sich alle noch in Ubuntu befinden, damit Anwendungen, die diese Bibliotheken benötigen, weiterhin zuverlässig funktionieren können: 1. Xulrunner-1.8.1.18 (EOL) 2. Xulrunner-1.9.0.19 (EOL) 3. Xulrunner- 1.9.2.6 (mit Upstream-Support)
Hinzu kommen Mozillaanwendungen, die jeweils eine eigene, integrierte Xulrunner-Lib mitbringen, die also die oben erwähnten drei Xulrunner-Libs gar nicht mitbenutzen: 1. Seamonkey-Browser in Version 1.1.17 (EOL) 2. Thunderbird in Version 2.0.0.24 (EOL) 3. Firefox 3.6.6 (mit Upstream-Support) 4. Kompozer 0.7.10 5. Sunbird 0.7
Somit müßte Ubuntu im Falle von Sicherheitsaktualisierungen wenigstens acht Programme aktualisieren und damit Xulrunner-Libs über mindestens drei Generationen hinweg patchen. Von diesen acht xulrunnerabhängigen Programmen erhalten anscheinend nur noch zwei Upstream-Support (Firefox 3.6.x und Xulrunner-1.9.2.x). Die restliche Aktualisierungsarbeit wäre somit alleinige Aufgabe Ubuntus.
Das ist ein absoluter Supportalptraum.
Man sieht auch, dass man das augenscheinlich selbst bei einer Distro mit "nur" dreijährigem Desktopsupport kaum schafft. Somit bleiben alte Xulrunner-Versionen, in einzelner wie "versteckter" Form, mitunter ungepatcht.
Die Ursache liegt hier meiner persönlichen Einschätzung nach letztlich in den recht kurzen Supportzyklen von Seiten Mozillas. Es ist eine Illusion zu glauben, dass die Nicht-Xulrunner-Spezialisten der jeweiligen Distros mehrere Xulrunner-Generationen zugleich supporten könnten.
Die Linuxdistributionen ergreifen ja schon langsam Gegenmaßnahmen und stellen mehr und mehr Anwendungen auf das leichter zu pflegende Webkit um.
Dass in älteren Distros bis zu 200 Pakete von Firefox bzw. Firefoxbestandteilen abhingen, wird bestimmt nicht mehr vorkommen. Es ist besser, wenn z.B. Yelp Webkit benutzt und nicht Xulrunner, dessen Version sich aufgrund des "Updatezwanges" ja zwangslaüfig ändern wird. Nur so lässt sich verhindern, dass Abhängigkeiten von älteren Xulrunnerversionen Anwendungen im Extremfall sogar unbrauchbar machen, wenn ein "Zwangsupdate" erforderlich werden sollte.
Alternativ kann man natürlich das alte System beibehalten und alles selbst fixen.
> Dass in älteren Distros bis zu 200 Pakete von Firefox bzw. Firefoxbestandteilen abhingen
Fragmentierung von Upstream bis zur Unkenntlichkeit hat nix mit Mozilla zu tun.
Das ist auch nicht gemeint.
Damals war den Distro-Machern noch nicht wirklich bewusst, wie kurz der Mozilla-Support für Firefox- bzw. Xulrunnervesionen in Zukunft sein würde.
Wenn man zukünftig Firefox praktisch nur noch als statisches Paket mit eigenem "Firefox-Xulrunner" ausliefern kann, um beim dann notwendigen Updaten auf neuere Versionen andere Anwendungen nicht in Mitleidenschaft zu ziehen, dann ist Firefox/Xulrunner für viele Distros nicht mehr brauchbar. Das Aufbauprinzip von Linuxdistributionen richtet sich nun einmal nicht nach einem einzelnen Hersteller.
Eine Linuxdistribution nimmt eben nicht drei Webbrowser und zwanzig weitere Anwendungen, die alle das gleiche Xulrunner-Paket benötigen, und baut das gleiche Xulrunner-Paket dann dreiundzwanzigmal in dreiundzwanzig verschiedene Programme ein, um im Fehlerfall dann gleich dreiundzwanzigmal statt einmal patchen und gleich dreiundzwanzig Pakete neu bauen zu müssen.
Wichtige Webkitbrowser wie Epiphany-Webkit müssen allerdings vorher noch etwas aufholen. In ein bis zwei Jahren dürfte es aber so weit sein.
Die Auswirkungen solcher Xulrunner-Updates in Linuxdistributionen kann man sehr gut an Ubuntu nachvollziehen:
https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/xulrunner-list
Für die Zukunft hilft da wohl nur Verzicht.
Mal eine einface frage: Warum soll WebKit einfacher zu flegen sein also xulrunner?
Im Vergleich zu Gecko (das in Xulrunner enthalten ist), ist Webkit klarer dokumentiert, leichter patchbar (die sog. „Hackability“ ist besser) und leichter in andere Anwendungen implementierbar, da es von vornherein auf dieses „Embedded-Dasein“ ausgelegt wurde.
Der Gecko/Xulrunner-"Monstercode“ ist in dieser Hinsicht weitaus schwieriger zu handhaben.
Das wird selbst im "Kleinen" offenbar: Während Du sofort eine hervorragende Webkitseite für Entwickler findest, ist bei Gecko so gut wie Fehlanzeige.
Gecko war m Gegensatz zu Webkit anscheinend nie als eigenes Projekt gedacht, sondern war und ist für Mozilla immer nur etwas, was u.a. in Firefox und Thunderbird drin ist und fertig. Das macht das Arbeiten damit schwieriger und zeitaufwendiger, vor allem dann, wenn der Support für die verwendete Xulrunner-/Gecko-Version viel zu früh ausläuft und man alles selber patchen muß.
Schau Dir dazu das aktuelle Ubuntu 8.04 an: Normalerweise zerlegt man Programme derart in einzelne Bibliotheken, dass man häufige, von vielen Programmen gemeinsam benutzte Bibliotheken nur einmal im System vorhält. Also sagen wir einmal, 20 Programme hängen von Webkit ab, 20 Programme von Xulrunner, dann ist es ideal, dass alle Programme, die Webkit benötigen, nur von einer Webkit-Lib abhängen, und alle Programme, die Xulrunner/Gecko benötigen, ebenfalls nur von einer Xulrunner-Lib. Im Falle von Sicherheitsupdates muß man so nur eine Bibliothek fixen und alle darauf aufsetzenden 20 Programme sind automatisch mitgefixt. Bei Webkit ist das problemlos möglich (auch wenn Ubuntu hier die gleiche Webkit-Lib in eine GTK- und ein QT4-Webkit-Lib aufteilt, um die Anzahl der nachgezogenen desktopspezifischen Abhängigkeiten kleiner zu halten), bei Xulrunner steht einem die "Natur" der mozillaeigenen Anwendungen im Weg.
Infolge des Updatechaos und der allzu frühen Supporteinstellung u.a. von Firefox- bzw. Xulrunner-Versionen zeigt mir Ubuntus Synaptic folgende Xulrunner-Libs an, die sich alle noch in Ubuntu befinden, damit Anwendungen, die diese Bibliotheken benötigen, weiterhin zuverlässig funktionieren können:
1. Xulrunner-1.8.1.18 (EOL)
2. Xulrunner-1.9.0.19 (EOL)
3. Xulrunner- 1.9.2.6 (mit Upstream-Support)
Hinzu kommen Mozillaanwendungen, die jeweils eine eigene, integrierte Xulrunner-Lib mitbringen, die also die oben erwähnten drei Xulrunner-Libs gar nicht mitbenutzen:
1. Seamonkey-Browser in Version 1.1.17 (EOL)
2. Thunderbird in Version 2.0.0.24 (EOL)
3. Firefox 3.6.6 (mit Upstream-Support)
4. Kompozer 0.7.10
5. Sunbird 0.7
Somit müßte Ubuntu im Falle von Sicherheitsaktualisierungen wenigstens acht Programme aktualisieren und damit Xulrunner-Libs über mindestens drei Generationen hinweg patchen. Von diesen acht xulrunnerabhängigen Programmen erhalten anscheinend nur noch zwei Upstream-Support (Firefox 3.6.x und Xulrunner-1.9.2.x). Die restliche Aktualisierungsarbeit wäre somit alleinige Aufgabe Ubuntus.
Das ist ein absoluter Supportalptraum.
Man sieht auch, dass man das augenscheinlich selbst bei einer Distro mit "nur" dreijährigem Desktopsupport kaum schafft. Somit bleiben alte Xulrunner-Versionen, in einzelner wie "versteckter" Form, mitunter ungepatcht.
Die Ursache liegt hier meiner persönlichen Einschätzung nach letztlich in den recht kurzen Supportzyklen von Seiten Mozillas. Es ist eine Illusion zu glauben, dass die Nicht-Xulrunner-Spezialisten der jeweiligen Distros mehrere Xulrunner-Generationen zugleich supporten könnten.