Updatefrequenz Suse vs. Ubuntu

[stefan74]

Servus zusammen,

mir ist in den letzten zwei Jahren aufgefallen, dass Suse leider sehr langsam geworden ist mit der Bereitstellung von Updates. Bei Ubuntu bekomme ich innerhalb von Tagen (z.B. aktuell Firefox 3.5.6) den Patch angeboten. Bei suse dauert das immer ein bis zwei Wochen. Auch bekomme ich bei Ubuntu deutlich mehr Updates angeboten?!
Versteht mich nicht falsch! Ich finde es spitzenmäßig dass es Firmen wie Novel, Canonical, ReadHat usw. gibt und bin auch den Entwicklern dankbar für ihren tollen Einsatz. Aber bei Suse ist mir das in letzter Zeit ziemlich ins Auge gestochen.

Teilt ihr meine Meinung?

[gropiuskalle]

Überhaupt nicht. Der aktuelle Firefox war doch sofort auf den servern, auch bei anderen Softwarebereichen erscheint mir die SuSE-Community etwas flotter - das Team ist allerdings auch ungleich größer.

openSUSE verfolgt eine etwas andere update-Politik; die offiziellen Quellen von SuSE sind zum einen statisch (oss & non-oss), zum anderen werden nur bugfixes rückportiert (update), d.h. major-releases bleiben in ihrem Funktionsumfang unverändert. Wer es aktuell oder sogar bleeding edge haben will, sollte sich entsprechende Quellen (z.B. 'Mozilla') einbinden.

[derRichard]

Teilt ihr meine Meinung?

nein.
mir ist lieber wenn ich ein update erst etwas später bekomme und es dafür auch funktioniert.
grad ubuntu gibt oft ungetestete pakete aus.
das ist ein schönes beispiel:
https://bugs.edge.launchpad.net/ubuntu/+source/phpmyadmin/+bug/392324

und, dass ein update von suse 2 wochen unterwegs ist, dann ist schon sehr selten.

//richard

[Schreibtroll]

*Buntu ist etwas experimentierfreudiger und gibt daher Updates schneller raus. Denke mal, mit Fedora hast Du das gleiche "Problem" während SuSE die etwas ausgiebiger testet bevor die eingepflegt werden. Debian als Vater von *Buntu ist noch konservativer weshalb es auch nicht gerade für brandneue Hardware geeignet ist wenn wir hier von OOTB reden...

[naraesk]

Also bei Fedora ist das arg unterschiedlich. Zum Beispiel die reinen Bugfix- Updates bei KDE (4.3.3 / 4.3.4) dauern meist einen Monat, KDE 4.3.4 ist heute oder gestern erst in Testing aufgetaucht.
Das ist bei einem Bugfix- Release schon arg lang. Wird aber wohl eher auf des überschaubare KDE- Team bei Fedora zurückzuführen sein,

Firefox 3.5.6 kam 3 Tage nach dem Release, das ist ziemlich fix denke ich.

[gropiuskalle]

Unter SuSE dauert derlei auch nicht lang, z.B. sind Firefox oder Thunderbird innerhalb von 24 Stunden aktualisiert, das KDE-Team von openSUSE ist eh unschlagbar (finde ich). Aber wie gesagt, es kommt auf die eingebundenen Quellen an. Und davon hat man unter SuSE wirklich reichlich zur Verfügung (mir ist jedenfalls nicht bekannt, dass es unter *Ubuntus davon mehrere hundert gibt...), und einige dieser Quellen beinhalten sogar stabile Pakete! :)

Die Aussage, SuSE würde Pakete ausgiebiger testen, bevor sie eingepflegt werden, stimmt so eigentlich nicht.

[drcux]

Die Aussage, SuSE würde Pakete ausgiebiger testen, bevor sie eingepflegt werden, stimmt so eigentlich nicht.

Wenn wir bei openSUSE von Updates sprechen, meinen wir eigentlich immer die aus der offiziellen Update-Quelle, und die werden schon ausgiebiger getestet.

Alles andere sind zusätzliche, meist unabhängige Repos, das hat nichts mit Updates zu tun.

[gropiuskalle]

Das ist allerdings 'ne typische SuSE-Kiste, die ich im SuSE-Kontext auch so verstehe. Wer wirklich nur auf das update-Repo setzt (was wohl eher im z.B. betrieblichen Zusammenhang interessant sein dürfte), der verfolgt natürlich die Intention eines gnadenlos stabilen Systems. Eine derartige Repo-Auswahl ist auf home-desktops aber wohl eher die Ausnahme.

Was wäre SuSE z.B. ohne Packman?

Aber man muss tatsächlich sehr genau zwischen den offiziellen stabilen Repos des openSUSE-Teams (lediglich oss, non-oss und update) und 3rd-Party-Quellen unterscheiden. Kam in meinem letzten post nicht ganz rüber.

[Rain_maker]

Wer dieses Testen mitmachen will (verbunden mit dem Risiko, daß dann auch mal ein "faules Ei" unter den Updates sein _kann_), der kann sich ja das entsprechende "*-test" Repo von hier einbinden.

http://download.opensuse.org/update/

Dazu sollte man sich aber schon etwas besser mit Linux/openSUSE auskennen, vor allem für den Fall, wenn denn mal etwas schief geht.

[smurfle]

Wer bei dem Testen unbedingt mitmachen will/muss sollte dann aber auch die gefundenen Fehler an Suse melden. Für einige ist das selbstverständlich aber man kann es nicht oft genug wiederholen. Den nur gefundene und gemeldete Fehler können behoben werden.

Mfg Smurf

[Rain_maker]

Wer bei dem Testen unbedingt mitmachen will/muss sollte dann aber auch die gefundenen Fehler an Suse melden. Für einige ist das selbstverständlich aber man kann es nicht oft genug wiederholen.

Full ACK.

Und um eine der "Standardausreden" zu diesem Thema auch gleich zu entkräften:

https://bugzilla.novell.com/

Da gehts lang.

Für Standardausrede Nr.2 "Aber mein Englisch ist zu schlecht" gilt: "Dann lass halt die Finger davon".

[stefan74]

Hier nochmal ein aktuelles Beispiel um meine Behauptung zu untermauern. Firefox 3.5.7 wurde am 5.1.2010 von Mozilla freigegeben.
Ber erst heute am 1.2.2010 hab ich das Update von Suse angeboten bekommen. Das letzte mal war ich am 31.1.10 online.
Bei Ubuntu war das Update innerhalb von ein paar Tagen verfügbar!

[lOtz]

FUD!
http://download.opensuse.org/update/11.2/rpm/i586/
11.01.2010


lotz@webgine:~/Download> wget http://download.opensuse.org/update/11.2/rpm/i586/MozillaFirefox-3.5.7-1.1.1.i586.rpm


lotz@webgine:~/Download> rpm -qp --info MozillaFirefox-3.5.7-1.1.1.i586.rpm
Name : MozillaFirefox Relocations: (not relocatable)
Version : 3.5.7 Vendor: openSUSE
Release : 1.1.1 Build Date: Mo 11 Jan 2010 18:25:45 CET
Install Date: (not installed) Build Host: build31
Group : Productivity/Networking/Web/Browsers Source RPM: MozillaFirefox-3.5.7-1.1.1.src.rpm
Size : 3531156 License: GPLv2+ ; LGPLv2.1+ ; MPLv1.1+
Signature : RSA/8, Mo 11 Jan 2010 18:26:33 CET, Key ID b88b2fd43dbdc284
Packager : http://bugs.opensuse.org
URL : http://www.mozilla.org/
Summary : Mozilla Firefox Web Browser
Description :
Mozilla Firefox is a standalone web browser, designed for standards
compliance and performance. Its functionality can be enhanced via a
plethora of extensions.
Distribution: openSUSE 11.2

Und nu?

[drcux]

In 3.5.7 sind keine Sicherheitslücken gefixt worden, oder? Und wenn es sich um ein reines Bugfix handelt, sind die Susianer halt ein wenig zurückhaltender.

[drcux]

FUD!


Mag ja sein, das er am 11.01. gebaut wurde, aber im offiziellem Update-Repo ist er erst seit heute.

[lOtz]

Dann eben Kommando zurück :D
Meiner kommt so oder so aus dem BuildService.

[Newbie314]

.. und wenn man das Mozilla Repo einbindet .. ist dieses Thema eh kein Thema .. man muss gar nicht erst auf den Build Service... auch die Mozilla Repo Pakete waren bei mir bisher sehr stabil ...

[drcux]

.. und wenn man das Mozilla Repo einbindet .. ist dieses Thema eh kein Thema .. man muss gar nicht erst auf den Build Service... auch die Mozilla Repo Pakete waren bei mir bisher sehr stabil ...

Von welchem Mozilla-Repo sprichst du?

[Newbie314]

Ups... gerade nachgesehen: ich verwende das aus dem buildservice.... schäm :ugly:

[Rain_maker]

Wie immer bei solchen Themen:

<Textbaustein>
Einzige, "offiziell unterstützte" Repos bei openSUSE sind:

- OSS

- NON-OSS

- Updates
</Textbaustein>

Einziges "must have"-Drittanbieterrepo für openSUSE ist Packman, bei allen anderen gilt

a) keine offiziellen Repositories (ok, das gilt natürlich auch für Packman)

b) sich drei mal überlegen, was man aufnimmt und was nicht und nicht auf alles klicken, was bei drei nicht auf dem Baum ist.

- ALLES, was aus dem BuildService kommt, egal wie "offiziell" es klingen mag, sind keine offiziellen Repos (nein, auch nicht die beliebten KDE-Repos, das Mozilla-Repo, das OOo-Repo oder die Treiber aus driver:wireless um mal ein paar bekannte Vertreter zu nennen).

- ALLES, was "home" im Namen trägt, sollte mit doppelter Vorsicht betrachtet werden, denn auf gut Deutsch kann "jeder Dödel" sein eigenes home-Projekt aufmachen und veröffentlichen, und wer besonders tolle Beispiele will, was man sich damit einhandeln kann, der darf sich z.B. das hier durchlesen:

http://www.pc-forum24.de/suse-treiber/10569-compat-wireless-auf-opensuse-11-2-kaputte-pakete-im-obs.html

Da hat sich die Situation übrigens so weit entspannt, daß die neusten Pakete nun nach einer Umstellung des Makefiles für compat-wireless praktisch leer sind (weil im chroot scheinbar keine der CONFIG-Optionen greift) und deshalb keinen Schaden mehr anrichten können, aber auch das hat scheinbar keiner der "Maintainer" dieser Home-Projekte gemerkt, was aber auch schwierig ist, denn wenn man sich mal den Spaß macht und in die SPEC-files reinschaut, dann sieht man, daß die alle nur voneinander kopieren und wenn der eigentliche Ersteller pennt, dann kommen die anderen Esel direkt hinterher, weil scheinbar keine Sau sich wirklich drum kümmert, was sie da zusammenschustern.

Das ist dann eben der Nachteil des "für alle offen"-Buildservice (auch ich habe diese Probleme beim Bau der compat-wireless Pakete gehabt, und auch ich bin mir bewusst, daß ich wahrscheinlich schon viele "miese" Pakete gebaut habe, aber ich war wenigstens nicht so dämlich und habe den Kram ohne lokale Tests auf den Server hochgeladen, damit sich $DURCHSCHNITTSUSER sein System aufgrund eines offensichtlichen Fehlers von mir fröhlich zerschiessen kann, das kann er schließlich auch ohne meine Hilfe ganz gut).