Canonical stopt in Desktop Next met .deb ten faveure van 'snappy apps'

Canonical vervangt in de eerstvolgende Ubuntu Desktop Next de reguliere Debian-packages door een variant die enkel met 'snappy apps' werkt. Zulke apps levert de softwareleverancier al mee met Ubuntu Core, een minimalistische versie van de Linuxdistro.

'Snappy apps', zoals Canonical ze noemt, zijn read-only images van applicaties die makkelijk te updaten zijn. Zo kunnen ontwikkelaars bestanden bundelen voor apps en die in één enkele package publiceren. Met deze methode zou ook het terugzetten van oude versies snel en probleemloos moeten gaan.

Canonicals Will Cooke schrijft dat het bedrijf van plan is om behalve Ubuntu Core ook de toekomstige versie van Desktop Next van 'snappy apps' te voorzien. De Desktop Next-release is Canonicals proeftuin, waarmee het bedrijf ook experimenteert met de in aanbouw zijnde Mir-displayserver en de Unity 8-omgeving.

"Ons plan voor 15.10 is om een build te bouwen die op Snally Personal is gestoeld. De huidige op .deb-gebaseerde Desktop Next-build zal dan worden vervangen door een nieuwe Snappy-versie", zo legt Cooke uit. Meer details geeft hij niet, hoewel die binnenkort wel volgen.

Deze week gaf Canonical zijn recentste Ubuntu-release uit: 15.04. Net als in de vorige versie schonk Canonical in de reguliere build weinig aandacht van de Unity-interface, vooral omdat zijn ontwikkelaars zich focussen op de mobiele Ubuntu-versie en projecten als de Mir-displayserver. Twee officiële Ubuntu-smaken, namelijk die met KDE- en Xfce-interface, sprongen er wel uit, zo schreef Tweakers in een review.

Reacties (52)

[Rafe]

Op (Linux) servers is het verpakken van applicaties in containers de afgelopen twee jaar al een hot item* met Docker. Wat niet helemaal duidelijk in dit nieuwsbericht naar voren komt is dat deze 'snappy apps' van Ubuntu verpakt kunnen worden in verschillende containerformaten, en dat Docker een van die (en ik geloof momenteel de enige?) formaten is.

Zoals al opgemerkt wordt hier in de reacties bevat zo'n container de applicatie en al zijn dependencies, en ligt de scheiding op de calls naar de kernel. Bij virtualisatie krijg je nog een eigen OS en ligt de scheiding op calls naar de hypervisor/CPU. De overhead tijdens runtime is dus flink lager. Een container wel groter om op te slaan, maar je bent wel van dependency hell af. En je weet dat exact die container die op jouw laptop draait het dus ook doet op 1000en instanties in de cloud

*hot item: van RedHat/Ubuntu tot VMWare tot Microsoft (voor Windows Server) zijn bezig met support voor Docker en hun laatste geschatte waarde ligt rond de $1 miljard.

[Reactie gewijzigd door Rafe op 23 juli 2024 18:41]

[Maurits van Baerle]

Is dit vergelijkbaar met .app bestanden op OS X?

.App bestanden zijn stiekem eigenlijk folders waarin alle resources die bij de executable horen in zitten. Je kunt daardoor gewoon een .app overschijven en hij is geupdate of hem naar een andere directory slepen en je hele applicatie is verhuist. Ideaal.

[conhen]

Dus beginnen we weer opnieuw met het meeleveren van libraries bij apps die je al 10 keer op je PC hebt staan... Het voordeel van Deb (en andere package managers) is toch juist dat dat niet meer hoeft (dependencies), en dus de packages klein blijven?

[eonflux]

Dat maakt toch niet zoveel meer uit. Opslag kost nu veel minder dan 10jaar geleden.
Ik kom regelmatig op ubuntu.co.uk en altijd dat geklaag van mensen. Het is zo groot. Het is zo zwaar. Het werkt niet met mijn 10 jaar oude computer. Ik zeg niet dat jij het hebt maar gooi die oude troep weg en investeer in een nieuwe computer.

Het zou zeer mooi zijn als windows ook zoiets zou doen. Zoals het op OSX werk is echt heel fijn

[Blokker_1999]

Het gaat hem niet zozeer om de ruimte, wel op beveiliging. Wanneer er een bug in een library word gevonden kan je nu door de shared library te updaten heel je systeem patchen. Wanneer libs mee in elke package zitten dan moet elk package geupdate worden. Als je dan iemand hebt in upstream die zijn pakket niet onderhoud krijg je zo weer bijkomende veliigheidsrisicos.

[Brent]

Ook dat punt mogen we echt wel schrappen van het lijstje pluspunten van dynamic linken, want immers: als jouw repository bugs niet fixed, static gelinkt of dynamic, heb je al verloren. Voor veiligheid geld: of je kunt je repo vertrouwen, of niet. En dan maakt het niet uit hoe er gelinkt is.

Installeer je zelf buiten het officiele repo om zelf je eigen repo of package, dan kies je er al voor dat je dat risico neemt. Dus maakt static/dynamic ook niet uit. Wel heeft static het voordeel dat de onvermijdelijke api-change niet het draaien van je binarie kan verprutsen.

Kortom, naast het feit dat de opslag/memory voordelen van dynamic linken inmiddels achterhaald zijn, is het ook onjuist te veronderstellen dat het een veiligheidsvoordeel heeft. Dat hangt namelijk van de bronnen (repo) af, niet van hoe er gelinkt is. Dat eventuele zelf-geinstalleerde binaries wel of niet baat bij een geupdate library zouden hebben staat hier buiten. Bovendien wijst een populair alternatief platform uit (Windows) dat die voordelen inderdaad theoritisch zijn, en dat juist het voordeel van een self-contained static gelinkte binarie veel meer op prijs gesteld wordt.

[Reactie gewijzigd door Brent op 23 juli 2024 18:41]

[Sir Isaac]

Dan moet iedere ontwikkelaar dus zijn code opnieuw compileren en distribueren als er een patch voor een library verschijnt. Dat betekent dat het veilig houden van software meer werk is dan nu. Gezien de prioriteit die veiligheidsproblemen nu hebben ben ik niet optimistisch over de werkbaarheid van dit model.
Overigens vind ik het punt opsluigruimte wel degelijk relevant. Op een 256Gb SSD wil geen gb extra kwijt zijn omdat basale bibliotheken n keer op je systeem staan. En dan hebben we het nog niet over het n x laden in het geheugen gehad.
Onzalig idee, statisch linken.

[Reactie gewijzigd door Sir Isaac op 23 juli 2024 18:41]

[graey]

Nee, dat kan automatisch op de reposerver gebeuren, waarbij er een melding gedaan wordt aan developers/onderhouders als het niet meer compilet door incompatibiliteit met een geüpdate library. Weinig verschil met nu dus.

[Brent]

Dit model werkt prima, want welk probleem lost Docker nu eigenlijk op? Eindeloos geneuzel met dependencies en updates van libraries maar niet van apps die niet weten dat er een api change was en dus niet meer werken.

DIt is een enorm probleem, en opnieuw compileren is a) helemaal het werk niet van een ontwikkelaar maar van de repo/package maintainer en b) triviaal anno 2015.

Nee, als compileren in handen van individuele ontwikkelaars zou liggen, dan hadden we pas een veiligheidsprobleem. God mag weten wat voor compromised compiler/libraries die allemaal op hun systeem hebben.

[BlackOwl]

SSDs zijn nog redelijk wat duurder dan HDDs dus dat achterhaald zijn van de opslag/memory voordelen van dynamic linken valt nog wel tegen.

[sfc1971]

Precies hetzelfde probleem bestond altijd met Windows. Iedere applicatie had zijn eigen libraries dus een lek kon allang zijn gepatched in de library maar ergens was er nog een oude versie aanwezig in een applicatie die niet was geupdate en BAM! Je bent nog steeds kwetsbaar.

[CurlyMo]

Dat is deels waar. Zoals ook hierboven geschreven. Een voorbeeld. In pilight gebruikt ik polarssl. Die wil ik best dynamisch linken, maar op Debian Wheezy is de nieuwste versie 1.2.9. Op Debian Jessie 1.3.9. Ik heb niet de mogelijkheid om mijn programma zo te maken dat hij ook 1.3.9 kan gebruiken aangezien 1.2.9 functies bevat die niet in 1.3.9 zitten. En in 1.3.9 zijn wel een aantal kritieke bugs opgelost. Ik zou polarssl ook dynamisch kunnen laden terwijl pilight draait en dan kijken welke functies de librarie bevat, maar dat vind ik geen duurzame oplossing.

In dit geval heb ik er dus voor gekozen om het geheel te integreren en met pilight mee te compileren. Het is zelfs al zo dat polarssl is overgenomen door ARM en nu mbed TLS heet. Die is al helemaal nergens te vinden. De versie die wordt meegeleverd met pilight is nu dus 1.3.10. Nieuwer dan in de standaard repositories.

pilight wordt daarnaast elke nacht automatisch gecompileerd aan de hand van de laatste development code en in de repository gezet. Bugfixes zijn dus per direct beschikbaar.

[Reactie gewijzigd door CurlyMo op 23 juli 2024 18:41]

[TimDJ]

Toch scheelt het in gebruik geheugen en snelheid qua inladen van libraries. Die moeten dan meerdere keren worden ingeladen. Waarom zou je inleveren op snelheid?

[Mikke8]

Nu laad elk process ook zelf (of het OS) de library.
Dit komt omdat elk process een eigen Virtual Address Space heeft ( http://en.wikipedia.org/wiki/Virtual_address_space )

Dus opzich verwacht ik bij beide methodes een gelijke laad tijd.

[Keeper of the Keys]

Voor Shared Libraries heeft het OS mechanismes om ze slecht 1 keer in het geheugen te laden en meerdere processen te laten delen, daarom worden ze ook zo gecompileerd dat het "Position Independent Code" is (alleen relatieve jumps, geen hard-coded adressen etc.).

Shared Libs zijn niet voor niets in het leven geroepen.

@Brent:
De "kleine overhead" voorkomt meer swappen statisch gelinkte applicaties is leuk als je er niet zoveel draait maar als je een hele desktop omgeving en grote applicaties statisch gelinkt gaat draaien zul je je heel snel gaan ondervinden wat thrashing was/is... (tenzij je 16G geheugen hebt misschien).

[Brent]

Dynamic heeft een kleine overhead tijdens het draaien van je app, er is immers een extra laag van abstractie. Dus je zou het argument van snelheid ook om kunnen keren: eens geladen, is een static app sneller.

[SuperDre]

Aan de andere kant, waarom inefficient bezig zijn als het ook efficient kan? We krijgen steeds snellere cpu's/gpu's maar toch lijkt het weer dat elke nieuwe versie van software trager draait op dezelfde hardware dan de oude versie ervoor..
En laten we dan al helemaal hebben over meerdere gebruikers tegelijkertijd op server, zou het niet fijner zijn als resources zo efficient mogelijk gebruikt worden?

[rvl1980]

Dat maakt toch niet zoveel meer uit. Opslag kost nu veel minder dan 10jaar geleden.

Jaja... M'n ultrabook 800 euro, 3 maanden oud, heeft gewoon een 120GB ssd erin hoor:

Filesystem Size Used Avail Use% Mounted on
/dev/dm-1 106G 98G 8G 92% /

En nee daar staan geen tientallen films, iso's of whatever op... Ubuntu 14.10 redelijk default, ontwikkelomgevingen zoals Android Studio met android SDK en andere, wat virtual machines van bescheiden grootte (4-6G per stuk) etc.

Dus ik zit nu op het punt dat ik moet kijken: wat heb ik niet nodig en wat moet ik op externe disk opslaan.

[Terracotta]

Opslag kost misschien niets, het downloaden van deze updates kost wel.
Enkel Thuis updaten?
Wat dan als je in het buitenland bent en je telefoon begint te updaten (yes android, looking at you), elke update wordt zo nog een pak groter (en duurder)

Niet updaten in het buitenland?
Wat dan met veiligheidsupdates in verschillende pakketten, een niet gepatcht systeem is een onveilig systeem.

Honestly,
Dependency hell is al even geen probleem meer. Goed geschreven code daarentegen...

[fraggie]

Dan had je alleen updaten via wifi aan moeten zetten...

[roy-t]

Ik denk dat tegenwoordig geheugen gebruik van libraries niet meer zo'n probleem is. Veel vervelender is het als een programma niet meer werkt omdat je niet exact dezelfde versie van een library hebt als bedacht was ten tijden van het maken van het programma. Op Windows heb je hier onder andere SxS voor, maar sommige programma's werken net weer anders en gaan dan toch op hun bek.

Maarja het heeft dus zowel voor als nadelen.

[rubenvb]

Linux so's hebben versie nummers, zodat als de ABI verandert, je een apart bestand hebt, bv libvpx.so.1.2 en libvpx.so.2.0. Applicaties die niet geüpdatet zijn voor de nieuwe versie linken gewoon met de oudere. SxS was een briljant systeem om DLL hell op te lossen, maar Linux heeft helemaal geen DLL hell, tenminste als je weet waar je mee bezig bent.

[StGermain]

Ik heb jarenlang Ubuntu gebruikt (meestal tot mijn volle tevredenheid) tot ik snapte dat Steam goedkoper is dan Xbox games spelen (dat terzijde) en ik terug gegaan ben naar Windows.

Ik moest toch geregeld de terminal induiken om programma's die niet meer werkten virtueel te linken met de nieuwere libraries omdat de oudere libraries niet meer te vinden waren. De ING software was daar een voorbeeld van.

Als ze dit er uit krijgen doordat ze met de snappy apps eindelijk een echte appstore gaan hebben waarbij de terminal geen 5 minuten staat te stampen op dependencies wordt Ubuntu misschien eindelijk echt geschikt voor de gewone gebruiker die niet kan of wil gaan zoeken naar oplossingen wanneer iets niet werkt.

Dat beetje verlies aan diskspace kan daar niet tegen opwegen.

[tinus61]

Volledig mee eens, inefficentie ten top

Ik ben daarnaast van mening dat Canonical met Ubuntu Desktop Next exact dezelfde fout als Microsoft met Windows 8 maken.

Mensen willen geen telefoon UI op hun 32" desktop scherm.

Ik gebruik Ubuntu sinds 2007 na tevredenheid, maar wat mij betreft begint Canonical nu toch echt de weg kwijt te raken. Verandering om de verandering

[MadEgg]

Daar lijkt het wel op. Elk programma levert dan zijn eigen libraries mee. Nogal omslachtig, hierdoor zijn de Mac OS X programma's vaak ook nodeloos groot. Uiteindelijk heb je meerdere keren dezelfde library erop.

Wat OS X nog als voordeel heeft is dat je een aantal system libraries hebt welke door praktische elk programma gebruikt worden (CF, Carbon, Cocoa en dat soort dingen) en dus niet met elk programma meegeleverd hoeven te worden, maar in Linux-land is er door de enorme keuze veel minder overeenstemming over welke libraries men gebruikt. Hierdoor kun je van veel minder libraries op het systeem uitgaan en moet er veel meer met de software meegeleverd worden.

Wat mij betreft een slecht idee. Maar goed, ik ben al een tijdje klaar met Ubuntu. Ubuntu phones / tablets zou ik nog wel eens willen uitproberen maar voor mijn desktop en laptop ga ik er niet meer aan beginnen.

[Reactie gewijzigd door MadEgg op 23 juli 2024 18:41]

[Aaargh!]

Heel goed idee juist, shared libraries geven niets dan ellende. Je moet alsnog een shitload verschillende libraries en versies bijhouden, elke app heeft toch een berg specifieke libraries nodig dus heel veel valt er vaak niet te sharen buiten was system libraries om.

Met bundles heb je alles bij elkaar staan ipv de files van 1 app over je hele systeem verspreid. Bundle weggooien en alle overbodige libs zijn weg.

[Blokker_1999]

En als je dan een lek hebt in de library moet je maar hopen dat elke maintainer die die lib gebruikt zijn/haar pakket wil bijwerken.

Shared libs zijn imho net een grote kracht van linux.

[SuperDre]

Shared libs zijn imho net een grote kracht van linux.

Je bedoelt het is een grote kracht van elk OS... nu doe je het overkomen alsof alleen linux dat heeft...

[rubenvb]

Elk OS heeft idd shared libraries, maar enkel de gecentraliseerde structuur van een Linux distro laat toe alles daarrond te laten draaien. Door de gedisciplineerde ABI compatibility van dingen zoals GCC, glibc, maar ook Qt en andere grote en kleine componenten geldt dit ook voor gesloten apps als steam en Skype, ware het niet dat zij insisteren op he meeleveren van verscheidene so's die de gebruiker dan maar terug moet verwijderen om het ding te laten werken.

Elke app op Windows levert z'n eigen DLL's, soms zelfs voor "core" dingen als de VC++ runtime. Dit maakt het onmogelijk om bugs in alle kopies van zo'n library op een systeem deftig te patchen.

Beide systemen werken maar er is wel degelijk een verschil in efficiëntie, niet alleen in schijfruimte, maar ook in security.

[SuperDre]

Onzin natuurlijk wat je zegt, want in principe is het net als bij linux de bedoeling dat je generieke dll's gebruikt die centraal zijn opgeslagen (bv de windows map), dat sommige mensen zelf hun versies van dll's meeleveren in de programma map heeft meer te maken dat ze geen risico willen nemen OF omdat ze echt een compleet afwijkende versie hebben..
DLL hell heb je op elk OS in principe (en ook .NET heeft net zo goed een DLL hell).

[rubenvb]

Sorry, maar dat is gewoon niet waar: de ABI compatibiliteit op Windows is veel brakker! Het feit dat iedereen z'n DLL's meelevert is omdat er geen manier is om zeker te zijn dat er wel een compatibele versie geladen wordt. Linux heeft hier so versies voor. Ja, je kan dezelfde techniek toepassen voor Windows, maar dat gebeurt gewoonweg niet, zelfs niet binnen de OS libraries.

[Nibble]

Ik weet niet of dit nou wel zo'n slim plan is. Zolang ze dan maar wel deb blijven ondersteunen, anders voorzie ik de zoveelste fork na hun zoveelste ideetje. Beetje raar ook om dat zo om te gooien als je juist niet bezig bent met je desktop omgeving. Hou dan tenminste wat je hebt stabiel en ga niet op 2 fronten (phone en desktop) innoveren met alle risico's van dien...

[SV_25]

Hier heb je een Q&A: http://www.webupd8.org/20...eventually-switch-to.html

"Q: Will all of Ubuntu be based on snappy packages in the mid-/long term instead of deb/click?
A: All Ubuntu will use snap packages eventually, yes. But the system images and even some of the snappy apps will be built from debs.'

Ik zie ook niets anders dan voordelen in het systeem
"A: Snap packages are more secure, yes, and they can be updated by their upstream at any time, they don't get frozen to the Ubuntu release. So you get newer apps, safer apps, and the upstream gets more control over it's distribution."

Edit: hopelijk zouden ze delta updates kunnen toevoegen, waardoor je niet verplicht bent om een hele snappy pakket opnieuw binnen moet halen na een update (libreoffice bv?). Iets gelijkaardig wordt bv al gedaan in de Play store op android.

[Reactie gewijzigd door SV_25 op 23 juli 2024 18:41]

[Blokker_1999]

Leuk dat upstream meer controle krijgt, maar dat is minder goed voor mensen die een stabiel systeem willen waarbij pakketten goed getest zijn en tijdens een release zo min mogelijk veranderen.

[Dykam]

Het lijkt mij aannemelijk dat je versies kan bevriezen.

[moeilijkenaam]

Het mooie aan snappy apps is toch juist dat als het misgaat je alleen de snapp weg moet halen, en het is gefixed? Omdat het, voor zo ver ik weet, andere (essentiële) delen van het systeem niet kan beïnvloeden?

[Treenaks]

Okay.. terug naar Debian dus op de middellange tot lange termijn. Check.

[Dubbeldrank]

Innovatie is niets mis mee, en zoals je kan lezen gaat het nog niet om een vervanging in de officiële releases. Ze gaan met 15.10 een aparte build maken in hun Desktop Next-lijn waarin ze dit gaan testen.

Overigens weet ik nog niet wat ik hier van moet vinden, ik heb met Ubuntu Snappy Core gespeeld en zag nog niet direct voordelen in dit nieuwe systeem. Zeker qua gebruiksvriendelijkheid ten opzichte van .deb en het apt-systeem.

[brompot758]

Voordeel van de .deb ondersteuning is dat je vaak dezelfde packages als debian kan gebruiken. Dat ze wat toevoegen is prima, maar als .deb ondersteuning verdwijnt zoals het artikel aangeeft ga ik op zoek naar een andere distro.

[sharkwouter]

Dan mogen ze wel dedup gaan implementeren.

[devvy]

Uitstekend idee. Apps nemen doorgaans niet het leeuwendeel van de schijfruimte in, dat zijn mediafiles. Dus die paar libs dubbel is geen issue.
De voordelen zijn enorm, install issues met incompatibele libs passé!

[mutley69]

Jammer genoeg zal ik dan naar debian overstappen - heb dat al draaien trouwens. Jammer - maar geen probleem dus.

[Verwijderd]

Ubuntu wil de desktop en mobiel integreren. Dat is een van hun keuzes.

Ubuntu moet keuzes maken en sommige keuzes, zoals Unity en MIR, worden grote controversiele issues omdat er goede argumenten voor en tegen zijn. Maar Unity werkt gewoon prima, Mir zal hoogstwaarschijnlijk ook goed werken en de snappy apps ook.

Stel nu dat canonical de keuze zou maken om er mee op te houden: we krijgen zoveel kritiek, blijkbaar kunnen we het niet, sorry. Dat zou pas echt jammer zijn.

Nee, daarmee bedoel ik niet dat er geen kritiek gegeven moet worden, of dat niet weer een nieuwe fork gestart zou mogen worden. Ik bedoel wat anders: Ubuntu werkt, Ubuntu onderhoudt vele 'smaken' en geeft daardoor keuzes aan de gebruikers. Kijk toch ook naar wat ze ondertussen wel opgebouwd hebben. Er zullen altijd controversiele keuzes opduiken.

@Thc_Nbl: Je zult wellicht een optie krijgen als: deze app heeft een security probleem, wil je de app disablen totdat het opgelost is?

[Thc_Nbl]

read-only images van applicaties die makkelijk te voorzien zijn van mailware/spyware/virussen ..
en fijn dat het dan read-only is.. kan je ze ook niet verwijderen...

dus...

bye ubuntu...

[Yggdrasil]

Een nogal naïeve reactie, volgens mij, tenzij ik je verkeerd begrijp.

Wat heeft malware/spyware, etc., nou te doen met read-only? Deze containerized apps zijn minder kwetsbaar voor malware als ze eenmaal geïnstalleerd zijn, en je kunt ze makkelijk volledig deïnstalleren. Read-only doelt op de inhoud van de applicaties, niet dat je de applicatie in zijn geheel niet kunt verwijderen.

Waarom zou je grote delen van je systeem, die na installatie alleen gelezen hoeven te worden, onnodig read/write laten? Kwaadwillende applicaties of users kunnen dan meer schade aanrichten dan wanneer deze read-only zijn.

[Verwijderd]

Ik weet niet of het wel handig is van Canonical.