Officiële Ubuntu-flavors stoppen vanaf 23.04 met standaard ondersteunen Flatpak

over het artikel
ik moet eerlijk zeggen dat ik de kwaliteit (diepgang) van dit artikel wel wat tekort vind schieten, vooral als we kijken naar wat flatpack is wat snap is, en hoe cononical het voor gebruikers verziekt om een goed eenduidig en stabiel systeem te draaien. [spoiler] men probeert vooral snap nog meer voorsprong te geven op flathub, en dat terwijl je als ontwikkelaar voor snap aan cononcial moet betalen terwijl flathub in principe free (as in beer) te gebruiken is. [/spoiler]

over containers de voor- en nadelen
snapd, flatpack en appImage zijn 3 nagenoeg identieke manieren waarop je software onder linux kunt draaien zonder het in feite op je system te installeren. een beetje zoals je bij windows soms portable-software kunt gebruiken, alles staat dan in feite in één mapje of één zip-bestand

het grote voordeel van zoiets is natuurlijk dat de maker van de software veel invloed heeft op de inhoud van zo’n bestand, je komt dus nooit in de knoei met in deze versie zit een bug waardoor precies dit stukje software ineens niet meer werkt, dat kan soms namelijk tot vervelende situaties leiden waarbij: software a gebruik maat van lib-blabla versie 1.21 en daar heel stabiel op gaat, maar software b werkt sinds de nieuwe release alleen nog maar met lib-blbla versie hoger dan 1.30 die incompatible is met software a. door in zo’n geval dus alles in een apart container te hebben kun je voor beide stukjes software hun eigen lib-blabla versie gebruiken.

er zijn daarbij wel 3 grote nadelen.
1: software in een container integreert lang niet zo goed (of eigenlijk vrij slecht) met de rest van je systeem, dat wil zeggen dat toegankelijkheids opties, niet of slecht werken, dat documenten printen vanuit een app in een container extra problemen kan veroorzaken, dat het ene stukje software moeilijker kan samenwerken met een ander stukje software.
2: doordat software in een container van alles hun eigen versie moet draaien, betekend dit dat er een bepaalde overhead ontstaat, je dus meer ram en meer cpu nodig hebt, dat je laptop korter gaat op z’n batterij, en dat je systeem over-all gewoon slechter presteert.
3: als elk container zijn eigen versie van lib-blabla draait, dan betekent dat ook, dat elke container onafhankelijk moet worden geupdated, wanneer er een kritieke bug wordt gevonden in dat stukje software.. waar je normaal afhankelijk bent van 1 of 2 partij(en) (namelijk het lib-blabla development team, en in een sommige gevallen wellicht de package beheerder van je distributie. wordt dat aantel verhoogt voor elke container waarin dat stukje software wordt gebruikt.

stel je dan eens voor dat lib-blabla op een dag het QT of GTK framework is, dan mag je in 1 klap niet 1 package in apt-get updaten, maar in plaats daarvan wellicht 10 pakketen in snapd of flathub. dan ben je niet allen meer resourse kwijt, maar ook, meer update tijd en een veelvoud aan bandbreedte.

over Ubuntu en snapd / flatpack
Nu je wellicht wat beter begrijpt wat snap- en flatpack- packages zijn, zul je misschien snappen dat het weliswaar heel handige tools zijn, maar dat je ze tegelijkertijd ook heel spaarzaam zou moeten gebruiken, heb je bijvoorbeeld één stukje legacy software dat echt afhankelijk is van een oudere versie van bijv QT of een ander pakket, dan zijn dit soort containers een ideale manier om de software toch bruikbaar te houden zonder dat de rest van het systeem daar onder lijdt. ook wanneer je software draait in vreemde configuraties of met apps en libs die je verder nergens voor kunt gebruiken kan een container een handige optie zijn. het is ook heel handig voor de distributie van zeer gevoelige software waarbij de configuratie nauw luistert.

voorbeelden van software die goed in een snap-pack zou passen is bijvoorbeeld microsoft office of wellicht bepaalde andere windows software, waar dan ook direct de juiste wine-versie bij zit met de juiste configuratie en de nodige andere tweaks of bestanden.

bij bij ubuntu is het de laatste jaren helaas een beetje anders geworden, ubuntu is zo noob-vriendelijk (lees: transparant) geworden dat je met een paar clicks in de software-center niet eens meer (zeker) weet of je nu de distro-versie of de snapd versie van een bepaald programma te pakken hebt… dus voor je het weet heb je google chrome in een container, en snap je maar niet waarom je schermlezer er niks mee kan. – nu zullen er mensen zijn die meteen blij worden van een browser in een container, maar die keuze zou wel bij de gebruiker en dus niet bij random toeval moeten liggen…

voor je het weet staat je pc vol met containers waarvan je bij sommigen niet eens weet of ze wel op tijd de juiste updates krijgen, van lib-blabla bijvoorbeeld en niet alleen van het pakket waar het om draait.

bekenende voorbeelden hiervan zijn onder andere: google chrome, en libre-office en Firefox waarbij de snap versie soms hoger in de lijst met aanbevelingen staan dan de distro-versies. en vooral voor libre-office kan dat soms een probleem zijn, als blijkt dat je bepaalde bijlages in je mailclient ineens niet kunt openen omdat libreoffce als snap-package geïnstalleerd was

offtopic:
met lib-blabla bedoel ik hier dus een stukje sofware waar andere programma’s van afhankelijk kunnen zijn (bij windows denk je dan misschien aan het .NET-framework) maar bij linux kan zoiets bijna alles zijn: van GTK of QT tot bijvoorbeeld ook lib_ssl of lib_decrypt

[Reactie gewijzigd door i-chat op 22 februari 2023 20:39]