Also ich hatte weder bei Ubuntu noch Debian Probleme mit den Upgrades auf ein neues Release an sich. Und die Probleme die ich hatte (geändertes Format des Konfigfiles) hätte ich auch bei einem Rolling release gehabt.
ich kenne Leute, die nutzen seit Jahren Ubuntu und machen nur LTS Updates. (also alle 2 Jahre) natürlich zu den normalen Updates.
Die Systeme laufen auf den ersten Blick ganz gut, aber sobald ich "unter die Haube" schaue ist alles verhunzt. Mergefehler, die sich mit jedem Update immer mehr verschlimmern. Selbst einfachste Packetupdates sorgen dafür das irgendwelche Treiber nichtmehr geladen werden (machmal GFX, manchmal WLAN)...schau ich in die modprobe Blacklist, ist diese komplett kaputtgemerged. Jede Paketinstallation schmeist irgendwelche Fehler. Fehler um Fehler. Schaut man in die grub Liste sind dort 30 Kernels drin und man muss genau wissen, welche läuft und welcher nicht.
Niemals Betriebsystemupdates(!=Paketupdates) machen! Aber da bin ich vl auch von der Windowswelt so geprägt ;) Ich kann einem OS einfahc nichtmehr "trauen" wenn es ein Update bekommen hat.
selber bin ich ein Fan von RR...nutze Arch und ist Hammer. Auch mergen tu ich per Hand, ist zwar mehr Arbeit, dafür hab ich über Jahre hinweg ein sauberes System und kann sicher sein, dass das Update sauber funktioniert hat (ich merg ja selber und kontrollier alles)
aber ja, ist beeindruckend, in meinem Freundeskreis wird überwiegend Linux benutzt und da ist kein ITler dabei ;) "Ist doch Linux, da geht doch bestimmt einfach so alles" auf den ersten Blick ist das auch so, nur wenn mal wieder was schief geht muss ich ran
Ein RR für Ubuntu würde mir viel Supportaufwand sparen
Als ich noch Ubuntu benutzte hatte ich mit Release-Upgrades keine Probleme. Wurde eine Konfig geändert, an der ich geschraubt hatte, konnte ich mir die Änderungen anzeigen lassen und entscheiden ob ich die alte Version behalten, die neue verwenden oder mergen will. Ich habe mich im Normalfall für die neue entschieden. War es eine config mit wichtigen Anpassungen habe ich hinterher die Anpassungen aus dem Backup der alten config in die neue übertragen. Damit hatte ich überhaupt keine Probleme.
Ubuntu hat sich damit nicht von dem Verhalten unterschieden, wie ich es auch unter Debian testing/sid habe.
Komisch ... ich hab schon so viele dist-upgrades bei Debian durchgezogen ... meine Server von Lenny nach Squeeze ... und jetzt von Squeeze nach Wheezy .... da ist noch nie etwas kaputt gegangen. Sogar auf den Desktop-Systeme laeuft alles super
Hatte bisher wenig Probleme mit Upgrades. Oft arbeitenden sie sogar in ungewöhnlichen Situationen reibungslos. So betrieb ich eine zeitlang OSS4 anstatt PulseAudio/Alsa. Trotzdem gab es beim Upgrade keine Probleme. Eine Ubuntu Installation von mir erlebte 6 Upgrades bis ein HDD tot das System zerstörte.
Von Schnappsidee am Mi, 23. Januar 2013 um 15:26 #
> kein staendiges upgrade auf die neuste Version ... kein staendiges Daten uebertragen
Irgendwie hat du den Artikel nicht verstanden.
Ein Rolling Release bedeutet, dass du jede Woche neue Updates ziehen mußt, damit dein installiertes System nicht völlig den Anschluss an das System verliert, welches mit einem aktuellen Repo installierbar wäre.
Das hat also zur Folge, das du nach 2-3 Monaten nicht mehr ohne Probleme zu bekommen Updaten kannst, wenn du diese wöchentlichen Updates vergessen oder nicht durchgeführt hast.
Ich finde diese Idee also gar nicht gut, allerdings hatte ich eh vor, mich von Ubuntu zu verabschieden.
Keine Sorge. Debian macht das mit dem RollingRelease schon etwas besser als du beschreibst. Egal, ob das letzte Update Tage, Wochen oder Monate her war, habe ich bisher immer gut updaten können. Ubuntu wird da auch einen Weg finden.
So wie ich das verstehe soll ja die LTS Version erhalten bleiben und lediglich die Versionen dazwischen sollen Rolling Release werden.
Das wäre dann so ähnlich wie bei Debian: Eine stabile Version (in diesem Fall unterstützt über 5 Jahre), und ein Entwicklungszweig (testing) und das kann ich eigentlich nur befürworten!
Schon klar. Ein bisschen geht aber dann das Alleinstellungsmerkmal von Ubuntu verloren.
Obwohl... eigentlich liegt da ja auch eine Menge Potenzial drin: SID + Ubuntu / Unity würde ja Ubuntu wieder 100% kompatibel zu Debian machen. Theoretisch. Hm... darauf wird's aber wohl nicht hinauslaufen, schätze ich.
Wobei ein Merkmal bei Ubuntu (neben Unity und PPAs) ja die LTS Versionen sind. Gibt es zwar auch von anderen Größen (SUSE, Red Hat), allerdings nicht mit DEB Paketformat und zumindest das geht ja nicht verloren (ebenso gehen auch Unity und die PPAs nicht verloren).
Von Schnappsidee am Mi, 23. Januar 2013 um 15:30 #
Ich gebe dir völlig recht.
Ich habe in der Vergangenheit die alle 6 Monate erscheinenden Ubuntu Releases sehr geschätzt und zum Großteil auch genutzt, ein RR moving Target wie Debian Testing wollte ich nie haben.
Ich kann mich meinen Vorrednern nur anschließen, die LTS Version (wie bisher) für den Produktiven Einsatz und privat kann ich mir ja dann das RR gönnen, um auf dem aktuellen Stand zu bleiben.
Ich verstehe die Begeisterung rund um "rolling releases" nicht so ganz.
Weiter oben waren ja ein paar sehr positive Kommentare zu lesen:
kein staendiges upgrade auf die neuste Version ... kein staendiges Daten uebertragen bzw. Die Systeme laufen auf den ersten Blick ganz gut, aber sobald ich "unter die Haube" schaue ist alles verhunzt. Mergefehler, die sich mit jedem Update immer mehr verschlimmern.
Ich verstehe jetzt aber nicht, inwieweit "rolling releases" hier irgendwie helfen. Rein prinzipiell machen doch "rolling releases" alles nur noch komplizierter...
Mal im Detail: Wenn derzeit das System nach diversen Updates kaputt ist, weil einige Migrationsskripte kaputt waren, passiert das doch genauso bei einem RR-Modell. Eventuell könnte das Argument sein, dass Distro-Upgrades schlechter getestet werden als normale Paketupgrades und dabei dann mehr kaputt geht.
Das fände ich aber ein schwaches Argument, weil dann nicht am eigentlichen Problem gearbeitet wird und zweitens bei sinnvollen Distributionen die Pakete-Skripte/Upgrades in den verschiedenen Distro-Versionen doch aufeinander aufbauen sollten (d.h. F18 hat 1.0, gleichzeitig wird in rawhide dann 1.0.1, 1.1, ... eingepflegt). D.h. im Entwicklungsbranch sind doch die Migrationen bereits getestet, wenn der User dann das Distro-Upgrade macht.
Andererseits ist es auch für die RR-Paketierer nicht wirklich einfacher, zumindest wenn man nicht davon ausgeht, dass ein User wirklich jedes Update auch installiert. Viele Nutzer spielen ja nur alle 3-4 Monate überhaupt Sicherheitsupdates ein. Folglich müssen die Paket-Skripte auch damit klarkommen, dass jemand von 1.0 -> 1.4 direkt aktualisiert anstatt 1.1, 1.2, 1.3 in der Zwischenzeit einzuspielen.
Bei einem echten "Upgrade" hat man da noch mehr Chancen, indem man die User dazu bringt, erst mal die neuesten Updates der alten Distro einzuspielen, somit hat man tendenziell einen besser definierten Stand.
Als normaler Nutzer muss ich bei RR aber jederzeit mit geänderten Konfig-Files oder größeren Änderungen (bsp UsrMove) rechnen, anstatt nur bei einem Distro-Upgrade. Gleichzeitig hat ein Upgrade-Tool doch viel mehr Möglichkeiten, aufwändig die Umgebung abzusuchen/zu verändern, ohne in das normale "Paket-Update-Skript" gepresst zu werden.
Gleichzeitig schätze ich als normaler Nutzer auch die Möglichkeit, noch eine Weile bei alter Software zu bleiben: Zum Beispiel habe ich eine Fedora-Version übersprungen, weil ich bei Gnome3 lieber etwas warten wollte.
Einzig für die Distro-Entwickler sehe ich z.T. Vorteile, weil die eben einfach weniger Versionen parallel pflegen müssen.
Mir erschließt sich also die Begeisterung für RR nicht so ganz. Wer wirklich immer aktuell sein will, kann doch rawhide o.ä. verwenden. Das ist doch dann aber nur eine ganz kleine Nutzergruppe...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jan 2013 um 12:59.
Manchmal ist es eben doch ein Unterschied (gerade im Punkt "Kompatibilität"), wenn man von Version 3.5 auf Version 3.6 oder eben von Version 2.5 auf Version 3.6 springen muss. Ich denke das hat einfach den Vorteil, dass man stetig auf dem Laufenden mit den Anwendungen ist und so nicht immer unbedingt das Update von einer Version auf die nächste Version fürchten muss.
Wenn z.B. ein Konfig-Format geändert wird, muss das aktualisiert werden. Egal ob ich von 2.5 -> 3.6 springe oder von 2.9 -> 3.0. Da sehe ich keinen Vorteil.
Es könnte höchstens sein, dass das Upstream-Projekt seine Migrationen nicht im Griff hat (falls z.B. 3.5->3.6 auch noch mal eine benötigt), so dass eben 2.5 -> 3.6 dann schief geht. Das sind dann doch aber eher Defizite des Upstream-Projekts. Zudem ist man bei RR davor ja auch nicht gefeit: Man Anwender aktualisieren ja auch nur alle Jubeljahre.
Das ganze Problem erschließt sich aber nicht mehr, wenn ich ja weiterhin LTS mit Upgrades anbiete und ansonsten meinen RR-Zweig fahre. Diejenigen, die stabile Pakete wollen, bleiben auf ihrem gepflegten Langzeitrelease und alle anderen, welche Fokus auf aktuellere Anwendungen und neue Funktionen legen, wenden sich eben dem RR zu. Und ich finde es auch für die Community besser, wenn es keine Kurzzeitveröffentlichungen mehr gibt, denn somit muss weniger Support geleistet werden und gerade der ganze Migrationsrummel ist mit immens viel Arbeit verbunden.
upgrade von 12.04 auf 12.10 dauert schon über 3 Stunden, so etwas jedes halbe Jahr, nein danke, nen Roling Release würde da sicher viel schneller ablaufen, weil ja bei jedem update wesntlich weniger bearbeitet werden muss
beim 6 Monatszyklus geht eben alle 6 Monate viel schief und es geht erstmal garnichts mehr. beim 1 Tageszyklus geht nur einmal die Woche was kaputt und man weiß in der regel genau was kaputt ist.
Tut man das? Mein Verdacht ist, dass das bei Enthusiasten und technisch sehr versierten Nutzern sein mag, aber für den "ich will doch einfach nur arbeiten" Menschen eher nicht.
Persönliches Beispiel: Ich schalte morgens meinen Rechner an, um dann damit Geld zu verdienen. Jede Minute, die ich ggf. mit irgendwelchen Update-Fehlern zu kämpfen habe, kostet Geld.
Ich kann aber relativ einfach alle 6 Monate Zeit einplanen, um mein System zu aktualisieren und mir Zeit zu nehmen, die Release Notes durchzusehen. Im Zweifelsfall klappt dann auch ein Downgrade: Festplatten-Image und fertig.
Aber danke für die Argumente. Mein persönlicher Schluss ist, dass RR tatsächlich nur eine Frage der persönlichen Präferenzen sind und keine echten technischen Vorteile bieten.
Ich vermute jetzt, Ubuntu will seine internen Kosten senken, ohne das geplante Business-Modell (Service-Verträge für LTS) zu sehr zu gefährden.
Upgrade von 12.10 nach 13.04 dauerte heute ganze 40 Minuten. Das ist bei mir Durchschnitt. Allerdings gab es in all den Jahren auch Ausreißer. 12.04 auf 12.10 ging z.B. völlig daneben und nur eine Neuinstallation konnte das Ding retten.
Die Home-Verzeichnisse haben aber *immer* "gepasst". Soweit zur Datensicherheit.
Bei Config-Dateien hatte ich nur Probleme mit Scannern.
Von Schnappsidee am Mi, 23. Januar 2013 um 15:49 #
Diejenigen, die stabile Pakete wollen, bleiben auf ihrem gepflegten Langzeitrelease und alle anderen, welche Fokus auf aktuellere Anwendungen und neue Funktionen legen, wenden sich eben dem RR zu.
Ein RR ist kein Ersatzt für die 6 monatig erscheinenden "stabilen" Releases.
Ich habe die LTS nur selten genutzt, weil ich oftmals neue Treiber oder Software benötigte, die ich in den 6 monatig erschienenen Releases gefunden habe, allerdings wollte ich auch nie das neuste vom neusten haben (Gnome 3 habe ich z.B. vermieden, so lange es geht), daher habe ich von den 6 monatig erscheinenden Releases sehr profitiert.
11.04 war z.B. das letzte Ubuntu mit Gnome 2, aber es war kein LTS und bot trotzdem wichtige Treiber für neue HW, die es im 1 Jahr älteren 10.4 LTS nicht gab. Und das fand ich gut, denn ich konnte die 11.04 bis Ende Oktober 2012 nutzen.
Jetzt mit einer RR Veröffentlichungspolitik wird das nicht mehr funktionieren.
Dann werde ich entweder immer ein uraltes LTS haben, was besonders nervt, wenn das LTS so langsam auf die 2 Jahre zu geht, also schon über 1 Jahr alt ist oder ich muss auf ein Moving Target setzen bei dem immer etwas schief laufen kann oder Software und Schnappsideen (Gnome 3) reinkommen, die ich nicht haben will. Es ist auch nicht so, dass man ständig Zeit hätte, sich für Alternativen umzusehen, wenn mal eine Schnappsidee Software in die Distri wandert und die alte gute Software ohne Ersatz ersetzt.
Um den richtigen Ersatzdesktop für Gnome 3 zu finden habe ich mir z.B. sehr viel Zeit nehmen müssen. Auf einem produktivsystem kann ich nicht einfach mal auf ein anderes Desktop Environment wechseln, nur weil es technisch geht. Denn darunter leidet die Produktivität. Daher muss ein Desktop Environment erst einmal ausgelotet werden um die Grenzen, Nachteile und Vorteile zu finden und die kann man dann auch später, wenn man die Schwächen kennt (z.b. habe ich in XFCE ein paar entdeckt) umschiffen. So etwas kostet aber Zeit und solche Probleme kann auch auf andere Software zutreffen.
Erst letztens wurde Evolution aus dem offiziellen Ubuntu Repo entfernt und durch Thunderbird ersetzt, aber das nicht mehr offiziell supportete Evolution Paket in der neuen Ubuntuversion hat enorme Schwierigkeiten ein Backup der E-Mail Daten aus der vorherigen Evolutionversion einzuspielen, hier existiert ein Bug. Solche Regressionen führen also dazu, dass man auch zwangsläufig dazu gezwungen ist, sich nach alternativer Software umzusehen und dahin zu migrieren. So etwas kostet aber Zeit und in der Zwischenzeit möchte ich noch die alte SW einsetzen können, bei der das noch so funktioniert wie ich es gewohnt bin.
Deswegen sind RR schlecht und deswegen waren die 6 Monatigen Releases sinnvoll. Letztere waren ein guter Kompromiss zwischen einer alten LTS und einem viel zu schnell wandelnden RR.
Um mal zumindest diese "Treiber Argument" zu entkräften: Mit der Version 12.04.2 wird der Kernel aus 12.10 zurückportiert um alle aktuellen Treiber in 12.04 zu haben. So just BTW ...
Und ich nehme an, dass dann nur mit mit den LTS Releases Umbrüche stattfinden, alles zwischendrin eher nicht die Paradigmen umwirft. Aber das ist reine Spekulation und noch ist nichts entschieden. Wir werden sehen. Solltest du das Spiel nicht mehr mitspielen wollen, so kannst du dich ja auch für Suse oder Fedora entscheiden. Und ein schönes Gnome2 bekommst du noch immer mittels CentOS/RHEL und Derivaten.
- es kann immer ein updateskript kaputt sein (siehe ubuntu bug tracker...der ist nicht leer ) - es kann auch ein paket die eigene config kaputt machen und beim update dann nicht sauber mergen (akonadi?) (da kann ubuntu kaum was machen) - es kann immer mal was sein
beim 6 Monatszyklus geht eben alle 6 Monate viel schief und es geht erstmal garnichts mehr. beim 1 Tageszyklus geht nur einmal die Woche was kaputt und man weiß in der regel genau was kaputt ist.
beim 6 Monatszyklus kann man dann nicht einfach mal googlen "hier geht ja überhaupt nix mehr" aber wenn einmal die woche nur in einem Paket was kaputt geht dann kann man konkret nach etwas googlen. Am Beispiel von Arch kuck ich dann einfach auf die HP, da steht dann sowas wie "manual intervention required" oder im forum hat direkt einer das Problem gepostet und man findet sofort ne Lösung. Sowas kriegt sogar meine Oma hin.
jemand der von Linux keine Ahnung hat, kommt mit Arch besser zurecht als mit Ubuntu, wenns probleme gibt. (Natürlich unabhänging von der Erstinstallation...da ist Ubuntu natürlich bei weitem einfacher!)
ein RR hat nicht mehr oder weniger Fehler, sie kommen nur eben vereinzelter und überfordern einen nicht direkt. Beim RR kann man auch einfahc mal wieder ein alten Paket nutzen falls was nicht geht (Abhängigkeiten beachtet). Aber ein OS Update einspielen -> was geht kaputt -> OS Downgrade -> alten Stand erwarten? -> mitsicherheit nicht
Außerdem passieren manchmal so dinge wie, dass sich das default filesystem ändert (/tmp?). Da hat ein updateskript fast keine Chance. Manuell ist das zwar ein Problem aber machbar und besser als wenn Ubuntu einfach Pakete updated und dann sagt "passt alles" ... es läuft zwar alles weiterhin aber macht aufjedenfall nervös.
Ist wohl eine Glaubensfrage aber ich vertrau mir eben mehr beim updaten der einzellne Pakete als ubuntu
jemand der von Linux keine Ahnung hat, kommt mit Arch besser zurecht als mit Ubuntu, wenns probleme gibt. (Natürlich unabhänging von der Erstinstallation...da ist Ubuntu natürlich bei weitem einfacher!)
Full Ack.
Das schwierigste an Arch ist die Installation und die ist nicht schwer.
Mir war Arch zu stressig. Alle paar Tage gabs massig Updates, irgendwann blieb der Paketmanager wegen Inkonsistenzen in den Paketen ganz stehen, und wenn man Anwendungen nur selten benutzt, merkt man gar nicht, dass etwas kaputt ist (ich drucke z.B. sehr selten und merke erst, dass was kaputt ist, wenn ich dringend was ausdrucken möchte).
Wenn sich eine Bibliothek in einem höheren Release inkompatibel ändert, dann müßt man alle davon abhängigen Pakte neu übersetzen, um diese an die neue API anzupassen. Das ist die Stärke von Distributionen wie Gentoo, weil das dort automatisch möglich ist. Insofern frage ich mich schon immer, wie rolling releases bei rein binären System möglich sien soll. IMHO kann das nur sehr eingeschränkt funktionieren und ist nicht wirklich das, was man unter Rolling Release wirklich versteht.
Von ein mächtiger Pirat am Mi, 23. Januar 2013 um 14:04 #
Wenn sich eine Bibliothek in einem höheren Release inkompatibel ändert, dann müßt man alle davon abhängigen Pakte neu übersetzen, um diese an die neue API anzupassen.
Ja, bei Arch Linux wird das so gemacht. Bei Inkompatibilität zur neuen Library fliegt die Anwendung raus.
IMHO kann das nur sehr eingeschränkt funktionieren und ist nicht wirklich das, was man unter Rolling Release wirklich versteht.
Arch Linux funktioniert erstaunlich gut und stabil. Allerdings hat Arch nicht ganz so viel Software im Repository und die täglichen Updates sind relativ groß. Des weiteren ist Arch keine reine Binary-Distribution. Für Anwendungen, die nicht im Repository vorrätig sind, gibt es das AUR (Arch User Repository), dessen Software manuell erstellt werden muss.
Ubuntu könnte/müsste möglicher Weise ein paar Dinge anders machen um reine Binary-Repositories anbieten zu können und nach Bibliotheks-Updates keine Software ausmustern zu müssen.
So könnten beispielsweise mehrere Versionen einer Bibliothek installiert werden. Dazu müsste man ein sauberes Versionsschema ausarbeiten. Auch das PPA-System könnten geschickt erweitert und eingesetzt werden. u.v.m.
Ein Rolling Releas mit so breitem Softwareangebot wie Ubuntu ist durchaus eine Herausforderung.
Technisch sehe ich nicht wirklich das Problem. Rolling Release funktioniert mit Debian Sid oder entsprechenden Distros mit wesentlich mehr Paketen als bei Ubuntu ja auch.
Und das aus gutem Grund. So oft wie bei Debian SID die Paketabhängigkeiten kaputt sind (Was ja dem Status von SID geschuldet ist), könnte man es auch nicht veröffentlichen.
Von Schnappsidee am Mi, 23. Januar 2013 um 16:00 #
Bei Inkompatibilität zur neuen Library fliegt die Anwendung raus.
Na super, und da nicht jede Software gleichermaßen von den Entwicklern gewartet wird, muss man sehr lange verzichten, bis eine für einen wichtige Nischensoftware einen Bugfix erhalten hat, so daß diese endlich mit der neuen Lib Version funktioniert.
Und es versteht sich natürlich von selbst, das Canonical sich kaum um die Nischensoftware kümmern wird, auch dann nicht, wenn Canonical durch ein RR mehr Paketmaintainerkapazität freibekommt.
Denn Paketmaintainer sind noch lange keine guten Coder, die den Quellcode jeder Nischensoftware in und auswendig kennen.
und die täglichen Updates sind relativ groß.
Das wundert mich nicht, wenn eine Lib upgedaded werden muss, zu der ein dutzend darauf aufbauender SW Anwendungen nicht mehr binärkompatibel sind, dann müssen die natürlich auch upgedaded werden und schon hat man ein Update, das fast schon so viele MB Downloaden muss, wie bei einem gewöhnlichen 6 monatigen Dist Upgrade.
So könnten beispielsweise mehrere Versionen einer Bibliothek installiert werden. Dazu müsste man ein sauberes Versionsschema ausarbeiten.
Windows läßt Grüßen. Dort werden auch dutzende DLL Versionen vorrätig gehalten, um kompatibel zu alter Software zu bleiben.
Wenn das in Ubuntu eingeführt wird, dann ist das bald Geschichte, dass eine kleine 5-20 GB Partition für /usr genügt, dann wird man mit 50 GB und mehr rechnen müssen.
Die Startzeiten der einzelnen Anwendungen werden sich ebenfalls verschlechtern, wenn jede Anwendung eine andere Lib Version in den Speicher laden muss.
Tja und Arbeitsspeicher wird man auch mehr brauchen.
Von Herman Toothrot am Mi, 23. Januar 2013 um 16:34 #
Na super, und da nicht jede Software gleichermaßen von den Entwicklern gewartet wird,muss man sehr lange verzichten, bis eine für einen wichtige Nischensoftware einen Bugfix erhalten hat, so daß diese endlich mit der neuen Lib Version funktioniert.
Windows läßt Grüßen. Dort werden auch dutzende DLL Versionen vorrätig gehalten, um kompatibel zu alter Software zu bleiben.
Wenn das in Ubuntu eingeführt wird, dann ist das bald Geschichte, dass eine kleine 5-20 GB Partition für /usr genügt, dann wird man mit 50 GB und mehr rechnen müssen.
Deine beiden Meinungen widersprechen sich.
Entweder es ist eine Cutting-Edge-Distribution wie Arch, oder sie hält eben verschiedene Versionen einer Bibliothek bereit, wie es bei Ubuntu, Debian oder auch Gentoo der Fall ist.
Gentoo braucht nicht verschiedene Versionen einer Bibliothek vorzuhalten um Kompatiblität zu den Anwendung zu gewährleisten. Gentoo compiliert die Anwendung einfach neu, wenn eine Bibliotheksupgrade dieses erfordert. Bibliotheken sind bei Gentoo zwar in verschiedenen Versionen verfügbar, aber nicht aus kompatitbilitätsgründen. Das kann eine binäre Distribution prinzipell nicht leisten - auch arch nicht.
Gentoo braucht nicht verschiedene Versionen einer Bibliothek vorzuhalten um Kompatiblität zu den Anwendung zu gewährleisten. Gentoo compiliert die Anwendung einfach neu, wenn eine Bibliotheksupgrade dieses erfordert
Das selbe kann man mit einer Binär Distribution machen, nur dass dort das neu Kompilieren Serverseitig geschieht. Das kann dann natürlich große Updates zur Folge haben. Genau so wie es bei Gentoo passieren kann, dass dem Upgrade eine einzelnen Bibliothek das halbe System neu kompiliert werden muss.
Bei Gentoo muss man noch gar nicht mal gleich alles neu Kompilieren, was von jenen Libs abhängig ist. Mit Portage 2.2 gibt es bei Gentoo durch die "preserved libs" auch die Möglichkeit, die alten Libs (nur die .so - Dateien) weiter im System zu behalten, so lange sie von irgend einer Anwendung benötigt werden. Installiert/Kompiliert man neue Programme, so verwenden diese die neuen Libs, während die alten (nicht neu kompilierten) Programme weiterhin die alten Libs verwenden.
Damit die alten Libs nicht vergessen werden, bekommt man zu jedem emerge am ende eine kurze Info, dass im System noch alte Libs bestehen. Und mit dem Set "@preserved-rebuild" kann man dann all jene Anwendungen, die noch von den alten Libs abhängig sind, einfach neu kompilieren lassen. Und zwar dann, wenn es einem passt. Und so lange funktionieren alle Anwendungen weiterhin wie gewohnt. Sowie eine alte Lib von keiner Anwendung mehr benötigt wird, löscht portage sie automatisch.
Also ich finde diese Funktion ausgesprochen praktisch. Portage 2.2 ist zwar (u.a.) wegen den preserved libs noch maskiert, aber ich hatte in den letzten 2 Jahren damit keinerlei Probleme.
Vor einem halben Jahr hatte ich noch ein Notebook mit einem DualCore 2,53GHz und 8GB RAM. Die Platte hat laut hdparm etwa 80MB/s geschafft. Auf diesem Rechner gingen ca. 1h pro Woche für die Updates drauf. Für die größeren KDE-Updates gingen monatlich jeweils ca. 2,5-3h drauf. Da ich die portrage_niceness und die cgroups (sowohl CPU als auch I/O) passend eingerichtet hatte, konnte ich mit dem Rechner nebenher gut Arbeiten.
Da mir aber nach 3,5 Jahren täglicher Nutzung (sowohl im Büro als auch auf der Arbeit, aber privat gekauft) die Hintergrundbeleuchtung kaputt gegangen ist, hat mir mein Arbeitgeber ein neues zur Verfügung gestellt (frei nach Wahl). Nun ist es ein i7 3820QM (QuadCore) mit 2.7GHz, 24GB RAM und einer dicken SSD. So gehen die Updates natürlich wesentlich schneller. Pro Woche brauche ich im Schnitt etwa 20 Minuten, und KDE ist auch nach etwa 1h15m durch. Und dank der SSD kann das neben der Arbeit ganz problemlos laufen.
Bei den wöchentlichen Updates sind aber auch einige Live-ebuilds dabei, wie z.B. die neue Messenger-Suite von KDE (KDE-Telepathy), oder seit neustem auch die neue Bildschirm-Verwaltung (Screen management got magic). Ist mit Gentoo ganz praktisch, da man so die neuste Test-Version (aus SVN, GIT...) zum Testen haben kann, diese aber ebenso wie alle anderen Anwendungen auch über den Paketmanager verwaltet werden. So kann ich bequem die Entwicklung mitverfolgen.
Meine Kollegen (mit Debian, K/Ubuntu, Mint, ...) fragen mich zwar auch dauernd, ob sich Gentoo überhaupt lohnt. Aber ich sehe Gentoo (nach nun ca. 11 Jahren) wie einen maßgeschneiderten Anzug an. Er ist zwar teurer (Einstieg und auch das Updaten dauern länger), ist dafür aber eben besser an mich angepasst, als ein Anzug von der Stange. Wenn mir ansehen muss, was meine Kollegen als an Abhängigkeiten Installieren müssen, kommt mir das wie ein "zwicken im Schritt" vor.
Von Schnappsidee am Mi, 23. Januar 2013 um 22:25 #
Danke für deine Antwort.
Dafür sind dann wohl heute die modernern CPUs mit noch mehr Kernen notwendig, damit man Gentoo ein paar Minuten schneller kompilieren kann. Intel sollte für Gentoo Werbung machen, es könnte sich lohnen.
Der QuadCore, der viele Speicher, und die SSD sind in erster Linie deshalb Notwendig, da ich tagtäglich für die Entwicklung 2-3 Virtuelle Maschinen am laufen habe. Das macht das Arbeiten wesentlich angenehmer.
Von "nur sehr eingeschränkt&q am Mi, 23. Januar 2013 um 14:45 #
finde ich äußerst diplomatisch von Dir formuliert (Full ack von mir als Gentoo-User dazu).
Rolling Release scheint gerade in Mode zu kommen, bei den binären Distros. Selbst Debian denkt schon länger darüber nach: http://www.pro-linux.de/news/1/17013/debian-diskutiert-rolling-release-zweig.html Mehr Details zur möglichen Funktionsweise gibt's im Artikel unter dem Link "konkrete Vorschläge". Ob Cannonical wohl darauf aufsetzen möchte... - egal.
So richtig gut kann RR ohnehin nur auf einem Quell-basierenden System funktionieren, weil nur dort nach erfolgreicher Kompilation von upgedateten Paketen diese erneut, gegen die auf dem System tatsächlich vorhandenen oder upgedateten Libraries gelinkt werden, wodurch deren Abhängigkeiten wiederum erfüllt sind.
Deshalb kann bei Gentoo auch fast jedes Paket einzeln released werden und der User kann sehr einfach stable und unstable Pakete nach Herzenslust mischen.
Bei den Binären muss dagegen der Distributor irgendwie versuchen die Konsistenz sicherzustellen, was für sein Referenzsystem auf dem ja auch lokal kompiliert wird noch relativ einfach ist. Wie er das dann aber auf der User-Seite, mit den zum Download angebotenen binären Paketen, sicherstellen will, entzieht sich ja in weiten Teilen seiner Einflussnahme. Daher müssen sich die User in Genügsamkeit üben, um nicht die Konsistenz ihres Systems zu gefährden. Also bitte keine fremden Repositories einbinden ,nur um an aktuellere Pakte zu gelangen. Wenn's denn unbedingt sein muss, besser selber lokal hinzu kompilieren (merkt ihr was ;-), aber dann geht sowas längst nicht so einfach und komfortabel und update-persistent wie bei Gentoo.
Dort funktioniert RR von Anfang an, also schon seit 13 Jahren
Von Schnappsidee am Mi, 23. Januar 2013 um 16:56 #
Wenn's denn unbedingt sein muss, besser selber lokal hinzu kompilieren (merkt ihr was ;-), aber dann geht sowas längst nicht so einfach und komfortabel und update-persistent wie bei Gentoo.
Dort funktioniert RR von Anfang an, also schon seit 13 Jahren
Und wenn in Software Sicherheitslücken gefunden wurde, dann muss man erstmal Stundenlang, sofern viele andere Software von dieser SW mit der Lücke abhängig ist, das System neu compilieren, ehe man es gefahrfrei benutzen kann.
Dabei wollte man doch nur mal schnell die E-Mail checken, bevor der Bus kommt, den man unbedingt nehmen muss, weil man nach XY hin will.
Fazit: Freizeit kann man auch anders verschwenden.
Genau. Und wenn es von einer Anwendung ein neues Paket gibt, weil die alte Sicherheitslücken aufwies, muss man bei Binär-Distris noch einige Stunden warten bis die Pakete fertiggestellt wurden. So lange kann man es nicht gefahrenfrei benutzen. Bei Gentoo reicht in den meisten Fällen eine Kopie des ebuilds mit der entsprechenden Versionsnummer, wenn man es ganz eilig hat.
Dabei will ich aber nicht noch 8h auf den Maintainer warten, sondern die Software lieber in 1h wieder Benutzen können.
Klar, bei den Binär-Distris kann man sich auch die Mühe machen, und jene Pakete dann eigens kompilieren. Aber dazu muss man erst etliche -dev Pakete Installieren, und hat jene Versionen dann - wenn man kein eigenen Pakete daraus erstellt - noch nicht mal im Paketmanager verwaltet.
Fazit: Nicht alles an Gentoo ist Freizeitverschwendung.
Alles hat seine Vor- und Nachteile. Dem einen reicht ein Anzug von der Stange, der andere mag eher einen (teureren) maßgeschneiderten Anzug.
Von Schnappsidee am Mi, 23. Januar 2013 um 22:29 #
Das muss aber nicht immer zutreffen.
Es kann auch sein, das der Maintainer im Amerika sitzt und das Binärpaket am nächsten Morgen fertig hat.
Damit hat man keine Zeit verloren, denn bevor die Sicherheitslücke bekannt wurde, ist man schon schlafen gegangen und am nächsten Morgen zählt dann, wie lange das System braucht um die Lücke zu stopfen.
Das ist also eine Win Situation für ein binärpaketbasiertes System.
Deine Argumente lassen wirklich zu wünschen übrig.
Du schreibst etwas von "Das muss aber nicht immer zutreffen." und "Es kann auch sein...", und bewertest es gleich als WIN-Situation. Dass es eben auch NICHT zutreffen muss, und auch NICHT sein kann, gibst du ja selbst zu, lässt es aber nicht in deine Bewertung einfließen. So etwas kannst du dann ebenso auch eine LOSE-Situation nennen. Ganz zu schweigen davon, dass die Sicherheitslücken nicht nur an einem Abend bekannt gemacht werden.
Ich habe zwar auch eine Extrem-Situation genommen, dass man sich mit einer Source-basierten Distribution die Pakete schneller und leichter selbst zusammen bauen kann, als auf den Maintainer warten zu müssen. Aber dies war bewusst so gemacht, weil du die "Sicherheitslücke-schließen-da-ich-schnell-zum-Bus-muss" als die andere extreme Situation geschildert hast.
Wenn sich eine Bibliothek in einem höheren Release inkompatibel ändert, dann müßt man alle davon abhängigen Pakte neu übersetzen, um diese an die neue API anzupassen.
Nur wenn die Bibliothek bei diesen Schritt nicht korrekt versioniert wurde. Die meisten Bibliothekshersteller tun das jedoch.
Der Systemlinker wird dann erst gar nicht versuchen für eine Anwendung, die für die alte ABI gebaut ist, eine neue Bibliothek zu verwenden, sondern wird weiterhin die entsprechende Version wählen
Eine rolling release für Fortgeschrittene oder Leute die es gerne aktuell mögen, und eine LTS für Normalverbraucher die einfach mit PC arbeiten möchten. Und die die jetzt meckern bitte Klappe halten und andere Distri suchen.
Hatte vorher sid und aptosid. Das wurde mir aber zu nervenaufreibend, weil ja doch ab und zu mal was wackelte und ich Schimpfe von der Frau oder im Büro dem Admin befürchtete. Meist lief es zwar ganz gut und war interessant, aber ich wollte nun in etwas ruhigere Gefilde kommen. Daher habe ich erst vor kurzem auf Kubuntu gewechselt.
Habe jetzt so ein bisschen gemischte Gefühle bzgl RR in Ubuntu. Die LTS-Version dagegen ist mir dann wiederum nicht aktuell genug. Alle halbe Jahr neue Versionen (bspw. von KDE) ist eigentlich ziemlich gut.
Alle halbe Jahre eine neue Version rauszubringen fand ich schon Blödsinn. Ressourcenverschwendung, man kann Energie für Besseres aufwenden. Soweit ich weiß werden in LTS Versionen auch Programme wie Firefox usw. aktuell gehalten.
Von Schnappsidee am Mi, 23. Januar 2013 um 22:33 #
Nach reichlicher Überlegung könnte ich mit einem RR leben, wenn dafür die LTS Versionen einmal im jahr erscheinen und jeweils 5 Jahre wie bisher supported werden.
Zumindest die neueste LTS-Version Ubuntu 12.04 wird aber auch mit Major Updates (u.a. neuer Kernel, neues Xorg) versorgt werden. Demnächst steht ein ebensolches Update für Ubuntu 12.04 LTS an.
"This is the first time we have shipped a backported Hardware Enablement stack in a LTS release, comprised of a new kernel and graphics subsystem."
Mit "Stabilität" a la Debian oder RHEL hat das nichts zu tun, das erinnert eher an die Suse-Methode, die leider in SLES 11 SP1 ff. Einzug gehalten hat.
Das klingt auch etwas nach einem "LTS-Rolling Release", wenn man das Backporten von Ubuntu 12.10-Softwareversionen nach 12.04 LTS so nennen möchte. In Zukunft besteht dann der Unterschied zur heutigen Situation einfach darin, dass neben der LTS-Version keine Halbjahresdistribution mehr existieren wird. Gebackportet im Sinne des Integrierens neuer Softwareversionen in das ältere LTS-System wird dann aber weiterhin.
Von Schnappsidee am Do, 24. Januar 2013 um 07:17 #
Das neue Xorg wird den letzten NVidia 96.x Treiber für Geforce < = 4 Karten killen, den man vor 2-4 Wochen erst so mühsam in Ubuntu 12.04 LTS reingeflickt hat.
In Ubuntu 12.10 gibt es daher diesen Treiber erst gar nicht mehr im Repo, denn diese letzte 96.x Treiberversion von NVidia ist nicht mehr binärkompatibel zur veränderten API in der neuen XOrg Version.
"This is the first time we have shipped a backported Hardware Enablement stack in a LTS release, comprised of a new kernel and graphics subsystem."
Ja, ein neues Graphic Subsystem, das wird zum Problem führen. Siehe oben.
PS: Übrigens nouveau ist auf einer Geforce 4 zwar besser als gar nichts, aber wirklich zu gebrauchen ist so ein System nicht mehr. Selbst der VESA Treiber läuft stabiler ohne störende Grafikeffekte und ist auch nicht wesentlich langsamer als nouveau. Für Youtube Filmchen kann man nouveau definitiv vergessen. IMO war sogar bei Videos der alte nv Treiber schneller, auch wenn er keinen 3d Support bot.
Wer also kann, der tut sich selbst einen Gefallen wenn er so lange wie möglich bei den CS Treibern von NVidia bleibt, denn damit laufen die Geforce 4 Karten noch wie ne 1.
Insofern bin ich mal gespannt wie die das bei Ubuntu 12.04 machen werden. Zum einen wollen sie für andere neue Grafikhardware neue Xorg Versionen anbieten, zum anderen aber müssen sie die alte Xorg Version behalten, damit man noch die 96.x NVidia Treiber verwenden kann.
Ich tippe mal darauf, dass der Einfachheit halber der 96.x NVidia Treiber aus dem Repo genommen wird und der User dazu gewzungen wird auf Nouveau zu setzen. Das wäre die einfachste Lösung und entspricht auch den Weg, den Canonical bisher immer gegangen ist, wenn es bei alter HW Probleme gab. (früher flog z.B. die libglide Bibliothek aus dem offiziellen main Repo, obwohl die TDFX Treiber noch wunderbar liefen.)
Die Geforce4-Nutzer besitzen wohl aber keine kritische Größe mehr, auf die man noch allzu groß Rücksicht nehmen muss.
Ich habe eine NV17-Grafikkarte, die wird von Nouveau in openSUSE 11.4 gut unterstützt, in openSUSE 12.1 so einigermaßen. Demgegenüber erhalte ich mit meinem 2VGA-Onboard-Nv1f-Chip (~NV18) ohne Riesenherumgfrickel unter Nouveau noch nicht einmal ein Bild. Hier waren übrigens auch schon die Nvidiatreiber der 96er-Serie nicht mehr stabil benutzbar.
Nv läuft damit zwar noch, allerdings fliegt XAA aus den neuesten Xorg-Versionen heraus, wodurch nv sehr, sehr langsam werden wird.
D.h.: Es gibt nichts mehr außer Nouveau im freien Treiberbereich, was in 12.04.2 mit einer Geforce 4 funktionieren wird.
Was sind nun Deine Optionen?
Meine Vorschläge:
1. Die alten Geforce4-Karten gegen neuere, noch unterstützte Nvidia-Karten austauschen.
2. Gleich auf alte Radeons wechseln, der freie radeon-Treiber verfügt wenigstens neben EXA- über eine Basis-3D-Unterstützung, selbst noch im Zusammenspiel mit einer uralten Radeon 7500.
3. Du wechselst zu einem RHEL5- oder RHEL6-Klon, benutzt Debian Squeeze oder kehrst zu Ubuntu 10.04 zurück.
4. In Ubuntu 10.04 kannst Du den Support bis Anfang 2015 ausdehen, wenn, ja wenn Du Deine GUI selber flickst. Canonical liefert die Basis- ("Server"-) Unterstützung.
Lieber viele kleine Updates, die auch nur wenig Schaden anrichten, als alle zwei Jahre (oder auch nur alle 6 Monate) ein "fettes" Update, bei dem man sich sicher sein kann, daß hinterher tagelange Nacharbeiten notwendig sind.
Ich stelle mir das rolling gerade in der Infrastruktur unseres Unternehmen vor: Ein Unternehmen mit ca. 9000 PC's in mehreren Inlands- und Auslands- Filialen (auf jeden Kontinent), 5000 Anwender, viele eigene Anwendungen, die z.T. mit anderen Unternehmen der Branche geteilt werden und (unter Windows) ca. 15.000 Programme (inkl. plugins und Kleinkram). Und weil das Leben so spielt (z.B. Kostendruck), wacht der IT-Chef eines Morgens auf und will alles nach Linux umstellen. Und dann sage ich ihm, dass Ubuntu ganz toll ist, weil wir jeden Tag die aktuellste Distribution haben werden (weil rolling) und natürlich ist die source.list auf die internen Aktualisierungsserver angepaßt, aber weil wir viele Produktionen in Freiland Umgebung haben, werden die Laptops gnadenlos über VPN aktualisiert und die Leitungen nach Johannesburg, Moskau und Washington glühen, weil das rolling ja rüber muss. Mal sehen, wer die rechnung für die WAN Rechnungen dann sachlich-richtig zeichnet.... Ehrlich gesagt: Wir sind etwas gebrannte Kinder. Nach dem update auf 6.01 iPhone funktionierte die MDM Lösung nur noch eingeschränkt, dass Flash-update verbog die Rechte auf den Macromed Ordner und als Mozilla auf rolling umsattelte, bekamen unsere Entwickler schluckauf (Ergebnis: ESR Version). Und jetzt stellen wir uns die Probleme hunderfach vor und alles rolling. Kurz: In den Prospekten sieht das immer toll aus, aber ab einer gewissen Größenordung artet das in Arbeit aus. Ich dachte, Canonical wollte in den Geschäftskunden- Markt: Ich hoffe, die machen sich nicht nur über den rolling Server im Wohnzimmer Gedanken.
Richtig. Ich würde mir trotzdem dann so eine Art "freeze" Schalter auf den Clients wünschen, denn wenn ich die Tagespresse richtig in Erinnerung habe, plant Canonical ja auch z.B. sporadisch neuere Kernel- Versionen in eine laufende LTS Version einzupflegen. Damit werden aber wahrscheinlich auch andere Pakete ihr Recht auf Aktualisierung verlangen (Sprich: Paket-abhängigkeiten). ich bin (noch) Freund von einer konservativen Release- Politik.
Das waere super ...
kein staendiges upgrade auf die neuste Version ... kein staendiges Daten uebertragen
Also ich hatte weder bei Ubuntu noch Debian Probleme mit den Upgrades auf ein neues Release an sich. Und die Probleme die ich hatte (geändertes Format des Konfigfiles) hätte ich auch bei einem Rolling release gehabt.
ich kenne Leute, die nutzen seit Jahren Ubuntu und machen nur LTS Updates. (also alle 2 Jahre) natürlich zu den normalen Updates.
Die Systeme laufen auf den ersten Blick ganz gut, aber sobald ich "unter die Haube" schaue ist alles verhunzt. Mergefehler, die sich mit jedem Update immer mehr verschlimmern. Selbst einfachste Packetupdates sorgen dafür das irgendwelche Treiber nichtmehr geladen werden (machmal GFX, manchmal WLAN)...schau ich in die modprobe Blacklist, ist diese komplett kaputtgemerged.
Jede Paketinstallation schmeist irgendwelche Fehler. Fehler um Fehler. Schaut man in die grub Liste sind dort 30 Kernels drin und man muss genau wissen, welche läuft und welcher nicht.
Niemals Betriebsystemupdates(!=Paketupdates) machen! Aber da bin ich vl auch von der Windowswelt so geprägt ;)
Ich kann einem OS einfahc nichtmehr "trauen" wenn es ein Update bekommen hat.
selber bin ich ein Fan von RR...nutze Arch und ist Hammer. Auch mergen tu ich per Hand, ist zwar mehr Arbeit, dafür hab ich über Jahre hinweg ein sauberes System und kann sicher sein, dass das Update sauber funktioniert hat (ich merg ja selber und kontrollier alles)
aber ja, ist beeindruckend, in meinem Freundeskreis wird überwiegend Linux benutzt und da ist kein ITler dabei ;)
"Ist doch Linux, da geht doch bestimmt einfach so alles" auf den ersten Blick ist das auch so, nur wenn mal wieder was schief geht muss ich ran
Ein RR für Ubuntu würde mir viel Supportaufwand sparen
Als ich noch Ubuntu benutzte hatte ich mit Release-Upgrades keine Probleme.
Wurde eine Konfig geändert, an der ich geschraubt hatte, konnte ich mir die Änderungen anzeigen lassen und entscheiden ob ich die alte Version behalten, die neue verwenden oder mergen will.
Ich habe mich im Normalfall für die neue entschieden. War es eine config mit wichtigen Anpassungen habe ich hinterher die Anpassungen aus dem Backup der alten config in die neue übertragen.
Damit hatte ich überhaupt keine Probleme.
Ubuntu hat sich damit nicht von dem Verhalten unterschieden, wie ich es auch unter Debian testing/sid habe.
Ich hatte bisher weder bei Debian noch bei Ubuntu nach einem dist-upgrade ein funktionierendes System, und durfte neu installieren.
Komisch ... ich hab schon so viele dist-upgrades bei Debian durchgezogen ... meine Server von Lenny nach Squeeze ... und jetzt von Squeeze nach Wheezy .... da ist noch nie etwas kaputt gegangen.
Sogar auf den Desktop-Systeme laeuft alles super
Hier auch.
Von Debian Hamm über Woody (unstable, testing, stable und ab da nur noch stable) nach Squeeze. Kein Problem.
Hatte bisher wenig Probleme mit Upgrades. Oft arbeitenden sie sogar in ungewöhnlichen Situationen reibungslos. So betrieb ich eine zeitlang OSS4 anstatt PulseAudio/Alsa. Trotzdem gab es beim Upgrade keine Probleme.
Eine Ubuntu Installation von mir erlebte 6 Upgrades bis ein HDD tot das System zerstörte.
> kein staendiges upgrade auf die neuste Version ... kein staendiges Daten uebertragen
Irgendwie hat du den Artikel nicht verstanden.
Ein Rolling Release bedeutet, dass du jede Woche neue Updates ziehen mußt, damit dein installiertes System nicht völlig den Anschluss an das System verliert, welches mit einem aktuellen Repo installierbar wäre.
Das hat also zur Folge, das du nach 2-3 Monaten nicht mehr ohne Probleme zu bekommen Updaten kannst, wenn du diese wöchentlichen Updates vergessen oder nicht durchgeführt hast.
Ich finde diese Idee also gar nicht gut, allerdings hatte ich eh vor, mich von Ubuntu zu verabschieden.
Keine Sorge. Debian macht das mit dem RollingRelease schon etwas besser als du beschreibst. Egal, ob das letzte Update Tage, Wochen oder Monate her war, habe ich bisher immer gut updaten können. Ubuntu wird da auch einen Weg finden.
So wie ich das verstehe soll ja die LTS Version erhalten bleiben und lediglich die Versionen dazwischen sollen Rolling Release werden.
Das wäre dann so ähnlich wie bei Debian: Eine stabile Version (in diesem Fall unterstützt über 5 Jahre), und ein Entwicklungszweig (testing) und das kann ich eigentlich nur befürworten!
Und was hat man dann am Ende? Richtig, SID mit Unity. Ob das so eine prächtige Neuerung ist?
Neuerung != Veränderung
Im Übrigen ... gibt es in SID schon Unity? Ich glaube nicht, also besteht hier doch eine entsprechende Differenz!
Schon klar. Ein bisschen geht aber dann das Alleinstellungsmerkmal von Ubuntu verloren.
Obwohl... eigentlich liegt da ja auch eine Menge Potenzial drin: SID + Ubuntu / Unity würde ja Ubuntu wieder 100% kompatibel zu Debian machen. Theoretisch. Hm... darauf wird's aber wohl nicht hinauslaufen, schätze ich.
Wobei ein Merkmal bei Ubuntu (neben Unity und PPAs) ja die LTS Versionen sind. Gibt es zwar auch von anderen Größen (SUSE, Red Hat), allerdings nicht mit DEB Paketformat und zumindest das geht ja nicht verloren (ebenso gehen auch Unity und die PPAs nicht verloren).
Im Gegensatz zu rhel und sled bringt ubuntu LTS vor allem viel viel mehr Pakete.
DEB oder RPM ist wohl nur für wenige Nutzer ein Argument.
Ich gebe dir völlig recht.
Ich habe in der Vergangenheit die alle 6 Monate erscheinenden Ubuntu Releases sehr geschätzt und zum Großteil auch genutzt, ein RR moving Target wie Debian Testing wollte ich nie haben.
Ich kann mich meinen Vorrednern nur anschließen, die LTS Version (wie bisher) für den Produktiven Einsatz und privat kann ich mir ja dann das RR gönnen, um auf dem aktuellen Stand zu bleiben.
Ich verstehe die Begeisterung rund um "rolling releases" nicht so ganz.
Weiter oben waren ja ein paar sehr positive Kommentare zu lesen:
kein staendiges upgrade auf die neuste Version ... kein staendiges Daten uebertragen
bzw.
Die Systeme laufen auf den ersten Blick ganz gut, aber sobald ich "unter die Haube" schaue ist alles verhunzt. Mergefehler, die sich mit jedem Update immer mehr verschlimmern.
Ich verstehe jetzt aber nicht, inwieweit "rolling releases" hier irgendwie helfen. Rein prinzipiell machen doch "rolling releases" alles nur noch komplizierter...
Mal im Detail:
Wenn derzeit das System nach diversen Updates kaputt ist, weil einige Migrationsskripte kaputt waren, passiert das doch genauso bei einem RR-Modell. Eventuell könnte das Argument sein, dass Distro-Upgrades schlechter getestet werden als normale Paketupgrades und dabei dann mehr kaputt geht.
Das fände ich aber ein schwaches Argument, weil dann nicht am eigentlichen Problem gearbeitet wird und zweitens bei sinnvollen Distributionen die Pakete-Skripte/Upgrades in den verschiedenen Distro-Versionen doch aufeinander aufbauen sollten (d.h. F18 hat 1.0, gleichzeitig wird in rawhide dann 1.0.1, 1.1, ... eingepflegt). D.h. im Entwicklungsbranch sind doch die Migrationen bereits getestet, wenn der User dann das Distro-Upgrade macht.
Andererseits ist es auch für die RR-Paketierer nicht wirklich einfacher, zumindest wenn man nicht davon ausgeht, dass ein User wirklich jedes Update auch installiert. Viele Nutzer spielen ja nur alle 3-4 Monate überhaupt Sicherheitsupdates ein. Folglich müssen die Paket-Skripte auch damit klarkommen, dass jemand von 1.0 -> 1.4 direkt aktualisiert anstatt 1.1, 1.2, 1.3 in der Zwischenzeit einzuspielen.
Bei einem echten "Upgrade" hat man da noch mehr Chancen, indem man die User dazu bringt, erst mal die neuesten Updates der alten Distro einzuspielen, somit hat man tendenziell einen besser definierten Stand.
Als normaler Nutzer muss ich bei RR aber jederzeit mit geänderten Konfig-Files oder größeren Änderungen (bsp UsrMove) rechnen, anstatt nur bei einem Distro-Upgrade. Gleichzeitig hat ein Upgrade-Tool doch viel mehr Möglichkeiten, aufwändig die Umgebung abzusuchen/zu verändern, ohne in das normale "Paket-Update-Skript" gepresst zu werden.
Gleichzeitig schätze ich als normaler Nutzer auch die Möglichkeit, noch eine Weile bei alter Software zu bleiben: Zum Beispiel habe ich eine Fedora-Version übersprungen, weil ich bei Gnome3 lieber etwas warten wollte.
Einzig für die Distro-Entwickler sehe ich z.T. Vorteile, weil die eben einfach weniger Versionen parallel pflegen müssen.
Mir erschließt sich also die Begeisterung für RR nicht so ganz. Wer wirklich immer aktuell sein will, kann doch rawhide o.ä. verwenden. Das ist doch dann aber nur eine ganz kleine Nutzergruppe...
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 23. Jan 2013 um 12:59.Manchmal ist es eben doch ein Unterschied (gerade im Punkt "Kompatibilität"), wenn man von Version 3.5 auf Version 3.6 oder eben von Version 2.5 auf Version 3.6 springen muss. Ich denke das hat einfach den Vorteil, dass man stetig auf dem Laufenden mit den Anwendungen ist und so nicht immer unbedingt das Update von einer Version auf die nächste Version fürchten muss.
Wenn z.B. ein Konfig-Format geändert wird, muss das aktualisiert werden. Egal ob ich von 2.5 -> 3.6 springe oder von 2.9 -> 3.0. Da sehe ich keinen Vorteil.
Es könnte höchstens sein, dass das Upstream-Projekt seine Migrationen nicht im Griff hat (falls z.B. 3.5->3.6 auch noch mal eine benötigt), so dass eben 2.5 -> 3.6 dann schief geht. Das sind dann doch aber eher Defizite des Upstream-Projekts. Zudem ist man bei RR davor ja auch nicht gefeit: Man Anwender aktualisieren ja auch nur alle Jubeljahre.
Das ganze Problem erschließt sich aber nicht mehr, wenn ich ja weiterhin LTS mit Upgrades anbiete und ansonsten meinen RR-Zweig fahre. Diejenigen, die stabile Pakete wollen, bleiben auf ihrem gepflegten Langzeitrelease und alle anderen, welche Fokus auf aktuellere Anwendungen und neue Funktionen legen, wenden sich eben dem RR zu. Und ich finde es auch für die Community besser, wenn es keine Kurzzeitveröffentlichungen mehr gibt, denn somit muss weniger Support geleistet werden und gerade der ganze Migrationsrummel ist mit immens viel Arbeit verbunden.
upgrade von 12.04 auf 12.10 dauert schon über 3 Stunden, so etwas jedes halbe Jahr, nein danke, nen Roling Release würde da sicher viel schneller ablaufen, weil ja bei jedem update wesntlich weniger bearbeitet werden muss
beim 6 Monatszyklus geht eben alle 6 Monate viel schief und es geht erstmal garnichts mehr.
beim 1 Tageszyklus geht nur einmal die Woche was kaputt und man weiß in der regel genau was kaputt ist.
Tut man das? Mein Verdacht ist, dass das bei Enthusiasten und technisch sehr versierten Nutzern sein mag, aber für den "ich will doch einfach nur arbeiten" Menschen eher nicht.
Persönliches Beispiel: Ich schalte morgens meinen Rechner an, um dann damit Geld zu verdienen. Jede Minute, die ich ggf. mit irgendwelchen Update-Fehlern zu kämpfen habe, kostet Geld.
Ich kann aber relativ einfach alle 6 Monate Zeit einplanen, um mein System zu aktualisieren und mir Zeit zu nehmen, die Release Notes durchzusehen. Im Zweifelsfall klappt dann auch ein Downgrade: Festplatten-Image und fertig.
Aber danke für die Argumente. Mein persönlicher Schluss ist, dass RR tatsächlich nur eine Frage der persönlichen Präferenzen sind und keine echten technischen Vorteile bieten.
Ich vermute jetzt, Ubuntu will seine internen Kosten senken, ohne das geplante Business-Modell (Service-Verträge für LTS) zu sehr zu gefährden.
fs
Upgrade von 12.10 nach 13.04 dauerte heute ganze 40 Minuten. Das ist bei mir Durchschnitt.
Allerdings gab es in all den Jahren auch Ausreißer. 12.04 auf 12.10 ging z.B. völlig daneben und nur eine Neuinstallation konnte das Ding retten.
Die Home-Verzeichnisse haben aber *immer* "gepasst". Soweit zur Datensicherheit.
Bei Config-Dateien hatte ich nur Probleme mit Scannern.
Ein RR ist kein Ersatzt für die 6 monatig erscheinenden "stabilen" Releases.
Ich habe die LTS nur selten genutzt, weil ich oftmals neue Treiber oder Software benötigte, die ich in den 6 monatig erschienenen Releases gefunden habe, allerdings wollte ich auch nie das neuste vom neusten haben (Gnome 3 habe ich z.B. vermieden, so lange es geht), daher habe ich von den 6 monatig erscheinenden Releases sehr profitiert.
11.04 war z.B. das letzte Ubuntu mit Gnome 2, aber es war kein LTS und bot trotzdem
wichtige Treiber für neue HW, die es im 1 Jahr älteren 10.4 LTS nicht gab.
Und das fand ich gut, denn ich konnte die 11.04 bis Ende Oktober 2012 nutzen.
Jetzt mit einer RR Veröffentlichungspolitik wird das nicht mehr funktionieren.
Dann werde ich entweder immer ein uraltes LTS haben, was besonders nervt, wenn das LTS so langsam auf die 2 Jahre zu geht, also schon über 1 Jahr alt ist oder ich muss auf ein Moving Target setzen bei dem immer etwas schief laufen kann oder Software und Schnappsideen (Gnome 3) reinkommen, die ich nicht haben will.
Es ist auch nicht so, dass man ständig Zeit hätte, sich für Alternativen umzusehen, wenn mal eine Schnappsidee Software in die Distri wandert und die alte gute Software ohne Ersatz ersetzt.
Um den richtigen Ersatzdesktop für Gnome 3 zu finden habe ich mir z.B. sehr viel Zeit nehmen müssen.
Auf einem produktivsystem kann ich nicht einfach mal auf ein anderes Desktop Environment wechseln, nur weil es technisch geht. Denn darunter leidet die Produktivität.
Daher muss ein Desktop Environment erst einmal ausgelotet werden um die Grenzen, Nachteile und Vorteile zu finden und die kann man dann auch später, wenn man die Schwächen kennt (z.b. habe ich in XFCE ein paar entdeckt) umschiffen.
So etwas kostet aber Zeit und solche Probleme kann auch auf andere Software zutreffen.
Erst letztens wurde Evolution aus dem offiziellen Ubuntu Repo entfernt und durch Thunderbird ersetzt, aber das nicht mehr offiziell supportete Evolution Paket in der neuen Ubuntuversion hat enorme Schwierigkeiten ein Backup der E-Mail Daten aus der vorherigen Evolutionversion einzuspielen, hier existiert ein Bug.
Solche Regressionen führen also dazu, dass man auch zwangsläufig dazu gezwungen ist, sich nach alternativer Software umzusehen und dahin zu migrieren.
So etwas kostet aber Zeit und in der Zwischenzeit möchte ich noch die alte SW einsetzen können, bei der das noch so funktioniert wie ich es gewohnt bin.
Deswegen sind RR schlecht und deswegen waren die 6 Monatigen Releases sinnvoll.
Letztere waren ein guter Kompromiss zwischen einer alten LTS und einem viel zu schnell wandelnden RR.
Das original gelesen / angehört?
Um mal zumindest diese "Treiber Argument" zu entkräften: Mit der Version 12.04.2 wird der Kernel aus 12.10 zurückportiert um alle aktuellen Treiber in 12.04 zu haben. So just BTW ...
Und ich nehme an, dass dann nur mit mit den LTS Releases Umbrüche stattfinden, alles zwischendrin eher nicht die Paradigmen umwirft. Aber das ist reine Spekulation und noch ist nichts entschieden. Wir werden sehen. Solltest du das Spiel nicht mehr mitspielen wollen, so kannst du dich ja auch für Suse oder Fedora entscheiden. Und ein schönes Gnome2 bekommst du noch immer mittels CentOS/RHEL und Derivaten.
Und die NVidia Treiber für die ganz neue NVidiakarte kriegst du auch im Repo?
Das mit den aktuellen Treibern gibt's übrigens erst seit LTS 12. Vorher wurde das bei keinem LTS gemacht.
Ja, ich kriege auch aktuelle Treiber aus dem Repo, z. B. über xorg-edgers.
mir geht es hauptsächlich darum:
- es kann immer ein updateskript kaputt sein (siehe ubuntu bug tracker...der ist nicht leer
)
- es kann auch ein paket die eigene config kaputt machen und beim update dann nicht sauber mergen (akonadi?) (da kann ubuntu kaum was machen)
- es kann immer mal was sein
beim 6 Monatszyklus geht eben alle 6 Monate viel schief und es geht erstmal garnichts mehr.
beim 1 Tageszyklus geht nur einmal die Woche was kaputt und man weiß in der regel genau was kaputt ist.
beim 6 Monatszyklus kann man dann nicht einfach mal googlen "hier geht ja überhaupt nix mehr" aber wenn einmal die woche nur in einem Paket was kaputt geht dann kann man konkret nach etwas googlen. Am Beispiel von Arch kuck ich dann einfach auf die HP, da steht dann sowas wie "manual intervention required" oder im forum hat direkt einer das Problem gepostet und man findet sofort ne Lösung. Sowas kriegt sogar meine Oma hin.
jemand der von Linux keine Ahnung hat, kommt mit Arch besser zurecht als mit Ubuntu, wenns probleme gibt. (Natürlich unabhänging von der Erstinstallation...da ist Ubuntu natürlich bei weitem einfacher!)
ein RR hat nicht mehr oder weniger Fehler, sie kommen nur eben vereinzelter und überfordern einen nicht direkt.
Beim RR kann man auch einfahc mal wieder ein alten Paket nutzen falls was nicht geht (Abhängigkeiten beachtet). Aber ein OS Update einspielen -> was geht kaputt -> OS Downgrade -> alten Stand erwarten? -> mitsicherheit nicht
Außerdem passieren manchmal so dinge wie, dass sich das default filesystem ändert (/tmp?). Da hat ein updateskript fast keine Chance. Manuell ist das zwar ein Problem aber machbar und besser als wenn Ubuntu einfach Pakete updated und dann sagt "passt alles" ... es läuft zwar alles weiterhin aber macht aufjedenfall nervös.
Ist wohl eine Glaubensfrage aber ich vertrau mir eben mehr beim updaten der einzellne Pakete als ubuntu
Full Ack.
Das schwierigste an Arch ist die Installation und die ist nicht schwer.
So.so.
Mir war Arch zu stressig. Alle paar Tage gabs massig Updates, irgendwann blieb der Paketmanager wegen Inkonsistenzen in den Paketen ganz stehen, und wenn man Anwendungen nur selten benutzt, merkt man gar nicht, dass etwas kaputt ist (ich drucke z.B. sehr selten und merke erst, dass was kaputt ist, wenn ich dringend was ausdrucken möchte).
Nee, nee, lieber Slackware stable.
Wenn sich eine Bibliothek in einem höheren Release inkompatibel ändert, dann müßt man alle davon abhängigen Pakte neu übersetzen, um diese an die neue API anzupassen. Das ist die Stärke von Distributionen wie Gentoo, weil das dort automatisch möglich ist.
Insofern frage ich mich schon immer, wie rolling releases bei rein binären System möglich sien soll. IMHO kann das nur sehr eingeschränkt funktionieren und ist nicht wirklich das, was man unter Rolling Release wirklich versteht.
Bei Inkompatibilität zur neuen Library fliegt die Anwendung raus.
Aus der FAQ - Arch Linux
Arch Linux funktioniert erstaunlich gut und stabil. Allerdings hat Arch nicht ganz so viel Software im Repository und die täglichen Updates sind relativ groß.Des weiteren ist Arch keine reine Binary-Distribution. Für Anwendungen, die nicht im Repository vorrätig sind, gibt es das AUR (Arch User Repository), dessen Software manuell erstellt werden muss.
Ubuntu könnte/müsste möglicher Weise ein paar Dinge anders machen um reine Binary-Repositories anbieten zu können und nach Bibliotheks-Updates keine Software ausmustern zu müssen.
So könnten beispielsweise mehrere Versionen einer Bibliothek installiert werden. Dazu müsste man ein sauberes Versionsschema ausarbeiten. Auch das PPA-System könnten geschickt erweitert und eingesetzt werden. u.v.m.
Ein Rolling Releas mit so breitem Softwareangebot wie Ubuntu ist durchaus eine Herausforderung.
Technisch sehe ich nicht wirklich das Problem. Rolling Release funktioniert mit Debian Sid oder entsprechenden Distros mit wesentlich mehr Paketen als bei Ubuntu ja auch.
Debian SID ist aber kein Rolling Release, sondern der Entwicklungszweig von Debian.
Stimmt, aber auch nur, weil es nicht released wird.
Und das aus gutem Grund. So oft wie bei Debian SID die Paketabhängigkeiten kaputt sind (Was ja dem Status von SID geschuldet ist), könnte man es auch nicht veröffentlichen.
Na super, und da nicht jede Software gleichermaßen von den Entwicklern gewartet wird,
muss man sehr lange verzichten, bis eine für einen wichtige Nischensoftware einen Bugfix erhalten hat, so daß diese endlich mit der neuen Lib Version funktioniert.
Und es versteht sich natürlich von selbst, das Canonical sich kaum um die Nischensoftware kümmern wird, auch dann nicht, wenn Canonical durch ein RR mehr Paketmaintainerkapazität freibekommt.
Denn Paketmaintainer sind noch lange keine guten Coder, die den Quellcode jeder Nischensoftware in und auswendig kennen.
Das wundert mich nicht, wenn eine Lib upgedaded werden muss, zu der ein dutzend darauf aufbauender SW Anwendungen nicht mehr binärkompatibel sind, dann müssen die natürlich auch upgedaded werden und schon hat man ein Update, das fast schon so viele MB Downloaden muss, wie bei einem gewöhnlichen 6 monatigen Dist Upgrade.
Windows läßt Grüßen.
Dort werden auch dutzende DLL Versionen vorrätig gehalten, um kompatibel zu alter Software zu bleiben.
Wenn das in Ubuntu eingeführt wird, dann ist das bald Geschichte, dass eine kleine 5-20 GB Partition für /usr genügt, dann wird man mit 50 GB und mehr rechnen müssen.
Die Startzeiten der einzelnen Anwendungen werden sich ebenfalls verschlechtern, wenn jede Anwendung eine andere Lib Version in den Speicher laden muss.
Tja und Arbeitsspeicher wird man auch mehr brauchen.
Deine beiden Meinungen widersprechen sich.
Entweder es ist eine Cutting-Edge-Distribution wie Arch, oder sie hält eben verschiedene Versionen einer Bibliothek bereit, wie es bei Ubuntu, Debian oder auch Gentoo der Fall ist.
Sie widersprechen sich nicht, denn sie beziehen sich auf das davor angegeben Zitat, das wiederum eine Fallbetrachtung ist.
Gentoo braucht nicht verschiedene Versionen einer Bibliothek vorzuhalten um Kompatiblität zu den Anwendung zu gewährleisten. Gentoo compiliert die Anwendung einfach neu, wenn eine Bibliotheksupgrade dieses erfordert. Bibliotheken sind bei Gentoo zwar in verschiedenen Versionen verfügbar, aber nicht aus kompatitbilitätsgründen. Das kann eine binäre Distribution prinzipell nicht leisten - auch arch nicht.
Das selbe kann man mit einer Binär Distribution machen, nur dass dort das neu Kompilieren Serverseitig geschieht. Das kann dann natürlich große Updates zur Folge haben. Genau so wie es bei Gentoo passieren kann, dass dem Upgrade eine einzelnen Bibliothek das halbe System neu kompiliert werden muss.
Bei Gentoo muss man noch gar nicht mal gleich alles neu Kompilieren, was von jenen Libs abhängig ist. Mit Portage 2.2 gibt es bei Gentoo durch die "preserved libs" auch die Möglichkeit, die alten Libs (nur die .so - Dateien) weiter im System zu behalten, so lange sie von irgend einer Anwendung benötigt werden. Installiert/Kompiliert man neue Programme, so verwenden diese die neuen Libs, während die alten (nicht neu kompilierten) Programme weiterhin die alten Libs verwenden.
Damit die alten Libs nicht vergessen werden, bekommt man zu jedem emerge am ende eine kurze Info, dass im System noch alte Libs bestehen. Und mit dem Set "@preserved-rebuild" kann man dann all jene Anwendungen, die noch von den alten Libs abhängig sind, einfach neu kompilieren lassen. Und zwar dann, wenn es einem passt. Und so lange funktionieren alle Anwendungen weiterhin wie gewohnt. Sowie eine alte Lib von keiner Anwendung mehr benötigt wird, löscht portage sie automatisch.
Also ich finde diese Funktion ausgesprochen praktisch. Portage 2.2 ist zwar (u.a.) wegen den preserved libs noch maskiert, aber ich hatte in den letzten 2 Jahren damit keinerlei Probleme.
Wieviel Zeit geht bei Gentoo eigentlich pro Woche im Schnitt fürs Compilieren drauf?
Das würde mich mal interessieren.
(Bitte dazu auch die HW angeben. Also CPU, RAM und Festplattendurchsatz)
Vor einem halben Jahr hatte ich noch ein Notebook mit einem DualCore 2,53GHz und 8GB RAM. Die Platte hat laut hdparm etwa 80MB/s geschafft. Auf diesem Rechner gingen ca. 1h pro Woche für die Updates drauf. Für die größeren KDE-Updates gingen monatlich jeweils ca. 2,5-3h drauf. Da ich die portrage_niceness und die cgroups (sowohl CPU als auch I/O) passend eingerichtet hatte, konnte ich mit dem Rechner nebenher gut Arbeiten.
Da mir aber nach 3,5 Jahren täglicher Nutzung (sowohl im Büro als auch auf der Arbeit, aber privat gekauft) die Hintergrundbeleuchtung kaputt gegangen ist, hat mir mein Arbeitgeber ein neues zur Verfügung gestellt (frei nach Wahl). Nun ist es ein i7 3820QM (QuadCore) mit 2.7GHz, 24GB RAM und einer dicken SSD. So gehen die Updates natürlich wesentlich schneller. Pro Woche brauche ich im Schnitt etwa 20 Minuten, und KDE ist auch nach etwa 1h15m durch. Und dank der SSD kann das neben der Arbeit ganz problemlos laufen.
Bei den wöchentlichen Updates sind aber auch einige Live-ebuilds dabei, wie z.B. die neue Messenger-Suite von KDE (KDE-Telepathy), oder seit neustem auch die neue Bildschirm-Verwaltung (Screen management got magic). Ist mit Gentoo ganz praktisch, da man so die neuste Test-Version (aus SVN, GIT...) zum Testen haben kann, diese aber ebenso wie alle anderen Anwendungen auch über den Paketmanager verwaltet werden. So kann ich bequem die Entwicklung mitverfolgen.
Meine Kollegen (mit Debian, K/Ubuntu, Mint, ...) fragen mich zwar auch dauernd, ob sich Gentoo überhaupt lohnt. Aber ich sehe Gentoo (nach nun ca. 11 Jahren) wie einen maßgeschneiderten Anzug an. Er ist zwar teurer (Einstieg und auch das Updaten dauern länger), ist dafür aber eben besser an mich angepasst, als ein Anzug von der Stange. Wenn mir ansehen muss, was meine Kollegen als an Abhängigkeiten Installieren müssen, kommt mir das wie ein "zwicken im Schritt" vor.
Ich meinte natürlich "sowohl im Büro als auch zu Hause"
Danke für deine Antwort.
Dafür sind dann wohl heute die modernern CPUs mit noch mehr Kernen notwendig, damit man Gentoo ein paar Minuten schneller kompilieren kann.
Intel sollte für Gentoo Werbung machen, es könnte sich lohnen.
Nö, nicht unbedingt Notwendig.
Der QuadCore, der viele Speicher, und die SSD sind in erster Linie deshalb Notwendig, da ich tagtäglich für die Entwicklung 2-3 Virtuelle Maschinen am laufen habe. Das macht das Arbeiten wesentlich angenehmer.
finde ich äußerst diplomatisch von Dir formuliert
(Full ack von mir als Gentoo-User dazu).
Rolling Release scheint gerade in Mode zu kommen, bei den binären Distros. Selbst Debian denkt schon länger darüber nach:
http://www.pro-linux.de/news/1/17013/debian-diskutiert-rolling-release-zweig.html
Mehr Details zur möglichen Funktionsweise gibt's im Artikel unter dem Link "konkrete Vorschläge".
Ob Cannonical wohl darauf aufsetzen möchte... - egal.
So richtig gut kann RR ohnehin nur auf einem Quell-basierenden System funktionieren, weil nur dort nach erfolgreicher Kompilation von upgedateten Paketen diese erneut, gegen die auf dem System tatsächlich
vorhandenen oder upgedateten Libraries gelinkt werden, wodurch deren Abhängigkeiten wiederum erfüllt sind.
Deshalb kann bei Gentoo auch fast jedes Paket einzeln released werden und der User kann sehr einfach stable und unstable Pakete nach Herzenslust mischen.
Bei den Binären muss dagegen der Distributor irgendwie versuchen die Konsistenz sicherzustellen, was für sein Referenzsystem auf dem ja auch lokal kompiliert wird noch relativ einfach ist.
Wie er das dann aber auf der User-Seite, mit den zum Download angebotenen binären Paketen, sicherstellen will, entzieht sich ja in weiten Teilen seiner Einflussnahme. Daher müssen sich die User in Genügsamkeit üben, um nicht die Konsistenz ihres Systems zu gefährden. Also bitte keine fremden Repositories einbinden ,nur um an aktuellere Pakte zu gelangen.
Wenn's denn unbedingt sein muss, besser selber lokal hinzu kompilieren (merkt ihr was ;-), aber dann geht sowas längst nicht so einfach und komfortabel und update-persistent wie bei Gentoo.
Dort funktioniert RR von Anfang an, also schon seit 13 Jahren
Wäre echt ein Ding, wenn die das in den Griff bekommen würden.
Und wenn in Software Sicherheitslücken gefunden wurde, dann muss man erstmal Stundenlang, sofern viele andere Software von dieser SW mit der Lücke abhängig ist, das System neu compilieren, ehe man es gefahrfrei benutzen kann.
Dabei wollte man doch nur mal schnell die E-Mail checken, bevor der Bus kommt, den man unbedingt nehmen muss, weil man nach XY hin will.
Fazit:
Freizeit kann man auch anders verschwenden.
Genau. Und wenn es von einer Anwendung ein neues Paket gibt, weil die alte Sicherheitslücken aufwies, muss man bei Binär-Distris noch einige Stunden warten bis die Pakete fertiggestellt wurden. So lange kann man es nicht gefahrenfrei benutzen. Bei Gentoo reicht in den meisten Fällen eine Kopie des ebuilds mit der entsprechenden Versionsnummer, wenn man es ganz eilig hat.
Dabei will ich aber nicht noch 8h auf den Maintainer warten, sondern die Software lieber in 1h wieder Benutzen können.
Klar, bei den Binär-Distris kann man sich auch die Mühe machen, und jene Pakete dann eigens kompilieren. Aber dazu muss man erst etliche -dev Pakete Installieren, und hat jene Versionen dann - wenn man kein eigenen Pakete daraus erstellt - noch nicht mal im Paketmanager verwaltet.
Fazit:
Nicht alles an Gentoo ist Freizeitverschwendung.
Alles hat seine Vor- und Nachteile. Dem einen reicht ein Anzug von der Stange, der andere mag eher einen (teureren) maßgeschneiderten Anzug.
Das muss aber nicht immer zutreffen.
Es kann auch sein, das der Maintainer im Amerika sitzt und das Binärpaket am nächsten Morgen fertig hat.
Damit hat man keine Zeit verloren, denn bevor die Sicherheitslücke bekannt wurde, ist man schon schlafen gegangen und am nächsten Morgen zählt dann, wie lange das System braucht um die Lücke zu stopfen.
Das ist also eine Win Situation für ein binärpaketbasiertes System.
Du dagegen mußt am nächsten Morgen dann trotzdem warten, bis dein Computer den Quellcode durchcompiliert hat.
Insofern bist du langsamer mit der Aktualisierung.
Habe das Wort "Nachtrag" vergessen.
Dies:
ist eine Antwort auf squirrels Posting und nicht auf meines, nur dass das niemand falsch versteht.
Deine Argumente lassen wirklich zu wünschen übrig.
Du schreibst etwas von "Das muss aber nicht immer zutreffen." und "Es kann auch sein...", und bewertest es gleich als WIN-Situation. Dass es eben auch NICHT zutreffen muss, und auch NICHT sein kann, gibst du ja selbst zu, lässt es aber nicht in deine Bewertung einfließen. So etwas kannst du dann ebenso auch eine LOSE-Situation nennen. Ganz zu schweigen davon, dass die Sicherheitslücken nicht nur an einem Abend bekannt gemacht werden.
Ich habe zwar auch eine Extrem-Situation genommen, dass man sich mit einer Source-basierten Distribution die Pakete schneller und leichter selbst zusammen bauen kann, als auf den Maintainer warten zu müssen. Aber dies war bewusst so gemacht, weil du die "Sicherheitslücke-schließen-da-ich-schnell-zum-Bus-muss" als die andere extreme Situation geschildert hast.
Aber dies alles passt ja nicht in dein Weltbild.
Nur wenn die Bibliothek bei diesen Schritt nicht korrekt versioniert wurde.
Die meisten Bibliothekshersteller tun das jedoch.
Der Systemlinker wird dann erst gar nicht versuchen für eine Anwendung, die für die alte ABI gebaut ist, eine neue Bibliothek zu verwenden, sondern wird weiterhin die entsprechende Version wählen
Ja, wozu soll denn sonst revdep_rebuild nötig sein?
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 28. Jan 2013 um 13:34.Keine Ahnung, ich bin kein Gentoo User.
Eine rolling release für Fortgeschrittene oder Leute die es gerne aktuell mögen, und eine LTS für Normalverbraucher die einfach mit PC arbeiten möchten.
Und die die jetzt meckern bitte Klappe halten und andere Distri suchen.
Hatte vorher sid und aptosid. Das wurde mir aber zu nervenaufreibend, weil ja doch ab und zu mal was wackelte und ich Schimpfe von der Frau oder im Büro dem Admin befürchtete. Meist lief es zwar ganz gut und war interessant, aber ich wollte nun in etwas ruhigere Gefilde kommen. Daher habe ich erst vor kurzem auf Kubuntu gewechselt.
Habe jetzt so ein bisschen gemischte Gefühle bzgl RR in Ubuntu. Die LTS-Version dagegen ist mir dann wiederum nicht aktuell genug. Alle halbe Jahr neue Versionen (bspw. von KDE) ist eigentlich ziemlich gut.
Alle halbe Jahre eine neue Version rauszubringen fand ich schon Blödsinn. Ressourcenverschwendung, man kann Energie für Besseres aufwenden. Soweit ich weiß werden in LTS Versionen auch Programme wie Firefox usw. aktuell gehalten.
Hi,
also ich bin ein beführworter von rolling releases, was denkst Du darüber?
Bitte hier abstimmen.
Danke!
Nach reichlicher Überlegung könnte ich mit einem RR leben, wenn dafür die LTS Versionen einmal im jahr erscheinen und jeweils 5 Jahre wie bisher supported werden.
Zumindest die neueste LTS-Version Ubuntu 12.04 wird aber auch mit Major Updates (u.a. neuer Kernel, neues Xorg) versorgt werden. Demnächst steht ein ebensolches Update für Ubuntu 12.04 LTS an.
Siehe:
https://lists.ubuntu.com/archives/ubuntu-devel-announce/2013-January/001003.html
"This is the first time we have shipped a backported Hardware
Enablement stack in a LTS release, comprised of a new kernel and
graphics subsystem."
Mit "Stabilität" a la Debian oder RHEL hat das nichts zu tun, das erinnert eher an die Suse-Methode, die leider in SLES 11 SP1 ff. Einzug gehalten hat.
Das klingt auch etwas nach einem "LTS-Rolling Release", wenn man das Backporten von Ubuntu 12.10-Softwareversionen nach 12.04 LTS so nennen möchte. In Zukunft besteht dann der Unterschied zur heutigen Situation einfach darin, dass neben der LTS-Version keine Halbjahresdistribution mehr existieren wird. Gebackportet im Sinne des Integrierens neuer Softwareversionen in das ältere LTS-System wird dann aber weiterhin.
Das neue Xorg wird den letzten NVidia 96.x Treiber für Geforce < = 4 Karten killen, den man vor 2-4 Wochen erst so mühsam in Ubuntu 12.04 LTS reingeflickt hat.
In Ubuntu 12.10 gibt es daher diesen Treiber erst gar nicht mehr im Repo, denn diese letzte 96.x Treiberversion von NVidia ist nicht mehr binärkompatibel zur veränderten API in der neuen XOrg Version.
Ja, ein neues Graphic Subsystem, das wird zum Problem führen. Siehe oben.
PS:
Übrigens nouveau ist auf einer Geforce 4 zwar besser als gar nichts, aber wirklich zu gebrauchen ist so ein System nicht mehr.
Selbst der VESA Treiber läuft stabiler ohne störende Grafikeffekte und ist auch nicht wesentlich langsamer als nouveau.
Für Youtube Filmchen kann man nouveau definitiv vergessen. IMO war sogar bei Videos der alte nv Treiber schneller, auch wenn er keinen 3d Support bot.
Wer also kann, der tut sich selbst einen Gefallen wenn er so lange wie möglich bei den CS Treibern von NVidia bleibt, denn damit laufen die Geforce 4 Karten noch wie ne 1.
Insofern bin ich mal gespannt wie die das bei Ubuntu 12.04 machen werden.
Zum einen wollen sie für andere neue Grafikhardware neue Xorg Versionen anbieten, zum anderen aber müssen sie die alte Xorg Version behalten, damit man noch die 96.x NVidia Treiber verwenden kann.
Ich tippe mal darauf, dass der Einfachheit halber der 96.x NVidia Treiber aus dem Repo genommen wird und der User dazu gewzungen wird auf Nouveau zu setzen. Das wäre die einfachste Lösung und entspricht auch den Weg, den Canonical bisher immer gegangen ist, wenn es bei alter HW Probleme gab. (früher flog z.B. die libglide Bibliothek aus dem offiziellen main Repo, obwohl die TDFX Treiber noch wunderbar liefen.)
Die Geforce4-Nutzer besitzen wohl aber keine kritische Größe mehr, auf die man noch allzu groß Rücksicht nehmen muss.
Ich habe eine NV17-Grafikkarte, die wird von Nouveau in openSUSE 11.4 gut unterstützt, in openSUSE 12.1 so einigermaßen. Demgegenüber erhalte ich mit meinem 2VGA-Onboard-Nv1f-Chip (~NV18) ohne Riesenherumgfrickel unter Nouveau noch nicht einmal ein Bild. Hier waren übrigens auch schon die Nvidiatreiber der 96er-Serie nicht mehr stabil benutzbar.
Nv läuft damit zwar noch, allerdings fliegt XAA aus den neuesten Xorg-Versionen heraus, wodurch nv sehr, sehr langsam werden wird.
D.h.: Es gibt nichts mehr außer Nouveau im freien Treiberbereich, was in 12.04.2 mit einer Geforce 4 funktionieren wird.
Was sind nun Deine Optionen?
Meine Vorschläge:
1. Die alten Geforce4-Karten gegen neuere, noch unterstützte Nvidia-Karten austauschen.
2. Gleich auf alte Radeons wechseln, der freie radeon-Treiber verfügt wenigstens neben EXA- über eine Basis-3D-Unterstützung, selbst noch im Zusammenspiel mit einer uralten Radeon 7500.
3. Du wechselst zu einem RHEL5- oder RHEL6-Klon, benutzt Debian Squeeze oder kehrst zu Ubuntu 10.04 zurück.
4. In Ubuntu 10.04 kannst Du den Support bis Anfang 2015 ausdehen, wenn, ja wenn Du Deine GUI selber flickst. Canonical liefert die Basis- ("Server"-) Unterstützung.
Lieber viele kleine Updates, die auch nur wenig Schaden anrichten, als alle zwei Jahre (oder auch nur alle 6 Monate) ein "fettes" Update, bei dem man sich sicher sein kann, daß hinterher tagelange Nacharbeiten notwendig sind.
Ich stelle mir das rolling gerade in der Infrastruktur unseres Unternehmen vor:
Ein Unternehmen mit ca. 9000 PC's in mehreren Inlands- und Auslands- Filialen (auf jeden Kontinent), 5000 Anwender, viele eigene Anwendungen, die z.T. mit anderen Unternehmen der Branche geteilt werden und (unter Windows) ca. 15.000 Programme (inkl. plugins und Kleinkram).
Und weil das Leben so spielt (z.B. Kostendruck), wacht der IT-Chef eines Morgens auf und will alles nach Linux umstellen.
Und dann sage ich ihm, dass Ubuntu ganz toll ist, weil wir jeden Tag die aktuellste Distribution haben werden (weil rolling) und natürlich ist die source.list auf die internen Aktualisierungsserver angepaßt, aber weil wir viele Produktionen in Freiland Umgebung haben, werden die Laptops gnadenlos über VPN aktualisiert und die Leitungen nach Johannesburg, Moskau und Washington glühen, weil das rolling ja rüber muss. Mal sehen, wer die rechnung für die WAN Rechnungen dann sachlich-richtig zeichnet....
Ehrlich gesagt: Wir sind etwas gebrannte Kinder. Nach dem update auf 6.01 iPhone funktionierte die MDM Lösung nur noch eingeschränkt, dass Flash-update verbog die Rechte auf den Macromed Ordner und als Mozilla auf rolling umsattelte, bekamen unsere Entwickler schluckauf (Ergebnis: ESR Version). Und jetzt stellen wir uns die Probleme hunderfach vor und alles rolling.
Kurz: In den Prospekten sieht das immer toll aus, aber ab einer gewissen Größenordung artet das in Arbeit aus.
Ich dachte, Canonical wollte in den Geschäftskunden- Markt: Ich hoffe, die machen sich nicht nur über den rolling Server im Wohnzimmer Gedanken.
Warum sollte sich ein Unternehmen mit Rolling Releases rumschlagen? Klar ist das indiskutabel, dafür gibt es LTS-Versionen.
Dass die Kisten so konfiguriert werden, dass sie ausschließlich einen internen Update-Server nutzen, ist korrekt. Nur so lassen sich Updates planen.
Richtig. Ich würde mir trotzdem dann so eine Art "freeze" Schalter auf den Clients wünschen, denn wenn ich die Tagespresse richtig in Erinnerung habe, plant Canonical ja auch z.B. sporadisch neuere Kernel- Versionen in eine laufende LTS Version einzupflegen. Damit werden aber wahrscheinlich auch andere Pakete ihr Recht auf Aktualisierung verlangen (Sprich: Paket-abhängigkeiten). ich bin (noch) Freund von einer konservativen Release- Politik.