Ubuntu introduceert 'snap' in komende lts-versie

Canonical introduceert een nieuw verpakkingsformaat voor applicaties in de komende lts-uitgave van Ubuntu. Snap-packages kunnen in tegenstelling tot deb-packages alle afhankelijkheden zelf meenemen, waardoor een ontwikkelaar alle afhankelijkheden kan meeleveren.

De nieuwe wijze van pakketbeheer zal bestaan naast de standaard-deb-pakketten. Het grote voordeel ten opzichte van deb-pakketten is dat het makkelijker wordt om nieuwere software te installeren op oudere machines, doordat in een snap-pakket naast het programma zelf ook de afhankelijkheden of dependencies meegeleverd kunnen worden.

Daarnaast zijn snaps veiliger dan debs, doordat ze in een soort container boven op het besturingssysteem zelf worden geïnstalleerd, zonder impact te hebben op de rest van het besturingssysteem. Zo is het makkelijk om een applicatie te installeren die bijvoorbeeld gebruikmaakt van een nieuwere softwarebibliotheek dan op het systeem aanwezig is. De bibliotheken moeten dan wel door de ontwikkelaar aan de snap zijn toegevoegd.

Op dit moment is het nog zo dat een applicatie niet kan worden geïnstalleerd als een afhankelijkheid ontbreekt en ook niet in de softwarebronnen zit. Dan moet eerst naar de desbetreffende afhankelijkheid worden gezocht en eventueel een niet-vertrouwde softwarebron worden toegevoegd. Dit kan leiden tot onveilige situaties.

De nieuwe methode biedt niet alleen voordelen voor nieuwe apps op oude besturingssystemen, maar ook voor oude apps op nieuwe besturingssystemen. Canonical gaat bijvoorbeeld oude debs die niet meer zullen werken op nieuwe versies van Ubuntu migreren naar snaps, zodat ze in de toekomst toch nog gebruikt kunnen worden.

Aan de ontwikkelaarskant is het praktisch dat nieuwe versies van applicaties sneller hun weg naar eindgebruikers kunnen vinden. Nu is het nog zo dat de beheerders van de softwarebronnen die eerst moeten updaten. Een snap kan na een update direct naar eindgebruikers gepusht worden.

De ontwikkeling van snaps is een verbetering van het systeem dat Canonical ontwikkelde voor het app-ecosysteem van Ubuntu Phone: de clicks. Snaps waren in eerste instantie speciaal bedoeld voor het Snappy Ubuntu Core-OS, een besturingssysteem gericht op iot-apparaten. Canonical had daarvoor namelijk een provider grade-upgrademechanisme nodig. Dat betekent ook dat er goed is nagedacht over dataverbruik. Een update van een snap kan incrementeel doorgevoerd worden en maakt gebruik van delta-updates. Dat houdt in dat alleen de gewijzigde code gedownload hoeft te worden.

Canonical heeft ook een tool ontwikkeld om snaps te maken: Snapcraft. Op het moment van schrijven zijn er praktisch nog geen snap-packages te vinden voor Ubuntu 16.04. Navraag bij Canonical leert dat de meeste snaps nog specifiek voor Snappy Ubuntu Core zijn en dus geen ui hebben. Als proof-of-concept heeft Canonical een klok en een rekenmachine als snap vrijgegeven voor Unity 7.

Reacties (84)

[thomasv]

Toch moet je dan wel er rekening mee houden dat verschillende packages verschillende versies van libraries bevatten. Waar je nu bijvoorbeeld OpenSSL op heel je Ubuntu machine (of wat voor linux distributie dan ook) update, is er straks de kans dat een package dan toch de verouderde versie daarvan wellicht blijft gebruiken en de kans dus bestaat dat zo'n package een zwakke schakel in je systeem wordt. Dan ben je des te meer afhankelijk van of een package developer wel zijn packages op tijd update.

Omdat ik in het artikel niks over sandboxing zie staan kan ik er weinig over zeggen, maar dit hele systeem doet me vooral denken aan hoe Apple het in OSX heeft gedaan, waar applicaties inderdaad dit soort op zichzelf staande packages zijn.

[Reactie gewijzigd door thomasv op 25 juli 2024 05:47]

[Superstoned]

Snaps zijn volledig self-contained, alles zit er in. Bij ownCloud zijn we, samen met Canonical, een snap aan het maken voor ownCloud. Daar zit MySQL en Apache al ingebakken. Zie hier: https://github.com/kyrofa/owncloud-snap/

We willen Redis caching, dus dat gaat er ook in... Ja, het is totaal gesandboxed, als je inlogged op een apparaat wat de ownCloud snap aan het draaien is kun je niet bij ownCloud of Apache of MySQL - als je de settings aan wilt passen moet je de snap clonen, aanpassen en opnieuw bouwen. Echt een heel andere wereld ;-)

Snaps mogen ook absoluut geen dependencies hebben - da's ook niet lastig want je kunt niet buiten je container komen, geen socket communicatie tenminste.

[sumac]

Dus straks heb je drie MySQL engines draaien? Is dat wenselijk? Hoe zit het met de poorten? Zijn die ook gesandboxed? Lijkt me niet toch?

[Superstoned]

Standaard niet, dus dat kan gevaarlijk zijn. En ja, je krijgt overhead. Al kun je natuurlijk 1 MySQL snap gebruiken en via de poorten laten praten, lijkt me. Maar dan krijg je weer dependencies en da's Verboten

Ja, containers hebben natuurlijk nadelen. De Snap mensen zijn wel bezig om dat te minimaliseren maar het hoe en wat daarvan weet ik ook niet zo.

[jaapzb]

Dat is dan wel gelijk een andere insteek dan Docker, aangezien het in Docker juist wenselijk is om elke service een eigen container te geven, en deze containers met elkaar te laten praten.

[OMX2000]

Definieer service?

[DJFliX]

In deze context: dienst die met gebruik van een (TCP) poort aangeboden kan worden aan andere services/clients op een ander (of hetzelfde) systeem.

[jaapzb]

Als je een systeem heeft dat MySQL, nginx, redis, en een Python applicatie bevat, dan zou je in Docker dus een MySQL container, een nginx container, een redis container, en een container voor je python applicatie draaien. Die je dan vervolgens met elkaar linkt. Ofwel elke keer dat je een nieuw "proces" zou starten, moet die dus in een eigen container draaien.

Je kan ook gewoon al die processen in 1 docker container draaien, maar dat is niet handig en dat is dus ook niet wat docker aanbeveelt.

[Verwijderd]

Precies en dan heb je er 2 geupdate en 1 die vol zit met bugs net niet .. En daar wordt je gepakt, daar gaat je systeem dan om zeep.

[xoniq]

Volgens mij niet, want die MySQL database wordt enkel door die applicatie gebruikt, en je kan niet bij de rest van het systeem omdat een snap geïsoleerd is (sandbox).

[Verwijderd]

Oke niet je systeem maar je applicatie gaat dus om zeep. Valt dus mee te leven. Op zich is het dan niet een slecht plan.

[paradoXical]

Dan installeer je dus de deb versie

[thomasv]

Dus het is een andere term voor een container zoals Docker die ook toepast. Waarom dan de keuze om voor deze snap methode te gaan en niet voor Docker? Docker is al langer bezig met de weg te plaveiden en hebben ook al een aardige track record op dit gebied. Of heeft een snap minder overhead dan een Docker container?

[Reactie gewijzigd door thomasv op 25 juli 2024 05:47]

[letatcest]

Ik moet zeggen dat we het er gister nog een tijd over gehad hebben hier op de Tweakers of het nou 'erg op docker' lijkt of niet. Eigenlijk hebben we het gevoel van wel, maar Canonical zelf noemt het afaik nooit container. Daarnaast zet Canonical erg natuurlijk erg in op containers de laatste tijd, o.a. via lxd en container lxc en docker.

Snaps kunnen via interfaces communiceren met andere snaps of met (delen van) het OS of bv. een externe database. Maar ondanks dat ik gister heb zitten kijken naar een Q&A, hielden ze voor de komende LTS nog wel het e.e.a. onder de pet, al verzekerde men dat Snaps in 16.04 zitten. Ik heb overigens zelf nog niet de calculator-snap kunnen vinden (maar misschien verkeerd/niet goed gezocht

Wel zei men dat er de komende week steeds meer bekendgemaakt wordt. We wachten *rustig* af

[janbaarda]

Waar past juju in dit geheel? Juju was/is ook bedoeld voor lxc containers en verzorgt op een standaardmanier de communicatie tussen verschillende applicaties, in of buiten de eigen container.

[Superstoned]

Volgens wat comments op G+ is Mister Shuttleworth daar ook nog niet uit, dus - goeie vraag, geen antwoord ;-)

[MoonWatcher]

Juju kan software uitrollen in LXC/LXD containers.

Ubuntu 16.04 gaat LXC/LXD standaard out of the box aanzetten.
Mijn vermoeden is dat snap ook werkt op basis van LXC/LXD.
Hoewel ik dat zelf nog niet heb kunnen factchecken.

Met Juju zit het in ieder geval dus wel goed in Ubuntu 16.04

[kramer65]

Snaps verschillen van Docker containers in het feit dat een Docker container echt een heel OS op zichzelf is, terwijl een Snap alleen de applicatie (met dependencies) is. De overhead bij Snaps zou theoretisch dus minder moeten zijn dan bij Docker.

Gezien ik er zelf nog geen tests mee heb gedraaid, kan ik daar echter nog geen sluitende dingen over zeggen. Ik ben heel erg benieuwd en ga hier zéker mee testen!

[Superstoned]

Je hebt gelijk, het lijkt enorm op Docker. Ik ben niet genoeg thuis in Snapper en Docker om je te kunnen vertellen wat de verschillen en voor- en nadelen zijn...

[Blokker_1999]

Maar stel, op een dag stoppen jullie met het project (geen geld meer, geen interesse meer, ... niemand heeft een glazen bol) en een week later word er een ernstig lek gevondenn in 1 van jullie dependencies. Vandaag word dat zeer snel opgelost net omdat die dependency door het OS zal bijgewerkt worden. Bij een snap ben je dus afhankelijk van de maintainer, en als die stopt heb je ineens een zeer onveilige app draaien. Hoe gaat Canonical er voor zorgen dat zoiets niet gebeurd?

[cyberstalker]

Dat is een goede vraag. Zou een snap zelf ook weer kunnen bestaan uit een soort mini-pakketsysteem waarbij je dus eigenlijk een soort 'bundel' van pakketten hebt? In dat geval zou je zo'n snap ook moeten kunnen updaten door daar een nieuw pakket in te stoppen.

[Superstoned]

Dat klopt, je bouwt een snap uit Deb pakketten. En bij een open source project en een open source snap kun je heel eenvoudig een nieuwe versie bouwen als dat nodig is. Dat helpt natuurlijk flink met het probleem wat Blokker aankaart. Al blijft het minder dan ideaal - het is natuurlijk in de praktijk zo dat veel projecten simpelweg een statische build maken, en dan is de shit net zo groot als bij een snap behalve dan dat een snap erg isolated en beveiligd is terwijl een static binary enorm veel schade kan aanrichten.

Kortom - het is niet de BESTE oplossing, maar minder erg dan wat ISV's op dit moment moeten doen.

[Superstoned]

Zeg, op een dag stoppen de maintainers van je distro package ermee. Geen zin meer, geen geld... Zit je net zo goed met een probleem en dat komt jammergenoeg voor.

Maar je hebt natuurlijk gelijk, het is niet ideaal. Het zou beter zijn als er een makkelijker manier was om packages te bouwen voor verschillende distributies, als distributies flexibeler waren en bijvoorbeeld het makkelijker maakten meerdere versies van libraries te installeren en meerdere onder houden, en wanneer distributions wat minder moeilijk deden over het extreme opsplitsen van applicaties en wanneer distributies hun best zouden doen om de vele kleine, arbitrare verschillen tussen distributies te verminderen zodat het eenvoudiger wordt om een applicatie te bouwen voor meerdere distro's.

Maar na tientallen jaren is dat nog steeds niet gebeurt dus zijn er een half dozijn projecten die een andere oplossing zoeken, van Docker tot Project Atomic (RH), Snappy (Ubuntu), Tumbleweed/OBS (openSUSE), XDGapps (GNOME) etcetera.

[jeanj]

Ik zie de toegevoegde waarde als je alles op 1 server zet. Ik heb alleen een eigen MySQL/MariaDB server draaien, hoe kan ik voorkomen dat MySQL op de owncloud server wordt gezet? Of blijft men de deb packages ook leveren?

[Reactie gewijzigd door jeanj op 25 juli 2024 05:47]

[Superstoned]

We blijven wel packages leveren, snap is sowieso Ubuntu-only. En de tarball blijft sowieso. Voorlopig is dit nieuw, interessant en leuk - maar geen oplossing voor iedereen.

[hottestbrain]

Klinkt als een omslachtige manier van het voorkomen van wat op windows DLL-hell genoemd werd, maar wellicht interpreteer ik dit verkeerd?

[thomasv]

Nou dat heb je juist niet met het packagen ervan, en wel met het centraal hebben van die libraries zoals nu gebeurd. Dit zou dus inderdaad de DLL-Hell tegen kunnen gaan die ze nu misschien ervaren maar zoals ik zeg het geeft ook ruimte aan het creëren van zwakke schakels in je systeem.

[sumac]

Ieder nadeel heb z'n voordeel!

[base_]

Kost dit niet heel veel extra resources? Zowiezo een stuk meer schijfruimte en bovendien krijg je dan ook meerdere instances van bijvoorbeeld een mysql of andere daemon/service?

[Verwijderd]

Kost dit niet heel veel extra resources? Zowiezo een stuk meer schijfruimte [...]

Bij het UWP in Windows staat elke app ook los van elkaar (al kan een auteur weer dingen tussen zijn apps delen, maar dat doet er nu niet toe). Windows kijkt bij elke app welke bestanden er zijn. Als twee apps een zelfde bestand hebben, bit voor bit, word deze maar één maal opgeslagen en gelinkt aan beide apps. Er word dan soms meer gedeeld dan alleen een software librarie, wat meer schijfruimte kan besparen dan alleen de libraries op een centrale plek houden.
Ik weet niet hoe Ubuntu Snaps in elkaar zitten, maar denk wel dat het mogelijk is om dit, als het nog niet ingebouwd is, dit in te bouwen. Het os / Snap systeem moet paden die lijden naar een bestand omzetten naar de shared plek buiten het programma om.

Het gaat daarnaast vaak maar om een paar mb. Als ik bij mij en ander kijk in mijn omgeving is de harde schijf nog lang niet vol en doen die paar het mb dus ook niet

en bovendien krijg je dan ook meerdere instances van bijvoorbeeld een mysql of andere daemon/service?

De meeste servicesop mijn pc zijn ouderwetse updaters (ik gebruik WIndows). Bij linux hoeft dit niet omdat er een centraal update systeem is. Bijvoorbeeld MySQL word ook niet door veel desktop programma's gebruikt naar mijn weten. MySQL is handig als je heel vaak tegelijkertijd (met meerdere users) een database moet benaderen. Voor een desktop programma is bijvoorbeeld SQLite veel makkelijker. De meeste browsers gebruiken bijvoorbeeld SQLite.

Op servers word voor containers (ik vind Snaps veel op containers lijken) gekozen omdat het je apps van elkaar isoleert, makkelijk en snel op te starten is en ook weer makkelijk te killen is. Software A kan dan niet zomaar B om zeep helpen. (Ik weet dat er meer redenen voor containers zijn, maar dat heeft vgm niks meer met Snaps te maken)
Ik denk dat Snaps vooral voor desktop, IOT, tablet, mobile, etc is bedoeld, maar niet voor de Server. Op servers bestaan al héél goede technologieën als Docker. Aangezien het draaien van services voor desktop software vaak niet van toepassing is, denk ik dat het niet héél merkbaar aan je geheugen gaat vreten en je veiligheid omhoog gaat.

[Reactie gewijzigd door Verwijderd op 25 juli 2024 05:47]

[Aikon]

Aan de andere kant kon je vroeger pas updaten als alle programma's de nieuwe versie van bijv. Openssl ondersteunen. Dat kan lang duren. Nu wordt eea geüpdatet zodra het kan.

[i-chat]

als het goed is werken snaps wel degelijk in een sandbox,

as snap applications are isolated from the rest of the system.

, maar desalniettemin praat cononical zelf oa over bijv desktop omgevingen, in dat geval maakt het vrijwel geen fuck uit of er nu wel of geen container gebruikt wordt, aangezien die op zijn minst permissies krijgt op het hele userfilesystem. en je dus naar exploits alsnog crypto-lockers kunt inbakken in je 'custom' versie van de package.

daarnaast ben ik heel erg bang dat vooral commeciele partijen snap-packages zullen gaan gebruiken, om die vervolgens niet of nauwelijks up to date te houden, en je binnen hun app dus alsnog kwetsbaar bent voor attacks.

[Superstoned]

hoeft niet. Er zijn best wat slimme trucks die het mogelijk maken om apps geisoleerd te houden en maar heel beperkt toegang te geven tot bestanden. XDG-apps van GNOME doet dat ook - je moet elke app permissies geven om dingen te mogen doen op een manier die echt heel netjes en impliciet is.

Het is niet perfect natuurlijk maar het wordt een stuk lastiger om crypto-lockers te maken.

[Hikari]

Dit lijkt inderdaad heel erg op OSX, betekent dit ook dat als 2 verschillende snap packages dezelfde dependency nodig hebben, je die dependency ook 2x hebt in ruimte? aangezien het in het package mee komt.

[thomasv]

Dit lijkt inderdaad heel erg op OSX, betekent dit ook dat als 2 verschillende snap packages dezelfde dependency nodig hebben, je die dependency ook 2x hebt in ruimte? aangezien het in het package mee komt.

Ja dat is inderdaad wat het betekend

[Jantje2000]

Heel mooi. Wel heb ik een vraagje. Hoe doen besturingssystemen als Windows dit? Hebben die ook zoiets?

[Reactie gewijzigd door Jantje2000 op 25 juli 2024 05:47]

[Croga]

Windows doet dit zo'n beetje sinds het begin. De DLLs die bij ieder programma zitten bevatten veel (common) libraries.

Dit is lange tijd het argument van Linux geweest; Windows vreet harddisk ruimte omdat common libraries bij ieder programma los geïnstalleerd worden terwijl Linux dit maar één keer doet.

Beiden zijn dus aan het veranderen. Windows gebruikt tegenwoordig steeds meer centrale libraries (zie, bijvoorbeeld, de .net redistributables), Linux gaat nu de kant van de gebundelde libraries op. Beiden hebben dus de merites van de werkwijze van de ander gezien.

[GekkePrutser]

Niet elke Linux. Ubuntu is vooralsnog de enige.

Er zitten ook nadelen aan trouwens. Als er nu een bug gevonden wordt in een library, kan je die updaten en is gelijk elke applicatie op je systeem gefixt. Met dit nieuwe systeem ben je van veel meer package maintainers afhankelijk.

[Reactie gewijzigd door GekkePrutser op 25 juli 2024 05:47]

[frogger3d]

Dat is niet helemaal correct. Met de nieuwe .NET core zijn ze juist de richting van een compleet modulaire setup in gegaan waar de BCL helemaal niet meer gebruikt wordt.

.NET core is helemaal modulair gemaakt met behulp van NuGet in tegenstelling tot de monolitische base class library die tot noch toe system-wide geinstalleerd wordt. Dat betekent dat elke .NET core applicatie met zijn eigen dependencies.

[Reactie gewijzigd door frogger3d op 25 juli 2024 05:47]

[BeosBeing]

Sinds het begin heeft Windows DLL's met (common) libraries. Vaak had programma A minimaal versie 1 nodig en programma B minimaal versie 2. Met versie 2 zou het dan goed moeten zijn, helaas waren sommige programma's/installers zo gemaakt dat ze rucksichtlos de oude versie installeerden ook als de nieuwe er al was en die nieuwe vaak onbruikbaar maakten. Andere programma's waren dan weer zo gemaakt dat ze alleen werkten met versie 1.1a en zoms zelfs alleen 1.1a gecompileerd met compiler Y versie z.

Het gevolg was de dependency hell en die was het ergst ten tijde van Windows 3.11 met Win32s en Windows 95. Microsoft is toen eisen gaan stellen aan softwaremakers, o.a. voor het 'made-for-Windows98' logo. Dat hielp maar niet afdoende.

Vanaf Windows XP is men toen aan een andere oplossing gaan werken WinSxs. Hierin zouden dan alle verschillenden versies van een bepaalde dll opgeslagen worden zodat ieder nukkig oud programma zijn eigen specifieke systeem-dll-versie kon gebruiken terwijl de echte systeemdll gewoon in de map Win32 stond. Dit kon omdat rond die tijd de harde schijven enorm toenamen in opslagcapaciteit. Sinds Visa/7 was dit systeem dusdanig uitgewerkt dat het inderdaad betrouwbaar op die manier functioneerd en daarom wordt deze map dan ook zo omvangrijk naarmate er meer programma's geïnstalleerd en/of gebruikt worden.

Ubuntu doet nu min-of-meer hetzelfde als Winsxs maar dan zo dat de specifieke libraries niet bij elkaar in een map gezet worden, maar blijven staan bij de andere onderdelen van het pakket waarvoor deze librarie nodig is, samen in één pakketje/container/snap-in dus.

[Verwijderd]

Volgens mij heeft Microsoft zoiets niet. Hun store lijkt er nog het dichtste bij in de buurt te komen.

[PvdVen777]

Doet me eigenlijk gelijk aan het goede ouwe DOS tijdperk denken. Daar had je ook altijd zo'n beetje alles behalve het core OS in een package (disk/cd) om iets te kunnen draaien.

[- peter -]

Lijkt me alleen wel dat de grootte van zo'n snap erg toeneemt tov een deb.

[davasch]

Daar is blijkbaar over nagedacht:

Een update van een snap kan incrementeel doorgevoerd worden en maakt gebruik van delta-updates. Dat houdt in dat alleen de gewijzigde code gedownload hoeft te worden.

[Kees]

Dat is alleen de update, de installatie is ook gewoon een stuk groter. Het doet denken aan docker containers, en die zijn ook snel een paar 100 MB. Er zal wel wat overlap inzitten waardoor je voor 10 aps maar 1 keer een 'baseimage' moet downloaden (zoals bij docker) maar voor hetzelfde geld ben je zo een paar gig kwijt aan 'oude' snaps.

[Gwunnik]

Deed mij idd ook erg aan Docker denken. Wel een groot voordeel dat het mogelijk is om meerdere versies van dezelfde library te draaien in aparte containers. Loop er nu nog wel eens tegenaan dat het een niet draait op een oudere versie van een dependency en een andere niet op een nieuwere van dezelfde dependency. Erg vervelend

[Superstoned]

Klopt. Maar maakt dat veel uit?!?! Vaak is het handiger om wat meer ruimte in te laten nemen dan te klooien voor een paar mb aan ruimte...

Gigabytes is wat overdreven, hoor, het gaat niet zo super snel. Er zitten ook trucks in om geheugen enzo te delen en er zal op een zeker moment ook wel deduplicatie komen van de ruimte die ze innemen.

Kortom - het valt wel mee met de overhead, al is die natuurlijk wel aanwezig. Maar snaps zijn dan ook niet geschikt voor high, end-user apps, maar voor server stuff. Je hebt een of twee snaps draaien - geen 50.

[Trunksmd]

Is geheugen tegenwoordig überhaupt nog een probleem? Bij een standaard x86 systeem heb je normaal gesproken genoeg geheugen voor programma´s.
Ik kan me wel voorstellen dat het sneller een probleem wordt voor oudere systemen of kleinere systemen zoals een arm systeem (bv Raspberry Pi). Maar daarvoor zijn genoeg alternatieven.

[Zer0]

Het lullige is alleen dat Snappy Core ook gericht is op IoT devices zoals de Rpi.
De bedoeling is om 'snaps' te ondersteunen op "kleine" en "grote" hardware.

[u_nix_we_all]

Maar dan nog. Als je een handvol applicaties hebt die dezelfde lib gebruiken die een update nodig heeft, dan hoef je met het deb-systeem alleen die library te updaten. Met het snap-systeem zijn het dan wel incrementele updates zodat je niet die hele snap hoeft te vervangen, maar elke snap die die library heeft zal deze moeten updaten.

[Superstoned]

Klopt. Dat is het nadeel. Het is natuurlijk wel zo dat die packages lang niet altijd super goed maintained zijn (zie bijv https://statuscode.ch/201...ages-considered-insecure/ ), het is regelmatig zo dat een vendor een betere reputatie/track record heeft (zeker het geval bij ons).

[Verwijderd]

Dit is precies de reden waarom ik denk dat dit systeem geen goed idee is. Als een applicatie een dependency heeft met een lib, is het aan de maintainer om de applicatie bij te werken zodra er een lib update is. Als je snap gaat gebruiken, werkt dat 'luiheid' in hand: de applicatie blijft werken met een oudere (misschien wel onveilige) lib.

[Superstoned]

Nou ja, vandaag de dag worden applicaties dan statisch gecompileerd. Je MOET het tenslotte mogelijk en makkelijk maken ze te deployen en RPM en DEB maken dat gewoon veel te moeilijk met al die veranderingen enzo.

Ik ben het met je eens dat dit niet de perfecte oplossing is, maar een BETERE oplossing vereist dat de distributies meer versies van bibliotheken toestaan, flexibeler worden met updaten, meer gaan samenwerken om verschillen in bijv. namen van packages of zelfs versie number conventies kleiner te maken etcetera. En dat doen ze niet. Dus ja, dan moet je wat. Dus krijg je Docker en Snappy en andere oplossingen.

En hou er rekening mee dat distributions er qua veiligheid ook een zootje van maken. Ubuntu's "Universe' package repo is TOTAAL unsupported, maar staat ondertussen wel standaard aan. Dat is dus eigenlijk gewoon "hey, gebruiker, hier is een backdoor voor hackers, ga maar lekker installeren!".

Debian doet het niet veel beter, veel van hun packages zijn echt veel minder veilig dan ze zo graag beweren, zie mijn link. Dus ja. Snap zorgt tenminste dat die library, ALS er geen nieuwe versie komt, geen of heel weinig schade aan kan richten.

Je moet goed begrijjpen: dit is een *praktische* oplossing. Geen theoretisch ideale oplossing--maar die gaat er (denk ik) niet komen door koppigheid/luiheid/NIH/menselijkheid/whatever bij de distributies.

[Stoelpoot]

Dan nog bestaat het nadeel dat als applicatie A en applicatie B allebei library C gebruiken, zij allebei library C meeleveren. Stel dat library C nu 5 libraries zijn van elk 200MB. Dat betekend dat in plaats van 1GB, 2GB op het systeem staat, wat maar 1 zou kunnen zijn bij gebruik van een deb-package.

[i-chat]

het punt is dat er niet zo heel veel pakketten zijn met dusdanig grote dependancies dat je over gigabytes gaat praten in plaats van megabytes.

[majetta]

dan download je wat meer i.p.v de pakketjes los te opzoeken en installeren waardoor je meer tijd kwijt bent tenzij je alle dependencies al op de installatie hebt staan.

[cyberstalker]

Daar hoef je eigenlijk niet voor te zoeken hoor. Dependencies worden automatisch meegeinstalleerd door aptitude of apt-get. Het is puur als je losse pakketten wilt installeren, bijvoorbeeld direct via dpkg.

[Carharttguy]

Als ze in de standaard repo's zitten natuurlijk. Anders mag je de dependency zelf installeren of ergens een PPA zoeken die het heeft.

[Verwijderd]

Anders mag je de dependency zelf installeren of ergens een PPA zoeken die het heeft.

Alleen dat laatste; als je gewoon zorgt dat er genoeg repo aanbod is, door middel van de standaard repo's en door middel van PPAs dan lost met name aptitude alle dependency problemen wel voor je op.

Dat is de hele kracht van aptitude namelijk.

[mard0]

Mogelijk dat ze overgestapt zijn op xz compressie.
Dit was eerder al voorgesteld voor de "oude" .deb pakketten maar volgens mij nooit uitgevoerd.

[RedPixel]

Probleem is dat dat niet backwards compatible zou zijn, dus dan zou je verschillende .debs moeten maken. Onder het motto "doe het in een keer goed", is dit een betere aanpak.

[84hannes]

Onder het motto "doe het in een keer goed", is dit een betere aanpak

Dit is niet goed. Dit is een stap terug. Of erger. Eén van de sterkste punten van Linux is package managment. Niet elk programma dat zichzelf update, maar een centrala systeem dat verantwoordelijk is voor al je software. Niet per programma een dikke binary downloaden met honderden statische libraries, maar elke library maar 1 keer op je pc, en wel de meest recente versie die je repositories aanbieden. Vrijwel alles vrijwel altijd vrijwel up to date.
Als ik lomp grote programma's wilde die zichzelf installeren en updaten, of die ik zelf handmatig moet updaten, dan zou ik wel Windows gebruiken.

[Reactie gewijzigd door 84hannes op 25 juli 2024 05:47]

[Sup4rdurt]

Maar gelukkig zijn er voor anderen wel meerdere redenen om Linux te gebruiken en vinden zij (waaronder ik) deze ontwikkeling wel handig.

Ik snap het principe van shared libs maar toch juich ik dit wel toe.

[MadEgg]

In uitzonderlijke situaties is het wel handig. Maar het risico is dat ontwikkelaars hier 'lui' van worden en geen .debs meer aanbieden maar alleen de snap-packages gaan aanbieden. Dat schiet niet op natuurlijk.

[Halfscherp]

Niet alleen in uitzonderlijke situaties. Als deze ontwikkeling zich doorzet naar de meeste distro's (OS X-stijl installeren, drag 'n drop zeg maar), dan wordt Linux een stuk toegankelijker voor de leek.

[MadEgg]

Dat is echt niet nodig. Drap-and-drop kan ook prima met .deb-packages. Die geven de dependencies door aan apt welke ze vervolgens installeert.

Waar het om gaat is dat de .deb packages aangeboden worden en voor de juiste distributie. Bij de ontwikkelaars dus. Er is weinig reden om alle dependencies in elke package te bundelen. Behalve dus in uitzonderlijke situaties waar software nieuwe libraries vereist die nog niet gepackaged zijn voor Ubuntu. Ook in dat geval is het eigenlijk een voordeel voor de ontwikkelaar en niet voor de gebruiker, die laatste kost het alleen maar meer schijfruimte en geheugen, en een grotere kans op security vulnerabilities.

[The_Worst]

Het lijkt mij dat dit extra schijfruimte gaat kosten. Als elke applicatie, voor het gemak, zich als snap laat installeren en ze leveren allemaal apart dezelfde bibliotheken mee dan heb je sommige bibliotheken tig keer op het systeem staan.

Het kan ook een beveiligingsprobleem opleveren. Als bepaalde apps nalaten om de laatste bibliotheken mee te leveren...

[m8ZBm1Si]

Maar die beveiligingsproblemen blijven dan beperkt tot die ene snap, en niet tot het volledige systeem.

[ATS]

Eh, nee. Dat lijkt me niet. Als er één lek is is je complete systeem natuurlijk lek. Als bijvoorbeeld SSL een lek zou hebben dat een remote expoit mogelijk zou maken, dan is op dat moment dus elke snap die SSL gebruikt lek. En het lek is pas opgelost als al die snaps geupdate zijn, in plaats van als je je SSL deb geupdated hebt.

[wica]

Afhankelijk van de bug, is het best mogelijk om uit een container te breken en door te gaan naar de host.

Dus ja, ik maak me best zorgen om verschillende versies die gebruikt kunnen worden binnen verschillende containers.

[Verwijderd]

Misschien tijd voor fatsoenlijke deduplication op filesysteem-nivo.
Btrfs kan het al, alleen niet volautomatisch.
Maar dan ben je in principe niet meer ruimte kwijt dan nu, afgezien van de extra versies/pakketten.

[kaaas]

Deduplication is een enorme hit op je performance en geheugen gebruik.
Het is iets wat je alleen maar doet als je performance er niet toe doet en je alles overhebt voor zo veel mogelijk opslag. Een offsite backup server bijv.
Er zijn al meerdere file systemen die dit kunnen het staat alleen nooit aan standaard om bovenstaande redenen.

[Tofu]

Eindig je dan niet met véél grotere installaties die nog moeilijker te onderhouden zijn? Als je 10 programma's hebt die dezelfde dependency hebben dan staan er misschien 10 verschillende versies van die dependency op je systeem. En je bent dan afhankelijk van de maker van die 'snap' om die dependency te laten upgraden.

[LOTG]

Grotere installatie: Ja, want alle dependencies erbij
Moeilijker te onderhouden: juist niet, want de Snap moet dat zelf doen. Dus je hoeft alleen maar de snap package te updaten en die doet dan de dependencies.
Afhankelijk van maker: Ja, maar dat ben je nu eigenlijk ook al. Als er een update van een dependency is, dan moet je de applicatie die er gebruik van maakt ook updaten om te zorgen dat die compatible blijft met de nieuwe versie. Als de maker zijn software niet update kan het best zo zijn dat die niet meer werkt met de nieuwe library.

[PvdVen777]

Met goede (versie) en gebruiks management zou je dat af kunnen vangen.

D.w.z. niet twee keer dezelfde dependancy deployen en goed bijhouden of en welke apps die gebruiken alvorens iets definitief te verwijderen. Je hebt wel grotere installatie packages, maar in elk geval hoef je niet meer rond te zoeken, soms zelfs gissen om te vinden wat je nodig hebt om iets draaiend te krijgen.

[Reactie gewijzigd door PvdVen777 op 25 juli 2024 05:47]

[telenut]

Lijkt me toch niet zo ideaal...
Heb op Windows ook wel zo een software die mijn zijn eigen JRE komt. Maar die is dus nooit up to date, en neemt veel plaats in.
En weer versplintering in manier van software distributie

[Zapcheeser]

Zoals het op de DEV page is uitgelegd zal Snapcraft zelf de common repositories toevoegen aan de package.
Wat ik mij dan afvraag, waarom bouwen ze deze methode niet standaard in in hun software installation shell?
Dan download je toch '@install' je dependencies uit de common repositories / cloud parts voor zover die nog niet aanwezig zijn? Dan hoef je in je package alleen maar te verwijzen naar die repositories, toch?
Ik heb die hele installatiemethode binnen Ubuntu sowieso nooit begrepen wat dat betreft.

[ATS]

Als je geen externe dependencies wil, waarom compileer je dan niet gewoon static?
Allemaal je eigen "dynamic" dependencies meeleveren zorgt voor heel veel onnodig gebruik van resources, omdat elke app op zich vaak maar gebruik maakt van een beperkt deel van de library. Als je dynamisch linkt en de library wordt gedeeld is dat geen issue, maar als je de libraries niet meer deelt wordt het dat al snel wel: dan ben je heel veel keer op keer aan het laden en opslaan dat je niet nodig hebt. Als je statisch linkt, dan houdt je alleen de delen van de lib over die je wél gebruikt, zodat je geen overbodige overhead hebt.

[Reactie gewijzigd door ATS op 25 juli 2024 05:47]

[damylen]

Zal dit straks ook werken onder Windows 10?

[mg794613]

Interessante technology. Lijkt op docker, maar net niet helemaal.
Zal ook zijn kinderziektes hebben. Een soort static linking; in ieder zijn eigen laag. Beetje het tegenovergesteld van dynamic libraries. En dat deden we voor goede redenen: Minder bloat, minder attack surface, minder bugs.
Ik laat de boot dus even aan mij voorbijgaan voor de komende 2 jaar.
Er komen iets te veel technologien en fashion"bandwagons" voorbij die iets later compleet disastreus blijken.