Login
Newsletter
Werbung

Thema: Linux 3.4 wird Longterm-Kernel

2 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Aua am Mi, 22. August 2012 um 10:45 #

@ Nix Bibliothek hier inkompatibel und da inkompatibel etc.

Aua, das tut weh. Da habe ich meine Erfahrungen aus dem Windows-Testumfeld. Dort testen manch' große Firmen (= viel Softwarewildwuchs) über Zeitraum 6 Monate die Kompatibilität der Programme untereinander bei großen Updates. Und nicht immer mit Erfolg....

[
| Versenden | Drucken ]
  • 0
    Von Repository-Wildwuchs am Do, 23. August 2012 um 17:01 #

    Ich auch. Nicht gerne, aber ...

    "abc benötigt xyz, was nicht angeboten werden kann."

    Sowas frustet. Und es häuft sich, sogar bei angeblich wichtigen Sicherheits-Patches.

    Bei VLC: Einmal installieren; funktioniert. Aktualisieren: Nur über direkte Installation der neuen Version, nie über Yast, weil etwa 80 Prozent der als aktualisiert angebotenen Bibliotheken immer auf neue, jeweils nirgends vorhandene und nicht findbare andere Bibliotheken angewiesen sind.

    GLIBC: Hat man die Version x.y installiert, braucht ein Paket A zwingend die Version x.y+1; hat man die gefunden und installiert, braucht das Paket A auf einmal zwingend die Version x.y+2; man kann das Spielchen fortsetzen, bis eine Version gefordert ist, die noch nicht mal im daily snapshot zu finden ist!

    Oder beim Kernel: Ich hätte gerne Desktop- und Standard-Kernel mit den zugehörigen Base-Paketen und den zugehörigen Preload-Paketen, und bitte alles in derselben Version – oder ist das abwegig? Man bekommt das hin, aber nur, wenn man für die Installation zwischenzeitlich alle Abhängigkeiten ignoriert bzw. die Prüfung abschaltet; nach der Installation und dem Neustart funktioniert alles wie gehabt. Und auf einmal motzt die Abhängigkeitsprüfung nicht mehr!

    Ja, aber man kann doch einfach noch diese und jene Repository ...
    Klar: Man kann immer noch eine Repository einbinden. Auch klar: Natürlich erst, nachdem man herausgefunden hat, wo diese oder jene benötigte Bibliothek vielleicht doch zu finden ist. Auch klar: Natürlich nur, wenn man eine Repository für diese Bibliothek in der angeblich benötigten Version gefunden hat, was längst nicht immer klappt; ich sage nur "GLIBC"!
    Auch klar: Mit dem Einbinden irgendwelcher fragwürdiger Repositories steigt das Risiko enorm an, dass man Trojaner, Spy- oder SPAM-Bots oder Ähnliches in sein System integriert.

    Mit am Schwersten wiegt aber, dass man mit dieser "Methode" bald pro Projekt eine eigene Repository einbinden und pflegen muss, und drei oder vier für den Kernel und seine Module und zwei für den Graphiktreiber und die dafür benötigten Preload-Module und eine für dies und eine für das und ... und ... sprich: genau der Müll, den man von Windows her kennt – jedes Programm beim Hersteller oder dem aktuellen Rechteinhaber oder halt irgendwo aus dem Internet manuell aktualisieren müssen – und den man bei Linux eigentlich gerne anders gehabt hätte, weil es dort systembedingt auch anders geht. Oder zumindest: mal ziemlich gut ging: Ein zentrales Aktualisierungs-System für das gesamte System.

    Warum gibt es überhaupt so oft Objekte, die auf notwendige, scheinbare Basis-Bibliotheken verweisen, die dann aber doch nicht in der erforderlichen Version in den grundlegenden Repositories drin sind? Ganz einfach: Bei Linux wird in zunehmendem Maße leider genauso gefrickelt oder bestenfalls gecodet wie bei anderen BS-en auch: Optik vor Funktion, graphischer Schnickschnack als Ersatz für Funktionalität, bald täglich neue UnterSubSubUnterVersionen auf den Markt – sprich: in die unfreiwillige Betatester-Gemeinde – schubsen. Wer's haben sill, soll halt suchen, woher er die benötigten Bibliotheken x und y herbekommt, und wenn dann sonst nichts mehr mit diesen inoffiziellen Versionen tut: Pech für den Anwender! Zurück oder neu installieren.

    Besser wäre ein etwas härteres Reglement:

    • Wer ein Objekt (Programm, Bibliothek, Kernel, Treiber, ...) in einer Version a zur Verfügung stellt, muss nicht nur angeben, von welchen anderen Objekten dieses Objekt abhängig ist, sondern auch, wo (in welcher Repository – mindestens eine muss angegeben werden) die direkt referenzierten notwendigen anderen Objekte zu finden sind. Das herauszufinden, sollte kein Problem sein: Derjenige, der ein Objekt programmiert, weiß bzw. kann herausbekommen, woher er alle benötigten anderen Objekte bekommen hat; die listet er dann einfach auf. Das Vorhandensein dieser benötigten Objekte in den angegebenen Quellen maschinell zu überprüfen, ist auch kein Problem: Rekursiv durch den Abhängigkeitsbaum klettern. Und zwar bitte auf Server-Seite, nicht auf Client-Seite!

    • Das Aktualisierungs-Werkzeug kann dann nämlich
      • Objekte, die nicht allein aus den auf dem System des Anwenders aktuell aktivierten Repositories vollständig mit allem Benötigten versorgt werden können, leicht ausgrauen (bzw. im Terminal entsprechend kommentieren),

      • Objekte, die auch mittels der für dieses Objekt zusätzlich angegebenen, also möglichen aber aktuell nicht aktivierten Repositories nicht vollständig mit allem Benötigten versorgt werden können – das bedeutet, dass die Programmierer ein benötigtes Objekt nicht (korrekt) referenziert haben oder dass es nicht mehr oder noch nicht in den dafür angegebenen Repositories zu finden ist –, stark ausgrauen (bzw. im Terminal entsprechend kommentieren),

      • detailliert darüber informieren, was man von woher zusätzlich noch benötigt, wenn man dieses oder jenes leicht ausgegraute Objekt trotzdem installieren will, und diese zusätzlichen Repositories auf Wunsch auch gleich einbinden,

      • detailliert darüber informieren, dass ein Anwender, der ein "stark ausgegrautes" Objekt trotzdem installieren will, potentiell langfistig bis dauerhaft mit Problemen rechnen muss und dass ggf. die Konsistenzprüfung langfristig bis dauerhaft weiter schimpft und dass schlimmstenfalls auch mehr und mehr andere Pakete betroffen sein können, weil eben Objekte als benötigt aufgelistet sind, die nirgends gefunden werden können.

      • später, wenn ein fehlendes Objekt dann in passender Version in einer Repository auftaucht, dem Anwender mitteilen, dass sich ein Abhängigkeitsproblem lösen lässt, indem man das nun gefundene Objekt von dieser Repository installiert.

    Noch effektiver gegen den Wildwuchs helfen würde es, wenn Objekte, die zwingend das Vorhandensein anderer Objekte voraussetzen, nur dann überhaupt zur Installation oder Aktualisierung im Aktualisierungs-Werkzeug auftauchen, wenn sie vollständig

    • aus derselben Repository, in der sie drinstehen, oder
    • aus einer der zwei oder drei ganz hochoffiziellen primären Repositories

    ergänzbar sind. Klappt das nicht, werden diese Objekte als inexistent behandelt. Wenn ein Programmierer-Team meint, dass es diese oder jene Bibliothek doch verwenden will, dann muss es diese Bibliothek eben entweder selbst mitliefern oder in eine der offiziellen Repositories aufnehmen lassen, und zwar genau in dieser Version. Diese Methode würde gegen den Wildwuchs krass helfen und die Stabilität der Systeme bei und nach Aktualisierung massiv erhöhen. Sie erfordert allerdings die Bereitschaft, auf die Freiheit, sein System durch Installation der immer neuesten Gags und Gadgets in einen faktisch unbrauchbaren Zustand versetzen zu dürfen, zu verzichten zu Gunsten der Freiheit, wirklich funktionierende Aktualisierungen und konfliktfreie Erweiterungen angeboten zu bekommen und so das eigene System in einem Zustand zu erhalten, in dem es sogar in Produktiv-Umgebung nutzbar ist und bleibt.

    [
    | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung