[DE] Aktualität: Aptosid vs Arch

[phen]

Moin!

Vor kurzem hatte ich mir nen Arch eingerichtet, und ein hilfreiches Tool "Appset" hatte mich schon vor Tagen über KDE4.6.2 in den Repos informiert, was ich direkt installiert hatte.
Für Aptosid steht mir über das offizielle Debian/Sid Repo lediglich 4.4.5 zur Verfügung, über experimental-snapshots dann eben noch 4.6.1 - aber eben noch nicht 4.6.2.

Daher meine grundsätzliche Frage: Wie verhält sich mit der Aktualität der beiden Distros im Vergleich?
Stichwort: Debian Freeze?

Und gerade in Bezug auf KDE: Wie kommt es dass Arch schon 4.6.2 verpackt hat? Haben die mehr Devs?

Ich bin für jede eingehende Erklärung und Info hierzu dankbar!

PS: Zur Installation von KDE: Ich schätze mal auch in Arch ist es dringlich so was nur in init3 vorzunehmen?

[holgerw]

Hallo @phen,

Vor kurzem hatte ich mir nen Arch eingerichtet, und ein hilfreiches Tool "Appset" hatte mich schon vor Tagen über KDE4.6.2 in den Repos informiert, was ich direkt installiert hatte.
Für Aptosid steht mir über das offizielle Debian/Sid Repo lediglich 4.4.5 zur Verfügung, über experimental-snapshots dann eben noch 4.6.1 - aber eben noch nicht 4.6.2.

Auf Debian Sid aufsetzende Rolling Releases rollen anders als Distributionen wie PCLinuxOS. Der Zweig Sid ist davon abhängig, was im Zweig Stable passiert, dort agieren die Debian Maintainer im Hinblick auf das zukünftige Stable. Veröffentlichungsphasen bei Debian sind daher für Sid Anwender regelrechte Durststrecken, weil dann in Sid kaum noch etwas rollt, meine Erfahrung ist allerdings, dass nach einigen Monaten das Rollen wieder gewohnt zügig fortschreitet :-)

Bei PCLinuxOS hingegen wird geschaut, was die unterschiedlichen Software Projekte an neuen Versionen heraus bringen, und es wird zeitnah dann integriert, ohne dass man auf einen anderen Distributionszweig Rücksicht nehmen muss. Über Arch kann ich wenig sagen.

Viele Grüße,
  Holger

[agaida]

Zu Fragen der Aktualität: Arch wird immer um Längen aktueller sein als debian. Den wesentlichen Punkt hat holgerw schon genannt. Die Zielrichtung von sid als Zuarbeit für die stabile Distribution.

Packen bei Arch ist zudem auch wesentlich einfacher als bei debian. Ungefähr alles, was debian ausmacht fällt weg: Der Ansatz, auf breiter Hardware lauffähig zu sein (nur i686 und amd64), es wird, von wenigen Ausnahmen abgesehen, vanilla gepackt, was die Sache an sich ungeheuer vereinfacht, eine breite Userbasis, die auf ein stabiles Arch angewiesen ist, gibt es so nicht wirklich, Beschränkung auf wesentliche Pakete (sehr viel schmalere Basis in core und extra). Dazu kommt noch das Vertrauen darauf, dass die User wissen, was sie machen.

Wenn irgendwo testing im Repositorynamen steht, ist das ernstgemeint, das kann, wird und soll knallen und dürfte für nicht so versierte Arch-User mittelschwere bis sehr ernsthafte Probleme nach sich ziehen.

unstable (kde-unstable und gnome-unstable) dürfe bei Debianeren mittelschwere Panikattacken auslösen, weil es einfach für diesen Zustand keinerlei Entsprechung gibt. Einbindung von unstable in ein funktionierendes System macht aus diesem halt genau das. In anderern Worten: Die Wahrscheinlichkeit, dass das System dann nicht mal mehr eingeschränkt nutzbar ist, ist relativ hoch (>90%). Und damit sind dann auch keine Kleinigkeiten wie "meine Maus/Tastatur/Sound/X tut nicht richtig" gemeint. Sowas ist schon durch Testing abgedeckt

Diese Philosophie führt dann dazu, dass Fehler recht schnell bei den richtigen Leuten auffallen und gefixt werden. So ist es halt recht einfach und schnell möglich, core und extra eigentlich recht stabil zu halten.

[holgerw]

Hallo,

mir fällt gerade noch auf:

PS: Zur Installation von KDE: Ich schätze mal auch in Arch ist es dringlich so was nur in init3 vorzunehmen?

Warum eigentlich? Unter openSUSE kann ich bis zum Erbrechen diverse KDE Versionen unter laufendem KDE austauschen, ohne dass etwas schlimmes passiert. Unter Kubuntu kann ich eine Version 10.10 mit KDE 4.6.2 versorgen unter laufendem KDE, ohne das etwas passiert. Unter PCLinuxOS geht das.

Warum soll das unter anderen Distributionen gefährlich sein?

Damit sage ich nicht, dass es mal unkritisch in der Vergangenheit war.

Viele Grüße,
  Holger

[agaida]

@holgerw: Richtig. Und falls was Generelles schiefgeht, steht man beim nächsten Start eh in der Konsole. Immer wieder gern genommen sind in diesem Fall ja Änderungen an Treibern und X, die dazu führen, dass man mal bestimmte Sachen in der Konsole macht. Allerdings würde ich bei einem Major-Update einfach  neu starten, da mir die Frickelei mit eventuell noch laufenden alten Versionen zu blöd wäre.

[holgerw]

@alf:

Code: [Select]

zypper ps zeigt mir nach einer Aktualisierung an, bei welchen noch laufenden Prozessen Dateien ausgetauscht wurden und die deshalb besser neu gestartet werden sollten.

Viele Grüße,
  Holger

[agaida]

Auf das Argument habe ich gewartet - ein sauberer Neustart geht imho schneller. Es spricht nichts dagegen, es so zu tun, ist aber nicht mein Stil. Ich habe solche Künstler kennengelernt, die meinten, dass so was auf Serverebene geil wäre. Das Ende vom Lied war immer, dass der Server nach einer geplanten Abschaltung nicht oder nur unvollständig hochkam. Ich habe nach dem heutigen Update mal mit gestoppt. Neustart: 1:30 mit Runterfahren und einloggen. Die Zeit brauche ich auch, um eventuelle Dienste manuell neuzustarten..

Ist vielleicht ein wenig rustikal, meine Methode, dafür aber bewährt und ich sehe sofort, wenn ich in ein Problem gelaufen bin. Daraus folgt natürlich - keine Updates, wenn ich die Maschine wirklich dringenst brauche.

[cryptosteve]

Viele Distributionen empfehlen Updates nur auf der Console bzw. im Singleuser (BSD) durchzuführen. Ich habe das immer ignoriert und nie hat es geknallt - was aber natürlich nicht bedeutet, das es nicht trotzdem schiefgehen kann.

[DonKult]

Es geht nicht um den großen Knall (oder eher sehr selten) sondern um die vielen kleines Knalls. Der iceweasel Maintainer hat z.B. seine helle Freude mit major-upgrades von iceweasel während dieser läuft weil es dann passieren kann, dass Dialoge die sich öffnen einfach leer sind weil die Datei die er da öffnen will nicht mehr da ist (daher fragt der ob er iceweasel neustarten soll).

Da ich relative gute Verbindung zu ubuntu und deren Upgradeproblemen habe, weiß ich von denen, dass die spezielle Tests laufen lassen um zu prüfen ob bei ihnen das upgrade von stable zu stable in X einwandfrei läuft. Ein abschmierendes X ist eher ungewöhnlich, was aber häufiger vorkommt ist ein absterbendes Panel - oder seit neustem die Indikatoren - und solche Kleinigkeiten.

Ich mach auch einige meiner upgrades hier in X, ich mach die allerdings auch immer in screen - weil bisweilen auch schon mal die KDE Konsole in der das läuft abgeschmiert ist… - ohne ersichtlichen Grund, weil KDE war eigentlich nicht direkt beteiligt (und ich nutze auch nur sehr wenige Teile von KDE). Auch muss man bedenken, dass während dpkg da arbeitet, die Pakete an denen es da arbeitet in einem relativ undefinierten Zustand sind. Ob die während sie in diesem "Zustand" sind funktionieren oder nicht ist eher Glücksache, den definiert ist das nur für essentielle Pakete (die müssen immer funktionieren) damit auch andere Pakete sie verwenden können um sich funktionsbereit zu machen…

Um auf Ubuntu zurück zu kommen: Wie ich schon öfter gesagt habe: Die überlegen sich regelmäßig etwas zu machen was wohl auch bei Fedora (aber nagelt mich jetzt nicht auf die Distro fest) im Einsatz ist: Ein Upgrade "während" des herunterfahrens: Also eben genau dann, wenn der Nutzer nebenher gar nichts macht, also auch nichts für ihn abschmieren kann.
Den das ist mit eine Motivation für 'init 3'… Der weniger erfahrene wird nebenher eher weniger machen und der mehr wissende wird ein Gespür dafür entwickelt haben was er machen kann und was nicht… Wenn man wild nebenher Arbeit ist die Gefahr eben größer das sich etwas zerlegt.

Und wenn wir hier sagen: Immer außerhalb von X ersparen wir uns immerhin User die in X upgraden, denen dann X doch mal mittem im upgrade wegstirbt, neubooten und dann nix mehr bootet, weil das System inkonsitent ist… (grub unkonfiguriert oder kernel nur halb installiert, …).

[agaida]

Und wenn wir hier sagen: Immer außerhalb von X ersparen wir uns immerhin User die in X upgraden, denen dann X doch mal mittem im upgrade wegstirbt, neubooten und dann nix mehr bootet, weil das System inkonsitent ist… (grub unkonfiguriert oder kernel nur halb installiert, …).

Jetzt wo Du es so ansprichst, ja, nachvollziehbar. Endlich mal ein Argument, was auch ich begreife. Das mit dem "Das macht man halt so" war mir nicht so einleuchtend. Die Konsole ist mir zwar noch nie weggeschmiert , aber den Support-Aufwand nach so was kann ich mir lebhaft vorstellen

[ralul]

Zu dem was DonKult erzählt, kam bis vor einem Jahr noch hinzu, dass bei bestimmten upgrades Debian Maintainer versuchten die betroffenen Dienste neu zu starten, um sie im laufenden System auf den aktuellen Stand zu bekommen. Das crashte zwangsläufig des System eines eingeloggten Xorg Users.

Dahinter mag stehen, dass Debian mehr auf Server zielt, die auch über upgrades hinweg weiter und möglichst aktualisiert laufen sollen. Insofern ist bei Debian auch in Zukunft mehr Vorsicht geboten.

Noch ein Beispiel:
Ich würde unter xorg eingeloggt immer ein Office Programm upgraden. Aber ich kann nicht sicher sein, wenn ich vorher ein neues Dokument starte, nicht seinen Speicherort mit "save as" definiere, dann zwölf Stunden schreibe und dieses ungesichert ein DU anfange, dass ich meine Arbeit retten werde können. Und wenn ich dann während des DU auf "save as" drücke (*), dies mir den PC abschmieren lässt, haben wir das DU Chaos, was DonKult mit seiner "init 3" Empfehlung verhindern will ...

Also, wer Ahnung hat, kann sich frohen Mutes über so manche Empfehlung hinwegsetzen, aber wehe ...

*PS: gerade "save as" wird oft Hilfsbibliotheken öffnen (die noch nicht geladen sind), die es so nicht mehr gibt, oder nicht mehr passen nach einem DU. Denkbar für einen Crash sind auch nachladbare Plugins beim Arbeiten mit Digikam. Dann könnte ein upgrade kde-4.4 zu kde-4.6.2 crashen, aber vielleicht nicht kde-4.6.1 zu kde-4.6.2. Crashen könnte auch zB ein Öffnen einer neuen Version von Konsole beim upgrade von Kde.

[hefee]

Auch muss man bedenken, dass während dpkg da arbeitet, die Pakete an denen es da arbeitet in einem relativ undefinierten Zustand sind. Ob die während sie in diesem "Zustand" sind funktionieren oder nicht ist eher Glücksache, den definiert ist das nur für essentielle Pakete (die müssen immer funktionieren) damit auch andere Pakete sie verwenden können um sich funktionsbereit zu machen…

Wie stellen den das essentielle Pakete sicher, das sie immer gehen bzw. wieso kann dies nicht für alle Pakete sichergestellt werden?

[DonKult]

Auch muss man bedenken, dass während dpkg da arbeitet, die Pakete an denen es da arbeitet in einem relativ undefinierten Zustand sind. Ob die während sie in diesem "Zustand" sind funktionieren oder nicht ist eher Glücksache, den definiert ist das nur für essentielle Pakete (die müssen immer funktionieren) damit auch andere Pakete sie verwenden können um sich funktionsbereit zu machen…

Wie stellen den das essentielle Pakete sicher, das sie immer gehen bzw. wieso kann dies nicht für alle Pakete sichergestellt werden?

Gegenfrage: Wenn die Blackbox eines Flugzeugs unzerstörbar ist, warum baut man dann nicht das komplette Flugzeug aus dem Material?

Die Antwort auf 'Wie' ist Pre-Depends und ein sehr geringe Funktionalität, sodass sehr wenig benötigt wird um es lauffähig zu halten. Ersteres hat erhebliche Nachteile für den Paketmanager, sodass Pre-Depends generell verboten sind per debian-policy und deren Anwendung eine Diskussion auf debian-devel erfordert, letzteres läuft konträr zu den Anforderungen die ein Anwender normalerweise hat. Den ein Programm was ein Fenster öffnet, kann keinesfalls als "mit geringer Funktionalität" bezeichnet werden - vor allem weil es dann auch von massenhaft anderen Paketen abhängt, die alle wiederum selbst nicht die schlankesten sind.

[WilhelmHH]

Gegenfrage: Wenn die Blackbox eines Flugzeugs unzerstörbar ist, warum baut man dann nicht das komplette Flugzeug aus dem Material?

Weil das Flugzeug zu schwer würde?

[Mr.Smith]

Gegenfrage: Wenn die Blackbox eines Flugzeugs unzerstörbar ist, warum baut man dann nicht das komplette Flugzeug aus dem Material?

Weil das Flugzeug zu schwer würde?

Weißt Du wie schwer ein Flugzeug ist? Ich vermute mal, dass die BlackBox auch nicht mehr unzerstörbar wäre hätte sie die Ausmaße eines Flugzeugs.Abgesehen davon hätten die Passagiere so oder so das Nachsehen.