Menno schreef :
Als OpenCPN overgaat van de Flatpak-runtime versie 20.08 naar bijv. 22.08 moeten alle plug-ins ook weer voor die nieuwe variant gecompileerd worden.
Dat klopt, maar omdat de OpenCPN developer community nu zelf kan kiezen of en wanneer overgaan van runtime X naar runtime Y is dat beter te timen door dit in een major release van OpenCPN te doen.
Hoe het zit met (security) updates van de gebruikte Flatpak-runtime is me ook niet helemaal duidelijk. Net als de periode dat deze runtimes ondersteunt worden, en hoe vaak je dus over moet naar de volgende versie.
Bij het gebruikt van software uit de repository van de distributie (bijv. Debian) is het mij een stuk duidelijker wie er verantwoordelijk is voor de updates, en tot wanneer die geleverd worden.
Wel, je zou je kunnen inlezen door even over internet te struinen?
b.v. flatpak basic concepts
De grap is dat OpenCPN zélf bepaalt welke runtime er tegen aan gewerkt wordt. Dat zullen Dave en Pavel alleen doen, denk ik, wanneer dat echt nodig is. Ik denk dan aan (1) er nieuwe functionaliteit in zit die O nodig heeft of (2) er grote bugs niet meer gefixt worden in de huidige runtime maar wel pas als (3) die runtime door voldoende flatpak installaties ondersteund wordt.
Elke flatpak applicatie kiest zijn eigen runtime versie, dus je kan b.v. OpenCPN lekker houden op een werkende versie en wel je browser updaten naar de meest recente versie met een nieuwe Flatpak runtime. Dit lijkt eigenlijk heel erg op de aanpak die Microsoft is gaan doen sinds Windows 7 waarin applicaties denken dat ze DLLs delen maar ondertussen alle DLLs heel ergens anders opgeslagen worden (de SXS directory) met als enige nadeel dat het (vroeger) veel diskruimte koste (nu is een paar GB niet zo erg meer.)
Elke flatpak applicatie zit in zijn eigen zandbak, en daar kan niks in of uit behalve als de applicatie dat expliciet wil. Zo heeft dus de OpenCPN flatpak zandbak geen notie aan b.v. een lek in ssh, als die al in de zandbak zou zitten, omdat we geen inkomende poort naar ssh open zetten. Dus een flatpak app is niet zo gevoelig voor als de libraries in zijn zandbak wat ouder zijn. Ook alle systeem services zitten niet in de flatpak maar in het echte OS 'daarboven'. Bovendien doet de flatpak organisatie aan backporten van bugs, net als Debian zelf. Maar zoals gezegd, grote kwetsbaarheden zullen veel minder snel optreden door de opzet van Flatpak.
Ik was zelf eerst ook erg negatief over Flatpak, zo van daar gaan we weer, maar ben helemaal bijgedraaid.