Sid oder Sarge?

[Mossi]

Ich weiß nicht, ob ich jetzt im richtigen Forum bin, aber ich denke, dass es doch etwas mit einer Grundsatzfrage zu tun hat. Falls nicht, kann das bitte ein Moderator verschieben.

Also: Ich hab jetzt seit einiger Zeit Debian Sarge bei mir am Laufen. Ich bin im Großen und Ganzen auch ganz zufrieden damit. Aber immer wieder ärgere ich mich, weil ich eigentlich viele Sachen aus Unstable-Sid brauchen könnte. Bisher hab ich immer gewartet bis sie eben in Testing übernommen werden, aber ganz so einfach ist das nicht immer.

Ich verwende meinen Rechner zu 75% für Entwicklungen in C++, C#, Java, Pascal und was sonst noch so anfällt. Den Rest der Zeit ist der Rechner damit beschäftigt mich von einer Website zur anderen zu bringen. Also kurz: Programmieren und Surfen.

Da ich aber gerade im Bezug auf meine Programmierungen auf diesen Rechner angewiesen bin, bräuchte ich auch einen Erfahrungsbericht, wie es denn mit der Stabilität von Sid aussieht. Bei Sarge hab ich ja schon mehrmals ein Update gezogen, dass dann doch ein paar kleine Problemchen gemacht hat. Da Sid als unstable logischerweise noch mehr Fehler beinhaltet wird das denke ich auch öfter vorkommen. Aber wie oft? Und vorallem wie heftig?

vielleicht kann mir jemand ein paar Ratschläge geben. Ich danke jedenfalls schonmal

[Psych]

Es ist in Sid grundsätzlich wahrscheinlicher das man einen wirklichen schweren Fehler erwischt (fehlerhaftes Grub o.ä.)
Ich benutze seit nem halben Jahr Sid ohne größere Probleme... zwischendurch mal unerfüllte Abhängigkeiten aber nichts gravierendes...

Wenn du die Zeit und die Erfahrung hast dein System im Notfall mit ner Knoppix Cd wieder ans rennen zu kriegen (musste ich bisher nicht) spricht eigentlich nichts gegen Sid! Auf einem Pc den du täglich zu arbieten brauchst und der finanzielle Verluste bedeutet, wenn er mal nicht funktioniert,würde ich kein Sid installieren.

[Schatten_Krieger]

Lasst mich dazu mal ne ganz allgemeine Frage einschmeißen, was ist eigentlich der Unterschied zwischen woddy sarge sid lamp und wie sie alle heißen?
Ich blick da irgendwie nicht durch...
Mit i386 und co ist doch die Architektur meines Systems gemeint oder?
was für systeme sind den arm und powepc? hab ich noch nie ghört

[Abraxax]

woody - stable
sarge - testing
sid - unstable

lamp hat damit nichts zu tun. das lamp steht für
Linux
Apache
MySQL
PHP

[porci]

lamp = Linux Apache Mysql Php -> Das ist eine häufige Softwarekombination auf Webservern
woody = aktuelle stabile Version von Debian (3.0). Dort gibt es nur Updates, die Sicherheitslücken und kleinere Fehler beheben. Es werden keine neue Versionen oder gar neue Programme in woody eingepflegt.
sarge = aktuelle testing Distribution. Das wird irgendwann mal die nächste stabile (3.1) Debianversion werden. Hier findest du Pakete, die bereits getestet wurden und für so stabil gehalten werden, dass sie in sarge sein dürfen. Das ist sozusagen die Betaversion bzw. der Release Candidat von Debian
sid = still in development. Dort kommen alle neuen Pakete erstmal hin. Hier werden sie getestet und wenn sie stabil genug sind, kommen sie nach sarge. Man könnte das wohl als Alpha-Version bezeichnen.
PowerPC = Damit sind unter anderem die aktuellen Appple-Computer gemeint. Eben alle Computer, die Power-CPUs haben.
ARM = Das ist noch eine andere CPU-Architektur. ARM-Prozessoren sind hauptsächlich in kleineren Geräten wie zum Beispiel PocketPCs verbaut.

Ich hoffe, das ist alles so richtig

[Snoopy]

hi

@ mossi
ich würde auf testing bleiben...
ich denke die problematik dass alles etwas lange dauert bis es zu testing gewandert ist, ist im moment der nächste release
wenn dieser (hoffentlich anfang dieses jahres...bin ja manchmal optimistisch) vollzogen wurde, wird es wieder bissi schneller gehen

wieso willst du zum programmieren und surfen immer die aktuellesten programme haben ?

[mastermind_the_real_one]

Ich persönlich halte testing für das denkbar schlechteste Arbeitssystem und meine es auch mal irgendwo von einigen Debianentwicklern oder auf der Debianseite gelesen zu haben (bitte fragt nicht nach einem Link, ich weiß nur, dass ich damals lange überlegt habe ob ich von woody auf testing oder sid umsteige und dementsprechend das Web durchforstet habe). Und zwar aus folgenden Gründen:

In testing können genauso Fehler auftreten wie in sid. Es fließen dort keine Security Updates ein. In sid auch nicht, aber: Werden Sicherheitslücken entdeckt, dann werden aktualisierte Pakete zunächst in sid auftauchen und erst nach einiger Zeit in testing.

Hinzu kommen einige persönliche Gründe:
Wenn ich als Endnutzer in Kauf nehme hin und wieder am System herumzubasteln, weil ich gerne aktuelle Software nutze/brauche und keine Lust auf Backports oder Compileorgien habe, dann nutze ich lieber sid, da es aktueller ist und ein klein wenig "sicherer".

Mein Fazit:
Wenn man nicht schrauben will und kein Risiko eingehen möchte, dann sollte man stable nutzen. Ist man bereit ein wenig rumzudoktorn, dann aus oben genannten Gründen sid. Allerdings sollte man bei sid und testing immer davon ausgehen, dass im worst case das gesamte System zerschossen ist.

Meine Erfahrung mit sid:
Hier läuft zuhause auf meinem Hauptrechner seit 1 1/2 Jahren sid und auf einem weiteren ebenfalls seit einem Jahr. Beide Rechner haben bisher keine größeren Probleme bereitet (ich benutze fast ausschließlich (bis auf einige wenige) die Debian Quellen für unstable in meiner sources.list, keine exotischen, die irgendwo im Netz auftauchen).

Wenn ich mich recht entsinne, hatte ich auf meinem Rechner mal ein etwas größeres Problem ganz am Anfang (so nach ein zwei Monaten) und seitdem nur Kleinigkeiten. Es kann z.B. mal vorkommen, dass ein Programm nicht nutzbar ist (Hauptkandidat bei mir ist Amarok) und man dann ein anders nutzen muss (es findet sich eigentlich immer eine Alternative). Das kann auch mit KDE/Gnome passieren. Dessen sollte man sich bewusst sein. In der Regel sind solche Probs recht schnell gefixt und man kann mit den gewohnten Proggis arbeiten.

Hoffe geholfen zu haben.

greetz
mastermind

[Bert]

hi,

dem kann ich nun gar nicht zustimmen. Meine Erfahren mit SID (ist schon eine ganze Weile her) sind nicht die Besten. Damals hatte sehr heftige Probleme mit Abhängigkeiten, die mich letztlich (da ich arbeiten wollte), zu einer Neuinstalation der Stable-Distro gezwungen hat.

Vor derartigen Problemen ist man bei testing recht sicher, da ja ~2 Wochen ins land gehen, bevor die Probleme von SID nach Sarge wandern. Hab jetzt Testing zwar noch nicht so lange drauf, aber Probleme mit abhängigkeiten hatte ich noch keine.

Dazu kommt noch, das SID sehr stark in Bewegung ist. Es sollte also beim SID-Einsatzt auch bedacht werden, das entsprechende Download - Kapazitäten vorhanden sind.

Meine Meinung: SID ist was für Leute, die gerne Beeding Edge sind, aber auch willig und fähig bei Problemen mit Abhängigkeiten diese zu lösen.

Bert

[BeS]

Hallo,

Vor derartigen Problemen ist man bei testing recht sicher, da ja ~2 Wochen ins land gehen, bevor die Probleme von SID nach Sarge wandern.

Genau das kann aber auch zum Problem werden.
Also ich habe testing mal verwendet als woody noch testing war und da sehr schlechte Erfahrungen gemacht. In testing können sich genauso Fehler einschleichen, wenn das passiert, dann hängst du aber oft eine ganze Zeit lang darauf fest, wenn du keine ältere Version hast um wieder einen Schritt zurück zu gehen.
Wenn bei sid solche Probleme auftauchen ist in der Regel innerhalb 1-2 Tage ein aktualisiertes Paket da, dass das Problem behebt. Hat sich aber ein größeres Problem in testing eingeschlichen kann es Wochen dauern bis ein aktualisiertes Paket über sid nach testing kommt.
Ich verwende jetzt seit einem guten Jahr sid und hatte nie größere Probleme. Ich mache aber auch nicht jeden Tag ein dist-upgrade und habe apt-listbugs installiert. Wenn da bei kritischen Paketen offene Fehler gemeldet werden, dann verschiebe ich mein dist-upgrade nochmal um ein paar Tage. Damit bin ich bisher sehr gut gefahren.

[peschmae]

Genau das kann aber auch zum Problem werden.
Also ich habe testing mal verwendet als woody noch testing war und da sehr schlechte Erfahrungen gemacht. In testing können sich genauso Fehler einschleichen, wenn das passiert, dann hängst du aber oft eine ganze Zeit lang darauf fest, wenn du keine ältere Version hast um wieder einen Schritt zurück zu gehen.

Die ältere Version hast du mit http://snapshot.debian.net auf jeden Fall zur Verfügung.

MfG Peschmä

[BeS]

Die ältere Version hast du mit http://snapshot.debian.net auf jeden Fall zur Verfügung.

ja stimmt, aber das muß man ja auch erstmal wissen und dann braucht man das richtige Pakete, bei kleinen Problemen ist es noch einfach, aber wenn z.B. nach einem X oder KDE update X nichtmehr läuft? Dann kann man da schon bei der Suche nach den richtigen Paketen ins Rudern kommen, dazu kommt dann noch pinning usw. das man nach dem nächsten update nicht wieder das gleiche Problem hat.
Da ist es doch einfacher, vorallem wenn man eben doch nicht so tief in der "Debian-Technik" drin ist, am nächsten Tag nochmal ein dist-upgrade zu machen und das Problem hat sich erledigt.

Also nach meinen Erfahrungen ist meine Empfehlung klar:
Neulinge: nur stable, wenn einem das zu alt ist vielleicht auch mit einer anderen Distribution anfangen (Fedora?) und sich erstmal in GNU/Linux einarbeiten.
Ansonsten: Will man ein aktuelles Debian und möglichst wenig Arbeit bei Problemen: sid, aus den oben beschriebenen Gründen.

[Mossi]

Also im Grunde sind die Meinungen über SID nicht nur negativ so wie ich das sehe. Ich bin im grunde nie abgeneigt, wenn ich irgendwo basteln muss. Mittlerweile denke ich, dass ich mit dem System schon recht gut umgehen kann, so dass ich die meisten Fehler selber schon recht beheben können sollte.

Aber zu einer oberen Frage zurückzukommen. ich benötige zur Zeit zum Beispiel KDevelop 3.1 welches sich immer noch nicht in Testing befindet. Ich hatte eigentlich gehofft, dass es mit KDE 3.3.1 mitwandern wird aber da scheint es wohl noch probleme zu geben.
Ebenso mit den Mono-Paketen die vermutlich auch nicht in absehrbarer Zeit nach testing wandern werden, wobei ich diese eben selbst kompiliert habe.
Das sind jetzt nur zwei Beispiele, aber so sieht es im grunde meistens aus.

Wie sieht es denn mit Sicherheits-Systemen aus? Man könnte doch zum Beispiel Pakete immer lokal wegsichern und im Notfall dann wieder zu diesen zurückswitschen. Zumindest stell ich mir das rein theoretisch so vor. Nur wie kann man so etwas wirklich realisieren? Man bräuchte irgendwie eine zusätzliche Quelle in sources.list in der die Vorgängerversionen gehalten werden. Bei Fehlern wieder downgraden. Aber das mit dem Downgrade ist meines Wissens auch nicht ganz einfach.

[Fentanyl]

Ohne das Grundsatzthema wieder hochholen zu wollen, aber man sollte auch bedenken, dass Sarge in absehbarer Zeit stable werden wird.

MfG, Fenta

[peschmae]

Die ältere Version hast du mit http://snapshot.debian.net auf jeden Fall zur Verfügung.

ja stimmt, aber das muß man ja auch erstmal wissen und dann braucht man das richtige Pakete, bei kleinen Problemen ist es noch einfach, aber wenn z.B. nach einem X oder KDE update X nichtmehr läuft? Dann kann man da schon bei der Suche nach den richtigen Paketen ins Rudern kommen, dazu kommt dann noch pinning usw. das man nach dem nächsten update nicht wieder das gleiche Problem hat.

Ich mach das so:

Code: Alles auswählen

deb http://snapshot.debian.net/archive/date/1-days-ago/debian unstable main contrib non-free

(für Sid, das benutze ich auch) und dann das ganze so richtig hoch pinnen > 1000. Dann ist die Sache weg.

Das gilt natürlich sowohl für Sid als auch für Sarge. Anzumerken ist aus meiner Sicht dass:
- Ich mit Sarge nach 1 Jahr auf 2 Computern nie Probleme hatten die das nötig machten
- Ich das mit Sid schon ab und zu mal gemacht habe (sagen wir 3 Mal in dem Jahr).
Einmal wars recht strub (da kannte ich snapshots auch noch nicht *g*) - da konnte entweder Gnome mit dem ganzen krempel oder KDE installiert sein (update von gnutls) - naja, hab ich halt abwechslungsweise das eine oder andere Installiert, wenn ich gerade was brauchte
Das Problem war aber - auch wenn da immer von "am nächsten Tag" die Rede ist - erst nach einer Woche behoben. Kann also durchaus auch mal etwas dauern - auch in Sid.

MfG Peschmä

[mastermind_the_real_one]

Ich mach das so:

Code: Alles auswählen

deb http://snapshot.debian.net/archive/date/1-days-ago/debian unstable main contrib non-free

(für Sid, das benutze ich auch) und dann das ganze so richtig hoch pinnen > 1000. Dann ist die Sache weg.

Hmm, interessant. Was passiert, wenn Du z.B. nur einmal in der Woche ein dist-upgrade fährst, dabei was schief geht und das Paket des Vortags bereits hinüber war? Oder verstehe ich das 1-days-ago falsch und es wird automatisch die vorherige Paketversion genutzt?

Ich hab mich bisher immer aus /var/cache/apt/archives/ bedient oder per pedes bei snapshot.debian.net. Manchmal sind die Mirrors auch nicht alle auf dem selben Stand und man kann Synaptic sagen, dass es die ältere Version nehmen soll.

Nicht dass man es häufig benötigt, aber das Automatisieren per sources.list klingt interessant.

greetz
mastermind

[Mossi]

und man kann Synaptic sagen, dass es die ältere Version nehmen soll.

Ich benutze ja im grunde auch Synaptic. Aber wie kann man dem Teil beibringen, dass es eine ältere Version verwenden soll? Dabei würde mich auch interessieren, wie ich herausbekomme, von woher das entsprechende Paket geholt wird. Es gibt da ja teilweise mehrere Möglichkeiten.

[DeletedUserReAsG]

Mal ein anderer Ansatz: Ich benutze meinen Rechner ja auch nur zum Programmieren, zum Surfen und zur Administration anderer Rechner. Für die letzten beiden Punkte benötige ich nicht die aktuellste Version der jeweiligen Software, so dass es im Grunde auch mit Woody ohne Backports funktionieren würde.

Für den ersten Punkt brauche ich aktuelle Software, allerdings beschränken sich die Sachen auf einige, wenige Pakete, die ich ohne Probleme per Hand updaten kann, so dass ich da auch nicht von einem speziellen Distri-Release abhängig bin.

Wenn also der einzige Grund für deine Überlegung SID<->Sarge die paar Sachen, die du zur Softwareentwicklung brauchst, sind, solltest du eher zu Sarge greifen.

Ich selbst setze lokal auch Sarge ein, und hatte damit bislang noch keine Probleme. Auf den Servern rennt Sid, aber die haben auch genügend Bandbreite, um innerhalb kurzer Zeit eine Menge Pakete umherzuschieben.

cu
niemand

PS: Gruß an Fenta, ohne irgendein df kommst du auch nicht aus, oder?

[Aresius]

Also ich verwende seit über drei Jahren testing (auch schon als woody noch testing war) und ich hatte bisher nur drei Probleme damit:
1. kurz nach dem Release von woody war sarge nicht wirklich gut brauchbar. Ich war mehrfach gezwungen viele Pakete aus sid zu installieren um ein nutzbares System zu haben. Das hatte sich aber nach etwa 1/2 Jahr gelegt, so das ich sid wieder aus der source.conf kommentieren konnte.
2. Frag mich nichtmehr was genau das Problem war, aber es hing mit der Umstellung von gstreamer auf 0.8 zusammen, irgendwas wollte da eine Zeit lang nicht, so dass ich mir die Pakete auch aus sid geholt habe.
3. Das Gnome update von 2.4 auf 2.6 *würg* das war ein Gemetzel, Pakete mit falschen Namen in den depends, Versionen vor und zurück... hoffe das wird jetzt nicht alle 6 Monate so (gnome soll ja jetzt jedes halbe Jahr ein Update bekommen)

Also ich fahre jetzt mit der Taktik testing und bei Bedarf sid Pakete von Hand. Und das geht bis auf sehr seltene Ausnahmen ausgezeichnet.

Übrigends gäbe es da noch eine Möglichkeit: chroot
Wenn es am Plattenplatz nicht mangelt, installiere sarge und installiere sid in einer chroot-Umgebung. Dann kannst Du mit sid arbeiten und sehen wie es sich verhält, sollte sid wirklich kaputt gehen, hast Du noch das andere System mit dem Du arbeiten kannst. (Wenn Du es geschickt anstellst musst Du für Sarge nichtmal neue Pakete runterladen, weil Du immer die alten aus sid nehmen kannst, Stichwort: .../archives -> chroot/.../archives)

Gruß
Stephan

[peschmae]

Hmm, interessant. Was passiert, wenn Du z.B. nur einmal in der Woche ein dist-upgrade fährst, dabei was schief geht und das Paket des Vortags bereits hinüber war? Oder verstehe ich das 1-days-ago falsch und es wird automatisch die vorherige Paketversion genutzt?

Dann schreibst du dort halt 7-days-ago rein

MfG Peschmä

[mastermind_the_real_one]

Dann schreibst du dort halt 7-days-ago rein
MfG Peschmä

Ok, dann hätte ich die Quelle von vor 7 Tagen. Beide Varianten setzen aber einen halbwegs regelmäßigen Updatezyklus voraus, damit es so easy funktioniert wie von Dir beschrieben. Da das bei mir stark schwankt (mal täglich, mal 14tägig, mal monatlich oder noch länger), werde ich wohl bei meiner Zufuß-Methode bleiben (benötigt man ja sowieso sogut wie nie). Aber trotzdem ein sehr interessanter Ansatz.

greetz
mastermind

[peschmae]

Naja, könntest ja ein Script schreiben was die "days ago" kalkuliert. Das muss ja nicht regelmässig sein, musst nur wissen wann.

Manuell tuts aber meistens tatsächlich auch.

MfG Peschmä