Login
Newsletter
Werbung

Thema: Zukunftspläne für Flatpak

40 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
5
Von \m/Leon\m/ am Di, 9. Oktober 2018 um 13:27 #

Gibt´s eigentlich nen Minimal Distrie mit Flatpak? So nen Basis Linux wo man sich alles Andere als Flatpak downloaded?
So wie bei Windows wo man sich ne exe downloaded und installiert? So was fehlt in der Linux Welt!

  • 5
    Von Kay am Di, 9. Oktober 2018 um 13:45 #

    Deutlicher hättest du mir meine Ängste nicht vor Augen führen können :shock:

    • 1
      Von schmidicom am Di, 9. Oktober 2018 um 14:12 #

      Ohne solche Erwartungen zumindest Optional zu erfüllen wird Linux aber vermutlich nie wirklich relevante Anteile am Markt (abseits der Server) ergattern können. Das gefällt mir zwar auch nicht so ganz aber ich persönlich kann (zum Beispiel in form von Flatpak's) damit leben.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 14:13.
      1
      Von Nille02 am Di, 9. Oktober 2018 um 18:25 #

      Deutlicher hättest du mir meine Ängste nicht vor Augen führen können :shock:

      Dann hätten die GNU/Linux Distros mal die Probleme beseitigen müssen. Man hat aber lieber mit jeder Distro Version ein neues Snapshot vom Upstream erstellt was inkompatible mit älteren Anwendungen ist. Je nach Distro kann dieser Snapshot wenige Stunden, Tage, Wochen oder Monate alt sein, oder mehrere Jahre.

      Ich will nicht mal wissen wie viele Stunden vollkommen nutzlos verschwendet worden sind durch das "Maintainen" der Distros. Das könnte man auch gemeinsam im Upstream machen.

      Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 18:41.
      • 1
        Von asdfghjkl am Mi, 10. Oktober 2018 um 12:09 #

        Und genau deshalb ist die wahrscheinlich wichtigste Distro, Debian, so erfolgreich?! Da werden Jahre alte Programmstände "maintained". Upstream hat eben vollkommen andere Ziele als Debian und dennoch arbeiten die Maintainer und Upstream meist gut zusammen. Ich habe mit dem gut abgehangenen Debian exzellente Erfahrung gemacht und kann daher kein Problem erkennen.

        • 3
          Von Nille02 am Mi, 10. Oktober 2018 um 12:51 #

          Der Upstream ist nicht immer mit Debians Politik glücklich und oft auch Kontraproduktiv. Ein Beispiel aus der nicht zu fernen Vergangenheit war xscreensaver. Der Upstream war sehr verärgert weil Debian eine alte Version weiterhin verteilt obwohl sie Fehlerbehaftet war. Die Fehler aus der alten Version wurden in Debian nicht beseitigt und so haben sich User weiterhin beim Upstream darüber beklagt. Dieser hat daraufhin eine Überprüfung der Version in ihre Software eingebaut und beim erkennen einer neuen Version darauf hingewiesen. Der Maintainer hat die Meldung über die neue Version einfach entfernt.

          Oder Owncloud/Nextcloud. Debian bestand auf einer Version für die es nur noch Sicherheitsfixes geben sollte. Das Releasemodell passte aber da nicht dazu und so mussten die User mit einer sehr alten Version auskommen und ein Upgradepfad wurde extrem erschwert bis Unmöglich.

          Ein Klassischer Fall ist auch ffmpeg und avconv. Der Debain Maintainer war auf Seiten von avconv und hat erst mal ffmpeg raus geworfen es für depricated und totes Projekt erklärt. Bei avconv wurde schnell die Kompatibilität fallen gelassen das alle Scripte nicht mehr liefen und man hat dennoch lib Namen übernommen die es fast unmöglich machten beides gleichzeitig zu nutzen.
          Hier wurde also nun noch mehr Arbeit in das Patchen von Upstream Projekten investiert die ffmpeg nutzen damit man den Willen einer Person umsetzen konnte. Denn darüber gab es keinen Diskurs ob man nun weiterhin ffmpeg nutzen wolle oder auf den Fork wechseln wollte.

          Aber noch mal zum eigentlichen Thema der alten Anwendungen. Ich habe nichts gegen alte Version. Mein Problem ist das ja nicht nur Debian solch alten Versionsstände pflegt. Auch Ubuntu macht das für ihre LTS Versionen die mal jünger oder älter sein können als das was ich in Debian Stable bekomme. Auch Red Hat und Suse pflegen teils alte Versionen über einen längeren Zeitraum.
          Jeder macht das nur für sich alleine.
          Genau hier setzt meine Kritik an. Man verschwendet unglaublich viel Arbeitszeit in das Pflegen seiner eigenen kleinen alten Version. Wenn man das im Upstream bündelt, könnten viele Entwickler sich mit wichtigerem Beschäftigen. Aber dann müsste man ja zusammenarbeiten und noch schlimmer, mit einander Sprechen.

          Dann ist da noch das große was, wäre, wenn. Wenn ich doch mal neue Versionen einer Lib oder Anwendung brauche lässt einen Debian und co. vollkommen im Regen stehen. Dann geht das gebastelt los was erst mal die richtigen Löcher aufreißt. Oder noch schlimmer, das einbinden von Fremdquellen.

          Mein Rechner mit Debian 9 fasse ich daher nun eine sehr lange Zeit nicht mehr an. Denn ein Upgrade wird wohl nicht mehr sauber funktionieren oder alles was ich am Repo vorbei erledigen musste würde nach einem Upgrade garantiert nicht mehr laufen.

          Dieser Beitrag wurde 1 mal editiert. Zuletzt am 10. Okt 2018 um 13:07.
          • 1
            Von asdfghjkl am Mi, 10. Oktober 2018 um 15:52 #

            Mir ist schon bewusst, dass es nicht konfliktfrei ist, deshalb schrieb ich "meist" und habe darauf hingewiesen, dass Upstream und Debian "völlig unterschiedliche Ziele" haben. Klar will ein Entwickler, dass "seine" User immer die aktuellste Version nutzen, da er keine Bug-Reports von alten Versionen bekommen möchte und seine neuesten Features präsentieren möchte. Nur wie will man eine rock solid Distro hinbekommen, wenn man nicht wie Debian arbeitet? Es ist schon der richtige Weg, einen Stand einzufrieren und diesen dann nur noch zu patchen. Sonst hat man eine rolling Distro und die ist eben NICHT vergleichbar mit Debian.

            Wenn man das im Upstream bündelt, könnten viele Entwickler sich mit wichtigerem Beschäftigen. Aber dann müsste man ja zusammenarbeiten und noch schlimmer, mit einander Sprechen.
            Es reicht eben nicht, miteinander zu sprechen. Man müsste auch die gleichen Ziele verfolgen und das tut man eben nicht. Das ist keine Kritik an einer der Seiten, sondern eine nüchterne Feststellung. Ich kann hervorragend damit leben, dass ich mit Debian eine etwas veraltete, aber dafür sehr stabile Distro habe. Wenn ich mal eine spezielle aktuelle Version einer Software benötige, dann installiere ich mir ein Flatpak, von dem ich weiß, dass es auch regelmäßig aktualisiert wird. Für mich ist das eine großartige Ergänzung. Ich nutze also Debian stable (ohne weitere Fremdquelle) plus 2-3 Flatpaks. Und wer andere Präferenzen hat, der kann ja eine rolling-Distro verwenden.

            OT: Dein erstes Beispiel:

            Dieser hat daraufhin eine Überprüfung der Version in ihre Software eingebaut und beim erkennen einer neuen Version darauf hingewiesen.
            Das ist eine freundliche Untertreibung! Der Entwickler von xscreensaver hatte eine Popup-Timebomb eingebaut, um Debian/Ubuntu-User zu ärgern.

            • 1
              Von Nille02 am Mi, 10. Oktober 2018 um 16:31 #

              Ich störe mich nicht prinzipiell an der Arbeitsweise von Debian. Denn genau das will ich ja in der Regel. Ein stabiles System an dem ich nicht alle paar Wochen Handanlegen muss weil ein Patch etwas kaputt gemacht hat.
              Ich kritisiere die mangelnde Zusammenarbeit in der Langzeitpflege unter den Distributionen. Diese Zusammenarbeit klappt nicht mit jedem wie du selbst ja auch schon sagst. Aber das ist auch nicht schlimm, denn ich kann mir ja anschauen wer ähnliche oder die gleichen Ziele verfolgt. Dabei lande ich idr. bei Ubuntu LTS, Red Hat und Suse. Aber jeder macht sein eigenes Ding. Wenn die vier im Upstream ihre LTE Version einer Bibliothek oder Anwendung Maintainen wollen, glaube ich kaum das es abgelehnt wird. Ansonsten können die vier das noch immer gemeinsam Forken.

              Dann kritisiere ich das z.B. Debian einen im Regen stehen lässt wenn ich doch mal was aktuelleres brauche. Ein Ausweichen auf selber compilieren, Frem-Repos oder gar ein weiteres Paketformat das getrennt vom System ihre Anwendung mitbringt halte ich für ganz furchtbare Lösungen.
              Seit über 20 Jahren gibt es die zentralen Softwareverzeichnisse der Distributionen. Das Problem was wir heute haben hätte seit dem bereits gelöst sein können. Aber man will sich Absolut nur auf eine Version festlegen. Ich verstehe warum man es machen wollte, aber das entspricht nun mal nicht der Softwarelandschaft und auch nicht dem wie sich Entwickler verhalten.

              Es kann ja erst mal die Stabile Default Version installiert werden, aber wenn ich eine aktuelle Version brauche soll es mir die auch geben können. Das ich dann die eine oder andere Bibliothek in zwei unterschiedlichen Versionen auf dem System habe ist bei Speichergrößen kein Problem.

              Eine Rolling Release Distro löst auch nicht das Problem, denn wenn nicht alles dem mitgeht laufen Anwendungen die man extern installiert hat irgendwann nicht mehr.

              • 1
                Von Ghul am Do, 11. Oktober 2018 um 09:40 #

                Dann kritisiere ich das z.B. Debian einen im Regen stehen lässt wenn ich doch mal was aktuelleres brauche.
                Debian bietet Backports.

                Das ein oder andere Schätzchen findet man da durchaus. So z.B. das neue KiCad Version 5 für Debian stable, welches Standardmäßig eigentlich nur KiCad 4.x mitliefert.

                Das Backports Angebot müsste lediglich noch etwas weiter ausgebaut werden, vor allem um die Endanwendersoftware und davon vor allem die, die nicht ständig die neuesten Libs benötigen. Mit solchen wäre das gut umsetzbar, ohne bei der alten Version in stable hängen bleiben zu müssen.

                • 1
                  Von Grenzgänger am Do, 11. Oktober 2018 um 10:19 #

                  Debian bietet Backports.

                  Du hast nicht wirklich verstanden, was dir dein Vorposter vermitteln wollte.

                  Das Backports Angebot müsste lediglich noch etwas weiter ausgebaut werden, vor allem um die Endanwendersoftware und davon vor allem die, die nicht ständig die neuesten Libs benötigen. Mit solchen wäre das gut umsetzbar, ohne bei der alten Version in stable hängen bleiben zu müssen.

                  Falsch, die Debian Entwickler und Maintainer konzentrieren sich - völlig richtig - auf den Langzeitsupport.
                  Ein Indiz für dich sollte sein, dass die Backports nicht durch das Security-Team betreut wird.
                  Die Backports werden eher Stiefmütterlich behandelt.

                  • 1
                    Von Ghul am Do, 11. Oktober 2018 um 10:46 #

                    Ein Indiz für dich sollte sein, dass die Backports nicht durch das Security-Team betreut wird.
                    Die Backports werden eher Stiefmütterlich behandelt.

                    Dass die Sicherheitspolitik bei den Debian Backports verbesserungswürdig sind, sehe ich auch so.

                    Aber die Wahrscheinlichkeit dass man sich mit flatpacks mehr Sicherheitslücken installiert, als über die Backports ist weitaus größer, weil auch die flatpacks selbst eine wesentlich größere Angriffsfläche bieten.
                    Da ist nämlich nicht nur diese eine Endanwendersoftware dabei, sondern auch noch ein paar Dutzend libs.
                    Bei den Backports ist diese eine Endanwendersotware oft nur gegen die libs aus main compiliert und die libs aus main, die kriegen wiederum Sicherheitspatches.

            1
            Von Ghul am Do, 11. Oktober 2018 um 09:34 #

            Du hast das schlimmste Ereignis bei Debian vergessen.

            Die Ersetzung der cdrtools durch cdrkit.
            Letzteres hat bei mir nicht nur jede Menge CDs kaputt gebrannt, sondern der Maintainer hat es zwar geforgt und behauptet, er kriegt was besseres hin, aber nach ein paar Monaten wurde dann der Support eingestellt.

            Ich hätte daher ganz gerne ein cdrtools in wenigstens Debian non-free, wenn es schon nicht in main klappt.
            Und wenn das nur im Source vorliegen darf, dann eben als Script, das mir das Ding baut.

            OpenMandriva und OpenSUSE haben cdrtools jedenfalls wieder eingebaut.

    1
    Von schmidicom am Di, 9. Oktober 2018 um 14:01 #

    Endless OS

    Dieser Beitrag wurde 1 mal editiert. Zuletzt am 09. Okt 2018 um 14:02.
    4
    Von wurzel am Di, 9. Oktober 2018 um 14:47 #

    Gibt´s eigentlich nen Minimal Distrie mit Flatpak? So nen Basis Linux wo man sich alles Andere als Flatpak downloaded?
    So wie bei Windows wo man sich ne exe downloaded und installiert? So was fehlt in der Linux Welt!

    Das wäre tatsächlich ein Alptraum. Da jede App in diesem Fall seine komplette Umgebung mitbringen würde hättest du ruck-zuck ein paar Terabyte beisammen.
    Auch die ominösen Windows-Exes greifen in großem Umfang auf die Libs des Betriebssystems zurück. Es sind eben keine Flatpaks sondern stecken bis über beide Ohren im Basis-System.

    • 1
      Von Nille02 am Di, 9. Oktober 2018 um 18:32 #

      Das wäre tatsächlich ein Alptraum. Da jede App in diesem Fall seine komplette Umgebung mitbringen würde hättest du ruck-zuck ein paar Terabyte beisammen.

      Braucht man nicht. Man definiert ein SDK mit allen wichtigen Grundfunktionen. Ich kann dann die Anwendungen gegen dieses Flatpak Linken und brauche nicht alles mit schleppen.

      Das SDK kann man dann so lange aktualisieren solange es weiterhin abwärtskompatible ist.

      Man kann es auch vielleicht noch in einige wenige Grundkomponenten aufteilen.

      Auch die ominösen Windows-Exes greifen in großem Umfang auf die Libs des Betriebssystems zurück. Es sind eben keine Flatpaks sondern stecken bis über beide Ohren im Basis-System.

      Und MS macht einen beachtlichen Job wenn man sich anschaut wie Abwärtskompatible das System ist. Ich habe noch Win2k Anwendungen die auch heute noch auf meinem Windows 10 ohne Probleme laufen.

      • 1
        Von Kay am Di, 9. Oktober 2018 um 18:37 #

        Braucht man nicht. Man definiert ein SDK mit allen wichtigen Grundfunktionen. Ich kann dann die Anwendungen gegen dieses Flatpak Linken und brauche nicht alles mit schleppen.

        Das SDK kann man dann so lange aktualisieren solange es weiterhin abwärtskompatible ist.

        Man kann es auch vielleicht noch in einige wenige Grundkomponenten aufteilen.

        Und warum belässt man es dann nicht gleich bei der althergebrachten Paketverwalung? Dort geschieht doch auch nichts anderes, vor allem wenn es abwärtskompatibel bleiben soll. :huh:

        • 1
          Von Nille02 am Di, 9. Oktober 2018 um 19:08 #

          Und warum belässt man es dann nicht gleich bei der althergebrachten Paketverwalung? Dort geschieht doch auch nichts anderes, vor allem wenn es abwärtskompatibel bleiben soll. :huh:

          Das hatte ich vor 15 Jahren mal Vorgeschlagen. Ich hätte keine Ahnung und solle den Mund halten war der Tenor. (Denn ich könne ja einfach die Anwendung gegen die lib im Repo compilieren oder die Anwendung statisch als Blob compilieren was übrigens selbst wenn man mehr als Grundkenntnisse hat nicht einfach hinbekommt)

          Meine "Lösung" bestand einfach darin ein Repo für seine Distributionsfamilie zu haben. Ein Paket gibt halt die zu installierenden Versionen vor.

          Zum Beispiel bekomme ich über das Repo dann die libxml-1.0. Mit der 1.1 wurde die ABI geändert und ich müsste alle Anwendungen neu compilieren. Also landet auch eine libxml-1.1 im Repo was bei Bedarf genutzt werden könnte. Wenn ich nun eine neue Version installieren will die schon die neue Version verlangt, bin ich nicht gezwungen mein Halben System neu zu compilieren oder die neue Anwendung statisch gegen die neue zu linken. Ich werfe den Compiler extrem ungern an, denn damit werde ich zwangsweise in die Pflicht genommen mich um fixes für Sicherheitslücken zu kümmern.

          Das ganze setzt aber ein brauchbares Releasemodel im Upstream voraus und das nicht ständig die Schnittstellen geändert werden.

          Die Pflege der Versionen könnten die Distros dann auch direkt im Upstream erledigen.

          Aber das will wohl niemand. :shock:

          Aber nun bekommen wir das schlechteste aus allen Welten. Ich stopfe nun alles was meine Anwendung vermutlich braucht mit in mein Paket. Ob die Abhängigkeiten darin gepflegt werden, steht in den Sternen.

          Toll wird es auch wenn dann mein "Blob" auf Systembibliotheken zugreifen muss und es zu Konflikten in den Versionen kommt.
          Bei Steam gab/gibt es da einen tollen Fehler. Es bringt ja auch gleich einen ganzen Haufen von alten Bibliotheken mit. Die 3D Treiber hatten aber nun die neuen Versionen gebraucht.
          Steam ist also nie gestartet und es war nicht ersichtlich warum.

          Es lag dann daran das Steam die alte zuerst geladen hat und das auch dann dem 3D Treiber geben wollte. Das ging nicht gut aus und es ist in einem Segfault geendet. Der Workaround war es die alte Bibliothek in Steam einfach zu löschen (Wurde nach jedem Update neu geladen).

          Das ist zumindest in den 3D Treibern schon gefixt aber ist auch nicht der einzige Fall wo es da zu ähnlichen Problemen kommt.

          Dieser Beitrag wurde 3 mal editiert. Zuletzt am 10. Okt 2018 um 09:39.
          • 1
            Von Kay am Mi, 10. Oktober 2018 um 00:44 #

            Ok....wir sind im Prinzip der gleichen Meinung :D

            1
            Von r.koebler am Mi, 10. Oktober 2018 um 02:12 #

            Naja, die Lösung ist ein Paketmanager, der auch kein Problem mit dem gleichzeitigen Installieren mehrerer Versionen der gleichen Library hat. Und der alle Abhängigkeiten mitbringt und zwischen den installierten Paketen shared.

            Sowas gibt's auch, nennt sich "Nix" (siehe https://nixos.org/nix/) -- und das darauf aufbauende System ist NixOS. Funktioniert sehr gut, und dürfte Flatpak, Snap usw. meilenweit überlegen sein. Der Nix-Paketmanager funktioniert auf praktisch jeder Linux-Distribution -- damit schafft man es, ein Paket für alle zu bauen. Nur das User-Interface ist bisher noch nicht soo toll...

            • 1
              Von schmidicom am Mi, 10. Oktober 2018 um 08:00 #

              Die Sache mit den verschiedenen Versionen ist aber leider nur die eine Hälfte des Problems, wo und unter welchem Namen diese im Dateisystem zu finden sind ist die andere Hälfte. Hör dir doch einfach mal die RadioTux Sendung September 2018 an, da wird das auch angesprochen.

              • 1
                Von r.koebler am Mi, 10. Oktober 2018 um 15:09 #

                Naja, der "Nix-Paketmanager" löst auch dieses Problem sehr elegant.

                Viele der bisherigen Lösungsversuche haben einfach den komplett falschen Ansatz:


                • LSB und FHS: "wir verteilen Dateien über das komplette Betriebssystem" => Kollisionen, unklare Zugehörigkeit von Dateien und Paketen
                • Flatpak, Snap, AppImage, Docker: "jede Applikation bringt alles mit" => Overhead, Update-Hell
                • viele separate Paketmanager auf einem System: CMS-Module, npm, pip, ... => Update-Hell
                • übliches Distributions-Update-Verfahren: "wir ersetzen eine Bibliothek stillschweigend durch eine neuere Version, ohne den davon abhängigen Programmen etwas zu sagen, und es wird schon gut gehen", und "wir überschreiben einfach Dateien im System" => nicht robust, Prinzip "Hoffnung"

                Was man eigentlich bräuchte, wäre:


                • keine Kollisionen: Es sollen mehrere Versionen von Programmen/Libraries usw. gleichzeitig installierbar sein.
                • De-duplication: Eine Library soll nur einmal auf dem System liegen, und nicht separat für jedes Programm.
                • Robust: Eine Installation oder ein Update kann nichts kaputt machen, selbst wenn ich mittendrin "den Stecker ziehe". Und wenn ich ein Paket installiere und danach wieder entferne, soll sich bitte am Rest des Systems nichts geändert haben.
                • zentrales Update: Es soll 1 Update-Mechanismus geben, den ich zentral anstoßen kann, und der dann alles updated.
                • überall lauffähig: Es sollte reichen, 1 Paket zu erstellen, dass dann auf allen Linux-Distributionen lauffähig ist.

                Damit könntest du dir das ganze, um das es in der RadioTux-Sendung geht (OSTree, Flatpak, AppImage, Container, LSB, FHS, separate Pakete für jede Distribution), sparen.

                Und eine technisch saubere Lösung, die das ziemlich gut hinbekommt, ist der Nix Paketmanager -> http://www.nixos.org/nix/. Ledichlich an der Einsteiger-Usability mangelt es derzeit leider noch. Aber technisch ist Nix aus meiner Sicht den ganzen anderen Lösungsversuchen meilenweit voraus.

                • 1
                  Von Nille02 am Mi, 10. Oktober 2018 um 15:39 #

                  Das klingt zumindest nach einem Teil von dem was ich mir gewünscht habe. Ich setze aber keine Hoffnung darin, denn Flatpak kommt aus dem Gnome Projekt und damit aus Richtung Red Hat.

                  Und eine Abschaffen von pip, npm und co sollten wir alle entgegensehen.

        1
        Von wurzel am Di, 9. Oktober 2018 um 20:18 #

        Und MS macht einen beachtlichen Job wenn man sich anschaut wie Abwärtskompatible das System ist. Ich habe noch Win2k Anwendungen die auch heute noch auf meinem Windows 10 ohne Probleme laufen.
        DAS ist tatsächlich so und auch wenn MS für mich Vergangenheit und Horror ist .. DAS fehlt tatsächlich für Linux.
        Preis der Freiheit.

    3
    Von hjb am Di, 9. Oktober 2018 um 15:03 #

    Damit kommt man nicht weit, dazu müsste erst mal ein signifikanter Teil der Software als Flatpak paketiert sein. Dass Linux schon mehr als 25 Jahre weitgehend auf die von den Distributionen mitgelieferten Pakete aufbaut, liegt an den vielen Nachteilen, den die manuelle Softwareverwaltung hat, vor allem den massiven Sicherheitslücken, die die Benutzer dann nicht mal mitkriegen. Es hat Gründe, dass Windows so mies ist, wie es ist.

    • 2
      Von Ghul am Do, 11. Oktober 2018 um 10:10 #

      Es hat Gründe, dass Windows so mies ist, wie es ist.

      Viel mieser als Ubuntu ist es auch nicht. Denn in Ubuntu unstable kümmert sich kaum jemand aktiv darum, dass die Sicherheitslücken in unstable gestopft werden.

      Da findet man Pakete mit Sicherheitslücken, die in Debian stable schon vor 6 Monaten gefixt wurden und die Nutzer wiegen sich in falscher Sicherheit, weil sie glauben, dass mit einem apt-get upgrade && apt-get dist-ugprade alles nötige getan wäre und ihr Ubuntu sicher wäre.
      Dass die Ubuntu Nutzer ihre Pakete aus unstable aktiv selber pflegen müssten, das ist nur den wenigsten wirklich bewusst.

      Bei Windows weiß man wenigstens, das alles, was von Microsoft kommt, auch Dienstags mit dem Patchday gefixt wird.

      Als Problem bleiben dann nur die 3rd Party Tools, wie z.B. Gimp um mal ein Beispiel zu nennen.
      Welches vor ein paar Monaten mit der letzten stable Version noch mit einer Uraltversion von Python ausgeliefert wurde, welches selbst eine Sicherheitslücke hatte und keiner der Gimp Windowspaketierer kam nachdem die darauf hingewiesen wurden, auf die Idee, mal schnell einen neuen Installer mit Minorversion herauszubringen.

      Man hat einfach auf den nächsten stable Release von Gimp gewartet und ob man da die Pythonlib auf einen aktuellen Stand gebracht hat, habe ich noch gar nicht nachgesehen.

4
Von Mike11 am Di, 9. Oktober 2018 um 15:46 #

Wer sagt, dass jeder Linuxuser mehr Marktanteile möchte?
Ich nicht.

Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung