Und ich habe mich vor einem Jahr überzeugen lassen, Mandrake auf unserem WH Server zu packen. Das habe ich nun davon... na dann halt Debian! Das hat ja eh schon meinen alten Desktop ersetzt :-)
Hm ich weis es nicht genau auch wen ich Debian nutze. Aber wie lange supportet Debian alte Versionen? Wird z. B. noch Potato supportet und wen ja wie lange noch. Außerdem muß ich bei aktuellerer Software immer auf inoffizielle Quellen zurückgreifen bei denen es von wegen Support und Updates noch weitaus schlechter aussieht.
Eine Distribution muß ihre Kräfte auf ein ziel richten und darf sie nicht auf alte Zöpfe verschwenden. Besonders bei kommerziellen Distributionen kann das sonst zu einen Debakel führen.
Es bedeutet das du auf eine neue stable version updaten musst. Das mit den verkürzten Supportzeiten bei Mandrake und Debian ist aber nicht so tragisch, da bei beiden Updates kostenlos sind (im Gegensatz zu M$) und zumindest unter Debian mittels apt-get relativ einfach zu bewerkstelligen sind. Bei Mandrake gibt es etwas ähnliches wie apt-get, aber dazu kann ich nichts sagen, weil ich es noch nie benutzt habe. Vielleicht hat ja jemand erfahrung mit Mandrake.
Das Tool heißt urpmi und die Syntax ist so ähnlich wie apt-get. Die .rpm-Pakete werden dabei einfach mit "urpmi Paketname.rpm" eingespielt - wenn die Onlineverbindung steht, holt sich das Programm die eventuell zusätzlich benötigten Bibliotheken von den Mandrake-Servern. Zusätzlich gibt es noch ein Programm namens MandrakeUpdate, das automatisch nach Sicherheitsupdates sucht und sie einspielt. Wenn man das mit cron automatisiert, ist das System nahezu kontinuierlich auf dem aktuellen Stand (zumindest was Patches angeht).
Von Linux-phased am Mi, 5. Februar 2003 um 23:11 #
Ne du es gibt schon auch apt-get für Mandrake, das ist das gleiche Tool wie bei Debian nur halt auf die Mandrake angepasst, benutzen aber nur wenige und es gibt auch ganz wenig Mirrors, die Pakete für dieses apt-get haben.
RedHat User nehmen es schon vermehrt her, da gibts auch einige Mirrors für Pakete und es funktioniert auch recht gut. Freshrpms setzt auch auf apt-get für ihre RedHat Pakete. Aber urpmi ist eindeutig leistungsfähiger und handelt die dependencies besser, das letzte mal, als ich mir KDE bei ner RedHat 8.0 von der Rawhide installieren wollte ging das voll daneben, danach musste ich mit der Rettungsdiskette, zuerst wieder das RPM system fixen, denn das hat es auf Grund dependencies deinstalliert und dann ging nix mehr.
URPMI ist meiner Meinung nach eins der leistungsfähigsten Paketmanagementtools die es gibt, das einzige was Probleme bereiten kann ist, das in den Paketen die dependencies falsch gesetzt wurden, das System ansich ist zu 99,9% perfekt nur der Paketersteller ist das Problem, der einfach mal was vergisst, oder die dependencies nicht updated.
Also da Debian nicht kommerziell ist, finde ich das gerade den großen Vorteil, dass man etwas länger auf neue Releases warten muss. Für einen Server ist sowas optimal (stable), für den Desktop kann man auch die unstable nehmen.
Verkürzt Mandrake auch den Support für rpm-Pakete des letzten KDE-Releases oder dauerts nur ein bischen länger? Ich für meinen Teil warte zumindest immer noch bis die Pakete kommen, ansonsten werde ich mich wohl dran machen selber aus den Sourcen das neue KDE zu installieren.
Wer es nicht abwarten kann . . . . . . sollte doch die 3.1 rc5 von Mandrake-Cooker nehemen, die läuft bei mir (Mdk 9) tadellos. Beim Insrtallieren sollten einige Paketabhängigkeiten ignoriert werden - besser ist die alten KDE-Pakete komplett von der Platte zu putzen, bevor man die neuen einspielt. Einziger Fehler war, dass ich eine alte XF86Config reaktivieren mußte, aber daran kann auch der nvidia-Treiber schuld sein. Hab ich noch nicht komplett aufgeklärt. Das geht immer noch schneller als Neukompilieren, eine vorhandener MC erleichtert die Aktion.
Von Thorsten von Plotho-Kettner am Mi, 5. Februar 2003 um 05:43 #
Link klappt hier wunderbar als Downloadquelle. Das Update auf 3.1 mittels rpm -Uhv --nodeps *.rpm war klar und lief sauber durch. Die Version läuft auch absolut stabil bis jetzt.
Wow, danke. Ich werde das mal mit diesen Paketen probieren, auch wenn sie für eine andere Distro (Textstar) sind. Aber wenn's bei dir anständig läuft...
Texstar ist keine andere Distro. Er (Texstar) erstellt viele Pakete für Mandrake. Und meistens sind die dann besser als die vom Distributor selbst. Besonders die KDE-Pakete...
Von Linux-phased am Mi, 5. Februar 2003 um 07:56 #
Ne Mandrake hat es diesmal vorgezogen, nicht voreilig fehlerhafte Pakete herauszubringen(genauso wie RedHat), wir sind momentan bei 3.1.0-15mdk bei kdebase und müssen immer noch Patches vom CVS einfließen lassen, weil einfach zuviele Fehler da waren. Im Mandrakeclub gibts die Pakete ja schon länger und bei mir konnte man sich die KDE Pakete schon vor über einer Woche herunterladen, aber das war eher als Test gedacht.
Ich denke aber, dass man bis nächster Woche auch mit Paketen auf den offiziellen Mirrorn rechnen kann, die diesmal eine ordentliche Qualität haben und getestet wurden, nicht wie bisher.
Übrigends Texstars Pakete sind nicht für ne andere Distribution, sondern er markiert seine Pakete nur mit tex statt mdk, damit man sie unterscheiden kann, sie sind aber auf einer standard 9.0 kompiliert, so wie es meine Athlon optimierten sets sind. Wobei er aber scheinbar ein wenig nachhinkt und noch die ersten kdelibs und kdebase Pakete hat, deswegen momentan nicht zu empfehlen wegen einiger Fehler, leider ist mein Mirror immer noch total überlaufen, da sehr viele Leute auf athlon Pakete stehen, drum Poste ich den hier auch nicht, da es keinen Sinn macht evtl. wenn sich die Sache beruhigt.
Soweit ich weiß verhält sich die Sache bei Software wie bei Music-CD's. Einmal ausgepackt ist jeglicher Umtausch ausgeschlossen. Demzufolge gibts da keine rechtliche Handhabe. Außerdem stehen ja bei Mandrake nach einer gewissen Zeit eh ISO-Images der letzten Version im Netz, so dass man ohne größeren Aufwand updaten kann.
Juristisch nicht ganz richtig. Das CD-Auspacken lässt lediglich das Rückgaberecht nach Fernabsatzrecht (seit 2002 im BGB) erlischen. Nacherfüllung (also "Gewährleistung") ist davon nicht betroffen. Aber Gewährleistung bei Software ist sowieso so ne Sache
Ich denke die Linux Distributionen sollten weniger neue "große" Versionen herausbringen und dafür aber die alten besser über einen längeren Zeitraum supporten.
Microsoft liefert immerhin bis zu 5 Jahre Support. (das die Umsetzung davon nicht so wörtlich genommen wird lassen wir jetzt mal aus der Diskussion).
Ein Linux Distributor sollte aber IMHO ebenfalls diese Zeitspanne bieten, zumindest wenn es um Security Fix geht.
Wenn man pro Jahr nur eine große Version (also X.0) herausbringen würde, dann ist ein Support über 5 Jahre hinweg durchaus machbar.
Und damit die Distris immer noch Geld verdienen können, baut man weiterhin Minor Numbers welche ebenfalls verkauft werden. (also 1.x) Mit dem einzigen Unterschied, das diejenigen welche eine große Version gekauft haben, immer auf die allerletzte Minor Number updaten können. Und dies innerhalb der kleinen Versionen immer möglich ist. Das heißt von 9.0 zu 9.1 zu 9.2 etc.
Bsp: Wenn man sich z.b. die große Version 9.0 kauft, dann sollte man auf sämtliche kleinen Nachfolgeversionen updaten können. Dies wäre dann 9.1, 9.2, 9.3 etc.
Die letzte Minor Number gilt dabei immer als letzte Updateversion. Im großen und ganzen gibt es dann im Jahr so gesehen trotzdem immer nur eine einzige Version, nämlich die große 9.x wovon die neuste Minor Version gilt. Z.b. 9.3, wenn die 3 die letzte Minor Version war.
In einem Zeitraum von 5 Jahren währen das dann 5 verschiedene Versionen die ein Distributor gleichzeitig supporten müßte. 9.x, 10.x, 11.x, 12.x, 13.x
Wenn in diesem Falle 9.6 die neueste ist, dann muß man keinen Support für 9.2 leisten, weil 9.6 ja das eigentliche Update und der Support darstellt. D.h. der User updated einfach auf 9.6 und diese wird ja voll supported.
Leider scheint die Versionsnummernvergabe etwas halbwild zu sein. Wenn man wüßte nach welchen Kriterien entschieden wird, wann ein großer Versionsnummernsprung fällig wird, würde ich dies gutheißen. Bei der Mdk 9.0 vermute ich das der GCC und Apache dies rechtfertigen, aber ob das zutrifft ist auch der Mandrake Homepage nicht schlüssig zu entnehmen.
Und ich habe mich vor einem Jahr überzeugen lassen, Mandrake auf unserem WH Server zu packen. Das habe ich nun davon... na dann halt Debian! Das hat ja eh schon meinen alten Desktop ersetzt :-)
bis denn,
Martin
Eine Distribution muß ihre Kräfte auf ein ziel richten und darf sie nicht auf alte Zöpfe verschwenden. Besonders bei kommerziellen Distributionen kann das sonst zu einen Debakel führen.
Grüße
Sturmkind
MfG
phil
Zusätzlich gibt es noch ein Programm namens MandrakeUpdate, das automatisch nach Sicherheitsupdates sucht und sie einspielt. Wenn man das mit cron automatisiert, ist das System nahezu kontinuierlich auf dem aktuellen Stand (zumindest was Patches angeht).
RedHat User nehmen es schon vermehrt her, da gibts auch einige Mirrors für Pakete und es funktioniert auch recht gut.
Freshrpms setzt auch auf apt-get für ihre RedHat Pakete. Aber urpmi ist eindeutig leistungsfähiger und handelt die dependencies besser, das letzte mal, als ich mir KDE bei ner RedHat 8.0 von der Rawhide installieren wollte ging das voll daneben, danach musste ich mit der Rettungsdiskette, zuerst wieder das RPM system fixen, denn das hat es auf Grund dependencies deinstalliert und dann ging nix mehr.
URPMI ist meiner Meinung nach eins der leistungsfähigsten Paketmanagementtools die es gibt, das einzige was Probleme bereiten kann ist, das in den Paketen die dependencies falsch gesetzt wurden, das System ansich ist zu 99,9% perfekt nur der Paketersteller ist das Problem, der einfach mal was vergisst, oder die dependencies nicht updated.
Also da Debian nicht kommerziell ist, finde ich das gerade den großen Vorteil, dass man etwas länger auf neue Releases warten muss. Für einen Server ist sowas optimal (stable), für den Desktop kann man auch die unstable nehmen.
bis denn,
Martin
Ich für meinen Teil warte zumindest immer noch bis die Pakete kommen, ansonsten werde ich mich wohl dran machen selber aus den Sourcen das neue KDE zu installieren.
. . . sollte doch die 3.1 rc5 von Mandrake-Cooker nehemen, die läuft bei mir (Mdk 9) tadellos.
Beim Insrtallieren sollten einige Paketabhängigkeiten ignoriert werden - besser ist die alten KDE-Pakete komplett von der Platte zu putzen, bevor man die neuen einspielt.
Einziger Fehler war, dass ich eine alte XF86Config reaktivieren mußte, aber daran kann auch der nvidia-Treiber schuld sein. Hab ich noch nicht komplett aufgeklärt.
Das geht immer noch schneller als Neukompilieren, eine vorhandener MC erleichtert die Aktion.
So long
TuX.
Gruß,
Thorsten
Aber wenn's bei dir anständig läuft...
MfG
Steffen
Ich denke aber, dass man bis nächster Woche auch mit Paketen auf den offiziellen Mirrorn rechnen kann, die diesmal eine ordentliche Qualität haben und getestet wurden, nicht wie bisher.
Übrigends Texstars Pakete sind nicht für ne andere Distribution, sondern er markiert seine Pakete nur mit tex statt mdk, damit man sie unterscheiden kann, sie sind aber auf einer standard 9.0 kompiliert, so wie es meine Athlon optimierten sets sind. Wobei er aber scheinbar ein wenig nachhinkt und noch die ersten kdelibs und kdebase Pakete hat, deswegen momentan nicht zu empfehlen wegen einiger Fehler, leider ist mein Mirror immer noch total überlaufen, da sehr viele Leute auf athlon Pakete stehen, drum Poste ich den hier auch nicht, da es keinen Sinn macht evtl. wenn sich die Sache beruhigt.
Schlaft schön
TuX.
Microsoft liefert immerhin bis zu 5 Jahre Support.
(das die Umsetzung davon nicht so wörtlich genommen wird lassen wir jetzt mal
aus der Diskussion).
Ein Linux Distributor sollte aber IMHO ebenfalls diese Zeitspanne bieten,
zumindest wenn es um Security Fix geht.
Wenn man pro Jahr nur eine große Version (also X.0) herausbringen würde,
dann ist ein Support über 5 Jahre hinweg durchaus machbar.
Und damit die Distris immer noch Geld verdienen können,
baut man weiterhin Minor Numbers welche ebenfalls verkauft werden. (also 1.x)
Mit dem einzigen Unterschied, das diejenigen welche eine große Version gekauft
haben, immer auf die allerletzte Minor Number updaten können.
Und dies innerhalb der kleinen Versionen immer möglich ist.
Das heißt von 9.0 zu 9.1 zu 9.2 etc.
Bsp:
Wenn man sich z.b. die große Version 9.0 kauft,
dann sollte man auf sämtliche kleinen Nachfolgeversionen updaten können.
Dies wäre dann 9.1, 9.2, 9.3 etc.
Die letzte Minor Number gilt dabei immer als letzte Updateversion.
Im großen und ganzen gibt es dann im Jahr so gesehen trotzdem
immer nur eine einzige Version, nämlich die große 9.x wovon die neuste Minor Version
gilt.
Z.b. 9.3, wenn die 3 die letzte Minor Version war.
In einem Zeitraum von 5 Jahren währen das dann 5 verschiedene Versionen die ein Distributor gleichzeitig supporten müßte.
9.x, 10.x, 11.x, 12.x, 13.x
Wenn in diesem Falle 9.6 die neueste ist, dann muß man keinen Support für
9.2 leisten, weil 9.6 ja das eigentliche Update und der Support darstellt.
D.h. der User updated einfach auf 9.6 und diese wird ja voll supported.
Good Night
TuX.