Beiträge von TuxSv748

    meiner Meinung nach veränderst du dein System durch die Deinstallationen so und auch ungeplant, dass du hinterher wesentlich mehr Aufwand hast dies evtl so wieder hinzustellen.


    Wenn du den Zeitrahmen so genau eingrenzen kannst wäre immer noch mein Vorschlag einen älteren Snapshot zu booten, der noch funktioniert und darauf einen diff anzuwenden:
    siehe: Differences between two btrfs snapshots


    Vielleicht funktioniert das dort angebotene Script: Dann kann man immer noch unter den gelisteten Differenzen raten woran es liegt, aber die Liste dürfte kleiner und konkreter sein.
    vorausgesetzt du verwendest btrfs.
    Wenn es aber wie du geschrieben hast am User festzumachen ist, dann könnte es auch an Dateien unter /home liegen und das könnte xfs sein?


    meine Meinung - grüße

    ( und ich hab auch schon Pakete aus der Community installiert, weil nirgend anders verfügbar, Stichwort: djmount )
    also keine generelle Ablehnung/Mistrauen meinerseits

    irgendwo hört das Überprüfen ja auch auf.
    Hatte einen Kollegen der hat grundsätzlich seine LinuxInstallation aus den Sourcen selbst gebaut, den hab ich auch gefragt, ob es sich dann auch die Sourcen ansieht.


    Es ist nur ein kleiner Teilaspekt, bin ja nicht paranoid und vermute grundsätzlich auch nichts dabei.
    Ein im Repo der Release bereitgestelltes Paket betrachte ich als häufiger in Verwendung, auf Grund höhere Downloadzahlen, und evtl besserer Testabdeckung durch automatisierte Tests - falls vorhanden / bzw. Installationen von Anwendern mit evtl. Feedback, auch dies ist u.U. für ein Paket aus home:irgendwer nicht gegeben.


    Ich denke nicht dass über die Downloadzahlen von home:irgendwer Buch geführt wird um einen Eindruck zu haben wie viele Anwender dies in Verwendung haben. Selbst dies hätte keine Aussagekraft.


    Es war bisher mein Vorgehen, .. Der Krug geht so lange zum Brunnen ... ich hab bisher damit keinen direkten Schiffbruch erllitten. Man muss sich die Pakete die noch mitinstalliert werden etwas ansehen und abschätzen ob damit was schiefgehen kann durch Überschneidungen/Mehrfachverwendung mit anderen Programmen, somit lässt sich die Gefahr etwas in Grenzen halten.
    .. falls der Krug denn mal zerbochen ist werd ich's überdenken

    Es geht nicht um schnell auffallen.
    Es ist aufgefallen (ob schnell oder langsam / egal) es ist gemeldet worden, und es hat 10 Monate gendauert bis es entfernt wurde.


    Wer informierte in der Zwischenzeit die anderen Downloader dass der Container verseucht ist?
    Wer informiert evtl nach Abschluss die Downloader dass der verseucht war, die kümmern sich nachträglich evtl gar nicht mehr darum?


    Die wussten und wissen es evtl bis heute nicht.


    Mit schnell Auffallen allein ist es nicht getan.



    Deswegen versuch ich nicht zusammenzuklauben, sondern mich primär wenn es das File für mein Release nicht von offizieller Seite ( gelber Bereich im OBS ) gibt das File aus der gelben Sektion des neueren OS-Releases dem File von home:irgendwer ( roter Bereich Community ) vorzuziehen. Mit dem Nebeneffekt alle Abhängigkeiten auch vom neueren OS-Release nachziehen zu müssen.

    kurz noch ein kleiner Hinweis in die Runde warum ich es versuche zu vermeiden, auch wenn ich vielleicht die Begriffe hier wieder etwas durcheinander würfel, auf OBS home:Community Pakete von Community Membern zurückzugreifen, herunterzuladen und zu installieren, statt dessen lieber Pakete der offiziellen Releases verwende statt von 'home:*'


    5 Millionen Mal heruntergeladen: Bösartige Docker-Container schürfen Monero


    "Zehn Monate lang waren Docker-Images mit Hintertür über Docker Hub verfügbar, obwohl die Verantwortlichen längst über den Schadcode informiert waren."



    :?: Wer garantiert mir, dass so etwas nicht auch bei 'home:*' auftritt. (und ich bezieh mich jetzt nicht speziell nur auf miner)

    das wäre die Alternative gewesen, das image herunterzuladen und alles zu testen, ich befürchtete aber damit in letzter Konsequenz 1/2 Tag beschäftigt zu sein dies dann auch als Entwicklermaschine mit gcc/g++ aufgesetzt zu haben. Die Frage schien mir die schnellere Lösung.


    Eine andere Formulierung meines Problems.
    bei einem apt-get update unter ubuntu werden die einzelnen URLs aufgelistet von wo die Paketer bezogen werden.
    wenn bei einem apt update unter Mint auch URLs nach ubuntu erscheinen würden, plus zusätzliche nach linuxmint würde das darauf hindeuten dass es klappen könnte, die Basis direkt auf ubuntu aufbaut ergänzt durch linuxmint. Keine doppelte Paketpflege existiert


    ich denke den restlichen Weg zu meiner Lösung werd ich allein gehen, sonst wäre hier schon die Antwort gekommen.
    Mint ist nur ein Randaspekt, durch die zusätzliche snapshot Funktion im Vergleich zu ubuntu evtl interessanter als.

    Hallo @caroline,


    danke für deinen Beitrag.
    Mein eigentliches Problem war: wenn ich nur das Installationspaket für ubuntu kenn ohne Möglichkeit dies irgendwo von einem Server herunterzuladen oder auch das Repo kenne, also einen Aufruf wie apt-get install paketXY kann ich dann immer davon ausgehen, dass es mit apt install paketXY auch unter Mint funktioniert, weil automatisch dieselben Repos verwendet werden?


    Es geht mir hier nicht um allgemeine Pakete wie LibreOffice oder vlc, sondern eben SW und auch SOURCEN um darauf aufzusetzen die von Gooogle, Apache, Amazon und evtl Facebook bereitgestellt werden und auf Ihren Anleitungsseiten meist nur ubuntu, Windows und Mac berücksichtigen. Hast du da ein Mehrwissen?


    Grüße