Seit einigen Woche gibt es unter Wheezy für Chromium keine Sicherheitsupdates mehr und unter Jessie wird es, wie es aussieht, massive Probleme geben.
Möglicherweise wäre es das beste, wenn Debian Chromium ganz entfernt. Auch Fedora bietet keine offiziellen Chromium-Pakete, weil die Software ein einziger Maintainer-Albtraum ist. Das hätte natürlich Auswirkungen für auf Debian basierende Distros.
Google Chrome ist allerdings für Leute, die Wert auf freie Software legen keine Alternative. Man muss kein GPL-Hardliner sein, um Chrome aus Datenschutzgründen abzulehnen.
Die Frage ist dann nur, welche gute, freie Alternative es gibt, wenn man Mozilla basierte Browser nicht nutzen kann oder will.
Halte Dich nicht zurück, erkläre gerne - auf der Website bezeichnen die Iron als "Free and Open Source" und bieten Quellen an (die auf denen von Chromium aufbauen, bzw. diese säubern). Wo wird das jetzt unfrei?
Wie schön, dass sie das behaupten. Ich finde keine Quellen, aus denen man Iron kompilieren kann. Die Links unter "Download Sourcecode (for Coder)" bringen für mich nur "Fehler - Daten nicht gefunden" hervor.
Sowohl die deutsch- und englischsprachige Wikipediaseite beinhalten zudem den Hinweis, dass es unfreie Software sei.
Von kamome umidori am Do, 12. März 2015 um 22:30 #
Das Fehlen der Quellen auf der Website ist natürlich wirklich arm, man findet zwar Quellen auf SourceForge (ganz unten), allerdings sind die Dateien von 2011: http://sourceforge.net/projects/srwareiron.mirror/files/
Auch das hier klingt etwas ernüchternd: http://neugierig.org/software/chromium/notes/2009/12/iron.html
Vielleicht wird ja aus epic 'was - wenn die mal die Quellen veröffentlichen: https://www.epicbrowser.com/
Wer ein Chrome in Debian stable installieren will - was selten genug vorkommen wird - der kann sich doch einen aktuellen Kernel aus den Quellen backen oder einen von Debian testing/unstable installieren. So what?
dass es nicht nur um Debian Stale geht (momentan bei mir 3.2) sondern damit mal so ziemlich alle aktuellen nicht-beta Distributionen rausfallen. Fedora hat glaube 3.18, dafür aber Ubuntu 3.14, OpenSuSE 3.16, Slackware 3.10, Mint 3.13, CentOS 3.10, ... selbst Googles eigenes Android L (bis jetzt gerade mal 5% Verteilung) kommt nur mit 3.14
Das wäre ca. so als würde man für Windows-Software nur noch die aktuelle Win10-Entwicklerversion unterstützen
Die Kernel-Version ist nicht als einziges relevant, wichtiger ist, ob es Backports dafür gibt/gegeben hat. Canonical hat sich in der Vergangenheit mehrfach bereit gezeigt, Forderungen von Google (und anderen, wie Netflix) zu erfüllen, um damit die Nutzererfahrung zu verbessern. Dies wird sicher auch hier der Fall sein.
Bei Debian wird es wohl nicht kommen.
Allerdings halte ich den Ansatz von Google für nicht sooo falsch. Ginge es nach den "LTS" Distries, würden wir noch leicht 3 Jahre auf diese Funktion warten. Das lehnt Google zurecht ab.
Man sollte sich bei den LTS-Distributionen vielleicht auch mal Gedanken um das eigene Modell machen. Warum darf da nie ein Kernel aktualisiert werden? In irgendeinem Uraltkernel rumzupatschen, um da Änderungen aus aktuellen Kerneln unterzubringen halte ich für gefährlicher, als gleich einen aktuellen zu nehmen.
Bei Arch, Fedora und Gentoo wird doch regelmäßig der Kernel aktualisiert, ohne dass es da zu nennenswerten Problemen kommt.
Warum sollte Anwendungen warten, die Vorzüge aktueller Kernel zu nutzen, bis auch die letzte Distribution endlich mal einen etwas neueren Kernel verwendet? Sollten solche Neuerungen erst nach 5 Jahren verwendet werden dürfen?
Und es handelt sich hier um Desktopsysteme. Bei einem Server braucht man nicht unbedingt Chrome.
Ich würde mal annehmen der Hauptgrund warum manche Distributionen bei ihren Server-Ausgaben kein Kernel-Upgrade machen wollen ist der Support von spezieller Hardware.
Es gibt ja im Serverbereich ziemlich spezielle Hardware (z.B. Telefon- und Steuerungsanlagen) wo es dann meist nur für eine handvoll Distributionen einen passenden proprietären Treiber gibt. Und würde auf einer solchen Distribution einfach so ein neuer Kernel hereinschneien, auf dem die bisherigen Treiber dann womöglich nicht mehr laufen, wären sicher einige nicht sonderlich begeistert.
Eine Treiber-API (oder wie auch immer man das nennen will) die sich über mehrere Kernel-Versionen hinweg nicht verändert, könnte das Problem möglicherweise entschärfen. Aber darüber könnte man auch ewig diskutieren wenn es nicht schon gemacht wird...
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 09. Mär 2015 um 10:31.
Man muss das Kernelupdate ja nicht zur Pflicht machen. Man kann doch mehrere Kernel anbieten. Wer beim alten bleiben will, der bleibt beim alten und wer aktualisieren will, der aktualisiert.
Bei Gentoo habe ich von den gentoo-sources 18 Stück zur Auswahl. Die ich beliebig nutzen kann.
Sorry, aber genau das ist doch der Vorteil von LTS-Distributionen: Es wird überhaupt nichts geändert, was funktioniert. Deshalb ist Debian Stable der Inbegriff von "rock solid".
Bei Arch, Fedora und Gentoo wird doch regelmäßig der Kernel aktualisiert, ohne dass es da zu nennenswerten Problemen kommt.
Arch und Debian Stable sind zwei verschiedene Welten. "Keine nennenswerte Probleme" ist Definitionssache. Wer ein stabiles, fehlerarmes, gut getestetes System will, der muss zu Debian Stable, CentOS oder zu einer LTS-Version von Ubuntu, etc. greifen. Ich würde bspw. schon Fedora nicht einem Anfänger empfehlen, Arch und Gentoo sind für unbedarfte User vollkommen abwegig.
Warum sollte Anwendungen warten, die Vorzüge aktueller Kernel zu nutzen, bis auch die letzte Distribution endlich mal einen etwas neueren Kernel verwendet?
Bei LTS-Distros werden oft auch die Anwendungen nicht aktualisiert, weshalb ein alter Kernel seinen Zweck erfüllt. Die Anwendungen müssen ja auch nicht warten, sie können die Vorzüge neuer Kernel nutzen, sollten IMO aber auch alte Kernel unterstützen. Das kann man machen, wenn man denn nur will: "Bei Chromium könnte theoretisch der Patch zu Seccomp entfernt werden". Der Fall "Chrome" ist also eine absolute Ausnahme.
Und es handelt sich hier um Desktopsysteme.
Desktopnutzer müssen ja auch nicht LTS-Versionen verwenden.
Deshalb ist Debian Stable der Inbegriff von "rock solid".
Das mit dem "rock-solide" haben die Debianfans in die Welt gesetzt um eine Erklärung dafür zu haben, daß Debian beim Erscheinen längst veraltet ist. - Tatsächlich war Debian nie stabiler als etwa eine SuSE!
Tatsächlich war Debian nie stabiler als etwa eine SuSE!
Die Pakete von Suse Linux Enterprise sind ebenfalls sehr gut abgehangen, wie auch bei RHEL - das haben alle "rock solid"-Distros gemein. Falls du von OpenSuse spichst: Die Nutzungsszenarien von Debian Stable und OpenSuse sprechen für sich, da muss man nichts weiter dazu sagen... Ich würde OpenSuse eher mit Debian Testing vergleichen.
Diese News finde ich echt nicht gut. Ich habe auf meinen Linux-Systemen immer Google Chrome verwendet, da ich den Browser gut leiden kann und er für mich der bevorzugte Browser ist. Wenn ich mich nun damit beschäftigen muss den Kernel selber zu kompilieren und zu updaten oder auf einen Backport zu warten (das unter Umständen auch länger dauern kann) ist das wirklich nervig.
Vielleicht wird es dann mal wieder Zeit sich Firefox anzusehen, denn Chromium scheint ja auch die neue Kernelversion zu benötigen.
Die Information, dass nur in Chrome das aktuelle Flash-Plugin funktioniere, ist falsch.
Debian enthält ein Paket pepperflashplugin-nonfree. Damit wird das Flash-Plugin aus Chrome extrahiert und steht fortan allen Browsern zur Verfügung, auch Chromium und Iceweasel.
Die Google-Spyware muss also nicht eingesetzt werden, nur weil man vermessenerweise Flash benutzen möchte.
Die Information, dass nur in Chrome das aktuelle Flash-Plugin funktioniere, ist falsch.
Debian enthält ein Paket pepperflashplugin-nonfree. Damit wird das Flash-Plugin aus Chrome extrahiert und steht fortan allen Browsern zur Verfügung, auch Chromium und Iceweasel.
Die Google-Spyware muss also nicht eingesetzt werden, nur weil man vermessenerweise Flash benutzen möchte.
Nicht gänzlich falsch, aber so nicht haltbar. Schaut man sich den Bugreport unter https://code.google.com/p/chromium/issues/detail?id=401655#c70 an, so waren ja die Chrome-Entwickler selbst der Meinung, es sei Kernel 3.17 erforderlich.
Diese Aussage ist doch "gänzlich falsch", oder nicht? Im Bugreport ist nirgendwo die Rede davon, dass man alte Kernel nicht mehr unterstützen wird. Im Gegenteil: alle reden von einem "Bug" der gefixt werden muss, auch Julien Tinnes. Es geht hier um einen Bug und nicht um das Einstellen der Unterstützung älterer kernel. Ich nehme mal an, dass dieser Kommentar bei Debian die Falschmeldung auslöste: https://lists.debian.org/debian-kernel/2015/03/msg00133.html
Moment! Ganz vergessen zu erwähnen, dass dies keine Kritik an dir/euch sein soll. Ich finde es gut, dass Pro-Linux ganz nah am Geschehen ist und Diskussionen unter Entwicklern beobachtet und darüber berichtet.
Seit einigen Woche gibt es unter Wheezy für Chromium keine Sicherheitsupdates mehr und unter Jessie wird es, wie es aussieht, massive Probleme geben.
Möglicherweise wäre es das beste, wenn Debian Chromium ganz entfernt. Auch Fedora bietet keine offiziellen Chromium-Pakete, weil die Software ein einziger Maintainer-Albtraum ist. Das hätte natürlich Auswirkungen für auf Debian basierende Distros.
Google Chrome ist allerdings für Leute, die Wert auf freie Software legen keine Alternative. Man muss kein GPL-Hardliner sein, um Chrome aus Datenschutzgründen abzulehnen.
Die Frage ist dann nur, welche gute, freie Alternative es gibt, wenn man Mozilla basierte Browser nicht nutzen kann oder will.
"Seit einigen Woche gibt es unter Wheezy für Chromium keine Sicherheitsupdates mehr ... ": sind denn welche nötig?
Ja, siehe Debian Changelog in Testing
Netsurf.
Ohne Javascript und HTML5 lassen sich gefühlt 2/3 des Webs nicht richtig nutzen, daher ist Netsurf nicht wirklich geeignet.
Otter-Browser klingt vielversprechend. Mal abwarten.
http://www.srware.net/en/software_srware_iron.php
Klingt gut (habe ich aber noch nicht getestet).
Das ist jedenfalls keine freie Alternative.
Halte Dich nicht zurück, erkläre gerne - auf der Website bezeichnen die Iron als "Free and Open Source" und bieten Quellen an (die auf denen von Chromium aufbauen, bzw. diese säubern). Wo wird das jetzt unfrei?
Wie schön, dass sie das behaupten.
Ich finde keine Quellen, aus denen man Iron kompilieren kann.
Die Links unter "Download Sourcecode (for Coder)" bringen für mich nur "Fehler - Daten nicht gefunden" hervor.
Sowohl die deutsch- und englischsprachige Wikipediaseite beinhalten zudem den Hinweis, dass es unfreie Software sei.
Das Fehlen der Quellen auf der Website ist natürlich wirklich arm, man findet zwar Quellen auf SourceForge (ganz unten), allerdings sind die Dateien von 2011:
http://sourceforge.net/projects/srwareiron.mirror/files/
Auch das hier klingt etwas ernüchternd:
http://neugierig.org/software/chromium/notes/2009/12/iron.html
Vielleicht wird ja aus epic 'was - wenn die mal die Quellen veröffentlichen:
https://www.epicbrowser.com/
... oder bleibt Chromium in Debian, mit Patch ...
Qupzilla, Epiphany ?
Mit Gentoo wäre das nicht passiert!
Wer ein Chrome in Debian stable installieren will - was selten genug vorkommen wird - der kann sich doch einen aktuellen Kernel aus den Quellen backen oder einen von Debian testing/unstable installieren. So what?
dass es nicht nur um Debian Stale geht (momentan bei mir 3.2) sondern damit mal so ziemlich alle aktuellen nicht-beta Distributionen rausfallen.
Fedora hat glaube 3.18, dafür aber Ubuntu 3.14, OpenSuSE 3.16, Slackware 3.10, Mint 3.13, CentOS 3.10, ...
selbst Googles eigenes Android L (bis jetzt gerade mal 5% Verteilung) kommt nur mit 3.14
Das wäre ca. so als würde man für Windows-Software nur noch die aktuelle Win10-Entwicklerversion unterstützen
Die Kernel-Version ist nicht als einziges relevant, wichtiger ist, ob es Backports dafür gibt/gegeben hat.
Canonical hat sich in der Vergangenheit mehrfach bereit gezeigt, Forderungen von Google (und anderen, wie Netflix) zu erfüllen, um damit die Nutzererfahrung zu verbessern. Dies wird sicher auch hier der Fall sein.
Bei Debian wird es wohl nicht kommen.
Allerdings halte ich den Ansatz von Google für nicht sooo falsch. Ginge es nach den "LTS" Distries, würden wir noch leicht 3 Jahre auf diese Funktion warten. Das lehnt Google zurecht ab.
s/Nutzererfahrung/Nutzererlebnis/
;)
Man sollte sich bei den LTS-Distributionen vielleicht auch mal Gedanken um das eigene Modell machen. Warum darf da nie ein Kernel aktualisiert werden? In irgendeinem Uraltkernel rumzupatschen, um da Änderungen aus aktuellen Kerneln unterzubringen halte ich für gefährlicher, als gleich einen aktuellen zu nehmen.
Bei Arch, Fedora und Gentoo wird doch regelmäßig der Kernel aktualisiert, ohne dass es da zu nennenswerten Problemen kommt.
Warum sollte Anwendungen warten, die Vorzüge aktueller Kernel zu nutzen, bis auch die letzte Distribution endlich mal einen etwas neueren Kernel verwendet? Sollten solche Neuerungen erst nach 5 Jahren verwendet werden dürfen?
Und es handelt sich hier um Desktopsysteme. Bei einem Server braucht man nicht unbedingt Chrome.
Ich würde mal annehmen der Hauptgrund warum manche Distributionen bei ihren Server-Ausgaben kein Kernel-Upgrade machen wollen ist der Support von spezieller Hardware.
Es gibt ja im Serverbereich ziemlich spezielle Hardware (z.B. Telefon- und Steuerungsanlagen) wo es dann meist nur für eine handvoll Distributionen einen passenden proprietären Treiber gibt. Und würde auf einer solchen Distribution einfach so ein neuer Kernel hereinschneien, auf dem die bisherigen Treiber dann womöglich nicht mehr laufen, wären sicher einige nicht sonderlich begeistert.
Eine Treiber-API (oder wie auch immer man das nennen will) die sich über mehrere Kernel-Versionen hinweg nicht verändert, könnte das Problem möglicherweise entschärfen. Aber darüber könnte man auch ewig diskutieren wenn es nicht schon gemacht wird...
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 09. Mär 2015 um 10:31.Man muss das Kernelupdate ja nicht zur Pflicht machen. Man kann doch mehrere Kernel anbieten. Wer beim alten bleiben will, der bleibt beim alten und wer aktualisieren will, der aktualisiert.
Bei Gentoo habe ich von den gentoo-sources 18 Stück zur Auswahl. Die ich beliebig nutzen kann.
Sorry, aber genau das ist doch der Vorteil von LTS-Distributionen: Es wird überhaupt nichts geändert, was funktioniert. Deshalb ist Debian Stable der Inbegriff von "rock solid".
Arch und Debian Stable sind zwei verschiedene Welten. "Keine nennenswerte Probleme" ist Definitionssache. Wer ein stabiles, fehlerarmes, gut getestetes System will, der muss zu Debian Stable, CentOS oder zu einer LTS-Version von Ubuntu, etc. greifen. Ich würde bspw. schon Fedora nicht einem Anfänger empfehlen, Arch und Gentoo sind für unbedarfte User vollkommen abwegig.Bei LTS-Distros werden oft auch die Anwendungen nicht aktualisiert, weshalb ein alter Kernel seinen Zweck erfüllt. Die Anwendungen müssen ja auch nicht warten, sie können die Vorzüge neuer Kernel nutzen, sollten IMO aber auch alte Kernel unterstützen. Das kann man machen, wenn man denn nur will: "Bei Chromium könnte theoretisch der Patch zu Seccomp entfernt werden". Der Fall "Chrome" ist also eine absolute Ausnahme.Desktopnutzer müssen ja auch nicht LTS-Versionen verwenden.Deshalb ist Debian Stable der Inbegriff von "rock solid".
Das mit dem "rock-solide" haben die Debianfans in die Welt gesetzt um eine Erklärung dafür zu haben, daß Debian beim Erscheinen längst veraltet ist. - Tatsächlich war Debian nie stabiler als etwa eine SuSE!
Ich würde OpenSuse eher mit Debian Testing vergleichen.
Diese News finde ich echt nicht gut. Ich habe auf meinen Linux-Systemen immer Google Chrome verwendet, da ich den Browser gut leiden kann und er für mich der bevorzugte Browser ist. Wenn ich mich nun damit beschäftigen muss den Kernel selber zu kompilieren und zu updaten oder auf einen Backport zu warten (das unter Umständen auch länger dauern kann) ist das wirklich nervig.
Vielleicht wird es dann mal wieder Zeit sich Firefox anzusehen, denn Chromium scheint ja auch die neue Kernelversion zu benötigen.
Die Information, dass nur in Chrome das aktuelle Flash-Plugin funktioniere, ist falsch.
Debian enthält ein Paket pepperflashplugin-nonfree. Damit wird das Flash-Plugin aus Chrome extrahiert und steht fortan allen Browsern zur Verfügung, auch Chromium und Iceweasel.
Die Google-Spyware muss also nicht eingesetzt werden, nur weil man vermessenerweise Flash benutzen möchte.
Die Information, dass nur in Chrome das aktuelle Flash-Plugin funktioniere, ist falsch.
Debian enthält ein Paket pepperflashplugin-nonfree. Damit wird das Flash-Plugin aus Chrome extrahiert und steht fortan allen Browsern zur Verfügung, auch Chromium und Iceweasel.
Die Google-Spyware muss also nicht eingesetzt werden, nur weil man vermessenerweise Flash benutzen möchte.
Ist wohl 'ne Falschmeldung...
Siehe hier...
Nicht gänzlich falsch, aber so nicht haltbar. Schaut man sich den Bugreport unter https://code.google.com/p/chromium/issues/detail?id=401655#c70 an, so waren ja die Chrome-Entwickler selbst der Meinung, es sei Kernel 3.17 erforderlich.
Im Bugreport ist nirgendwo die Rede davon, dass man alte Kernel nicht mehr unterstützen wird. Im Gegenteil: alle reden von einem "Bug" der gefixt werden muss, auch Julien Tinnes. Es geht hier um einen Bug und nicht um das Einstellen der Unterstützung älterer kernel.
Ich nehme mal an, dass dieser Kommentar bei Debian die Falschmeldung auslöste:
https://lists.debian.org/debian-kernel/2015/03/msg00133.html
Moment! Ganz vergessen zu erwähnen, dass dies keine Kritik an dir/euch sein soll. Ich finde es gut, dass Pro-Linux ganz nah am Geschehen ist und Diskussionen unter Entwicklern beobachtet und darüber berichtet.
Ich habs schon richtig verstanden