Die Meta-Zyklen erscheinen mir sehr interessant. So hat man -je nach bedarf- eine sehr aktuelle oder eine sehr stabile Distribution. Aber auch die aktuelle Variante ist in sich homogen und kann daher langfristig genutzt werden.
Das vermisse ich bei Debian ein wenig. Die Stable ist mir definitiv zu alt. Die Testing/Unstable ist nicht konsistent. Meist ist das kein Problem, aber in regelmäßigen Abständen zerschießt man sich -zumindest für einige Zeit- das System. Auch muss man ständig das System auf dem neusten Stand halten. Ansonsten kann man nach einer Weile (halbes Jahr oder so) praktisch keine Software mehr installieren (ohne eine Updateorgie zu starten). Schön währe wenn man eine Unstable/Testing in eine Stable "Hineinwachsen" lassen könnte. Also mit Unstable beginnen und wenn die Stable die Versionsnummer der Unstable erreicht oder überschritten hat auf Stable umsteigen. Jeweils für Jedes Programm getrennt. Man könnte sich ein System mit der notwendigen Funktionalität erstellen und mit der Zeit würde es immer stabiler.
Ich will ja nicht flamen, aber Debian wird dank der Metazyklen aktueller als Ubuntu sein - wenn man stable als Grundlage nimmt. Debian wird alle 1 1/2 Jahre eine Neue Version rausbringen, Ubuntu laut Artikel nur alle 2-3 Jahre eine mit stable vergleichbare Distribution. Die Ubuntus zwischendurch scheinen dann nur noch den Charakter von testing/unstable zu haben.
Ubuntu hatte bis jetzt 3 stable Releases, bedeutet also ca. alle 1,5 - 2,5 Jahre einen Meta-Stable Release. Dazwischen liegen aber dann: Jahre / 0,5 Stable-Releases, bei Debian liegt dazwischen nur testing und unstable.
Daraus lässt sich einwandfrei folgern: Ubuntu hat die aktuellere Software in seinen stable-releases, ob diese Software dann auch wirklich mehr "stable" ist als die in debian testing steht auf einem anderen Blatt. Vor allem aber bleibt sie jeweils für minimal ein halbes Jahr stabil, bei Debian sinds minimal 1,5 Jahre (und wir kennen die Releasezyklen von Debian ja ).
Das Problem ist ja nicht Stable. Die ist halt Stable :-) Ich sehe es eher in der Inkonsistenz von Testing/Unstable. Als reine Zulieferer von Stable ist das ja O.K., aber nicht als aktuelle, einsetzbare Distribution. Daher würde ich so etwas wie eine Halbstable oder Testing-eingefroren die für ca. 1/2 bis 1 Jahr gepflegt wird sehr begrüßen. Zur Not würde es auch reichen wenn die alten Paketquellen noch erreichbar bleiben. Auch ein Hineinwachsen in die jeweils stabilere Variante währe toll. Könnte man das nicht mit einer gringfügigen Erweiterung von apg-get (bitte nicht schlagen wenn ich einen falschen Namen benutzt habe) realisieren? Schöne Grüße Mark
es ist geplant, alle 1,5 jahre ein neues stable zu veroeffentlichen. damit ist ein gepflegter testing branch in der praxis nicht wirklich noetig: nach einem jahr muesste solangsam der core freeze beginnen und updates sollten dann selten unangenehme ueberraschungen mit sich bringen. und 1 jahr alte software auf ner workstation ist selten ein problem (wenn ja, hilft backports.org in 90% der faelle).
Du hättest recht, wenn Debian stable und eine neue Ubuntu-Version (zur Zeit ca. alle sechs Monate) vergleichbar wären, was die Aktualität angeht. Das sind sie aber nicht. Debian wird weiterhin wesentlich konservativer sein als Ubuntu. Shuttleworth spricht von neuen Konzepten alle zwei, drei Releases für Ubuntu, und damit würde Ubuntu in wesentlich kürzerer Zeit ihre Distribution umbauen als Debian es jemals könnte. Debian stable wird weiterhin mit die stabilste aller Distributionen der Welt bleiben, aber garantiert nicht sehr aktuell und schon gar nicht aktueller als Ubuntu. Doch wenn die "Zwischenversionen" Ubuntus so stabil bleiben wie die bisherigen Ubuntu-Versionen, müssen wir uns auch da keine Sorgen machen. Ubuntu wird dazu auch Sachen ausprobieren, die sich Debian noch nicht zutraut. Dir als Nutzer bleibt die Wahl. Ich finde das großartig.
Ich bin auch davon ausgegangen, dass XEN es in dapper schafft. Zumindest wenn Ubuntu in den Server Bereich möchte wäre Xen ein sehr wichtiges Argument. Irgendwo auf der Ubuntu Seite hab ich auch gelesen, dass XEN drin sein soll und in der Nachricht stand ja nur drin, dass XEN in der nächsten Version drin sein wird, aber nicht das es in Dapper nicht drin ist.
Hat jemand schon eine Beta von dapper installiert und kann mal nachsehen ob XEN dabei ist?
Eine kleine Anmerkung am Rande: Selbst Fli4l hat inzwischen XEN Unterstützung und beim Partner Projekt Eisfair XEN ist in der Vorbereitung.
Da sollte doch ein Projekt wie Ubuntu das doch locker hinbekommen.
Von Kai F. Lahmann am Do, 20. April 2006 um 01:10 #
wenn du ließt, was mit Xen so alles noch nicht funktioniert, ist klar, wieso Ubuntu das noch nicht wirklich anbietet. Für Server ist es zwar schon ganz nett, aber Richtung Desktop (und da liegt immer noch der Schwerpunkt bei Ubuntu), ist es weitgehend nutzlos - Gast-Systeme kommen da an vieles nicht ran.
Tolle Sache, dieses SMART, ein einheitliches Paket-Verwaltungsprogramm für alle Linux-Plattformen... Funktionell sehe ich da aber keinen Unterschied zum KPackage, welches zumindestens unter Debian und dort so ähnlich wie Synaptic funktioniert.
Wo ist da der Unterschied zu autopackage? Scheint mir genauso sinnlos zu sein.
Wie sagte Havoc Pennington mal im Bezug auf autopackage so schön: "Man löst das Problem der Inkompatibilität durch unterschiedliche Paketmanager nicht, indem man einen neuen entwickelt, sondern indem man sich endlich für EINEN entscheidet!"
Dummerweise wird weder Redhat zu dpkg, noch Debian zu rpm wechseln, und Linux wird sich ewig den Vorwurf gefallenlassen müssen, die Softwareinstallation wäre schwierig.
smart ist ein Frontend für fast alle Paketmanager. Du kannst über smart z.B. zugleich auf YUM- und APT-Repositories zugreifen. Nimmt man APT, kann man keine YUM-Repositories für die Installation nutzen und andersherum. Man braucht sich beim Distributionswechsel auch nicht an einen neuen Paketmanager gewöhnen, wenn beide smart anbieten.
Korrekt, bis zu dem Zeitpunkt, an dem ein neuerer und besserer Paketmanager beide Systeme ablöst :-) Mich würde an der Stelle mal ein Vergleich zwischen conary, zeroinstall und traditionellen Paketmanagern interessieren.
Ferner hoffe ich, das die DebianAlliance oder das LSB sich zu einem Art Standard GNU/Linux Platform weiterentwickelt. Darauf setzen dann verschiedene Distributionen ihre Pakete auf, sei es Server oder Desktop. Vermutlich wird es dann immer noch zig verschiedene Distributionen geben, die eine Platform für embedded, für Desktop, für Soundstudios, für Server, etc. anbieten.
Es gibt seit längerem einen Weg Software auf verschiedenen Distributionen einzusetzen, und zwar ohne das darunter liegende Paketmanagement aufzugeben: ZeroInstall
So hat man -je nach bedarf- eine sehr aktuelle oder eine sehr stabile Distribution.
Aber auch die aktuelle Variante ist in sich homogen und kann daher langfristig genutzt werden.
Das vermisse ich bei Debian ein wenig. Die Stable ist mir definitiv zu alt.
Die Testing/Unstable ist nicht konsistent. Meist ist das kein Problem, aber in regelmäßigen Abständen zerschießt man sich -zumindest für einige Zeit- das System.
Auch muss man ständig das System auf dem neusten Stand halten. Ansonsten kann man nach einer Weile (halbes Jahr oder so) praktisch keine Software mehr installieren (ohne eine Updateorgie zu starten).
Schön währe wenn man eine Unstable/Testing in eine Stable "Hineinwachsen" lassen könnte.
Also mit Unstable beginnen und wenn die Stable die Versionsnummer der Unstable erreicht oder überschritten hat auf Stable umsteigen. Jeweils für Jedes Programm getrennt.
Man könnte sich ein System mit der notwendigen Funktionalität erstellen und mit der Zeit würde es immer stabiler.
Gruß
Mark
Daraus lässt sich einwandfrei folgern: Ubuntu hat die aktuellere Software in seinen stable-releases, ob diese Software dann auch wirklich mehr "stable" ist als die in debian testing steht auf einem anderen Blatt. Vor allem aber bleibt sie jeweils für minimal ein halbes Jahr stabil, bei Debian sinds minimal 1,5 Jahre (und wir kennen die Releasezyklen von Debian ja
).
Ich sehe es eher in der Inkonsistenz von Testing/Unstable.
Als reine Zulieferer von Stable ist das ja O.K., aber nicht als aktuelle, einsetzbare Distribution.
Daher würde ich so etwas wie eine Halbstable oder Testing-eingefroren die für ca. 1/2 bis 1 Jahr gepflegt wird sehr begrüßen. Zur Not würde es auch reichen wenn die alten Paketquellen noch erreichbar bleiben.
Auch ein Hineinwachsen in die jeweils stabilere Variante währe toll. Könnte man das nicht mit einer gringfügigen Erweiterung von apg-get (bitte nicht schlagen wenn ich einen falschen Namen benutzt habe) realisieren?
Schöne Grüße
Mark
Und was zum Specht ist SMART? Ich kenne nur S.M.A.R.T.
Gruß
Irgendwo auf der Ubuntu Seite hab ich auch gelesen, dass XEN drin sein soll und in der Nachricht stand ja nur drin, dass XEN in der nächsten Version drin sein wird, aber nicht das es in Dapper nicht drin ist.
Hat jemand schon eine Beta von dapper installiert und kann mal nachsehen ob XEN dabei ist?
Eine kleine Anmerkung am Rande:
Selbst Fli4l hat inzwischen XEN Unterstützung und beim Partner Projekt Eisfair XEN ist in der Vorbereitung.
Da sollte doch ein Projekt wie Ubuntu das doch locker hinbekommen.
Package: xen-tools
Priority: optional
Section: universe/utils
Installed-Size: 244
Maintainer: Radu Spineanu
Architecture: all
Version: 0.8.5-1
Depends: debootstrap, perl-modules, libterm-size-perl
Recommends: xen, reiserfsprogs, xfsprogs
Filename: pool/universe/x/xen-tools/xen-tools_0.8.5-1_all.deb
Size: 48488
MD5sum: 31c47ec3ba36bf338369248700f4af42
Description: Tools to manage debian XEN virtual servers
This package contains tools to manage debian based XEN virtual servers.
With them you can create, duplicate, update or delete virtual servers.
.
Homepage: http://www.steve.org.uk/Software/xen-tools
Bugs: mailto:ubuntu-users@lists.ubuntu.com
Origin: Ubuntu
(mal nach XEN suchen) ist XEN noch nicht im Kernel von Dapper angekommen...
Euer
Pilot
http://labix.org/smart
Funktionell sehe ich da aber keinen Unterschied zum KPackage, welches zumindestens unter Debian und dort so ähnlich wie Synaptic funktioniert.
Wie sagte Havoc Pennington mal im Bezug auf autopackage so schön: "Man löst das Problem der Inkompatibilität durch unterschiedliche Paketmanager nicht, indem man einen neuen entwickelt, sondern indem man sich endlich für EINEN entscheidet!"
Dummerweise wird weder Redhat zu dpkg, noch Debian zu rpm wechseln, und Linux wird sich ewig den Vorwurf gefallenlassen müssen, die Softwareinstallation wäre schwierig.
Man braucht sich beim Distributionswechsel auch nicht an einen neuen Paketmanager gewöhnen, wenn beide smart anbieten.
Mich würde an der Stelle mal ein Vergleich zwischen conary, zeroinstall und traditionellen Paketmanagern interessieren.
Ferner hoffe ich, das die DebianAlliance oder das LSB sich zu einem Art Standard GNU/Linux Platform weiterentwickelt. Darauf setzen dann verschiedene Distributionen ihre Pakete auf, sei es Server oder Desktop.
Vermutlich wird es dann immer noch zig verschiedene Distributionen geben, die eine Platform für embedded, für Desktop, für Soundstudios, für Server, etc. anbieten.
Warum muß sich ein Kernel den Vorwurf gefallen lassen, die Softwareinstallation wäre schwierig?
Es gibt seit längerem einen Weg Software auf verschiedenen Distributionen einzusetzen, und zwar ohne das darunter liegende Paketmanagement aufzugeben: ZeroInstall