Canonical brengt snap-ondersteuning naar Fedora

Canonical geeft Fedora officieel ondersteuning voor snap, het verpakkingsformaat voor applicaties. De snaps zijn te gebruiken in combinatie met Fedora 24, 25 en 26. Fedora heeft al ondersteuning voor het vergelijkbare Flatpak.

Ontwikkelaars van Ubuntu leggen uit hoe Fedora-gebruikers eerst een snapd-package kunnen installeren en vervolgens hun eerste snap met de basis-libraries kunnen installeren. Wel waarschuwen ze dat de sandbox van snaps op de AppArmor-backend berust. "Aangezien Fedora niet met AppArmor is uitgerust, draaien snaps niet afgebakend." Het ontwikkelteam van snapd roept ontwikkelaars op de SELinux-backend hiervoor bij te werken.

Snap-pakketten bevatten naast het programma zelf ook de afhankelijkheden of dependencies. De voordelen zijn dat ze snel te distribueren zijn, veiligheid bieden en makkelijk te updaten zijn door de ontwikkelaar. Een alternatief is er in de vorm van Flatpaks. Die zijn bedoeld als open formaat voor alle Linux-varianten, maar de drijvende kracht erachter is Red Hat. Fedora heeft vanaf versie 24 ondersteuning voor het Flatpak-formaat.

Canonicals doel met snaps is om het formaat naar zoveel mogelijk systemen te krijgen, waaronder internet-of-thingsapparaten. Flatpaks zijn meer op distributie naar desktops gericht. Een ander verschil is dat Flatpaks geen gecentraliseerde app-winkel hebben zoals snaps.

Reacties (34)

Ik hoop dat het gauw over zal zijn met Snap, Flatpak en andere dergelijke technieken. Ik begrijp erg goed waarom men graag deze technieken gebruikt: het is gemakkelijk om applicaties te kunnen distribueren, zonder kennis van het onderliggende systeem. Dit is denk ik ook het grote probleem van dergelijke technieken: ze liggen de verantwoordelijkheid van het selecteren van versies van pakketten en dus ook security-updates bij de applicatie-ontwikkelaar. Dat lijkt mij geen goed idee. Voor distributies is het al een hels karwei om alles up to date en veilig te houden, dat doe je als applicatie-ontwikkelaar er niet 'eventjes' naast.

Hoe dan ook, er is een onderliggend probleem waardoor technieken zoals Snap en Flatpak populair worden. Blijkbaar doen distro's hun werk niet goed genoeg, aangezien het niet gemakkelijk genoeg is om applicaties te distribueren. Distro's bieden niet de juiste (versies van) pakketten aan en het is niet gemakkelijk genoeg om native pakketten te bouwen voor alle distro's.

Zelf draag ik bij aan Nixpkgs/NixOS, een package set / operating system. Een belangrijke feature is dat ieder pakketje in een eigen folder wordt geplaatst en waarbij het vaak mogelijk is meerdere versies van applicaties en libraries (simultaan) te gebruiken. Dit werkt doorgaans erg goed, maar soms zijn er nog steeds limitaties, zoals bijvoorbeeld met Python. Bij Python bijvoorbeeld is het niet mogelijk om verschillende versies van een library tegelijk te importeren. Bovendien staan normaal gesproken alle Python pakketten in 1 map, en kan je slechts 1 versie van ieder pakket daar hebben. We bieden een hoop Python libraries aan maar ook Python applicaties.

Python applicaties zijn doorgaans een ramp voor distro's, aangezien ontwikkelaars ervoor kiezen om hun dependencies vast te zetten. Dit is erg begrijpbaar, aangezien ze testen tegen slechts een specifieke set. Maar dat betekent dat het lastig wordt om een set van pakketten aan te bieden welke bruikbaar zijn voor alle applicaties. De oplossing is dan al gauw virtualenv.

Het zou denk ik beter zijn als voor iedere taal/framework (bijvoorbeeld Python) er een gecurateerde pakkettenset zou zijn die ondersteund wordt door alle (grote) distibuties. Zegmaar iets als Haskell LTS en Stack. Dat betekent dat ontwikkelaars tegen een veel kleinere matrix van dependencies hoeven te testen. Het zou tegelijk ook (dubbel) werk weghalen bij de huidige distro's.

Zoals bij Node waarbij de facto NPM de package manager is. Werkt fantastisch. Maar is dependency hell daarmee opgelost? Nee, helaas niet.

De oorzaken liggen nog veel dieper. Een optioneel argument van een belangrijke functie verplicht maken en pats; tig builds die breken. Major versie nummer ophogen (want breaking change) en tig builds die het nog steeds zouden doen krijgen de nieuwste versie niet. Je kunt het onmogelijk goed doen. Vermenigvuldig dat met de tientallen of honderden dependencies van een applicatie, die vaak zelf ook weer dependencies hebben en daar ben je weer: dependency hell.

NPM is een goed punt, daar kan je inderdaad kiezen voor globaal package installatie of lokaal path en je bent tevens erg flexibel. Maar hier zit ook precies het punt dat @FRidh aangeeft, bij oudere projecten verlies je mogelijk interesse/geld, gevolg zijn out-of-dated en potentieel gevaarlijke JavaScript libs, niet echt iets wat je allemaal kunt oplossen door het maar in één sandbox te draaien.

Gevolg is dus inderdaad dependencies hell, maar het is het haast onmogelijk wat je zegt dit te voorkomen. Het enige wat zou kunnen is een globale package manager die alles kan en doet, maar ook dat is niet waterdicht.

Snap-pakketten bevatten naast het programma zelf ook de afhankelijkheden of dependencies. De voordelen zijn dat ze [...] veiligheid bieden [...].

En dat is dus maar de vraag. Daar gaat ook veel discussie over in de community. Want als een developer de ondersteuning stopt, en zijn snap niet meer geupdate wordt, dan blijft de snap oude libraries houden - met alle (beveiligings)problematieken die in nieuwere versies van de library verholpen zijn.

Krijg een beetje de indruk dat Tweakers in dit artikel klakkeloos de argumenten van Canonical overneemt, ben een iets kritischere houding gewend...

Het blijft schipperen tussen 2 kwaden. Bij de traditionele repositories zie je dat applicaties of libraries op oudere versies moeten blijven steken omdat anders iets anders stuk gaat. En het maintainen van packages voor specifieke repositories voor specifieke versies van specifieke distro's met ieder hun eigen beperkingen is ook een hel. Met een Snap ben je in 1 klap van die problemen af. Je kan eenvoudig naar de nieuwste versies van je dependencies, en je gebruikers kunnen ook eenvoudig naar de nieuwste versie van jouw applicatie, zonder dat dat gehinderd wordt doordat een andere applicatie breekt met de nieuwere versie van jouw dependency.

De keerzijde is dat alle makers van Snaps zelf verantwoordelijk zijn voor het bijhouden van hun dependencies, maar dat hoeven ze in dat geval maar voor 1 Snap te doen (als die toch overal kan draaien). Bij een applicatie die dus niet meer onderhouden wordt (of slecht onderhouden) kan dat dus betekenen dat er een vulnerable dependency bij zit. Maar die is dan wel gebonden tot de sandbox van die applicatie, wat de attack surface weer wat verkleint.

.deb is oud?

Nee, .deb is anders. .deb is voor Debian (dus ook ubuntu) wat RPM is voor Red Hat: een package dat afhaneklijk kan zijn van andere packages. Als je alle libraries maar 1 keer op je PC geinstalleerd wilt hebben, en bij bijvoorbeeld een (veiligheids)bug in de JPG library slechts 1 bestand wilt hoeven te updaten, dan gebruik je .deb (of RPM). Als je een fat-binary wilt installeren die niet afhankelijk is van andere packages, dan kun je snap gebruiken. Een bug in bijvoorbeeld een compressiebibliotheek betekent echter wel dat alle apps die deze bibliotheek gebruiken (dus meegeleverd hebben) moeten worden geupdate. Mensen zien dat als een groot voordeel: als een library niet langer ondersteunt wordt dan kan je een oud (mogelijk lekke) versie blijven gebruiken, het draait toch in een sandbox. Opslagruimte en bandbreedte zijn niet meer zo beperkend tegenwoordig.

@zovty volgens mij zijn snaps juist om die dependency hell (die onder Linux nooit zo erg is geweest als onder Windows) op dezelfde matige manier op te lossen als onder Windows: elke depdendancy meeleveren.

[Reactie gewijzigd door 84hannes op 12 april 2017 10:46]

@zovty volgens mij zijn snaps juist om die dependency hell (die onder Linux nooit zo erg is geweest als onder Windows) op dezelfde matige manier op te lossen als onder Windows: elke depdendancy meeleveren.

De dependency hell op Windows is op te lossen door de dependencies in de map naast de executable te droppen als je ze niet in je systeem wilt hebben.

Ik heb werkelijkwaar nog nooit de CLI in moeten duiken om handmatig wat symlinks te plaatsen omdat één of andere applicatie LibHell2.2.2.5 nodig heeft en LibHell2.2.2.6 geinstalleerd stond. Of de oh zo leuke LibHell2.2.2.5 nodig hebben, en dan staat er Lib-Hell-2-2-2-5 geinstalleerd, want oja oeps, de ene distro moet het zo nodig anders doen.

Het ergste op Windows is even de DLL opzoeken en dat naast je .exe droppen of even een setup.exe starten om de missende boel te installeren, welke 99/100 keer meegeleverd wordt met de software/game die het nodig heeft. De meeste half-native Windows meuk zoals de .Netjes e.d. pakt Windows helemaal zelf al en zal het je alleen vragen of hij dit voor je klaar mag zetten.

Mensen die dat als voordeel zien hebben nog nooit met windows en haar dependency hell gewerkt.

Dependency hell is nog iets anders. Maar het klopt wel dat Windiws gelijkaardige mechanismen kent waarbij Windows altijd eerst in de folder van de .exe zal kijken voor dependencies voor het de systeemwijde .dlls zal gaan gebruiken.

Dependency Hell is iets waar alle besturingssystemen last van hebben en is zeker niet een Windows-specifiek iets.

@zovty volgens mij zijn snaps juist om die dependency hell (die onder Linux nooit zo erg is geweest als onder Windows) op dezelfde matige manier op te lossen als onder Windows: elke depdendancy meeleveren.

Maar toch heb ikzelf tijdens gebruik vaker last gehad bij Linux van die dependancy hell dan bij Windows.
Als normale gebruiker of beginnende Linux gebruiker kan de visie anders zijn dan als ontwikkelaar of meer ervaren Linux gebruiker.

Hmmm, ik herinner me nog de win 98 hell met al die dll's. Laatste jaren idd veel verbetering bij Windows wat dat betreft

Dat is waar ook

Tja, het is niet echt fair om een 19 jaar oud OS erbij te slepen... natuurlijk zijn er sindsdien dingen verbeterd, bij zowel Windows als Linux.

Snap heeft het voordeel dat als je twee verschillende versies van een dependency moet hebben, je alleen het een of het andere kan kiezen; je kan geen twee verschillende versies van een pakket met dezelfde naam hebben. Dat is het probleem dat Snap oplost door alle dependencies apart te installeren.

Het grote nadeel is dat Snap ervoor zorgt dat je verouderde packages gebruikt, ook al is dat maar voor 1 doel, het kan nog steeds een beveiligingsprobleem zijn. het geeft ook developers een reden om niet elke keer de laatste library/dependency te gebruiken.

[Reactie gewijzigd door MrFax op 12 april 2017 13:53]

Het kan ook een voordeel zijn; er is geen enkele garantie dat nieuwe versies niet juist beveiligingsrisico's introduceren. Dat gebeurt ook regelmatig. Voorlopig is het nog steeds een beetje dweilen met de kraan open.

het geeft ook developers een reden om niet elke keer de laatste library/dependency te gebruiken.

Dat is geen reden, ook geen excuus, maar een kans. Ze krijgen de kans om niet de laatste versie van een library te moeten gebruiken.

Toch: Zolang die Snap packages niet in een sandbox draaien, is het een groot beveiligingsrisico, vindt je niet?

Ja, .deb is oud. Maar zeker niet verouderd. Snapd en Flatpak lossen een aantal beperkingen op die je met .deb hebt, denk daarbij aan het makkelijker, flexibeler kunnen distribueren van nieuwe versies van applicaties. Zoals altijd zitten aan deze techniek voordelen en nadelen.

Ik verwacht dat .deb de basis blijft voor de stabiele onderlaag van het OS, maar applicaties zullen steeds vaker via oplossingen als Snap of Flatpak worden aangeboden.

[Reactie gewijzigd door zordaz op 12 april 2017 10:58]

Als ik moet kiezen voor een snap of een .deb zal ik toch echt voor de deb kiezen. De snap mag dan wel afgeschermd draaien, als devs hun security niet op orde hebben blijft alle info waar de snap toegang toe heeft slecht afgeschermd.

Dat is ook zeker een van de belangrijkste nadelen; ontwikkelaars moeten inderdaad hun security op orde hebben...

Er zijn overigens best wat parallellen te trekken tussen Snap/Flatpak en de wijze waarop applicaties op Apple en Android gedistribueerd en geinstalleerd worden.

[Reactie gewijzigd door zordaz op 12 april 2017 10:52]

Oud, ja. Obsolete, nee.

edit:
De titel was voorheen "Fedora ondersteunt Snap" maar is nu aangepast. Onderstaand bericht sloeg op de oude titel

De titel verbaasde mij enigszins, omdat hij doet vermoeden dat Fedora (en dus RedHat) standaard ondersteuning inbouwt voor Snap terwijl dat direct concurreert met hun eigen Flatpak. Het blijk dus echter dat Canonical Snap nu ook op Fedora ondersteunt.

Alhoewel ik geen van beide formaten nog heb gebruikt, ben ik wel enorm benieuwd welke van de twee de meeste support gaat krijgen van de app bouwers.

[Reactie gewijzigd door kramer65 op 12 april 2017 10:40]

Snap was verschrikkelijk makkelijk in het gebruik. Een enkele definitie file, die Michael Hall voor me had gemaakt, en ik kan snaps van Krita maken zonder moeite. Het is nog niemand gelukt om een flatpak van Krita te maken. Maar de appimages die ik maak worden nog veel vaker gedownload.

Is Etcher hetzelfde eigenlijk? Wel frapant eigenlijk. Ze maken het dus klaar voor fedora maar zonder beveiliging. En vragen de beveiliging van Fedora om de beveiliging up te daten. Beetje krom.

[Reactie gewijzigd door rob12424 op 12 april 2017 10:25]

Fijn.

Er wordt echter gesproken op de achtergrond dat Flatpak en Snaps wellicht beide naast elkaar blijven bestaan voor verschillende doelen. Flatpak voor gebruikers en Snaps voor servers. Hier was een korte discussie over bij...ik geloof de Linux actionshow of Lunduke (sorry, ik slurp zoveel info op dat bronnen onthouden wat lastig is). Er werd in ieder geval over gespeculeerd.

Uiteindelijk zal adaptatie door gebruikers de 'winnaar' bepalen maar uit ervaring weet ik dat beide standaarden erg lang naast elkaar zullen blijven bestaan. (jaren zo niet decennia). Maar fijn dat Fedora support voor Snaps heeft toegevoegd.

@Mmore; Bedankt.

[Reactie gewijzigd door Auredium op 12 april 2017 11:16]

Snaps voor servers? Denk het niet hoor. Snaps ruilen veiligheidsaspecten (oude libraries) om voor het makkelijk kunnen installeren, en laten de meeste serverbeheerders nou totaal geen problemen hebben met het installeren van software, en degelijke serverbeheerders geven wel om veiligheid. Ik denk niet dat ik snel een snap of flatpak zou installeren op servers die ik beheer.

Wat ik begrijp van die snaps is dat het vooral handig zou moeten zijn voor een soort cross-platform "app store" die onder iedere Linux-distro werkt waar het snap-systeem zelf op draait. Oftewel voor eindgebruikers. Ik had willen zeggen "apparaten zoals smartphones" maar daar is canonical al mee gestopt. Vraag me af wie dan nu de doelgroep is van de snaps, aangezien de deb-repositories al alles bevatten wat ik nodig heb.

Brian Lunduke had het erover in de aflevering met Jono Bacon inderdaad.

Er staat dat deze techniek meer veiligheid biedt, maar in hoeverre klopt dit?
Stel een Flatpak/Snap heeft een verouderde ssl-lib waar nog een exploit in zit, in hoeverre is dit gevaarlijk voor het systeem zelf? Zo te lezen zou SELinux of Appammor dit moeten tegenhouden, maar gebeurd dit dan wel? Krijgen we dan DLL-hell op Linux?

[Reactie gewijzigd door HollowGamer op 12 april 2017 10:43]

Krijgen we dan DLL-hell op Linux?

We krijgen geen DLL-hell want we gebruiken geen dynamische geladen bibliotheken (waarschijnlijk binnenin de Snapp-app wel, maar die worden meegeleverd dus die moeten passen bij de executable). DLL-hell krijg je als je afhankelijk bent van DLL's die niet meegeleverd zijn bij een executable.

Dependency hell krijg je als er geen consistent systeem voor versioning is, dependencies allemaal centraal staan, je niet meerdere versies van een package kunt hebben staan, dependencies niet los bijgeleverd kunnen worden of dependencies niet op versie gelocked kunnen worden, of ontwikkelaars slordig met updates om gaan.

Zelfs al heb je al die zaken op orde, dan nog krijg je dependency hell. Het is een van de meest ingewikkelde problemen om op te lossen in de IT. Hele development methodologieen zijn er op gericht om de evolutie van software soepel te laten verlopen. En dan nog gaat het regelmatig mis.

Je hebt geen snaps nodig om je applicaties in een selinux- of apparmor jail te zetten. Dat kan prima met rpm's en deb's. Volgens mij is het security-verhaal dan ook voornamelijk zoeken naar argumenten om het systeem te promoten terwijl het eigenlijk niet zo veel oplost. Dependencies is er in ieder geval niet een van. Ik heb met rpm's en deb's ook nooit dependency-problemen, die worden allemaal op elkaar afgestemd door de distro-bouwer.

Daar breng je inderdaad een goed punt: zodra een package niet compatibel is met dependencies die in de repo's zitten (bijvoorbeeld niet de laatste ssl lib), meld ik dit als bug of probeer het opnieuw te compilen tegen de laatste versie.
Toegegeven dat dit niet voor elke gebruiker de oplossing is, maar dit lijkt me eerder een workaround die er niet hoeft te zijn. De package manager zorgt er toch juist voor dat elk pakket werkt met de juiste deps en dat het geheel logisch en gestructureerd in elkaar zit, waarom wil je hier dan vanaf stappen?

Wat nu als packages obsolete raken, die kan je dus oneindig blijven draaien maar wel met een enorm risico aan veiligheid issues, bugs en oude libraries die totaal niet matchen in de huidige GTK versie (om maar wat te noemen).