Linux-services packagen met Snap

Aan de slag met Canonicals pakketformaat

Je snap publiceren

Om je snap in de Snap Store te publiceren, moet je eerst een Ubuntu One-account hebben. Maak een nieuw account aan op de website van Ubuntu One. Voer je e-mailadres in, selecteer 'I don’t have an Ubuntu One account' en vul je naam en een wachtwoord in.

Log op Snapcraft in en klik rechtsboven op 'Developer account'. Log dan in met je Ubuntu One-account en accepteer de gebruikersvoorwaarden. Log daarna op de opdrachtregel in met je Snapcraft-account:

snapcraft login

Voordat je je snap kunt uploaden, moet je de naam van de snap registreren. Klik daarom rechtsboven op 'Register a snap name' en vul de naam van je snap in, of registreer je snap op de opdrachtregel met:

snapcraft register theengs-gateway

Voordat je nu een release uitbrengt, moet je zeker verifiëren of je confinement op strict hebt ingesteld en controleren of je toepassing werkt.

Upload daarna je snap met:

snapcraft upload --release=stable theengs-gateway_0.3.0_amd64.snap

Merk op dat dit alleen de snap voor de amd64-architectuur uploadt. Wil je de snap ook voor de andere architecturen beschikbaar maken, dan dien je deze op een andere architectuur te bouwen en te uploaden, ofwel van de mogelijkheid voor remotebuilds gebruik te maken: dan bouw je de snaps via GitHub Actions of op een Launchpad-buildfarm, via de opdracht snapcraft remote-build. Het nadeel van die laatste is dat een dergelijke build even kan duren. Soms heb je in een half uurtje tijd de snaps voor alle architecturen, op andere momenten moet je uren wachten. Lokaal crosscompilen is helaas niet mogelijk in de nieuwste versies van Snapcraft. Je kunt het wel doen met de multi-architecture Docker-container van Snapcraft en met de Snapcraft Multiarch Build Action voor GitHub Actions.

Je snap voor andere architecturen bouwen, kan op de Launchpad-buildfarm.

Zodra de snap in de Snap Store staat, kun je deze eenvoudig op elke Linux-distributie die snapd draait als volgt installeren:

snap install theengs-gateway

Daarna stel je weer de nodige opties in, maak je de juiste verbindingen en start je de service.

Je snap is te installeren via de Snap Store.

Conclusie

Services voor Linux-distributies packagen in het snapformaat is geen rocketscience, maar je bent er wel even mee bezig. De documentatie van Snapcraft is uitgebreid, maar niet altijd even duidelijk en up-to-date. Bovendien is het snapformaat sterk geëvolueerd, waardoor voorbeeldcode van vroeger of voor oudere cores niet meer werkt. Je moet ook wel even zoeken voor de build zonder foutmeldingen lukt, zeker als je meerdere architecturen wilt ondersteunen.

Het programma Snapcraft heeft wel een goede helpfunctie en geeft duidelijke en concrete foutmeldingen. Met wat iteraties en wat opzoekwerk lukt het zo wel om een service te packagen. Heb je dan uiteindelijk een snap, dan is het voordeel dat je deze op alle ondersteunde Linux-distributies kunt installeren. Snap is bovendien het native pakketformaat voor Ubuntu Core, waarop we in een volgend artikel ingaan.

Reacties (92)

[Cyberwizzard]

Zeer interessant!

Misschien ook relevant om te vermelden: snapcraft lijkt alleen cores gebaseerd op Ubuntu te ondersteunen: https://snapcraft.io/docs/base-snaps

Jammer, want ik heb wat oude software wat RedHat nodig heeft en dat werkt dan blijkbaar niet met snaps....

[SambalBij]

Ja ze verkopen het leuk als universeel formaat, maar het is simpelweg alleen maar Ubuntu... met alleen maar een Canonical app store...

https://xkcd.com/927

Deze meuk is in ieder geval voor mij de reden om gewoon weer Debian te draaien. Eerder was je al een tijd bezig om die snapd uit te schakelen en te verwijderen, maar geloof dat ze tegenwoordig bepaalde software alleen nog maar als snap distribueren en niet meer als normaal package.

[CybernDystopia]

Ik ben ook verbaast dat er een heel artikel gewijd wordt aan een package manager/store die >>>centraal<<< staat aan Ubuntu/Canonical, en dat er niet voor bijv. het distro breede Flatpak is gekozen.

Mensen die Linux Mint draaien (gebaseerd op Ubuntu) zullen ook tegen obstakels aanlopen omdat snap daar doelbewust aanvang 2019 uit is gesloopt en niet is te installeren zonder eerst specifieke handelingen te verrichten.

...
A Fedora user shouldn’t be told about Ubuntu and Ubuntu One when downloading software. His browser shouldn’t have bookmarks pointing to another distribution. His software shouldn’t be designed and tested primarily with another desktop environment and distribution in mind, and when he looks at screenshots he shouldn’t see Ubuntu everywhere. It’s wrong for Spotify to do that and it’s wrong for any vendor to think that such a store can be the only store for all Linux users. For this to work it would need to be governed by us all, with clear goals, without bias and without conflict of interest.
...

...
A year later, in the Ubuntu 20.04 package base, the Chromium package is indeed empty and acting, without your consent, as a backdoor by connecting your computer to the Ubuntu Store. Applications in this store cannot be patched, or pinned. You can’t audit them, hold them, modify them or even point snap to a different store. You’ve as much empowerment with this as if you were using proprietary software, i.e. none. This is in effect similar to a commercial proprietary solution, but with two major differences: It runs as root, and it installs itself without asking you.

First, I’m happy to confirm that Linux Mint 20, like previous Mint releases will not ship with any snaps or snapd installed. Second, to address this situation we’ll do exactly what we said we would:

In Linux Mint 20, Chromium won’t be an empty package which installs snapd behind your back. It will be an empty package which tells you why it’s empty and tells you where to look to get Chromium yourself.
In Linux Mint 20, APT will forbid snapd from getting installed.

You’ll still be able to install it yourself and we’ll document this in the release notes, but by default APT won’t allow repository packages from doing this on your behalf.
...

[Reactie gewijzigd door CybernDystopia op 22 juli 2024 14:16]

[Halfscherp]

Het zou Tweakers inderdaad gesierd hebben om dit artikel over Flatpak in plaats van Snap te schrijven..

[HollowGamer]

Of een vergelijking tussen de grootste. Daarvoor hoef ik overigens bij meerdere sites geen Plus-abo voor te nemen (en die gaan nog dieper ook).

[Pjotr Pinda]

Ach, was interessant om te lezen.
Het zou me verbazen als het maken van een flatpak wezenlijk anders gaat.
Ik heb een aantal RPM's gebouwd en ik zie vooral overeenkomsten.

[Mangu429]

Leuk voor je maar het zijn juist de verschillen die het gebruik ervan onmogelijk maken, zoals door anderen al aangegeven.

[hsb85]

Ja precies, universeel is het zeker niet. Vrijwel alle distro's ondersteunen snap helemaal niet of je moet iets extra's (en niet ondersteund) doen om het te krijgen.

Bij openSUSE bijvoorbeeld moet je een extra repo toevoegen die niet mee gaat in alle openQA testen en niet ondersteund wordt. Er zijn wel discussies gevoerd of snap in de officiële repo's kan, maar dat is altijd op basis van beveiliging-audits afgeschoten.

https://bugzilla.opensuse.org/show_bug.cgi?id=1127368#c3

[Reactie gewijzigd door hsb85 op 22 juli 2024 14:16]

[FireDrunk]

Uh he? Ik heb iets gemist... Fedora (wat ik draai) heeft native ondersteuning voor Snap, komt gewoon uit de normale Repo's.

Als ik deze wiki pagina mag geloven: https://en.wikipedia.org/wiki/Snap_(software)#Adoption

A number of Linux distributions support Snap out of the box such as Ubuntu (and its derivatives, such as Kubuntu and Xubuntu),[60] Manjaro,[61] Zorin OS,[62] KDE Neon,[63] Solus[64] and Li-f-e.[65] Snap is also available for many other distributions such as CentOS, Debian, Elementary OS, Fedora, GalliumOS, Kali Linux, Linux Mint, OpenEmbedded, Parrot Security OS, Pop!_OS, Raspbian, Red Hat Enterprise Linux and openSUSE.[66]

Dat zijn er toch echt een hoop...

[hsb85]

‘available’ betekent niet ondersteund of überhaupt beschikbaar in de officiële repos.

voor openSUSE moet je echt een aparte repo toevoegen. handleiding daarvoor staat wel op snapcraft.

en Linux Mint is ook bizar dat die op de lijst staat. zij werken snap juist actief tegen.

[Reactie gewijzigd door hsb85 op 22 juli 2024 14:16]

[pmeter]

Ik had ook graag willen lezen of Snap voor mij een goed idee is voordat ik verder ga met de howto. Starten apps bijv. trager op? Zijn de configuratie bestanden nog wel makkelijk te vinden op de plek waar howto's over specifieke progs zeggen dat ze staan? Beperk je jezelf als je in de snap store zoekt of staan vrijwel alle apps daarin? Lopen snaps gelijk op of achter op nieuwe versies. Zijn er andere nadelen? Wat zijn de voordelen tov apt-get? Zijn er andere alternatieven die ook de libs bundelen en hoe vergelijken die in functies, performance, aanbod etc?

Ik zou graag een artikel zien over zulke vragen. Dan kun je een geïnformeerde keuze maken en als je kiest voor Snap dan is deze howto handig.

[Reactie gewijzigd door pmeter op 22 juli 2024 14:16]

[kinlo]

Laat ik je vragen beantwoorden:

Starten ze trager op? Uiteraard, gezien elke applicatie in zijn eigen container draait heb je dus ook je eigen libraries en versies, waardoor je applicatie geen systeemlibraries meer kan hergebruiken, waardoor ze dus geen libraries kunnen hergebruiken (als je dezelfde library gebruikt gaat linux achterliggend de code geen 2x in het geheugen laden) dus er is meer geheugengebruik en meer laadtijd.

Zijn de configfiles op dezelfde plaats? Welja dat hangt af van hoe dat de snap gemaakt is, daar is de vrijheid van de persoon die de snap maakt over hoe het werkt

Beperk je jezelf met de snap store: Jazeker, veel applicaties staan niet in de snap store. Beschouw het als nog een extra plek om je applicaties op te publishen, het hangt dus van applicatie tot applicatie af

Lopen ze gelijk kwa versie? Hangt af van wie ze maakt en hoe actief die de snap's updated

voor/nadelen tov apt-get: Basically zijn snaps containers, dus je gaat een groot deel van het os dubbeldraaien zodat de persoon die de snap maakt niet alles opnieuw moet maken voor elke versie van elk os. Dit is dus een hele overhead die je niet hebt bij apt-get. Snaps zijn dus eigelijk alleen maar aan te raden per uitzondering, je wil niet telkens een hele nieuwe container opzetten en starten voor een dom klein randprogrammaatje. Het voordeel is wel natuurlijk dat het in een container draait en dat dus de rechten kunnen worden dichtgeschroeft, dat dus de applicatie in een zandbak kan draaien en dus veiliger kan zijn. Let op het gebruik van de voorwaardelijke wijs: dit hangt volledig af van hoe de snap gebouwd is

Alternatieven: wat er op andere comments al vermeld staat: flatpack is niet ubuntu-only en eigelijk the way to go...

[WernerL]

Gelukkig is er flatpak voor andere distributies. Maar wel jammer dat er niet één universele oplossing kan zijn voor Linux.

Ik ben ondertussen ook afgestapt van Ubuntu omdat dit niet de eerste keer is dat ze hun eigen meuk proberen te pushen. (Mir vs wayland)

[Blokker_1999]

Mir, Unity, upstart? (of was het kickstart?),... Zovele keren hebben ze het al geprobeerd en telkens geven ze het na enkele jaren op.

[Archcry]

Ik hoop dat snap dezelfde toekomst tegemoet gaat.

[HollowGamer]

Dan vergeet je ook nog hun mobiele Unit avontuur.

Maar inderdaad, ze maken nooit iets af of de implementatie ervan is gewoon niet community vriendelijk.

[Hydranet]

Volgens mij zijn Flatpaks en AppImages heel wat meer universeel als Snaps.

[Katsunami]

Het gaat zelfs zo ver dat ze de pacakage manager omleiden: als je "apt install firefox" doet dan krijg je de snap, niet de versie uit de repository. Dat is compleet van de zotten. Als ik "apt install" typ, dan verwacht ik een repo-package, en geen snap. Als ik die had gewild, dan had ik die wel geïnstalleerd.

[Clemens123]

Geen fan van snap / flatpack etc, alles containeren vraagt meer ruimte, zorgt voor slecht gemaintainde libs want niemand dwingt een snap / flatpack /... om de libs daar actueel te houden (gevolg mogelijke ongepatchte security problemen), developers trekken zich nog minder aan van stabiele apis in libs want geen probleem dankzij snaps / flatpacks...geef mij maar good old apt (of nala on top) en gelijkaardige varianten die shared libs juist gebruiken.
En als je alle afhankelijkheden wilt bundelen als fallback om welke reden dan ook...link gewoon statisch, geen flatpack / snap / ... nodig hiervoor imho.

[GekkePrutser]

Exact... Dat vind ik ook het probleem van te overvloedige containerisatie.

Nu op een traditioneel systeem, is er een exploit in OpenSSL ontdekt, update ik de lib en hoppa, alles gefixt. Met een snap systeem moet ik op elke maintainer gaan zitten wachten. Bovendien ontbreekt voor de maintainers nu de 'stok achter de deur' om nieuwere library versies te gaan ondersteunen: Immers kunnen ze gewoon de oude versie mee blijven leveren!

Bovendien kan de shared loader zijn werk niet goed doen als elke container aparte versies van libraries heeft. Dus veel meer geheugengebruik.

Voor echt exotische pakketten zie ik het nut wel, maar niet voor echt elk dingetje waarvoor ubuntu het nu gebruikt. Ik zie ze zelfs dingen snappen nu die in go gemaakt zijn dus helemaal geen dependencies hebben.. Dat gaat nergens meer over.

Blijft over de extra beveiliging van containers, maar dat is iets dat je ook prima op kan lossen met Mandatory Access Control technieken zoals AppArmor, SELinux enz.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:16]

[amx]

Inderdaad: Alleen maar omdat de kamer er opgeruimd uitziet, betekent het niet dat de kast niet uitpuilt van de rommel

Het vrijwaart je nog steeds niet als beheerder van de verantwoordelijkheid je systeem in de gaten te houden

Het gebruik van een socket waar alle communicatie met het hostsysteem door loopt, is echter aanzienlijk veiliger zodra je diensten aan het internet hangt

[Slaiter]

Het draait inderdaad in een container en als een andere snap/flatpack dezelfde libs nodig heeft wordt deze echt niet nog een keer geïnstalleerd en gewoon geshared.

[Clemens123]

Maar "zelfde lib" betekent exact dezelfde versie? Of major versie? En worden deze libs geupdate als er (security) patches zijn? Of is het aan de package maintainer van de snap om dat bij te houden?

[Reactie gewijzigd door Clemens123 op 22 juli 2024 14:16]

[Mangu429]

Ah, men wil zijn eigen DLL-hel, een lib-hell. Top!

[oef!]

Het is meer een kwestie van het juiste gereedschap voor de juiste klus. Soms is een package manager handig, soms een container. Een van de twee uitsluiten is jezelf tegenwerken.

[Clemens123]

Je kan zeker voor beide iets zeggen, en ik snap dat voor een dev het heel handig is alles tesamen te shippen voor de eindgebruiker. Alleen krijg je op die manier een onoverzichtelijke wildgroei van libs op je systeem waarvan de meesten outdated kunnen zijn.

Voor development zijn zulke containers top, voor uitzonderlijke situaties waarbij iets niet meer wil draaien (oude SW) ook, vind het ook goed dat devs het aanbieden, maar gebruikers uitleggen dat ze voor alles snap / flatpack gebruiken vind ik niet de juiste weg, omwille van de reden die ik aangehaald heb (outdated shared libs, geen overzicht hebben in welke libs nu op je systeem staan en of ze al dan niet outdated zijn). Maar is wel de kant dat de industrie naar toe gaat om Linux aan de man te brengen.

Nu ik heb zelf ook een tijd nodig gehad tegen ik goed door had hoe ik apt moet configureren met meerdere sources (pinning) zodat ik niet om de haverklap mijn systeem brick...maar het zou beter zijn als dit goed uitgelegd wordt (of eens een GUI voor gemaakt wordt voor de pinning) dan dat je een minder goed alternatief gebruikt.

[Reactie gewijzigd door Clemens123 op 22 juli 2024 14:16]

[HollowGamer]

Het voordeel is wel dat je containers kunt sandboxen.

[Clemens123]

Processen kun je ook gewoon sandboxen en heel veel restricties opleggen wat sockets / files aangaat, containers hebben daar weinig mee te maken denk ik.

Ook met snap is het waarschijnlijk wel makkelijker te managen die sandboxes, aangezien het altijd aan staat.

[Reactie gewijzigd door Clemens123 op 22 juli 2024 14:16]

[bertronics]

Dan kun je wel een mooi artikel schrijven over Snaps, complimenten, maar het punt voor mij is dat Ubuntu weer eens een eenmans-actie uithaalt die weinig ondersteuning van de community geniet.
Na Upstart, Mir, Unity, Hud etc. ben ik een paar geleden overgestapt op Fedora en dat bevalt prima.

[shades]

100 smaken, 100 meningen.
Op het werk gebruiken we oracle linux (redhat based, wat weer fedora based is) - Thuis werk het het liefst met debian (mijn werkstation is ubuntu 20.04 lts) want dat werkt allemaal toch net even wat beter fijner en voor mijn gevoel is er een grotere "fan-base" waardoor je ook meer oplossingen/hints voor oplossingen voor een probleem kan vinden. Maar in de basis is het eigenlijk hetzelfde. Oracle Linux heeft weer zijn eigen repo's die wel lijken op de van Fedora maar is niet hetzelfde. In die zin zou je kunnen zeggen dat dat ook weer een eenmans-actie is. Daarentegen: snap werkt gewoon lekker - het enige is dat je mount table echt vies wordt. Dat vind ik het grootste nadeel.

Verder een fijn plus topic.

[Reactie gewijzigd door shades op 22 juli 2024 14:16]

[divvid]

Fijn om hier eens wat meer van te leren. Thuis ook op Ubuntu 22.04. Dat van die mount table vind ik ook heel irritant. Bovendien wordt je base ook een stuk groter door allerlei dubbele libs. Wat ik mis in het artikel is een echte vergelijking met andere technologieen. Werkt het nou beter/slechter. Hoe zit het met performance? Is docker niet beter/slechter dan snaps, zeker met weinig gebruikte software? etc.etc.

Hier op het werk ook een grote discussie nadat CentOS rolling release is gegaan (wil je niet op productie servers in ons geval).

Wordt het nu RockyLinux, AlmaLinux of toch maar RH? Persoonlijk mijd ik zoveel mogelijk alles wat met Oracle te maken heeft nadat ze ons een grote licentie loer wilde draaien. (wat resulteerde in een versnelde invoer van PostgreSQL voor heel veel services....iets met voet en schieten)

[Reactie gewijzigd door divvid op 22 juli 2024 14:16]

[shades]

Docker en snap toch echt wel twee verschillende dingen. Voor wat betreft die dubbele libs: - ja en nee. Je hebt altijd een setje dat werkt. Hoe vaak komt het niet voor dat je iets via de reguliere repo's installeert of moet updaten (yum, of apt) en je krijgt een geupdate dependency wat net een andere applicatie totaal niet snapt (haha "snap"t) - Daarin kan je misschien docker en snap wel op 1 lijn zetten. Je krijgt wat en het "zou moeten werken" omdat je het als 1 geheel krijgt.

Op ons werk vinden we die rolling releases ook niet zo fijn, maar omdat we 20 oracle databases hebben willen we graag oracle linux hebben en ik vermoed dat oracle linux 9 ook rolling is. Nog niet eens naar gekeken. Persoonlijk had ik ook liever iets anders gezien dan oracle db; maar onze main applicatie maakt voor een heel groot deel nog gebruik van pl/sql - Het wordt wel steeds minder, maar "even ombouwen" is er gewoon niet bij - verder zou ik niet weten of postgresql ook materialized views en een dataguard mechanisme heeft.

[Ventieldopje]

Hoe vaak komt het niet voor dat je iets via de reguliere repo's installeert of moet updaten (yum, of apt) en je krijgt een geupdate dependency wat net een andere applicatie totaal niet snapt (haha "snap"t)

Nou, eigenlijk nooit? Weet niet hoe dat zit bij andere distros maar zelf gebruik ik al jaren Arch dagelijks voor werk als software developer en dat soort gekkigheid kun je op 1 hand tellen in al die jaren. Veel verhalen van mensen die dingen bricken zijn dan ook mensen die maar wat doen of partial upgrades willen doen.

Op ons werk vinden we die rolling releases ook niet zo fijn, maar omdat we 20 oracle databases hebben willen we graag oracle linux hebben en ik vermoed dat oracle linux 9 ook rolling is. Nog niet eens naar gekeken.

Die hebben dezelfde fout als CentOS 9 gemaakt dus? Op servers wil je gewoon geen rolling releases. Een goed upgrade path is wel fijn maar dan kun je daar zelf voor kiezen en is dan ook een stuk stabieler.

[shades]

Nou, eigenlijk nooit?

Dat klopt. Ik heb het zelf eigenlijk pas een keer meegemaakt: toevallig had ik een paar maanden geleden toch een issue met R - die kwam uit de epel repo en bij een eerst volgende update had die een versie nodig van r-core-devel (waarvan de initiële versie ook uit epel kwam) maar die stond mooi niet in de repo waar die vandaan zou moeten komen. En dan ben je dus aan het klooien om het goed te krijgen.

[divvid]

Ah R…net geprobeerd vanuit source. Hell

[Mellow Jack]

Die hebben dezelfde fout als CentOS 9 gemaakt dus? Op servers wil je gewoon geen rolling releases. Een goed upgrade path is wel fijn maar dan kun je daar zelf voor kiezen en is dan ook een stuk stabieler.

Oeh leuke discussie altijd, wij zijn uitgekomen op Alma Linux voor stabiele zaken maar in sommige situaties is iets als Cent OS stream logischer tov Alma, Rocky of Red Hat. Wij ontwikkelen voor klanten die RHEL draaien waardoor de realiteit is dat updates soms issues bij klanten veroorzaken voordat wij die updates ontvangen (want tja, Alma loopt gewoon net iets achter RHEL aan)

Enne je opmerking over jou ontwikkel machine is wel logisch, het veranderd wel iets wanneer je met een klein team 2000 of 3000 servers moet beheren die sterk van elkaar verschillen

[Reactie gewijzigd door Mellow Jack op 22 juli 2024 14:16]

[divvid]

verder zou ik niet weten of postgresql ook materialized views en een dataguard mechanisme heeft.

Jup, al weer een hele tijd. Ook wij hadden heel veel pl/sql. Lastig om te porten en uiteindelijk een hoop buiten de database getrokken. Dat helpt voor de maintainability. Uiteindelijk hebben we 87 % van de instances kunnen vervangen omdat dat uiteindelijk toch vrij simpele toepassingen waren

[Katsunami]

LOL. De hele Linux-wereld gaat over de knikker vanwege het feit dat Canonical WEER een eigen ding probeert te pushen waar niemand in geïnteresseerd is, en Tweakers schrijft er een Plus-artikel over. Had er dan een gemaakt over FlatPak, dat door iedereen behalve Canonical wordt gebruikt; of wat mij betreft, AppImage. Dan hadden we er nog iets aan gehad.

[Reactie gewijzigd door Katsunami op 22 juli 2024 14:16]

[Mellow Jack]

het feit dat Canonical WEER een eigen ding probeert te pushen waar niemand in geïnteresseerd is

De afgelopen jaren een hoop dingen geprobeerd traditionele apps, docker containers, appimages etc. Snaps hebben me tot nu toe de meeste fijne ervaring gegeven voor mijn privé situatie. Jammer dat je dus een statement probeert te maken over iets waar "niemand" in geïnteresseerd is

Moet eerlijk toegeven dat de door mij gewenste software ten tijde van mijn laatste herinstallatie niet o.b.v. flatpak beschikbaar was dus mogelijk werkt dat net zo fijn.

Zal het zakelijk nog niet in m'n hoofd gehaald om het te opperen maar dat komt vooral omdat we nogal redhat georiënteerd zijn. Maar in feite heb ik ook zakelijk flink wat situaties gehad waar iets als snaps fijn kunnen zijn. Zo moesten we een tijdje geleden rstudio en shiny voor een project klaarzetten, pff wat een ellende is dat

[Blokker_1999]

De kritiek gaat vooral over het feit dat snaps iets van Canonical is dat enkel door Canonical ondersteund wordt en er amper andere distributies zijn waarin je het kan gebruiken. Leuk als je gebruik maakt van Ubuntu, maar voor alle andere Linux gebruikers is het dan ineens weer niet meer van toepassing. En dat terwijl er dus andere formaten zijn die wel door alle distributies te gebruiken zijn.

Canonical komt altijd wel weer met iets nieuw af waarin zij denken een eigen alternatief op de wereld te kunnen zetten en eindelijk eens een technologie te bouwen die door heel de Linux wereld zal geadopteerd worden. Maar telkens falen ze opnieuw en opnieuw net omdat Canonical dit soort projecten meestal opzet als een te gesloten geheel.

[Mellow Jack]

Ben ik met je eens maar 't is wel typisch dat je veel klachten hoort en ziet over Canonical terwijl ook bijvoorbeeld RedHat meerdere dingen doet die ofwel niet werken op bijvoorbeeld Debian platformen ofwel alleen met een flinke omweg te realiseren zijn. Maar daar lees ik op sites als bijvoorbeeld tweakers.net nooit iets over

[GekkePrutser]

Daar heb je gelijk in hoor. Ik vind zowel Canonical als RedHat/IBM niet goed bezig, persoonlijk.

Daarom ben ik ook doorgegaan naar FreeBSD, daar zit de minste corporate invloed achter om het een bepaalde kant achter te sturen.

[bas-r]

Spijker op zijn kop!
Of schrijf iets over hoe je van een Snap een Flatpak maakt, daar zijn voldoende mogelijkheden voor, sommige beter dan anderen.

[Jerie]

Zijn ook nog steeds showstoppers met Snap (theming en trage opstart bijvoorbeeld). Ik ben in ieder geval pissed dat ik geen Firefox via APT als *.deb mag installeren.

Ik had dan inderdaad liever een artikel gelezen over Nix of Docker (in die volgorde).

[Hydranet]

Zijn ook nog steeds showstoppers met Snap (theming en trage opstart bijvoorbeeld). Ik ben in ieder geval pissed dat ik geen Firefox via APT als *.deb mag installeren.

Het kan wel maar dan moet je het wel zelf instellen. En ik het echt irritant hoe afhankelijk Ubuntu van Snaps is geworden omdat het bijna geen optie meer is.

[Reactie gewijzigd door Hydranet op 22 juli 2024 14:16]

[kiang]

...Dus Tweakers mag enkel wat schrijven over dingen waar bepaalde Linux-goeroes enthousiast van worden?

Gezien de populariteit van Linux moeten we misschien niet al te veel waarde hangen aan wat de hardcore Linux community wel of niet leuk vindt

[Katsunami]

Snap is kut. Daar zijn verschillende objectieve redenen voor. Het grootste deel van de Linux-wereld wil het niet, en mensen zijn bij Canonical weg aan het gaan vanwege het gepush, en het verkrachten van apt voor verschillende packages zoals Firefox.

FlatPak wordt door meerdere zo niet alle distributies ondersteund, is niet deels proprietary, heeft geen problemen met themes en start sneller, en de Linux-wereld is er blij mee (behalve misschien de ultra-hardcore mensen die vinden dat er niks anders bestaan dan repo-apps).

Als je dan een artikel schrijft over een container-technologie en je kunt kiezen tussen Snap en FlatPak, dan is Snap objectief de verkeerde keuze.

[amx]

Jammer en typisch. Ik vind het een goede bijdrage en wat mij betreft is een snap package op een Ubuntu server perfect. Ubuntu heeft nog steeds een imago als gebruikersvriendelijk en gezien de samenwerking van Canonical met Microsoft geeft het redelijk getuige van kunnen communiceren met andere visies nalevende bedrijven. Of zodra je eenmaal in de Linux materie verdiept bent Ubuntu nog steeds de meest gebruiksvriendelijke vindt, is een tweede.

Mijn ervaring als Ubuntu gebruiker is na installeren van een appliance via snap de drempel om andere containertechnologieen te leren lager werd. Aanvankelijk heb ik zowel LXD als Docker geinstalleerd als snap package. Voordeel is het automatisch updaten, en niet het gedoe om het te installeren.

Overigens is Canonical niet de enige overloper. Ook Leonard Poettering werkt voor Microsoft. Opnieuw een voorbeeld van hoe giftig de "Linux community" iets of iemand uitkotst zodra een mening heersend wordt.

[GekkePrutser]

Een van de problemen met snaps is dat Canonical de sourcecode van de store voor zichzelf houdt. Zij zijn de enige die snaps kunnen distribueren, blijven dus de 'gatekeeper' van dit platform en daarmee is het nooit echt open. Ik denk dat het idee erachter toekomstige monetisatie is (die bekende 30% van de apple app store enz). Logisch dat dat tegen de haren strijkt van de Linux gemeenschap. Je kan nu gratis software gewoon gratis publiceren, maarja, Canonical is een bedrijf, dat kan zo overgenomen worden en de stoel onder je uit getrokken worden.

Overigens is Canonical niet de enige overloper. Ook Leonard Poettering werkt voor Microsoft. Opnieuw een voorbeeld van hoe giftig de "Linux community" iets of iemand uitkotst zodra een mening heersend wordt.

Poettering was allang al een polariserend figuur al heel lang voordat hij voor Microsoft ging werken. en zelfs voor hij systemd maakte. Dat heeft niets met 'overlopen' te maken. Het gaat meer om de manier waarop hij zijn mening uitdraagt, en ook doordrukt op sommige gebieden (bijv. door Systemd een vereiste te maken voor andere dingen die uit de redhat koker kwamen, puur zodat mensen het wel moesten gaan gebruiken).

Overigens is dit niet iets waar hij alleen in staat. De open source gemeenschap bevat veel van dat soort mensen. Het zijn vaak mensen die nogal uitgesproken zijn en dus niet zo heel goed in het traditionele zakenleven inpassen. Linus himself is een hele tijd erg "toxic" geweest. Of Richard Stallman van Gnu? En andere mensen zoals Theo de Raadt van OpenBSD... Daar kan Poettering nog een puntje aan zuigen En het hogere gehalte van 'eigenaardige' figuren is dan ook wel iets wat zich uit in een wat gepolariseerdere community.

Vergeet ook niet dat in de FOSS gemeenschap het gebruikelijk is om gewoon te zeggen wat je vindt. Als je voor een Microsoft werkt dan kan je niet op het podium gaan blaten wat je wil, dan krijg je een hele berg media/PR types over je heen die alles zo non-aanstootgevend willen spinnen als het maar kan. Als je daar niet in mee gaat dan lig je er gewoon uit.

Eigenlijk geef ik dan ook wel de voorkeur aan wat meer 'echtheid' in de mensen in plaats van al dat fake PR geblaat en video's met blije mensen en vrolijke muziek. Ik ga veel liever naar een FOSS evenement dan naar een Microsoft Ignite, Blackhat, Google IO enz. Op een FOSS evenement leer ik hoe het echt zit, op die andere evenementen leer ik vooral wat hun salespakken ons willen gaan verkopen de komende tijd.

[Reactie gewijzigd door GekkePrutser op 22 juli 2024 14:16]

[Katsunami]

en gezien de samenwerking van Canonical met Microsoft

De meeste MS-producten zijn ook brak. Er valt niet meer fatsoenlijk mee te werken, met hun versplinterde user interface met 10 hamburgermenu's en "..." menu's voor elke regel. Als iets of iemand met MS samenwerkt wil ik het eigenlijk zelf al niet meer hebben. Ik werk er de hele dag op mijn werk mee, en de gebruikerservaring van veel MS-producten is simpelweg vreselijk. Heb je al eens geprobeerd om iets in de Azure-Wiki voor elkaar te krijgen? Je bent 70% van de tijd bezig met klikken door die gare UI. Als Ubuntu dat nastreeft, dan kan ik me indenken waarom de Linux-community de distro niet meer de moeite waard vindt, zeker naarmate ze zich steeds meer en meer gedragen als het Microsoft van vroeger.

[amx]

Ik maak me er niet zo druk om. Azure is vooral erg traag, is mijn ervaring. Ik vind het feit dat Canonical wel samenwerkt met Microsoft geen slechte ontwikkeling. Ik denk dat Microsoft op een hele andere manier in de desktopmarkt zit dan Canonical, en in de servermarkt is het besturingssysteem zelden waar je de meeste aandacht op richt.

[Katsunami]

Ook Leonard Poettering werkt voor Microsoft.

Mooi. Dan werkt hij dus hopelijk niet meer aan Linux- of opensource-producten. Lennart Poettering is een mafketel. Al zijn software waar hij ooit aan gewerkt heeft is enorm groot, probeert 200 dingen tegelijk te doen, slaat zijn spul op in binaire bestanden, werkt vaak niet samen met de Linux / Unix-manier van werken, en is vaak niet compatibile met andere systemen dan de laatste paar kernels van Linux zelf. In het slechtste geval zijn stukken software die niks met systemd te maken zouden moeten hebben, toch afhankelijk ervan, zoals Gnome.

Er is een reden waarom de open-sourcewereld Lennart Poettering in het algemeen uitkotst (en soms zelfs met de dood bedreigt). Hij schrijft software die opensource is, maar volledig anti-opensource werkt en meer lijkt op Microsoft-software dan op Linux-software.

De enige reden dat zijn software veel gebruikt wordt is omdat hij voor Red Hat werkte; en als Red Hat iets doet, dan doet iedereen het, bijna omdat je niet (meer) anders kan.

[Reactie gewijzigd door Katsunami op 22 juli 2024 14:16]

[Plofkotje]

Het pushen van deze Snap onzin is voor mij een reden om het hele serverpark van Ubuntu 18.04 naar Debian 11 te brengen.

Beetje klaar met Canonical die constant wilt afwijken van de rest.

[Anck]

Dit dus. Snap is objectief slechter dan repo, flatpak en appimage. Een van de grootste mankementen aan de laatste Ubuntu is de Firefox snap en de meest gezochte en aangeraden post install tip is dan ook het verwijderen van snap. Op Ubuntu gebaseerde distros slopen snap bewust eruit om zo een betere gebruiks ervaring te bieden. Wat mij betreft mag snap morgen bij het grof vuil maar ben bang dat canonical het nog een of twee releases blijft pushen voor ze het weer opgeven.

[GekkePrutser]

Wat mij betreft mag snap morgen bij het grof vuil maar ben bang dat canonical het nog een of twee releases blijft pushen voor ze het weer opgeven.

Ik denk dat ze tegen die tijd al zijn opgekocht door MS. Ze zijn zo met elkaar aan het aanpappen de laatste tijd, ik ben verbaasd dat het nog niet gebeurd is. Zeker nadat RedHat door IBM werd overgenomen, leek het me een kat-in-het-bakkie.

[hsb85]

Buiten Ubuntu worden snaps nauwelijks gebruikt. Veel groter zijn flatpaks.

willen jullie ook daar zo’n artikel over maken?

[WOteB2]

En niet te vergeten Appimage wat ook heel makkelijk is. Even uitvoerbaar maken en starten maar.

[hsb85]

ja mits je alle dependencies hebt die de AppImage verwacht dat je hebt. wat niet altijd het geval hoeft te zijn..

[samtoxie]

Die zitten gebundeld in de appimage...

Enige wat je geinstalleerd moet hebben is de appimage runtime

[hsb85]

nee, niet alle dependencies zitten er altijd bij. Dat is het probleem juist.

[Hatsjoe]

Dan is de AppImage niet goed gemaakt door de maintainers. Het concept achter AppImage stelt namelijk dat binnen een AppImage een enkele app moet zitten met alle dependencies. Als je toch nog extra dependencies nodig hebt dan is dat een bugreport waard want dat hoort niet.

[samtoxie]

Precies.

Moet ook zeggen dat ik zelf regelmatig gebruik maak van appimages en mij niet kan herinneren dat ik het beschreven probleem tegen ben gekomen.

[Ultraman]

Goed idee. Om die reden ook vooral. Snaps zijn min of meer een Ubuntu-specifieke aangelegenheid, want Canonical zwaait met de scepter over de Snap store (Snapcraft) en niemand kan een andere store opzetten. Flatpak is een stuk meer open in die zin.

[ndonkersloot]

Dat ik ook graag zien .

[oef!]

Goede content met voldoende diepgang, meer van dit aub

[SambalBij]

Vind je? Het wordt verkocht als plus artikel, maar het is eigenlijk gewoon een Ubuntu/Canonical advertorial...

[oef!]

Het is in mijn optiek gewoon een laagdrempelige how to.

Lang niet iedereen op Tweakers is op de hoogte van dit soort technologie, gecombineerd met de noob vriendelijkheid van Ubuntu kan het voor veel mensen een goede eerste introductie zijn. Als ze het interesseert zullen ze vanzelf wel naar andere oplossingen gaan kijken.

Ik gebruik dit zelf ook niet aangezien ik Debian gebruik, apt en docker compose dekken mijn persoonlijke use cases.

[SambalBij]

Een advertorial of publireportage (Belgisch-Nederlands) is een advertentie, in de vorm van een redactioneel artikel. Daardoor ontstaat er een ogenschijnlijk objectieve publicatie.

Bron: Wikipedia

Het lijkt een simpele howto. Met als enig doel om meer mensen packages te laten maken ter grotere glorie van Canonical

Met universele pakketformaten kan dat wel. Softwaremakers bieden met deze pakketformaten eenvoudig hun software aan voor diverse Linux-distributies. Zo installeer je als gebruiker makkelijk de nieuwste versies. Een van die universele pakketformaten is Snap

Maar snap is niet universeel! Snap is een gesloten systeem van Canonical. Ja het pakketformaat is in zoverre open dat iedereen zo'n ding kan maken, maar in hoeveel app stores/repo's kun je die vervolgens beschikbaar maken?

[WoutervOorschot]

Uitleg over hoe een .msi installer te maken is toch ook geen advertorial voor windows? Ubuntu is uiteindelijk wel gewoon erg populair, het was interessant(er) geweest als inderdaad ook flatpak verder behandeld zou zijn.

Zo te zien kun je willekeurige snaps wel installeren buitenom die store (gebeurd in het artikel), dus ze extern aanbieden zal dan ook wel kunnen.

[SambalBij]

Wel als je die msi probeert weg te zetten als 'universele installer' terwijl die eigenlijk toch alleen voor Windows blijkt te zijn...

[hsb85]

maar wel voor verschillende windows versies, S mode, x86, ARM, mobile. daarom durven ze het universeel te noemen..

[Mangu429]

Het lijkt een simpele howto. Met als enig doel om meer mensen packages te laten maken ter grotere glorie van Canonical

Jij denkt dat mensen die deze how-to lezen opeens packages gaan maken?
Degenen die al weten wat snaps zijn hoeven niet overgehaald te worden.

[Blokker_1999]

Zelfs .deb met apt heeft bredere ondersteuning.

[Quitzcused]

Eigenlijk puur mijn free plus artikel hiervoor gebruikt om de comments te lezen over het omstreden SNAP systeem

[amk]

same

[Madshark]

Same

[Slaiter]

Snapt is net als Flatpak op ieder (Linux) systeem te gebruiken.
Mocht je het eens willen proberen staat hier hoe je dat relatief eenvoudig kan doen.

[Reactie gewijzigd door Slaiter op 22 juli 2024 14:16]

[Anoniem: 420148]

Snapt is net als Flatpak op ieder (Linux) systeem te gebruiken.

Of je het moet willen is een ander

[Slaiter]

Daarom ook de 2e zin

[smitae]

Ik moet zeggen dat ik erg tevreden ben over snap. Vanuit het verleden wilde ik altijd zelf controle houden op de installs, dus ooit tarball, later apt,etc, etc. Maar merk dat ik voor mijn eigen desktop ubuntu toch een beetje te lui begin te worden om alles met de hand te doen. Dus moet ik mij maar eens minder druk maken over het controle verlies.

Snap maakt het gewoon wel erg eenvoudig, enige is dat upgrade van snap zelf wel een probleem kan zijn voor de mensen met minder Linux ervaring. Daarvoor moest ik toch echt ff opzoek naar een how-to en wat op de command-line doen. Dat zie ik een “gewone” gebruiker niet direct doen.

Maar verder blijf ik bij Ubuntu en is voor mij Windows EOL. Zeker nadat ik niet “mocht” upgraden naar W11, omdat mijn systeem (i7-6700/32Gb) dat niet meer aan zou kunnen en wat ook niet hielp dat tijdens een Win10 patch een jaar of 2 geleden de boel weer eens dood ging en ik geen zin had in nieuwe W10 installatie.

[hackerhater]

Het grote probleem met Snap is dat het een N.I.H. is voor Ubuntu.
Flatpak doet exact hetzelfde en is wel cross distro gedragen.

[smitae]

Ja, dat zou een issue kunnen zijn. Maar voor mij als gebruiker maakt mij dat echt niets uit. Werkt heerlijk op ubuntu. Alleen maar goed, meer optie’s, meer innovatie, meer ontwikkelingen.

Dus voor wie is het een probleem? Niet voor de gebruikers, ook niet voor Ubuntu? Voor andere distro’s? Mogelijk, maar denk dat de andere distro’s het ook geen probleem vinden. Die pushen mogelijk liever eigen optie’s.
Voor de software leveranciers. Die moeten wat extra klussen om de boel in snap te klussen en aangezien ze het meeste toch Open Source is maakt dat ook niet uit. Daar hebben we dan wel weer de community voor die dat oppakt.

Nee, dus echt geen groot probleem.

[hackerhater]

Grootste issue is voor de leveranciers dat ze dan weer dubbel werk hebben.
Terwijl ze ook gewoon Flatpak hadden kunnen ondersteunen ipv hun eigen versie te maken.

[Rainbow]

Wat ik wel eens begrepen heb van Snaps is dat het eigenlijk een gesloten technologie is. Vooral de server is in het beheer van Canonical en niet open source. Dus als Canonical er een potje van zou maken, kan je niet de server even forken, aanpassen, en zelf hosten. Dat geeft voor mij een naar gevoel, bij iets wat in mijn ogen open zou moeten zijn. Het is gewoon een vreemde stap in de context van GNU/Linux.

Functioneel vind ik het verder trouwens ook geen fijn systeem. Updates zijn volledig automatisch, dus je hebt daar eigenlijk geen controle over. Het gebeurd nog wel eens dat een update van een programma bugs heeft (of nare nieuwe features die je niet wilt). Dan wil je eigenlijk niet updaten, misschien wachten totdat de bugs opgelost zijn (of totdat er een fork beschikbaar is). Ik wil graag zelf zien wat er geüpdatet gaat worden, evt. release notes lezen, en vervolgens zelf kiezen wat ik wel en niet ga updaten (ik weet dat ze teruggedraaid kunnen worden, maar dan kan het kwaad al geschied zijn).

Al met al vind ik het hele snap gebeuren echt heel Microsoft-esque. Lijkt in weze wel deels op de Microsoft Store en UWP apps (en wellicht is dat ook de bedoeling).