Ubuntu's snap-apps werken nu op praktisch elke Linux-distributie

Canonical heeft aangekondigd dat de mogelijkheid om 'snap'-packages te installeren is geport naar andere Linux-distributies. Om precies te zijn is of wordt snapd geport naar onder andere Arch, Fedora, Debian, RHEL, CentOS en Gentoo.

Daarmee moet het in theorie makkelijker worden om applicaties voor verschillende distributies aan te bieden, doordat alle afhankelijkheden of dependencies in de snap-package zijn verpakt. Canonical ontwikkelde het snap-systeem in eerste instantie voor Ubuntu Phone en Ubuntu Snappy Core, zodat applicaties in hun eigen container draaien en zo een kleiner beveiligingsrisico vormen.

Met het snapcraft.io-platform hoopt Canonical deze vorm van pakketbeheer voor Linux tot een standaard te verheffen. Met snaps moet het voor ontwikkelaars makkelijker worden om software te publiceren, doordat een ontwikkelaar geen verschillende repositories en andere updatemechanismen meer hoeft bij te houden. Naast updates kan een ontwikkelaar zelf ook een update terugdraaien, wat vooral handig is op apparaten zonder beeldscherm en dergelijke, zoals internet-of-things-apparaten. Ook is het mogelijk om incrementele updates toe te voegen.

Mark Shuttleworth, oprichter van Canonical, heeft tijdens een presscall gezegd dat het project niet alleen door Canonical gedragen wordt, maar ook door ontwikkelaars van andere Linux-distributies, zoals Arch en Gentoo.

Tijdens dezelfde presscall over de introductie van snapd voor andere distributies, werden ook vragen gesteld over andere systemen met een vergelijkbaar doel, zoals Flatpak, App Image en Orbital Apps. Volgens Shuttleworth wordt heden ten dage zo'n '95 procent van de commits' door één werknemer van Red Hat gedaan bij Flatpak. Flatpak is de nieuwe naam van de Freedesktop.org xdg-app en daar is ook een specifieke Ubuntu-repository van.

Een andere interessante vraag tijdens het gesprek was of het mogelijk zou zijn het systeem naar Android te porten. Volgens OMG Ubuntu was Shuttleworth' antwoord daarop dat dit een goed idee zou zijn. Hij voegde eraan toe dat 'als OpenWRT snaps in minder dan een week aan de praat heeft', hij 'verbaasd zou zijn als Android niet iets vergelijkbaars zou kunnen regelen'.

Van de bekendere grote applicaties is onder andere van LibreOffice 5.2.0 bèta 2 een snap beschikbaar. Ook Mozilla heeft aangekondigd Firefox over niet al te lange tijd als snap te willen leveren.

Reacties (42)

Van wat ik begrepen heb is het een trade-off. Een groot dev. probleem is dat sommige distro's nogal eens oudere versies van software erop na houden. Het gevolg is dat developers echt idioot veel builds moeten maken en heel veel verschillende versies moeten ondersteunen voor een enkel pakket.

Door technologie zoals Snap-packages wordt dit nadeel weg gewerkt. Een nadeel van snap is echter vervolgens weer dat men de dependancies in de packages zelf moet updaten wat een grotere verantwoordelijkheid legt bij de developers. Dit kan leiden tot (populaire) software die niet goed wordt bijgewerkt en dus ondanks de sandbox beveiligingsrisico's bij zich brengt.

Voor developers is de nieuwe methode echter eenvoudiger met implementatie en ondersteuningen en is het voor bedrijven commercieel aantrekkelijker.

That said...Snap is slechts 1 enkele technologie. Er is momenteel een soort packagewars bezig in voor de heersende package distro te worden. Ubuntu had Snap welke bij 16.04 mee kwam. Een klacht ervan destijds was dat hiermee Ubuntu zijn eigen eilandje werd. Nu is dat opgelost omdat Ubuntu alsook de community er rondomheen veel werk heeft gestoken in het porten van de technologie naar andere disto's.

Persoonlijk snap ik het beveiligingsrisico en zullen er vast wel momenten zijn waarop gebruikers daardoor in de staart worden gebeten. Echter maakt Linux momenteel een redelijke groei door en zie ik ook wel in dat nieuwe developers en softwareproducenten van traditionele platforms zoals Windows niet echt graag een O.S. in willen springen waar ze moeten kiezen voor 1 distro tak of het maken van 15 verschillende versies voor alle Linux distro's.

[Reactie gewijzigd door Auredium op 15 juni 2016 14:00]

Het is het ouderwetse probleem van dependency hell waar geen éénduidig antwoord voor is.

Dit systeem kan handig zijn, mits het wordt aangegeven wanneer de meegeleverde dependencies als onveilig worden beschouwd en in welke scenario's. Bijvoorbeeld: een OpenSSL library die kwetsbaar is voor iets als Heartbleed heeft weinig impact als het alleen lokaal in zijn eigen sandbox (geen netwerkfunctionaliteit) gebruikt wordt om hashes te genereren.

Snaps leggen de verantwoordelijkheid neer bij de ontwikkelaar. Als het die makkelijk wordt gemaakt om snel een nieuw package te genereren met alle libraries up-to-date, dan kan het iets krachtigs zijn omdat dat package (per uitgegeven update) maar éénmaal getest hoeft te worden en vervolgens op de meeste Linux distributies draait. Een ontwikkelaar kan ook besluiten om door een tijdelijke bug in een dependency een kleine downgrade te doen, wat niet altijd lijdt tot een securityprobleem, om dit vervolgens in een latere versie in te halen.

Het kan dus krachtig zijn, maar je moet verantwoordelijke ontwikkelaars hebben. Als banken die al niet hebben (zie APK's van Android die SSL/TLS verificatie niet goed uitvoerden), wat kan je dan verwachten van anderen? Ja, er zijn zat vrijwilligers met passie en liefde. En er zijn ook luie vrijwilligers en commerciële partijen die liever ergens zo min mogelijk tijd in steken.

[Reactie gewijzigd door The Zep Man op 15 juni 2016 15:33]

Voor developers is de nieuwe methode echter eenvoudiger met implementatie en ondersteuningen en is het voor bedrijven commercieel aantrekkelijker.

Dat klopt en ik vrees dat Snaps daarom een succes worden. Het is een beetje als milieuvervuiling, het is makkelijk en goedkoop om olie te verbranden, zolang je geen rekening hoeft te houden met de vervuiling. Als het ware komt de rekening terecht bij toekomstige generaties. Zo zie ik snaps ook. Het is een handige techniek om nu snel software uit te brengen maar het betalen van de technische rekening wordt uitgesteld. Vroeg of laat zal dat een keer moeten gebeuren, maar hoe langer je blijft "lenen" hoe hoger de uiteindelijke rekening zal zijn.

In de IT hebben we altijd al vrijwing gehad tussen "dev" en "ops". Developers en Operators hebben nu eenmaal andere behoeftes, wensen en eisen. Er is een reden waarom ieder groot bedrijf in de wereld een IT-afdeling heeft die sotware kiest, test en installeeert in plaats van blind doosjes software van de mediamarkt te installeren. Er is een reden waarom Linux distributies heeft met packagers die er voor zorgen dat software goed intergreert met de rest van het systeem. Er is een reden waarom vrijwel ieder softwarebedrijf in de wereld een afdeling "verkoop" en een afdeling "ondersteuning" heeft met andere mensen dan de developers zelf. Het is van alle tijden dat "dev" en "ops" een compromis moeten sluiten om zowel voor de belangen van de ontwikkelaars als de belangen van de gebruikers te zorgen.

Containers, en zeker snaps, worden nogal eens gebruikt door developers om ops te ontwijken. "Ik doe het zelf wel dan heb ik geen last van de vervelende regeltje van ops, als developer weet ik toch wel wat het beste voor mijn gebruikers is", is al snel de gedachte. Dat al die vervelende regeltjes en beperkingen er met een reden zijn wordt maar even vergeten.

Laat ik OpenSSL nog maar eens als voorbeeld gebruiken. Hoeveel developers snappen nu echt hoe OpenSSL werkt en hoe alle subtiele instellingen met elkaar samen hangen? Niet veel, dat durf ik te garanderen, daar is OpenSSL veel te ingewikkeld voor*. Ik weet zeker dat 99 van de 100 developers die OpenSSL gebruiken niet op de OpenSSL-mailinglijst zitten om wek^wdagelijks te kijken over er nog security-patches zijn die moeten worden toegepast. Waarschijnlijk bevatten de meeste Snaps over een jaar oude versies van OpenSSL die vol gaten zitten maar niet worden gepatched tot de maker van de snap een nieuwe versie van z'n eigen software uitbrengt, als dat ooit nog gebeurt.

* Dat OpenSSL zo belachelijk moeilijk is, is een probleem op zich maar dat is een ander verhaal.

Betekent dat dan niet ook dat elk programma andere versies van dependencies gebruikt? Dus ook oudere versies?

Lijkt me ook extra ruimte in beslag nemen.

Edit: typo.

[Reactie gewijzigd door SipartiX op 15 juni 2016 13:24]

Ja dat zal mogelijk kunnen zijn. Ik vind t ook wat lastig in te schatten op t gebied van security zo. Ik ben al gewend om te werken met programma's zoals ze aangeboden worden in de repo. Mis ik daardoor iets wat bleeding edge is, en erg mooi, dan ga ik in de geduld modus, het komt ooit naar mijn distro (Debian testing).

Ik vraag me ook af of het kan met grotere pakketten, zoals Gnome, of je dan de nieuwste als snap kan draaien, maar dat alle bijkomende apps gewoon uit de repo kunnen komen, of dan ook snap moeten...

Voor standalone spul kan ik me hier nog wel het voordeel van voorstellen, maar ik zie mijn desktop toch min of meer als geheel met alle programma's die ik erbij heb staan. Het onderhoud is met repo-software een simpele update en 't is weer bij, maar hoe werkt dat als je 10 verschillende snaps hebt?

edit:
snaps updaten zichzelf daily blijkbaar. erg afhankelijk van de bron dus of een snap veilig is of niet. Dit gaat de nieuwe .exe worden. Software installatie op Linux wordt er toegankelijker van, maar ik zie de snaps al op elke download.com-website opduiken. Exe's geleverd met wine in een snap. En zo komen de virussen naar je distro.

Ik heb die snapverhalen even doorgelezen, maar het komt me erg hyped over. Ontwikkelaars vinden dit geweldig allemaal. Ze roepen veilig en snel, en minder gedoe voor 't packagen. Maar ik denk dat het hip is om een (sn)app achtig systeem te hebben, modern, zoals het hebben van een app op android hip is voor een bedrijf.

Ik heb nu al een aversie. Ik wil tegen een snap kunnen zeggen wat ie wel en niet mag. Mag de snap bij mijn mail? of mijn gelinkte accounts inzien? of mijn bestanden op mijn home doorbladeren? de configuratie van mijn websites en certificaten zien? Kan ik dat regelen/instellen per snap?

Ik voel me ineens hopeloos ouderwets kritisch.

[Reactie gewijzigd door Mar2zz op 15 juni 2016 13:43]

Ja dat zal mogelijk kunnen zijn. Ik vind t ook wat lastig in te schatten op t gebied van security zo. Ik ben al gewend om te werken met programma's zoals ze aangeboden worden in de repo. Mis ik daardoor iets wat bleeding edge is, en erg mooi, dan ga ik in de geduld modus, het komt ooit naar mijn distro (Debian testing).

Ik vraag me ook af of het kan met grotere pakketten, zoals Gnome, of je dan de nieuwste als snap kan draaien, maar dat alle bijkomende apps gewoon uit de repo kunnen komen, of dan ook snap moeten...

Het "probleem" word niet echt opgelost maar omzeilt door alle libs van de dev mee te leveren. Dan heb je niet meer dat "lastige" "it works on my machine"...
Alsof we alles weer statically gaan linken...

Voor standalone spul kan ik me hier nog wel het voordeel van voorstellen, maar ik zie mijn desktop toch min of meer als geheel met alle programma's die ik erbij heb staan. Het onderhoud is met repo-software een simpele update en 't is weer bij, maar hoe werkt dat als je 10 verschillende snaps hebt?

Dat werkt niet echt omdat je je rot zoekt welke lib in welke snap nou rot is. Of security flaw.
Eerst kon ik bij een CVE mn kwaadaardige lib updaten en mn systeem bijwerken. Nu zou je afhankelijk worden van deze individuele maintainers. (waar ik al niet zo'n hoge pet van op hebt als je je probleem niet GOED kan oplossen en het omzeilt met een snap)

snaps updaten zichzelf daily blijkbaar. erg afhankelijk van de bron dus of een snap veilig is of niet. Dit gaat de nieuwe .exe worden. Software installatie op Linux wordt er toegankelijker van, maar ik zie de snaps al op elke download.com-website opduiken. Exe's geleverd met wine in een snap. En zo komen de virussen naar je distro.

Inderdaad. Dat automatisch is al helemaal eng. Weg controle.

Ik heb die snapverhalen even doorgelezen, maar het komt me erg hyped over. Ontwikkelaars vinden dit geweldig allemaal. Ze roepen veilig en snel, en minder gedoe voor 't packagen. Maar ik denk dat het hip is om een (sn)app achtig systeem te hebben, modern, zoals het hebben van een app op android hip is voor een bedrijf.

Voornamelijk developers die niks willen weten van een eco systeem hemelen het de lucht in. Meeste distro maintainers doet het pijn aan de ogen. En inderdaad dit vind zijn oorsprong in de "apps" waar een hoop beunhazen zitten, die linux maar een moeilijk verhaal vinden.

Ik heb nu al een aversie. Ik wil tegen een snap kunnen zeggen wat ie wel en niet mag. Mag de snap bij mijn mail? of mijn gelinkte accounts inzien? of mijn bestanden op mijn home doorbladeren? de configuratie van mijn websites en certificaten zien? Kan ik dat regelen/instellen per snap?

Ik voel me ineens hopeloos ouderwets kritisch.

Neuh. Je hebt veel ervaring en je (terechte) gevoel geeft het signaal "uhoh" en dat is niet voor niks.

Zie onder ander ook de uitleg in de 16.04-review op pagina 3 over de werking van snaps: reviews: Ubuntu 16.04: meer dan een bugfix-release

Overigens na wat pielen met snap, je kunt met
snap find
ontdekken welke snaps al in de Ubuntu repo's zitten

Installeren werkt met
sudo snap install <snappakketnaam>

Verwijderen:
sudo snap remove <snappakketnaam>

Gek genoeg werkt het installeren van snaps via het Ubuntu Software Centre met de eis dat je een Ubuntu-account hebt. Op Ubuntu Phone is dat ook al zo. Beetje wonderlijk dat je daar dan niet omheen kunt.

Installeren via command line vraagt daar niet om.

(edit: handig, code-tags werken niet hier natuurlijk...)

[Reactie gewijzigd door letatcest op 15 juni 2016 15:14]

Bedankt voor t artikel. Toen wel gelezen maar weinig aandacht aan snaps besteed. Snaps zijn zie ik nu in het nieuwe alternatief voor wat je veel ziet als software buiten de repo om geïnstalleerd moet worden. Op websites kon je dan een .deb, .rpm, tar.gz vinden en daarmee aan de slag. In dat opzicht biedt een snap wel veel voordelen als het inderdaad over alle populaire distro's gedragen wordt.

Dit is op zich wel handig als je dat doet. Maar dat deed ik al nooit vanuit het oogpunt security (vanwege het zelf steeds in de gaten moeten houden en op moeten halen van nieuwe updates van de website zelf).

De losse .deb, .rpm's en dergelijke zullen dus wel verdwijnen door snaps. Dat lijkt me een goeie zaak. Ik hou 't wel bij wat de debian developers in goede balans op t systeem aanbieden via de repo's.

lijkt me vooral ook handig voor forks van de hoofd-distributies waarop die rpm's etc vaak niet (goed) werken en verouderde versies van software in hun repository heeft zitten (Zelfs Mint heeft hier al last van).
Zo'n systeem zou dus de diversiteit van (kleine) distro's ten goede kunnen komen omdat ze zonder moeite alle software kunnen ondersteunen.
Ben alleen bang dat je naast je .deb en .rpm nu ook .snap en .flatpack's zal krijgen, of dat je anders op je OS allebei de systemen moet gaan ondersteunen.

Als je 10 verschillende snaps draait, ben je afhankelijk van de ontwikkelaar welke versie dependenties je draait per snap.
Vergelijk het met een kamer waar 10 aquariums in staan:
iedere vis (applicatie) heeft andere leefomstandigheden (dependenties) nodig, maar deze aquariums worden wel als een pakket met vis verkocht (de snap applicatie). dus ook al hebben sommige vissen dezelfde behoeften, zullen deze alsnog apart met het pakket meekomen.

Het onderhoud is met repo-software een simpele update en 't is weer bij, maar hoe werkt dat als je 10 verschillende snaps hebt?

Zoals op iOS / Android, op zich geen probleem lijkt me.

Software installatie op Linux wordt er toegankelijker van, maar ik zie de snaps al op elke download.com-website opduiken. Exe's geleverd met wine in een snap. En zo komen de virussen naar je distro.

Volgens mij kunnen groepen mensen nog steeds 'repositories' voor "snaps" hebben, net zoals Android een repository (Google Play) heeft voor Android-applicaties, en apps met virussen kunnen ze hieruit weren.

Van wat ik ervan begrijp kan men inderdaad eigen versies van libraries meeleveren in een snap. En dat betekend inderdaad ook een vergroot risico op verouderde, niet up-to-date versies van libraries op je systeem.

Het hele punt van het Debian beleid met zijn apt is net altijd geweest dat libraries gedeeld moeten worden zodat er slechts 1 iemand verantwoordelijk is voor een bepaalde bibliotheek en zodat je een bug slechts op 1 enkele plaats moet corrigeren om heel je systeem opnieuw veilig te maken. Met snaps lijkt het mij dan ook dat dit concept onderuit word gehaald en dat je iets begint te creëeren zoals de DLL hell op Windows, al zien we vandaag al wel wat software onder Linux dat zijn eigen libraries meeleverd ipv de systeemlibs te gebruiken (vooral closed source software).

Met snaps lijkt het mij dan ook dat dit concept onderuit word gehaald en dat je iets begint te creëeren zoals de DLL hell op Windows

Nee, snaps voorkomen toch juist de DLL-hell? Of snap ik het verkeerd?

DLL-hell is dat bijv. Gimp-x.y.z wil dat je glibc <2.21 hebt, en libreoffice-x.y.z wil glibc >2.23. Dan kan je niet beide versies tegelijk installeren. De DLL-hell op Linux wordt dus juist veroorzaakt door "shared libraries".

Maak je een snap, dan heeft Gimp-x.y.z zelf ook glibc 2.21 aan boord, en libreoffice-x.y.z heeft glibc-2.23 aan boord, ze kunnen allebei tegelijk draaien zonder conflicten; snap voorkomt dus juist de DLL-hell!

ed: En waar juist Debian enorm de mist in gaat, is dat ze met hun "megafreeze"-model niet kijken welke software stabiel is of door de makers geadviseerd wordt, maar gewoon de nieuwste versie die op dat moment beschikbaar is meeleveren, hoe brak die ook mag zijn en hoeveel adviezen de makers van de software ook uitgeven tegen het gebruik van de versie, de Debian-package mensen denken dat zij het beter weten.

Dus misschien werkt hun distributie wel met Gimp-x.y.z en LibreOffice-x.y.z, maar de makers van Gimp willen misschien helemaal niet dat je x.y.z gebruikt of wensen die versie niet te ondersteunen, omdat ze jou aanraden versie u.v.w. te gebruiken. Debian heeft daar doorgaans lak aan, dus juist dan is het ter voorkoming van DLL-hell fijn dat jij als gebruiker lak kan hebben aan Debian's package-beleid en gewoon de versie kan kiezen die de makers van de software jou adviseren.

[Reactie gewijzigd door kidde op 15 juni 2016 13:54]

Dus misschien werkt hun distributie wel met Gimp-x.y.z en LibreOffice-x.y.z, maar de makers van Gimp willen misschien helemaal niet dat je x.y.z gebruikt of wensen die versie niet te ondersteunen, omdat ze jou aanraden versie u.v.w. te gebruiken. Debian heeft daar doorgaans lak aan, dus juist dan is het ter voorkoming van DLL-hell fijn dat jij als gebruiker lak kan hebben aan Debian's package-beleid en gewoon de versie kan kiezen die de makers van de software jou adviseren.

Dat model werkt vanuit het oogpunt van de "primaire" pakketten van zo'n snap maar het gaat fourt voor alle andere software.

Stel dat Gimp en LibreOffice allebij een bepaald pakket nodig hebben zoals OpenSSL. Traditioneel heb je dan 1 kopie van libssl op je systeem en Gimp en LibreOffice zullen het daar mee moeten doen. De versie van OpenSSL die gebruikt wordt is gekozen door de packager, iemand typisch gespecialiseerd is op zo'n pakket en er alles van weet.
Als je een Snap maakt moet iemand besluiten welke versie van OpenSSL er in gestopt wordt. Zowel de ontwikkelaars van Gimp als van LibreOffice weten dat niet, het is niet hun specialiteit en ze zijn gewend om die beslissing aan de distributie over te laten. Waarschijnlijk nemen ze dus de eerste de beste versie die voor handen is en kijken ze er nooit meer naar om. Over drie jaar heb je waarschijnlijk wel de nieuwste versie van Gimp of LO maar nog steeds dezelfde versies van OpenSSL met alle bugs die daar bij horen. Herhaal dat verhaal voor de 300 andere dependencies die deze software heeft.

Sterker nog, waarschijnlijk wordt de neiging om nooit meer iets te updaten alleen maar groter. Programmeurs gaan er immers aan wennen dat ze allemaal altijd precies hetzelfde systeem gebruiken. Daarmee verdwijnt de flexibiliteit die veel software nu heeft om met wisselende omstandigheden om te gaan. Zo'n monocultuur is een incubator voor bugs. In een diverse wereld vind je complexe bugs door verschillende versies en implementaties te gebruiken. Dat voorkomt dat je onderbewust rekening gaat houden met bugs van een bepaalde implementatie.. Enige diversiteit voorkomt dat.

Dan zijn we het eens dat we het daarover oneens zijn:

-Als een LibreOffice-maker een willekeurige OpenSSL kiest, pakt hij gewoon een van de bron zonder deze te wijzigen. Juist de Debian-packager die er zogenaamd verstand van had verneukte OpenSSL en veroorzaakte een gapend veiligheidsgat: https://en.m.wikipedia.org/wiki/OpenSSL#cite_note-24

Als LibreOffice zelf snappy pakketjes maakt, kunnen juist alle LO-packagers van alle distributies helpen een goede package te maken ipv hetzelfde werk iedere keer opnieuw te doen voor iedere distributie. Nu is de LO-verpak kennis verdeeld over 10+ distributies, en die groepjes doen allemaal hetzelfde; enorme verspilling! Je laat ook niet 10 programmeurs dezelfde printer driver schrijven voor iedere distro apart.

Met Mir of Wayland kan je sandboxen: Als dan App A (of Debian) je OpenSSL verneukt hoeft App B daar geen last vam te hebben. Apps hebben dan vziw ook geen root-toegang tot het kern-systeem meer nodig, dus App A kan het kern-systeem niet meer verneuken.

De 'wisselende omstandigheden' die u roemt maken juist het ontwerp complexer (paar extra abstractie lagen om het op te lossen), en complexer betekent altijd meer bugs! In plaats van complexe bugs te vinden door diversiteit voorkom je liever complexe bugs door eenduidigheid en eenvoud.

Daarbij komt nog dat iedere keer dat App A een beveiligingsupdate heeft, deze eerst langs de pakket-beheerders van de distro moeten voordat ze worden goedgekeurd, een vertraging waardoor gebruikers onnodig lang kwetsbaar zijn.

Ik ben het natuurlijk wel met u eens in het geval van kleine minder actieve stukjes software waarbij geen updates meer geleverd worden, maar voor de grote actieve projecten wegen de voordelen zwaarder lijkt me.

[Reactie gewijzigd door kidde op 16 juni 2016 08:40]

-Als een LibreOffice-maker een willekeurige OpenSSL kiest, pakt hij gewoon een van de bron zonder deze te wijzigen.

Dat is volgens mij het eerste misverstand. Volgens mij is dat namelijk niet mogelijk. Er is ontzettend veel software die je niet zomaar kan installeren zonder dat het botst met andere software. Typisch is er ook niet één manier van installeren maar zijn er tientallen configuratie-opties waar uit gekozen kan worden. Iemand moet die keuze maken en de defaults zijn lang niet altijd universeel bruikbaar.
Als je software direct "van de bron" haalt zal iemand die keuzes moeten maken. Dat is het werk van een distributie. Als je de distributie er uit haalt dan moet de applicatie-bouwer die beslissingen nemen voor al z'n dependencies. Daarmee moet iedere applicatie dus zelf voor distributie spelen.

Juist de Debian-packager die er zogenaamd verstand van had verneukte OpenSSL en veroorzaakte een gapend veiligheidsgat: https://en.m.wikipedia.org/wiki/OpenSSL#cite_note-24

Fouten worden overal gemaakt, zelfs door de experts. Debian kan z'n probleem centraal oplossen. 1 pakket patchen en alles is weer goed. Dat gaat niet met snaps.

Als LibreOffice zelf snappy pakketjes maakt, kunnen juist alle LO-packagers van alle distributies helpen een goede package te maken ipv hetzelfde werk iedere keer opnieuw te doen voor iedere distributie. Nu is de LO-verpak kennis verdeeld over 10+ distributies, en die groepjes doen allemaal hetzelfde; enorme verspilling! Je laat ook niet 10 programmeurs dezelfde printer driver schrijven voor iedere distro apart.

Maar de packagers van LO moeten dan wel verstand hebben van alle ander software die ze in hun snap opnemen. Gaan ze ook iedere week kijken of al hun dependencies nog wel veilig zijn en voeren ze dan patches door?

Apps hebben dan vziw ook geen root-toegang tot het kern-systeem meer nodig, dus App A kan het kern-systeem niet meer verneuken.

Dat is een mooi aspect maar het neemt mijn bezwaren tegen andere aspecten niet weg en dan met name dat containers (want dat zijn snaps) slecht worden geupdate.
Bij een snap is de auteur niet alleen verantwoordelijk voor zijn eigen software maar ook voor alle dependencies en ik geloof gewoon niet dat ze dat netjes gaan bijhouden.

Daarbij komt nog dat iedere keer dat App A een beveiligingsupdate heeft, deze eerst langs de pakket-beheerders van de distro moeten voordat ze worden goedgekeurd, een vertraging waardoor gebruikers onnodig lang kwetsbaar zijn.

Dat probleem word nu verplaatst naar de snap-beheerders en daarmee wordt het nog veel groter. Nu moet iedere beveiligingsupdate langs de snap-beheerder en moet iedere applicatie worden bijgewerkt. We hebben een paar dozijn grote distributies maar duizenden applicaties.

Ik ben het natuurlijk wel met u eens in het geval van kleine minder actieve stukjes software waarbij geen updates meer geleverd worden, maar voor de grote actieve projecten wegen de voordelen zwaarder lijkt me.

Ook bij dit soort projecten is het gebruikelijk dat de developers vooral met hun eigen software bezig zijn en niet geinteresseerd zijn in het oplossen van problemen met hun onderliggende dependencies.
Ik ben het met je eens dat het model beter zal werken voor grote projecten met veel actieve developers. Voor applicaties als Drupal of Wordpress die bijna dagelijks bijgewerkt moeten worden zie ik het nog wel werken, maar als algemeen systeem om software te distribueren vind ik het vragen om problemen.

Ik begrijp het, wat beter is staat of valt bij de capaciteit, welwillendheid en vaardigheid van pakketbeheerders. Als ik het lees heeft u weinig vertrouwen in Snappy-beheerders en software van de bron halen. Mijn ervaring met Gentoo is dat je prima software bij de bron kan halen (configuratie moet je dan wel zelf doen, dat is minder) , en mijn idee zou zijn dat alle bestaande packagers van 10+ distro's voortaan samen werken met elkaar en met upstream aan de snappy's, dan is er 10x zoveel capaciteit per pakketje om de boel up to date te houden. Ideaal gezien heeft een specifieke snappy een lijstje met dependencies en kan een snappy-repository manager snel uitvinden als een dependency kwetsbaar is, welke snappy's er gebruik van maken en die beheerders informeren. Misschien te utopisch...

Ik begrijp het, wat beter is staat of valt bij de capaciteit, welwillendheid en vaardigheid van pakketbeheerders. Als ik het lees heeft u weinig vertrouwen in Snappy-beheerders \\

Klopt, ik zie vooral developers en eindgebruikers die het huidige systeem te veel werk vinden en denken dat het met Snappy makkelijker wordt. Volgens mij is het meer werk om het goed te doen, niet minder.

en software van de bron halen. Mijn ervaring met Gentoo is dat je prima software bij de bron kan halen (configuratie moet je dan wel zelf doen, dat is minder) ,

Dat is precies het hele probleem. De kern van een distributie is dat er een standaard is voor het configureren van software en dat de packagers zorgen dat alle software wordt geconfigureerd om die standaard te volgen. Je kan zeggen dat die standaarden niet nodig zijn maar vroeg of laat krijg je dan conflicten. .

en mijn idee zou zijn dat alle bestaande packagers van 10+ distro's voortaan samen werken met elkaar en met upstream aan de snappy's, dan is er 10x zoveel capaciteit per pakketje om de boel up to date te houden.

Als je packagers van verschillende distributies laat samenwerken zullen ze een standaard moeten kiezen voor hun samenwerking. Dan ben je eigenlijk distributie-in-het-klein aan het spelen.
Daarbij is ieder stuk software dat je zelf vanaf source installeert een extra stuk werk, je zal die software ook moeten beheren, ook al gaat het je eigenlijk alleen om de hoofd applicatie. Voor iedere applicatie al dat werk opnieuw doen.

Ideaal gezien heeft een specifieke snappy een lijstje met dependencies en kan een snappy-repository manager snel uitvinden als een dependency kwetsbaar is, welke snappy's er gebruik van maken en die beheerders informeren. Misschien te utopisch...

Dan ben je eigenlijk weer een package-manager aan het uitvinden. Iedere keer dat er een libje wordt geupdate moet je alle snaps die daar van afhangen opnieuw bouwen. Als je een paar dozijn snaps hebt met een paar dozijn dependencies per snap dan durf ik haast te garanderen dat je ze iedere dag opnieuw moet bouwen. In praktijk verwacht ik dat de meeste mensen dit niet gaan doen, ze willen juist containers om de boel constant te houden ipv voortdurend in flux. Het gevolg is dat er dus bergen oude libjes in gebruik blijven omdat de snap niet wordt bijgewerkt.

Dan zijn we het eens dat we het daarover oneens zijn:

-Als een LibreOffice-maker een willekeurige OpenSSL kiest, pakt hij gewoon een van de bron zonder deze te wijzigen. Juist de Debian-packager die er zogenaamd verstand van had verneukte OpenSSL en veroorzaakte een gapend veiligheidsgat: https://en.m.wikipedia.org/wiki/OpenSSL#cite_note-24

Dat is een enkel voorbeeld en representeert niet de rest.

Als LibreOffice zelf snappy pakketjes maakt, kunnen juist alle LO-packagers van alle distributies helpen een goede package te maken ipv hetzelfde werk iedere keer opnieuw te doen voor iedere distributie. Nu is de LO-verpak kennis verdeeld over 10+ distributies, en die groepjes doen allemaal hetzelfde; enorme verspilling! Je laat ook niet 10 programmeurs dezelfde printer driver schrijven voor iedere distro apart.

Dat "zelfde" werk wat je daar noemt zorgt er juist voor dat fixxes gedeeld worden. De kracht van opensource. Dat "werk overnieuw doen" valt JUIST heel erg mee hierdoor.

Met Mir of Wayland kan je sandboxen: Als dan App A (of Debian) je OpenSSL verneukt hoeft App B daar geen last vam te hebben. Apps hebben dan vziw ook geen root-toegang tot het kern-systeem meer nodig, dus App A kan het kern-systeem niet meer verneuken.

Die device cgroup en apparmor is niet volledige afscherming. Het is een poging en mijn optiek eigenlijk ook de meest waardevolle toevoeging van snappy. Niet het complete libraries meeleveren "want het is zoveel werk"...

De 'wisselende omstandigheden' die u roemt maken juist het ontwerp complexer (paar extra abstractie lagen om het op te lossen), en complexer betekent altijd meer bugs! In plaats van complexe bugs te vinden door diversiteit voorkom je liever complexe bugs door eenduidigheid en eenvoud.

Daarbij komt nog dat iedere keer dat App A een beveiligingsupdate heeft, deze eerst langs de pakket-beheerders van de distro moeten voordat ze worden goedgekeurd, een vertraging waardoor gebruikers onnodig lang kwetsbaar zijn.

Ik ben het natuurlijk wel met u eens in het geval van kleine minder actieve stukjes software waarbij geen updates meer geleverd worden, maar voor de grote actieve projecten wegen de voordelen zwaarder lijkt me.

Ik denk dat ik er precies van de andere kant naar kijk. Als packager doe ik liever "meer" werk zodat iedere distro er baat bij heeft ipv mijn eigen kleine eilandje en "fuck de rest, je leeft er maar mee" want dat is basically wat snappy is.

Dat lijkt zo. Het probleem word enkel gemaskeerd en niet opgelost.

Op welke manier? Kunt u dit onderbouwen?

Zeg maar je
Je zou eventueel ook zelf even kunnen onderzoeken natuurlijk, maar:
Als een bugfix in een belangrijke lib komt en deze breekt functionaliteit in een applicatie dan word nu de applicatie "geforceerd" de nieuwe api/correcte functie te gebruiken waar dat in de toekomst met dit systeem niet meer gaat gebeuren. "Is meer werk voor maintainer van pakket"...

het draait in een container, dus alleen de applicatie is kwetsbaar niet je systeem.

Was het maar zo'n feest... Alleen je openssl package is kwetsbaar, je systeem verder nog compleet veilig hoor!

Toch heeft hij wel een punt. Als een snap een kwetsbare versie van OpenSSL meelevert dan is enkel de software uit dezelfde snap kwetsbaar. Omdat het in een container draait blijft de schade beperkt.

Ah zo, ja dat is dan wel weer waar. T zou best of both worlds Zijn als je per snap de dependances kon upgraden

Volgens Canonical wordt wel gekeken naar al geïnstalleerde pakketten, zodat het uiteindelijk niet veel groter wordt dan deb-pakketten. Maar dat klinkt nogal tegenstrijdig met de manier waarop snap steeds wordt uitgelegd, dus ik ben benieuwd hoe dat nu precies in de praktijk werkt.

Als een benodigd pakket reeds door het OS geinstalleerd/meegeleverd wordt kan een snap wellicht die gebruiken? Is er een andere versie nodig dan kan de snap die zelf meeleveren. Lijkt me niet heel spannend

"Wij zorgen voor de lunch. Als er niet genoeg eten is voor iedereen kun je beter je eigen lunch meenemen"
Je zult dus voor de zekerheid altijd je lunch mee moeten nemen.

Is er een andere versie nodig dan kan de snap die zelf meeleveren.

De Snap moet dus altijd zijn eigen versie meeleveren van elke library die hij ooit nodig heeft.

[Reactie gewijzigd door 84hannes op 15 juni 2016 15:53]

Is snap dus een soort docker/container ?

Nee. Een Docker image is een volledig gevirtualiseerd OS. Een Snap is meer als een .APK voor Android.

Een package manager die containers gebruikt en wat default veiligheidsinstellingen (device cgroup & AppArmor) om het te scheiden.

Each snap is confined using a range of kernel isolation and security mechanisms, tailored to the snap, ensuring that vulnerabilities in the application are contained to the greatest degree currently possible. A careful review process ensures that snaps only receive the permissions they require to operate. Users do not have to make complex security decisions when installing the snap.

Lijkt an sich een goed idee, maar de inclusie van complete omgevingen om het dependency probleem "op te lossen" weer niet, omdat het naar mijn idee het onnodig complex en redundant maakt. Ook lijkt me de belofte dat het software development helpt, omdat je "lekker snel" kan deployen/releasen niet reëel. Nu word iedereen soort van geforceerd fixes upstream aan te leveren, waar dat straks niet meer hoeft.

Kan ook een enorme boost geven voor de mobiele versies van Ubuntu.

Daarmee moet het in theorie makkelijker worden om applicaties voor verschillende distributies aan te bieden, doordat alle afhankelijkheden of dependencies in de snap-package zijn verpakt.

Zo gaat Linux steeds meer op Windows lijken.

Oneindig veel libraries op een systeem die compatibele zijn.

Met het snapcraft.io-platform hoopt Canonical deze vorm van pakketbeheer voor Linux tot een standaard te verheffen.

Hoop doet leven, maar ik denk dat de kans er klein is.

IMO is Mark Shuttleworth de weg kwijt c.q. denkt veel te commercieel.
IMO een slechte zaak voor een Linux distro.

Flatpak is niet vanuit GNOME, maar onafhankelijk/Freedesktop.org. Het is bedoeld voor desktop omgevingen. KDE is er bijvoorbeeld ook mee bezig.

Binnen Flatpak is het de bedoeling dat je een runtime gebruikt. Bijvoorbeeld een KDE runtime. Deze runtime hoort beheerd te worden door KDE (incl security updates etc). Je kan verschillende versies van deze runtime op je systeem hebben staan.

Door het aanmoedigen van desktop omgevingen om runtimes te leveren hoeven flatpak applicaties veel minder zelf aan te leveren.

Op een andere site zag je bijvoorbeeld dat een applicatie als Krita 1GB aan ruimte vereist. Verder is Snappy voor zover ik weet afhankelijk van AppArmor voor de beveiliging. Lijkt me dat sommige dingen op andere distributies niet aanwezig zal zijn. Fedora gebruikt bijvoorbeeld SELinux in plaats van AppArmor. Op dit moment moet je SELinux uitzetten indien je Snappy wilt gebruiken.

Als Snappy Apps op vrijwel alle Linux distributies werken, en Windows 10 Anniversary Update compabiliteit met Ubuntu binaries heeft, betekent dat dan ook dat Snappy Apps op Windows gaan werken?

Het Windows Subsystem for Windows word ingeschakeld wanneer de developer options ingeschakeld worden. Een pico proces kan dan alle Linux system calls omzetten voor de NT Kernel. hier kun je meer info over krijgen via de volgende links:
- https://channel9.msdn.com...ux-Architectural-Overview
- https://channel9.msdn.com...inux-Process-Architecture
- https://channel9.msdn.com...Linux-Syscall-Translation

De Ubuntu image is het volledige Ubuntu, het mist alleen een kernel en de drivers. Het Linux subsystem for Windows is gemaakt voor developers en werkt alleen met de cli. Je kunt dus geen grafische apps draaien. Meer info hierover kun je hier vinden: https://channel9.msdn.com/Events/Build/2016/C906

Alles wat in Ubuntu via de CLI werkt, werkt ook in de WIndows image. Snappy Apps die gebruik maken van een cli, werken dus binnen Windows.

Met Xming (bijv.) kan je ook grafische apps draaien: https://sourceforge.net/projects/xming/
https://channel9.msdn.com...ows10-Subsystem-for-Linux

[Reactie gewijzigd door DeadKennedy op 15 juni 2016 14:03]

Word het nu ook mogelijk om bijvoorbeeld een browser helemaal afzonderlijk in een (truecrypt)-container te draaien, zoals ik vroeger bij Windows deed? Met andere woorden, kunnen applicaties nu ook volledig portable draaien? Dat zou wel welkom zijn.

Ze kunnen in zekere zin portable draaien, mits het onderliggende systeem met Snap-packages overweg kan. Overigens bestaat dit concept al langer, onder andere namen/voorgangers en alleen bij minder bekende distributies.

Wel krijg ik een MSI deja-vu.... Er zitten zeker ook nadelen aan, want er zal maar een lek in de container van een Snap package met verouderde libraries zitten bijvoorbeeld....

Met Snaps volgens mij niet (maar ik kan het mishebben), maar dat kan sowieso al met bv. http://appimage.org/

Ik was zelf wel onder de indruk. Een weekje voor de Krita 3.0 release kwam Michael Hall met een snapcraft.yaml. Een iteratie of drie later, en we hadden een werkende snap in tijd voor de release. Uploaden naar de Ubuntu app store was al heel makkelijk -- en er zijn al meer dan 1000 downloads. En nu draait het op meerdere distributies.

Aan de andere kant, de AppImages die ik maak draaien echt op alle distributies die sinds 2012 zijn uitgekomen!

Van flatpak heb ik alleen maar gehoord dat mensen bezig zijn met Krita te packagen, maar resultaat heb ik, als Krita maintainer, nog niet gezien.