Det finns ett gammalt skämt i teknikvärlden att varje gång någon försöker skapa ett format som samlar det bästa av alla andra för att undvika spridning, är allt de gör att lägga till ett nytt till listan. En del av det finns där med ansträngningar att skapa ett paketformat som kan köras på alla Linux-distributioner utan modifiering. Hittills detta århundrade har vi redan haft tre.
Snap, Flatpak och Appimage. Skillnader med traditionella format
Den största skillnaden mellan inbyggda paketformat och oberoende paketformat är att de förstnämnda delar beroenden med andra program installerade på operativsystemet. Detta innebär att om program Y behöver beroende 1 och det beroendet installerades av program X som också behöver det, kommer det beroendet inte att installeras igen.
Program paketerade i fristående format inkluderar alla beroenden de behöver för att fungera. Detta innebär att beroende 1 kommer att installeras varje gång ett program som behöver det installeras.
Den andra skillnaden är att traditionella paketformat måste byggas efter specifikationerna för varje distribution.. Det är därför även om Ubuntu är en distribution som kommer från Debian, så är skillnaderna tillräckligt viktiga så att arkiven för den första inte kan användas i den andra.
Den tredje skillnaden är det varje modifiering av ett beroende av de traditionella paketen kan påverka driften av alla andra som behöver det. Å andra sidan kommer modifieringar av ett program i ett oberoende format inte att påverka resten av systemet.
Beroende på särdragen för varje distribution är det möjligt att installera applikationerna i oberoende format från en pakethanterare och automatisera deras uppdatering med den chef som ansvarar för dem.
I Ubuntu låter Software Center dig installera både traditionella och Snap-format program, vilket ger företräde åt det senare. Även om det finns en plugin som tillåter GNOME Software Center (som Ubuntu härrör från) fungerar det inte med denna distribution.
När det gäller Ubuntu Studio är det möjligt att aktivera alternativet att använda Snap-paket medan KDE Neon och Manjaro kan fungera med båda formaten.
snap
Det är det nyaste av de oberoende formaten sedan utvecklingen började 2014. Den är inte bara avsedd att användas i stationära Linux-distributioner utan också för Internet of Things, mobila enheter och servrar. TILLÄven om det är möjligt att skapa oberoende appbutiker finns det för närvarande bara en som drivs av Canonical, Snapcraft.
Även om Snapcraft har ett sortiment av de mest populära applikationerna med öppen källkod, Dess styrka är de program som utvecklats av proprietära mjukvaruutvecklare och molntjänstleverantörer.
Flatpak
Även om Flatpak lanserades officiellt 2015, är det en fortsättning på ett annat universellt formatprojekt känt som xdg-app. Detta projekt föddes med syftet att kunna köra applikationer i en säker virtuell sandlåda, som inte kräver root-privilegier eller utgör ett säkerhetshot mot systemet.
Flatpak är fokuserat på stationära distributioner och använder också appbutikskonceptet Flathub den mest kända.
Flathubs starka sida är det den har vanligtvis de mest uppdaterade versionerna av stora applikationer med öppen källkod.
AppImage
AppImage är det äldsta av de fristående paketformaten som först släpptes 2004.
Det var det första formatet som följde paradigmet "One Application-One File".. Det betyder att varje gång vi laddar ner en Appimage-fil laddar vi ner applikationen och allt den behöver för att fungera. Om vi vill använda applikationen behöver vi bara ge den körrättigheter och dubbelklicka på ikonen som identifierar den.
Appimage använder inte appbutikssystemet, men, hö en webbsida där vi kan hitta en lista över alla tillgängliga titlar.
För att uppdatera Appimage kan vi använda detta verktyg.
Jag saknar det faktum att snap inte har diskuterats om den ökande långsamheten av snap när man installerar appar eftersom det kräver en virtuell enhet för var och en.
Jag saknar det faktum att snap inte har diskuterats om den ökande långsamheten av snap när man installerar appar eftersom det kräver en virtuell enhet för var och en.
Tack för din kommentar. Jag ska ha det i åtanke.
Personligen tror jag att problemen med paketeringen av oberoende mjukvara inte är något annat än en återspegling av en mycket djupare konflikt, som har att göra med graden av överensstämmelse med LSB- och FSH-standarderna av de olika distributionerna.
En av grunderna bakom paketering är implementeringen av standardbibliotek, som behåller både platsen och platsen för programvaran, såväl som konfigurationsfilerna. På så sätt undviker bibliotekskonflikter. Något som är vanligt i andra operativsystem, och som tyvärr, genom att inte följa standarderna, slutar med att det blir svårt att underhålla och uppdatera mjukvaran, för att inte tala om migreringen av mjukvara från en distribution till en annan. Den dåliga praxisen med manuella sammanställningar, som ofta utförs från en howto, utan att analysera efterlevnaden av standarderna i dess implementering, slutar med att bli en enorm huvudvärk för systemadministratörer. Framför allt när någon måste ta över en produktionsserver installerad av en annan tidigare admin.
Oberoende förpackningar, på ett eller annat sätt, slutar med att bidra till den filosofin, främja mer än oberoende, beroende av ett visst format eller företag. Ofta gör plattformsmigrering till en nästan omöjlig uppgift. Tänker mer på kort sikt än på lång sikt. En situation som alla seriösa administratörer med mer än 15 års erfarenhet kan intyga om. Och jag säger den siffran med avsikt, eftersom det under den perioden kommer att ha sett tillräckligt många distributioner för att inse att förr eller senare kommer projekt eller tjänster att tvingas av en eller annan anledning att migrera till plattformen. Situation som sällan kommer in i utvärderingsprocesserna under genomförandet av ett projekt. Där det är lättast att migrera just de plattformar som bäst uppfyller de ovan nämnda standarderna. Att vara dessa oberoende paket, de som avviker längst från dessa standarder.
Intressant inlägg, det hade inte fallit mig in att tänka på det.
AppImage-filuppdateringsverktyget är praktiskt taget värdelöst. Av de 7 AppImage-filer jag har försökt med (Inkscape, Olive, KSnip, MuseScore, OpenShot bland annat) har den bara hotat att fungera med en, och slutat med en "No verification signature" och därför inte heller uppdatera den. Det vill säga, DET ÄR INTE ANVÄNDbart, du kan ta bort referensen. Dessutom har den inte uppdaterats på flera månader.
Tack för att du kommenterade