Abo
  1. Foren
  2. Kommentare
  3. OpenSource
  4. Alle Kommentare zum Artikel
  5. › Linux: Fedora will Konzept der…

Flatpacks

  1. Thema

Neues Thema Ansicht wechseln


  1. Flatpacks

    Autor: jayjay 29.07.17 - 13:49

    Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten hört sich nach einem enormen Ram verbrauch an. Denke wenn das soweit ist kann ich meine Rechner mit 2 und 4 gig Ram endgültig einmotten.
    Das Paketsystem war eigendlich aus meiner Sicht eines der Stärken von Linux und nun soll es durch OS X artige "Apps" ersetzt werden. Schade.

  2. Re: Flatpacks

    Autor: Dadie 29.07.17 - 14:04

    jayjay schrieb:
    --------------------------------------------------------------------------------
    > Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten hört
    > sich nach einem enormen Ram verbrauch an. Denke wenn das soweit ist kann
    > ich meine Rechner mit 2 und 4 gig Ram endgültig einmotten.
    > Das Paketsystem war eigendlich aus meiner Sicht eines der Stärken von Linux
    > und nun soll es durch OS X artige "Apps" ersetzt werden. Schade.

    Die Distribution Fedora bzw. Gnome möchte das so. Daraus lässt sich nicht schließen, dass andere Distributionen dem folgen. Ob andere Distributionen wie bei systemd und pulseaudio auch bei flatpack einknicken wird alleine die Zeit zeigen.

    Zumindest kann man flatpack nicht wie pulseaudio und systemd mit einer Gnome Abhängigkeit in anderen Distributionen "erzwingen" :)



    1 mal bearbeitet, zuletzt am 29.07.17 14:06 durch Dadie.

  3. Re: Flatpacks

    Autor: FreiGeistler 29.07.17 - 14:26

    jayjay schrieb:
    --------------------------------------------------------------------------------
    > Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten hört
    > sich nach einem enormen Ram verbrauch an. Denke wenn das soweit ist kann
    > ich meine Rechner mit 2 und 4 gig Ram endgültig einmotten.
    > Das Paketsystem war eigendlich aus meiner Sicht eines der Stärken von Linux
    > und nun soll es durch OS X artige "Apps" ersetzt werden. Schade.

    Dass jede Anwendung alle ihre Abhängigkeiten mitbringt widd ja als DIE Lösung gegen die "Dependency-Hell" resp. "dll-Hell" betrachtet.

    Wieso aber hat es sich eigentlich durchgesetzt, dass sich eine Abhängigkeit als libxy.so statt als libxy_1.2.3.so installiert?
    So hätte man halt Version 1.2.3 UND 1.2.4 installiert, wenn eine andere Anwendung diese braucht. Wäre aber immer noch besser als sämtliche Abhängigkeiten doppelt und dreifach zu haben, wie bei Flatpack, snappy und Portable Apps.

  4. Re: Flatpacks

    Autor: jayjay 29.07.17 - 14:46

    Dadie schrieb:
    --------------------------------------------------------------------------------
    > jayjay schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten
    > hört
    > > sich nach einem enormen Ram verbrauch an. Denke wenn das soweit ist kann
    > > ich meine Rechner mit 2 und 4 gig Ram endgültig einmotten.
    > > Das Paketsystem war eigendlich aus meiner Sicht eines der Stärken von
    > Linux
    > > und nun soll es durch OS X artige "Apps" ersetzt werden. Schade.
    >
    > Die Distribution Fedora bzw. Gnome möchte das so. Daraus lässt sich nicht
    > schließen, dass andere Distributionen dem folgen. Ob andere Distributionen
    > wie bei systemd und pulseaudio auch bei flatpack einknicken wird alleine
    > die Zeit zeigen.
    >
    > Zumindest kann man flatpack nicht wie pulseaudio und systemd mit einer
    > Gnome Abhängigkeit in anderen Distributionen "erzwingen" :)

    Ich selbst nutze kein Fedora, jedoch hat einfach die Vergangenheit gezeigt, was in Fedora Einzug hält wird mittelfristig "Standard" unter Linux.

  5. Re: Flatpacks

    Autor: Dadie 29.07.17 - 14:58

    FreiGeistler schrieb:
    --------------------------------------------------------------------------------
    > [..]
    > Wieso aber hat es sich eigentlich durchgesetzt, dass sich eine Abhängigkeit
    > als libxy.so statt als libxy_1.2.3.so installiert?
    > So hätte man halt Version 1.2.3 UND 1.2.4 installiert, wenn eine andere
    > Anwendung diese braucht. Wäre aber immer noch besser als sämtliche
    > Abhängigkeiten doppelt und dreifach zu haben, wie bei Flatpack, snappy und
    > Portable Apps.

    Disclaimer: Ich halte Software Isolation in Einzelfällen für gut und praktisch, in der Summe aber als nicht adäquaten Ersatz sondern als gute Ergänzung zu bestehenden Repos.


    Warum man das mit den Versionen so nicht macht hat viele Gründe. Zunächst müsste dann immer noch die Distribution auch libxy 1.2.3 und 1.2.4 bereit stellen. Sind die nicht in den Repos ist das Kind wieder in den Brunnen gefallen.

    Bleibt also nur die Option, dass alle mitgebrachten Libs wie du schon vorschlägst mit einer Version im Dateinamen an einen zentralen Ort gespeichert werden. Nun muss das OS bzw. die Software aber auch wissen, welche Lib Version von der Software verwendet wird.

    Im C++/C Source Code steht dann aber nur #include <libxy/foo.h>, daraus kann das OS schlecht "raten" welche Version du gerne hättest. Man müsste also zusätzlich noch einen "Starter" bauen der irgendwie erkennt oder erfährt, welche Software mit welchen Libs dynamisch gelinkt werden müssen und anschließend die Software mit den korrekten Libs startet.

    Als nächstes hast du das Problemen von einer Korruption deiner Libs auf diese Art. So kann ein flatpack einfach absichtlich mit einer defekten oder infizierten lib kommen die es selber nicht nutzt. Die wird dann auch in den zentralen Lib Ordner kopiert und korrumpiert dadurch ggf. alle aktuell laufenden Programme.

    Zusätzlich sind Programme so nicht mehr "isoliert" von einander. Gerade die Isolation ermöglicht aber Dinge wie ARL (Address Randomized Link), sodass jede Lib einzigartig ist. In Verbindung mit ASLR und AppAmore wäre das eine wirklich robuste Absicherung gegen unerlaubte Addresssprünge. Insbesondere aber stellt die Isolation sicher, dass die Installation eines Programms nicht ein bestehendes Programm unbrauchbar macht.

    Gerade letzteres ist nicht selten dank agiler Software Entwicklung. Gerade moderne Software kennt den Zustand API-Stable kaum noch. Und selbst wenn stabile APIs genutzt werden gibt es alle 3-6 Monate ein neues Major-Release mit API-Changes.

    Zuletzt erleichtert es auch den Vertrieb und Verkauf von Software, weil man alle Parameter (u.a. Libs) als Vertrieb kontrollieren kann. Dadurch spart man sich großen Support-Aufwand für Nutzer die irgendwelche exotischen libc's nutzen oder die libs selber (mit komischen Flags) kompilieren. Und die Entwicklung der Software wird einfacher, weil man nicht konstant auf den kleinsten gemeinsamen Nenner gehen muss. Bis heute sind viele C++ Projekte maximal C++11. Nicht weil C++14 und C++17 doof ist, sondern weil es genug Distributionen gibt die noch uralte libc++'s ausliefern.



    1 mal bearbeitet, zuletzt am 29.07.17 15:02 durch Dadie.

  6. Re: Flatpacks

    Autor: robinx999 29.07.17 - 15:07

    RAM Verbrauch sehe ich da weniger als Problem, eher ein erhöhter Festplattenbedarf, aber der dürfte bei heutigen Festplatten und Größen von Librarys fast zu vernachlässigen sein.
    Probleme sehe ich aber bei Sicherheitslücken, tritt jetzt eine auf wird eine Library Systemweit ausgetauscht und alles sollte funktionieren wie das aber ist wenn jedes Paket seine eigene mitbringt, da bin ich mir alles anderes als sicher, ob da auch bei allen Updates kommen.
    Spannend wird es ob man ältere Programme dann praktisch ewig nutzen kann, oder ob es dann auch irgendwann wieder Brüche gibt (Ich errinere mic damals an ein Programm das Ursrpünglich für QT2 geschrieben wurde mit QT3 noch lief, aber beim Umstieg auf QT4 war ende und das Projekt war eingeschlafen)

  7. Re: Flatpacks

    Autor: janoP 29.07.17 - 16:19

    robinx999 schrieb:
    --------------------------------------------------------------------------------
    > RAM Verbrauch sehe ich da weniger als Problem, eher ein erhöhter
    > Festplattenbedarf, aber der dürfte bei heutigen Festplatten und Größen von
    > Librarys fast zu vernachlässigen sein.
    > Probleme sehe ich aber bei Sicherheitslücken, tritt jetzt eine auf wird
    > eine Library Systemweit ausgetauscht und alles sollte funktionieren wie das
    > aber ist wenn jedes Paket seine eigene mitbringt, da bin ich mir alles
    > anderes als sicher, ob da auch bei allen Updates kommen.
    > Spannend wird es ob man ältere Programme dann praktisch ewig nutzen kann,
    > oder ob es dann auch irgendwann wieder Brüche gibt (Ich errinere mic damals
    > an ein Programm das Ursrpünglich für QT2 geschrieben wurde mit QT3 noch
    > lief, aber beim Umstieg auf QT4 war ende und das Projekt war eingeschlafen)

    Seh ich ganz genauso. Ich hoffe, dass Flathub dafür Richtlinien hat, also dass die Bibliotheken der Anwendungen, die über Flathub distributiert werden, zumindest im Sinne von Sicherheitsupdates aktuell sein müssen. Und solange Fedora die Flatpaks noch selbst packt, wird man sich auch drauf verlassen können. Aber wenn ein entwickler keine Sicherheitsupdates mitmacht, sollte das Projekt IMHO von Flathub entfernt werden.

    Der Aufgabe, das zu überprüfen und zu moderieren, könnten sich dann ja die jetzigen Fedora-RPM-packer widmen... Und im Zweifelsfall vielleicht auch selbst aktuelle Flatpacks packen.

  8. Re: Flatpacks

    Autor: t_e_e_k 29.07.17 - 16:34

    jayjay schrieb:
    --------------------------------------------------------------------------------
    > Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten hört
    > sich nach einem enormen Ram verbrauch an.

    Das heißt ja nicht, dass das System darunter nicht optimieren darf. Sprich, wenn es zweimal dieselbe findet, diese nur einmal Läd... Wenn sich das lohnt. Was eigentlich nur noch bei embedded Systemen der Fall sein sollte

  9. Re: Flatpacks

    Autor: hjp 29.07.17 - 16:39

    Dadie schrieb:
    --------------------------------------------------------------------------------
    > FreiGeistler schrieb:
    > ---------------------------------------------------------------------------
    > > Wieso aber hat es sich eigentlich durchgesetzt, dass sich eine
    > > Abhängigkeit als libxy.so statt als libxy_1.2.3.so installiert? So
    > > hätte man halt Version 1.2.3 UND 1.2.4 installiert, wenn eine andere
    > > Anwendung diese braucht. Wäre aber immer noch besser als sämtliche
    > > Abhängigkeiten doppelt und dreifach zu haben, wie bei Flatpack,
    > > snappy und Portable Apps.
    [...]
    > Warum man das mit den Versionen so nicht macht hat viele Gründe. Zunächst
    > müsste dann immer noch die Distribution auch libxy 1.2.3 und 1.2.4 bereit
    > stellen. Sind die nicht in den Repos ist das Kind wieder in den Brunnen
    > gefallen.

    Viele Distributionen stellen von zentralen Libraries aus genau diesem
    Grund mehrere Versionen zur Verfügung. Fedora habe ich schon lange nicht
    mehr verwendet, aber bei der Red Hat Enterprise Linux ist das jedenfalls
    der Fall.

    > Bleibt also nur die Option, dass alle mitgebrachten Libs wie du schon
    > vorschlägst mit einer Version im Dateinamen an einen zentralen Ort
    > gespeichert werden. Nun muss das OS bzw. die Software aber auch wissen,
    > welche Lib Version von der Software verwendet wird.
    >
    > Im C++/C Source Code steht dann aber nur #include , daraus kann das OS
    > schlecht "raten" welche Version du gerne hättest.

    Die #include sieht das OS nie, das sieht nur der Compiler. Auch die
    Linker-Optionen (die im Gegensatz zu #include tatsächlich Libraries
    referenzieren und nicht Header-File) sieht das OS nicht. Es sieht nur
    das Ergebnis: Das Executable.

    > Man müsste also zusätzlich noch einen "Starter" bauen der irgendwie
    > erkennt oder erfährt, welche Software mit welchen Libs dynamisch
    > gelinkt werden müssen und anschließend die Software mit den korrekten
    > Libs startet.

    Das wird seit 20 Jahren schon so gemacht. Der Starter existiert und
    welche Major Version von welcher Library benötigt wird, erfährt er vom
    Executable selbst (da steht das nämlich drin).

    hp

  10. Re: Flatpacks

    Autor: Seitan-Sushi-Fan 29.07.17 - 18:19

    jayjay schrieb:
    --------------------------------------------------------------------------------
    > Die Sache mit den Flatpacks die all ihre Libs mitbringen

    Der erste Satz ist noch nicht mal beendet und schon wurde der größte Unsinn gesagt. Keine Ahnung, ob du Flatpak mit AppImage verwechselst, aber Flatpak kennt sehrwohl das Konzept von externen Abhängigkeiten ähnlich zu klassischen Paketformaten – bei Flatpak werden die Runtime genannt.

  11. Re: Flatpacks

    Autor: lear 29.07.17 - 18:57

    FreiGeistler schrieb:
    --------------------------------------------------------------------------------

    > Wieso aber hat es sich eigentlich durchgesetzt, dass sich eine Abhängigkeit
    > als libxy.so statt als libxy_1.2.3.so installiert?
    > So hätte man halt Version 1.2.3 UND 1.2.4 installiert, wenn eine andere
    > Anwendung diese braucht.

    Das ist iW. der Status-Quo, allerdings:
    1. ist die letzte Stelle die release Version, diese *sollte* immer API und ABI-stabil sein (darunter wird das unterschiedlich gehandhabt) und ist es bis auf seltene upstream Fehler auch (wenn wir jetzt nicht gerade von selbstgestrickter software von absoluten noobs reden - die findet sich aber auch aus anderen Gründen selten downstream)
    2. achten die Distros schon darauf, alles gegen eine Version zu bauen, das hier also zu vermeiden. Parallelinstallationen von v1.0 und v1.1 gibt meist es nur übergangsweise bei harten API Inkompatibilitäten, die nicht von sämtlichem (ausgelieferten) Clientcode nachvollzogen worden sind (so wie jüngst bei OpenSSL)


    Flatpack & Co. sind eigentlich nur zur Distribution schlecht* programmierter proprietärer Software notwendig - oder wegen der mittleren Katastrophe, die sich J-A-V-A buchstabiert... und natürlich weil die gtk Entwickler das Toolkit zum "GNOME de toujours" umfunktioniert haben und Qt seit ein paar Versionen nur noch von einer Regression in die nächste stolpert...
    MaW, es ist ein lausiger Workaround für ein Qualitäts- und Disziplinproblem.

    *Die naheliegende Lösung wäre statisches Linken, das führt aber bei statisch-dynamisch verschränkten Hybriden schnell auf Probleme mit der Symbolauflösung die Du nicht ohne jede Ahnung bei Stackoverflow weg-googlen kannst.

  12. Re: Flatpacks

    Autor: Geistesgegenwart 30.07.17 - 08:37

    t_e_e_k schrieb:
    --------------------------------------------------------------------------------
    > jayjay schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > Die Sache mit den Flatpacks die all ihre Libs mitbringen und starten
    > hört
    > > sich nach einem enormen Ram verbrauch an.
    >
    > Das heißt ja nicht, dass das System darunter nicht optimieren darf. Sprich,
    > wenn es zweimal dieselbe findet, diese nur einmal Läd... Wenn sich das
    > lohnt. Was eigentlich nur noch bei embedded Systemen der Fall sein sollte

    Uiui, nein das geht nicht. Sonst bundle ich ein Flatpak mit einer modifizierten lib (=Malware) und andere Programme würden die Lib benutzen und ebenfalls zur Malware - was das Sandboxing der Flatpaks untereinander aufweichen würde.

  13. Re: Flatpacks

    Autor: xyzer 30.07.17 - 10:19

    Wenn sie modifiziert wurde, ist es ja nicht mehr die selber Lib. Und dies kann man ja z.B. per Hash leicht erkennen.

    Also natürlich ist das möglich. Ohne Änderungen ginge es schon jetzt über RAM-Deduplizierung.

  14. Re: Flatpacks

    Autor: Akhelos 30.07.17 - 11:07

    War das nicht eigentlich das was an Windows und Mac immer kritisiert wurde? Das die alles mitbringen und die Platte zumüllen? Was unterscheidet Linux dann noch von den beiden, wenn die jetzt auch alles als fette Pakete runterladen und installieren.
    Außer das alles über ein Repository geht, was bei den beiden anderen aber durch die integrierten Shops auch mehr und mehr kommt.
    Besitezr von SSDs auf Laptops die keinen Platz für ne zweite Terabyte HDD haben, werden sich freuen.

  15. Re: Flatpacks

    Autor: robinx999 30.07.17 - 11:10

    Teilweise ja wobei das Problem der DLL Hell ja Ursprünglich war das die DLL Dateien ursprünglich alle im Windows Verzeichnis gelandet sind und sich irgendwann Programm gegenseitig gestört haben. Momentan legen halt viele Programme ihre DLL Dateien im eigenen Programmverzeichnis ab und stören keine anderen Programme. Aber es bleiben Probleme. Einerseits wird die Festplatte zugemüllt, wobei die Größe der DLL Dateien halt gering ist, andererseits bleibt das Problem mit Sicherheitslücken, da so jedes Programm gepatcht werden muss und nicht nur eine DLL Datei (aber das habe ich oben schon geschrieben)

  16. Re: Flatpacks

    Autor: Geistesgegenwart 30.07.17 - 11:16

    Akhelos schrieb:
    --------------------------------------------------------------------------------
    > War das nicht eigentlich das was an Windows und Mac immer kritisiert wurde?
    > Das die alles mitbringen und die Platte zumüllen? Was unterscheidet Linux
    > dann noch von den beiden, wenn die jetzt auch alles als fette Pakete
    > runterladen und installieren.
    > Außer das alles über ein Repository geht, was bei den beiden anderen aber
    > durch die integrierten Shops auch mehr und mehr kommt.
    > Besitezr von SSDs auf Laptops die keinen Platz für ne zweite Terabyte HDD
    > haben, werden sich freuen.

    HDD Platz für Programme ist kein Problem mehr heutzutage; Speicherfresser sind Games und Videos. Bei Apple hat man ja schon seit Jahren die fetten .app Bundles wo jeder seine Libs selbst mitbringt - teilweise sogar in 32 und 64bit Ausfertigung in einem Bundle. Da ist halt ne "App" mal 100MB groß (nur executables/binary, keine Assets) - Wayne. Wieviel Apps installiert man den schon? Bestimmt nicht mehr als 50, da wären dann 5GB weg... Und wenn ne App 500 MB groß wär, das wären bei 50 Apps dann 25GB - auch nicht wirklich viel bei heutigen Systemen.

  17. Re: Flatpacks

    Autor: FreiGeistler 31.07.17 - 23:59

    @All:
    Danke für die Antworten!

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. THE BRETTINGHAMS GmbH, Berlin
  2. InfraServ GmbH & Co. Gendorf KG, Burgkirchen an der Alz
  3. Kisters AG, Oldenburg
  4. ITC ENGINEERING GMBH & CO. KG, Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. 469,00€
  2. 298,00€


Haben wir etwas übersehen?

E-Mail an news@golem.de


Mobile-Games-Auslese: Magischer Dieb trifft mogelnden Doktor
Mobile-Games-Auslese
Magischer Dieb trifft mogelnden Doktor

Ein Dieb mit Dolch in Daggerhood, dazu ein (historisch verbürgter) Arzt in Astrologaster sowie wunderschön aufbereitetes Free-to-Play-Mittelalter in Marginalia Hero: Golem.de stellt die spannendsten neuen Mobile Games vor.
Von Rainer Sigl

  1. Mobile-Games-Auslese Rollenspiel-Frühling mit leichten Schusswechseln
  2. Gaming Apple Arcade wird Spiele-Flatrate für iOS und MacOS
  3. Indiegames Stardew Valley kommt auf Android

Digitaler Knoten 4.0: Auto und Ampel im Austausch
Digitaler Knoten 4.0
Auto und Ampel im Austausch

Auf der Autobahn klappt das autonome Fahren schon recht gut. In der Stadt brauchen die Autos jedoch Unterstützung. In Braunschweig testet das DLR die Vernetzung von Autos und Infrastruktur, damit die autonom fahrenden Autos im fließenden Verkehr links abbiegen können.
Ein Bericht von Werner Pluta

  1. LTE-V2X vs. WLAN 802.11p Wer hat Recht im Streit ums Auto-WLAN?
  2. Vernetztes Fahren Lobbyschlacht um WLAN und 5G in Europa
  3. Gefahrenwarnungen EU setzt bei vernetztem Fahren weiter auf WLAN

Wolfenstein Youngblood angespielt: Warum wurden diese dämlichen Mädchen nicht aufgehalten!?
Wolfenstein Youngblood angespielt
"Warum wurden diese dämlichen Mädchen nicht aufgehalten!?"

E3 2019 Der erste Kill ist der schwerste: In Wolfenstein Youngblood kämpfen die beiden Töchter von B.J. Blazkowicz gegen Nazis. Golem.de hat sich mit Jess und Soph durch einen Zeppelin über dem belagerten Paris gekämpft.
Von Peter Steinlechner


    1. Mobilfunkinfrastrukturgesellschaft (MIG): Bundeseigene Mastengesellschaft aufgestellt
      Mobilfunkinfrastrukturgesellschaft (MIG)
      Bundeseigene Mastengesellschaft aufgestellt

      Eine Mobilfunkinfrastrukturgesellschaft soll schnell Masten errichten, um Funklöcher zu schließen. Das haben die Fraktionsvorstände von SPD und CDU/CSU beschlossen. Der marktwirtschaftlich getriebene Ausbau habe einen Mobilfunk-Flickenteppich geschaffen.

    2. AVG: Antivirus-Software beschädigt Passwortspeicher im Firefox
      AVG
      Antivirus-Software beschädigt Passwortspeicher im Firefox

      Ein spezieller Passwortschutz der Antiviren-Software AVG hat den Passwortspeicher des Firefox-Browser beschädigt. Nutzer hatten deshalb zwischenzeitlich ihre Zugangsdaten verloren. Diese können aber wiederhergestellt werden.

    3. Gamestop: Nerd-Versandhandel Thinkgeek hört auf
      Gamestop
      Nerd-Versandhandel Thinkgeek hört auf

      Der vor allem für seine teils obskuren Produkte bekannte Online-Versandhandel Thinkgeek stellt seinen Betrieb ein. Eine kleine Auswahl der Produkte soll weiter bei der Muttergesellschaft Gamestop erhältlich sein.


    1. 14:32

    2. 12:00

    3. 11:30

    4. 11:00

    5. 10:20

    6. 18:21

    7. 16:20

    8. 15:50