Snap, Flatpak en Appimage. Universele pakketindelingen voor Linux

Programma-indelingen

Er is een oude grap in de wereld van technologie die zegt dat elke keer dat iemand probeert een formaat te creëren dat het beste van alle anderen samenbrengt om verspreiding te voorkomen, het enige wat ze doen is een nieuwe aan de lijst toevoegen. Een deel daarvan is aanwezig met de inspanningen om een ​​pakketindeling te maken die zonder aanpassing op alle Linux-distributies kan worden uitgevoerd. Tot dusver zijn we deze eeuw al drie.

Snap, Flatpak en Appimage. Verschillen met traditionele formaten

Het belangrijkste verschil tussen native pakketindelingen en zelfstandige pakketindelingen is dat de eerstgenoemde afhankelijkheden delen met andere programma's die op het besturingssysteem zijn geïnstalleerd. Met andere woorden, als programma Y afhankelijkheid 1 nodig heeft en die afhankelijkheid is geïnstalleerd door programma X dat het ook nodig heeft, zal die afhankelijkheid niet opnieuw worden geïnstalleerd.

Programma's die in afzonderlijke formaten zijn verpakt, bevatten alle afhankelijkheden die ze nodig hebben om te functioneren. Met andere woorden, afhankelijkheid 1 wordt geïnstalleerd elke keer dat een programma dat het nodig heeft, wordt geïnstalleerd.

Het tweede verschil is dat traditionele pakketformaten moeten worden gebouwd met de specificaties van elke distributie.​ Dat is waarom, hoewel Ubuntu een distributie is die is afgeleid van Debian, de verschillen zo belangrijk zijn dat de repositories van de eerste niet kunnen worden gebruikt in de tweede.

Het derde verschil is dat elke wijziging aan een afhankelijkheid van traditionele pakketten kan de werking van alle anderen die het nodig hebben, beïnvloeden. Aan de andere kant hebben wijzigingen aan een programma in een onafhankelijk formaat geen invloed op de rest van het systeem.

Afhankelijk van de bijzonderheden van elke distributie, is het mogelijk om de applicaties in onafhankelijke formaten te installeren vanaf een pakketbeheerder en hun update te automatiseren met de manager die ervoor verantwoordelijk is.

In Ubuntu kunt u met het Software Center beide programma's in traditionele formaten zoals Snap installeren, waarbij u de voorkeur geeft aan het laatste. Hoewel er een plug-in is die het GNOME Software Center (waarvan Ubuntu is afgeleid) toestaat, werkt het niet met deze distributie.

In het geval van Ubuntu Studio is het mogelijk om de optie in te schakelen om Snap-pakketten te gebruiken, terwijl KDE Neon en Manjaro met beide formaten kunnen werken.

Snappen

Het is de nieuwste van de onafhankelijke formaten sinds de ontwikkeling ervan in 2014 begon.  Het is niet alleen bedoeld om te worden gebruikt in desktop Linux-distributies, maar ook voor het internet der dingen, mobiele apparaten en servers. NAARHoewel het mogelijk is om afzonderlijke app-winkels te maken, is er momenteel slechts één die wordt beheerd door Canonical, Snapcraft.

Hoewel Snapcraft een assortiment van de meest populaire open source-apps heeft, de kracht ervan zijn de programma's die zijn ontwikkeld door particuliere softwareontwikkelaars en cloudserviceproviders.

Flatpak

Hoewel Flatpak officieel werd gelanceerd in 2015, is het de voortzetting van een ander universeel formaatproject dat bekend staat als xdg-app. Dit project is geboren met als doel applicaties kunnen draaien in een veilige virtuele sandbox, waarvoor geen rootprivileges nodig zijn of die een beveiligingsrisico voor het systeem vormen.

Flatpak is gericht op desktop-distributies en maakt ook gebruik van het concept van applicatiewinkel Flathub de best bekende.

Flathub's sterke punt is dat het heeft meestal de meest up-to-date versies van de belangrijkste open source-applicaties.

AppImage

AppImage is de oudste van de zelfstandige pakketindelingen, aangezien het voor het eerst werd uitgebracht in 2004.

Het was het eerste formaat dat het "One app-one file" -paradigma volgde.​ Dat betekent dat elke keer dat we een Appimage-bestand downloaden, we de applicatie downloaden en alles wat nodig is om te functioneren. Als we de applicatie willen gebruiken, hoeven we hem alleen uitvoeringsrechten te geven en te dubbelklikken op het pictogram dat hem identificeert.

Appimage maakt geen gebruik van het app store-systeem, maar hooi een webpagina waarin we een lijst met alle beschikbare titels kunnen vinden. 

Om de Appimage bij te werken, kunnen we gebruiken deze tool.


Laat je reactie achter

Uw e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *

*

*

  1. Verantwoordelijk voor de gegevens: AB Internet Networks 2008 SL
  2. Doel van de gegevens: Controle SPAM, commentaarbeheer.
  3. Legitimatie: uw toestemming
  4. Mededeling van de gegevens: De gegevens worden niet aan derden meegedeeld, behalve op grond van wettelijke verplichting.
  5. Gegevensopslag: database gehost door Occentus Networks (EU)
  6. Rechten: u kunt uw gegevens op elk moment beperken, herstellen en verwijderen.

  1.   Satijn zei

    Ik mis dat er geen melding is gemaakt van de extreem toenemende traagheid van snap bij het installeren van apps, omdat er voor elke app een virtuele eenheid nodig is.

  2.   satijn zei

    Ik mis dat er geen melding is gemaakt van de extreem toenemende traagheid van snap bij het installeren van apps, omdat er voor elke app een virtuele eenheid nodig is.

    1.    Diego Duitse Gonzalez zei

      Bedankt voor je reactie. Ik zal het onthouden.

  3.   Claudio Joffre zei

    Persoonlijk denk ik dat de problemen van onafhankelijke softwareverpakkingen niets meer zijn dan een weerspiegeling van een veel dieper conflict, dat te maken heeft met de mate van naleving van de LSB- en FSH-standaarden door de verschillende distributies.
    Een van de grondbeginselen van het verpakken is de implementatie van standaardbibliotheken, waarbij zowel de plaats als de locatie van de software en de configuratiebestanden behouden blijven. Zo worden bibliotheekconflicten vermeden. Iets wat gebruikelijk is in andere besturingssystemen, en dat helaas, door niet aan de standaarden te voldoen, het moeilijk maakt om de software te onderhouden en bij te werken, laat staan ​​de migratie van software van de ene distributie naar de andere. De slechte praktijk van handmatige compilaties, die vaak vanuit een howto worden uitgevoerd, zonder de naleving van de normen bij de implementatie ervan te analyseren, wordt uiteindelijk een enorme kopzorg voor systeembeheerders. Vooral wanneer iemand een productieserver moet overnemen die is geïnstalleerd door een andere vorige beheerder.
    Onafhankelijke verpakkingen dragen op de een of andere manier bij aan die filosofie en bevorderen meer dan onafhankelijkheid, afhankelijkheid van een bepaald formaat of bedrijf. Platformmigratie vaak een bijna onmogelijke taak maken. Meer denken op korte termijn dan op lange termijn. Situatie die kan worden gezien door elke serieuze admin die meer dan 15 jaar ervaring heeft. En ik zeg dat cijfer met opzet, omdat het in die periode genoeg distributies zal hebben zien passeren, om te beseffen dat vroeg of laat projecten of diensten om de een of andere reden gedwongen zullen worden om van het platform te migreren. Situatie die zelden voorkomt in de evaluatieprocessen tijdens de uitvoering van een project. Waar het gemakkelijkst te migreren is, zijn juist de platforms die het beste voldoen aan de bovengenoemde normen. Omdat het deze onafhankelijke pakketten zijn, die het verst van deze normen verwijderd zijn.

    1.    Diego Duitse Gonzalez zei

      Interessante bijdrage, het was niet bij me opgekomen daarover na te denken

  4.   Rafael Linux-gebruiker zei

    De AppImage-tool voor het bijwerken van bestanden is praktisch nutteloos. Van de 7 AppImage-bestanden die ik heb geprobeerd (Inkscape, Olive, KSnip, MuseScore, OpenShot en andere), heeft het alleen geprobeerd met één te werken, eindigend met een "Er bestaat geen verificatiehandtekening" en daarom ook niet bijgewerkt. Dat wil zeggen, HET WORDT NIET VOOR IETS GEBRUIKT, u kunt de verwijzing verwijderen. Het is ook al maanden niet meer bijgewerkt.

    1.    Diego Duitse Gonzalez zei

      Bedankt voor je reactie