In Linux-distributies installeer je standaard thirdpartysoftware met behulp van een pakketbeheerder. Die is vaak specifiek voor die distributie of familie van distributies ontwikkeld en haalt de software uit een distributiespecifieke repository. Een alternatief vormen de distributieonafhankelijke pakketformaten. De bekendste zijn Flatpak en Snap. Snap hebben we in een eerder artikel behandeld; in dit achtergrondartikel kijken we naar de grootste concurrent Flatpak en wat de verschillen tussen de twee pakketformaten zijn.
We beginnen echter bij de distributiespecifieke pakketbeheerders. Zo gebruiken de Linux-distributie Debian en zijn afgeleiden, waaronder het populaire Ubuntu, het pakketformaat deb. Een ander pakketformaat is rpm, dat voor Red Hat Linux was gecreëerd, maar ondertussen buiten de Red Hat/Fedora-familie ook gebruikt wordt door openSUSE en andere distributies.
Dit zijn de klassieke pakketformaten die nog altijd de basis vormen van de meeste Linux-distributies. Een programma wordt verspreid in de vorm van een deb- of rpm-bestand, dat enerzijds de bestanden bevat die door de pakketbeheerder worden geïnstalleerd en anderzijds allerlei meta-informatie, waaronder afhankelijkheden (dependencies). Veel pakketten hebben immers andere pakketten nodig voor hun werking.
Een pakketbeheerder zoals apt (voor deb) of yum, dnf of zypper (voor rpm) bekijkt welke afhankelijkheden een pakket dat je wilt installeren heeft en installeert deze dan ook. De bron van al die pakketten is in de meeste gevallen een online repository die specifiek voor je distributie(versie) is opgezet.
Foutloos samenwerken
De beheerders van een Linux-distributie hebben de taak om ervoor te zorgen dat de pakketten in de officiële repository van je distributie stabiel zijn en samenwerken met de afhankelijkheden. Daar komt heel wat bij kijken, want bij elke update van een pakket moet getest worden of andere pakketten die daarvan afhangen, nog altijd foutloos met deze nieuwe versie samenwerken.
Voor softwaremakers die hun software voor verschillende distributies willen verspreiden, is de uitdaging nog groter. Ze zijn dan al verplicht om hun software zowel in deb- als rpm-formaat te verspreiden om minstens de twee grote distributiefamilies te bereiken, maar zelfs dat is niet altijd voldoende. Elke versie van een distributie bevat specifieke versies van de afhankelijkheden in de officiële repository’s. In de praktijk kun je zo niet garanderen dat een pakket met al die versies probleemloos samenwerkt.
Om die problemen te vermijden, zijn distributieonafhankelijke pakketformaten ontstaan die een toepassing samen met zijn afhankelijkheden bundelen in één pakket. De bedoeling is dat de ontwikkelaar dan maar één pakket van zijn software moet uitbrengen, dat je op diverse Linux-distributies kunt installeren. De bekendste van deze universele pakketformaten zijn Flatpak, voornamelijk ontwikkeld door Red Hat, en Snap, ontwikkeld door Canonical. In dit artikel leggen we beide ecosystemen naast elkaar.
Runtimeomgeving met geïsoleerde applicaties
Alle afhankelijkheden van een toepassing bundelen in één pakket zou nogal verspillend zijn. Dan zou elke Gnome-toepassing bijvoorbeeld alle Gnome-bibliotheken moeten bevatten en zou de download vrij groot zijn; dat is overigens hoe het alternatieve formaat AppImage pakketten verspreidt. Daarom kennen de pakketformaten Flatpak en Snap een systeem om toch belangrijke, gedeelde afhankelijkheden afzonderlijk te packagen. Pakketten die in hun metadata aanduiden dat ze dit basispakket gebruiken, hoeven al die bibliotheken dan niet meer zelf te bevatten en ze hoeven dan ook nog maar één keer gedownload te worden.
Bij Flatpak heet zo’n pakket met basisafhankelijkheden een runtime. De belangrijkste Flatpak-runtimes zijn Freedesktop, Gnome en KDE. Zo bevat die eerste essentiële bibliotheken en services als D-Bus, GLib, Gtk3, PulseAudio, X11 en Wayland. Voor al deze runtimes bestaan er ook nog uitbreidingen, bijvoorbeeld met vertalingen en codecs.
Snap noemt zijn runtimes base snaps. Ze bieden een minimale installatie van bibliotheken die gedeeld worden door de meeste toepassingen. In tegenstelling tot Flatpak gaat het hier echter niet over grafische bibliotheken, maar alleen over het basisbesturingssysteem. Zo zijn er base snaps gebaseerd op Ubuntu 16.04 ESM, Ubuntu 18.04 LTS, Ubuntu 20.04 LTS en Ubuntu 22.04 LTS. Voor een gedeelde grafische omgeving biedt Snap uitbreidingen aan, onder andere voor Flutter, Gnome en KDE. Zowel de base snaps als de extensions worden als afzonderlijke snaps geïnstalleerd en binnen de snap van de applicatie gemount.
In feite kun je zeggen dat je met zowel Flatpak als Snap je toepassingen niet meer voor een specifieke versie van een specifieke Linux-distributie maakt, maar voor een specifieke runtime (of base) en uitbreidingen. En dat maakt van beide een manier om je toepassingen op diverse Linux-distributies aan te bieden.
Applicaties isoleren
Flatpak en Snap isoleren toepassingen van elkaar en van het onderliggende besturingssysteem. Door deze sandbox hebben de toepassingen standaard maar beperkte toegang tot je systeem, waardoor ze minder schade kunnen aanrichten als ze gecompromitteerd worden. Beide systemen pakken die sandbox iets anders aan. Snap maakt voor zijn sandbox gebruik van de kernelonderdelen AppArmor, seccomp en cgroups. Snaps hebben daardoor standaard geen toegang tot resources buiten hun sandbox.
Flatpak maakt voor de sandbox van een applicatie gebruik van bubblewrap, dat door de makers beschreven wordt als een unprivileged sandboxing tool; bubblewrap, en dus ook Flatpak, draait zonder rootprivileges. Onder de motorkap maakt bubblewrap gebruik van namespaces en seccompfilters. Standaard heeft een flatpak niet eens toegang tot het netwerk, apparaatbestanden en PulseAudio, of tot bestanden buiten de runtime, de applicatie zelf en enkele standaarddirectory’s met data voor de applicatie.
Portals en ecosystemen
Hoe krijgen beide typen applicaties dan wel toegang tot de buitenwereld? Snaps kunnen toegang tot specifieke resources vragen via interfaces, waarvan sommige automatisch toegekend worden, maar altijd door de gebruiker zijn uit te schakelen. Snaps kunnen ook zelf interfaces aanbieden zodat andere snaps er toegang toe kunnen krijgen. Toegang tot de homedirectory van de gebruiker, de webcam, audio, bluetooth, het netwerk enzovoort: het wordt allemaal via interfaces geregeld.
Makers van een flatpak geven in de metadata op welke sandbox-permissies hun applicatie nodig heeft. Communicatie tussen de applicatie en het besturingssysteem gebeurt in Flatpak met portals, die een granulaire toegang tot het systeem mogelijk maken. Portals vragen de gebruiker om toestemming, en interfacetoolkits als GTK3 en Qt5 implementeren ondersteuning voor portals, zodat ontwikkelaars van toepassingen er geen extra aandacht aan hoeven te besteden. Zo vraagt de portal FileChooser aan de gebruiker om een of meer bestanden op zijn systeem te kiezen. Alleen de geselecteerde bestanden worden beschikbaar gesteld in de flatpak. Het besturingssysteem biedt services voor die portals aan met xdg-desktop-portal.
Snaps kunnen met elkaar en met de onderliggende Linux-distributie communiceren via interfaces. Bron: https://snapcraft.io/docs/interface-management
Open ecosystemen
In principe zijn beide ecosystemen open. Zowel flatpaks als snaps zijn op allerlei distributies te installeren. Uiteraard zijn er voorkeursdistributies. Een aantal distributies zijn out-of-the-box van Flatpak voorzien. Naast Fedora Workstation zijn dat ook enkele Ubuntu-afgeleiden, zoals elementaryOS, Linux Mint, Pop OS, Ubuntu MATE en Zorin OS. Ook op heel wat andere distributies is Flatpak te installeren. Daarna kun je eenvoudig flatpaks installeren op je systeem.
Het mag niet verbazen dat Canonical zijn distributie Ubuntu automatisch van Snap voorziet, zodat je daarop out-of-the-box snaps kunt installeren. Ook op andere distributies zijn snaps te installeren, zolang je de snap-daemon snapd installeert. Als je in de Snap Store naar een pakket zoekt, krijg je voor meer dan tien distributies instructies te zien hoe je snapd en daarna de gevraagde snap installeert.
Maar the devil is in the details. Niet alle distributies ondersteunen AppArmor, de Linux-kernelmodule die wordt gebruikt om de rechten van snaps in te perken. Zo gebruikt Fedora standaard SELinux en beide beveiligingsmodules kunnen niet tegelijk actief zijn. Zonder AppArmor draaien alle snaps in devel mode, waardoor ze dezelfde ongelimiteerde toegang tot je systeem hebben als klassieke pakketten. De gebruiker krijgt daar geen enkele waarschuwing voor. Voor Nextcloud is dat de reden om zijn snap alleen op Ubuntu te ondersteunen.
Snap Store
Het zichtbaarste verschil tussen Flatpak en Snap is dat die laatste maar met één applicatiewinkel samenwerkt, Canonicals Snap Store, terwijl Flatpak met verschillende repository’s te gebruiken is. Dat maakt Snap in de praktijk dus een gecentraliseerd systeem. Hoewel snapd en de opdrachten snap (voor het beheer van snaps) en snapcraft (om snaps aan te maken) open source zijn (je vindt de code in de organisatie snapcore op GitHub), is de broncode van de officiële Snap Store niet open, en de communicatie tussen de Snap-client en de applicatiewinkel gebeurt met een protocol waarvan geen specificatie bestaat. Iemand die een alternatieve applicatiewinkel wil ontwikkelen om snaps aan te bieden, moet dus in de broncode van snapd uitzoeken hoe die met de Snap Store communiceert. Voor Linux Mint, een afgeleide distributie van Ubuntu, was dat een belangrijke reden om snapd standaard niet-installeerbaar te maken. Wie wel snaps op Linux Mint wil gebruiken, moet dit expliciet inschakelen.
Toch lijkt Canonical niet principieel tegen alternatieve applicatiewinkels te zijn. Zelfs Canonical-oprichter Mark Shuttleworth liet in 2020 op het forum van Snapcraft weten dat het protocol is ontworpen om alternatieve applicatiewinkels mogelijk te maken. In 2016 publiceerde Bret Barker een Python-script dat een minimalistische snapwinkel implementeerde. Canonicals Dustin Kirkland schreef op de blog van Ubuntu zelfs een artikel hierover met de titel Howto: Host your own SNAP store, maar na wijzigingen in de api was de code niet meer compatibel met Snap. Ook een ander alternatief, OpenSnap, is een poging tot opensource-implementatie van de Snap Store, maar werkt nog niet en heeft al twee jaar geen updates meer gekregen. Vorig jaar verscheen er nog een alternatief: Kebe. De maker slaagde erin om met snapcraft op zijn eigen applicatiewinkel in te loggen door twee omgevingsvariabelen naar zijn server te laten verwijzen, maar heeft sindsdien geen updates meer gepubliceerd.
Het lijkt erop dat er dus weinig interesse in de community is om een alternatief voor de Snap Store te ontwikkelen. Canonicals aarzeling om de broncode van de Snap Store te openen kan er ook mee te maken hebben dat het wel de broncode voor Launchpad heeft gepubliceerd, maar dat er geen grote bijdragen van buiten Canonical zijn gekomen en dat er ook geen alternatieve Launchpad-installaties populair zijn geworden. Overigens kan snapd maar met één applicatiewinkel tegelijk verbonden zijn.
Canonical laat wel toe om een brand store aan te maken, waar een organisatie dan meer controle heeft over welke snaps beschikbaar zijn en ook extra snaps kan toevoegen. De webinterface van de Snap Store is wel open source en kan door een brand store dan ook aangepast worden. Aan de backend maakt zo’n brand store echter nog altijd gebruik van de Snap Store van Canonical.
Snaps zijn alleen te installeren vanuit Canonicals Snap Store.
Flathub en servertoepassingen
Flathub is dé plaats waar je flatpaks vindt; momenteel zijn er bijna 2000 flatpaks beschikbaar. Het is echter niet de enige plaats en Flatpak kan perfect met verschillende repository’s voor flatpaks tegelijk werken. Die repository’s worden door Flatpak remotes genoemd. Op een Linux-distributie met Flatpak is het geen uitzondering dat er verschillende remotes actief zijn.
Zo verspreidt Fedora een honderdtal flatpaks in zijn eigen remote, met als doel dat gebruikers de nieuwste versies van Fedora-toepassingen kunnen draaien zonder dat ze hun Fedora-installatie hoeven te upgraden. De flatpaks in deze remote worden dan ook gebouwd op basis van bestaande rpm-pakketten voor Fedora. Fedora verspreidt ook alleen opensourcesoftware in deze remote, terwijl Flathub ook propriëtaire software bevat. Alle flatpaks van de Fedora Flatpaks-remote gebruiken een van de Fedora-runtimes.
Je eigen Flatpak-repository opzetten is vrij eenvoudig, omdat er in tegenstelling tot bij de Snap Store geen nauwe integratie met andere achterliggende software is. Met flat-manager host en beheer je een flatpak-repository. Flathub maakt hier ook gebruik van. Flatpak-clients downloaden de flatpaks eenvoudigweg over HTTP van de website en er is ook een HTTP-api om nieuwe builds van je software naar de repository te uploaden.
Flathub is de populairste plaats om flatpaks te vinden.
Desktop en server
Zowel Flatpak als Snap is Linux-specifiek. Ze maken gebruik van specifieke functionaliteit van de Linux-kernel, zoals bind mounts, namespaces en seccomp om de sandbox te creëren waarin de software draait. Ze werken dus niet op andere Unix-achtige besturingssystemen, zoals FreeBSD. Snap heeft zelfs nog een extra vereiste; het hangt af van systemd en werkt dus niet op Linux-distributies die een ander init-systeem gebruiken. Bovendien moet zoals we al zagen, de AppArmor-kernelmodule geladen zijn om een snap in te perken.
Flatpak vereist geen systemd of AppArmor, maar heeft dan weer een andere beperking. Omdat het is ontwikkeld om in een desktopsessie te draaien, maakt het gebruik van de D-Bus-sessiebus. Hoewel je flatpak-pakketten op een server kunt bouwen, is het formaat dus niet geschikt om serversoftware te packagen. Snaps hebben die beperking niet. Canonical heeft zelfs een serverbesturingssysteem voor iot-toepassingen ontwikkeld dat volledig op basis van snaps is opgebouwd: Ubuntu Core. Daarin wordt zelfs de Linux-kernel als een snap verspreid. En het OpenPrinting-project werkt aan een volledige printerstack met CUPS in een snap.
Een ander verschil zijn de automatische updates. Snapd controleert vier keer per dag of er updates zijn voor de geïnstalleerde snaps. Bij deze refresh worden beschikbare updates geïnstalleerd. Deze automatische updates kun je niet uitschakelen, maar je kunt wel instellen op welke tijdstippen ze mogen gebeuren en je kunt ze tot 90 dagen uitstellen. Flatpaks worden niet automatisch bijgewerkt, zodat je daar meer controle over hebt.
Ubuntu Core is zo modulair opgebouwd dat zelfs de Linux-kernel als een snap wordt geïnstalleerd. Bron: Ubuntu Core datasheet
Alternatieven en conclusie
Flatpak en Snap zijn niet de enige oplossingen voor deze problemen. Een andere aanpak heeft Nix, een pakketbeheerder die verschillende versies van applicaties en bibliotheken naast elkaar kan installeren. Nix wordt vooral gebruikt in de Linux-distributie NixOS en heeft een collectie van meer dan 80.000 pakketten.
Er is ook AppImage, dat alle afhankelijkheden die een programma nodig heeft, in één binary zet. Die download je dan, je maakt het bestand uitvoerbaar en start het daarna eenvoudig. Je hebt dus geen packagemanager nodig voor AppImage en je hoeft het pakket ook niet van een applicatiewinkel te downloaden. Softwaremakers plaatsen een AppImage meestal gewoon op hun eigen website, al is er wel AppImageHub, dat meer dan 1100 AppImages host. Je hebt ook geen sandboxing om de rechten van de applicatie in te perken, maar je kunt dit wel bereiken met Firefail. Bij elke update moet je zelf een AppImage van de nieuwe versie installeren, tenzij je AppImageUpdate gebruikt. Een andere oplossing om AppImages meer met je Linux-desktop te integreren, is AppImageLauncher.
Een alternatief dat minder geïntegreerd is dan Flatpak en Snap, is AppImage, waarvoor je pakketten vindt op AppImageHub.
Wat kunnen we hier nu mee?
Zijn Flatpak en Snap blijvers? Ja, want beide systemen doen iets aan de frictie tussen de releasecycli van distributies en die van applicaties. Distributies zoals Fedora en Ubuntu brengen elk halfjaar een nieuwe release uit. Dat lijkt snel, maar dat betekent dat je tussen twee releases tot zes maanden moet wachten om nieuwe versies van applicaties uit hun repository’s te kunnen installeren. Tussen de releases van een distributie krijg je immers alleen maar beveiligingsupdates. Het probleem is nog groter bij de versies met long-termsupport; tussen twee Ubuntu LTS-releases ligt twee jaar, een eeuwigheid in softwareland. De gemakkelijkste manier om toch nog recentere applicaties te installeren, is dan Flatpak of Snap. Op distributies die een rolling-releasemodel gebruiken, zoals Arch Linux speelt dit voordeel minder.
Anderzijds zijn er ook applicaties waarvan de ontwikkelaars geen tijd hebben om mee te blijven gaan met de nieuwste ontwikkelingen. Of oudere applicaties die niet meer ontwikkeld worden, maar wel nog nuttig zijn. Die hebben dan misschien oudere bibliotheken nodig, die moeilijk rechtstreeks in je distributie te installeren zijn. Zo’n applicatie kun je eenvoudig samen met zijn dependency’s in een flatpak of snap isoleren. Zo kun je ze toch nog op een moderne distributie draaien zonder risico dat je je distributie om zeep helpt. Flatpak en Snap zijn om deze reden ook op distributies met een rolling-releasemodel nuttig.
Als Flathub maintainer (niet meer actief hier sinds dat ene NIntendo-emulator voorval) kan ik een paar details toevoegen:
- Snap werkt niet overal. Op papier wel en dat marketing zou je dat graag doen geloven, maar Snap heeft een anti-sandbox optie welke door veel partijen gretig gebruikt wordt... maar welke dus alleen op Ubuntu werkt. Andere Linux Distributies die dit soort namespace-escaping op kernel niveau blokkeren voor beveiligingsredenen kunnen veel Snaps niet draaien. Zie blogpost van NextCloud
- Flathub biedt meer dan Flatpaks. Flatpaks kun je op meerdere manieren maken, want ze leunen zwaar op het OCI formaat, maar niet alle formaten zijn gelijk. Flathub als project heeft extra vereisten opgesteld die zorgen dat de Flatpaks daar, de best practices gebruiken. Voorbeelden hiervan zijn een GIT-achtig update mechanisme waardoor je alleen maar diffs download.
- Flatpak heeft een mechanisme van hard- en softlinking om heel veel ruimte te besparen. Als je alle GNOME, KDE en FreeDesktop versies op jouw machine installeert... kom je op ~8 GB uit... wat veel klinkt totdat je bezeft dat je hiermee dus vier jaar aan software versies hebt. Dit staat dus ongeveer gelijk aan 8 Fedora releases van elk 2 GB.
- Flatpaks ontkoppelen juridische problematische componenten. Wil je hardware ondersteuning voor bepaalde media codecs? Of graag een bepaalde Game-console emulator die DPG-Media aan de ketting heeft? Flathub heeft het en kan deze leveren vanuit enkele politiek gunstigere gebieden. Het is bizar eigenlijk dat het uberhaupt nodig heeft, maar Flatpaks maken het dus mogelijk om bepaalde patent-problemen te ontwijken.
Hoe dan ook. Flatpaks zullen alleen maar meer terrein winnen, en nu dat partijen zoals Valve het ook accepteren als het enige software distributie mechanisme, lijkt het mij wel dat Snap voortaan tweede viool moet spelen.
Leuke tidbit: Popey, een voormalig Canonical medewerker o.a. bij het Snap Advocacy Team heeft sindsien Unsnap geschreven, een scriptje dat Snap pakketten deinstalleert en de equivalente flatpak installeert. Wie weet handig voor sommigen:
Er wordt in het artikel ook uitgelegd dat snap niet overal werkt toch? Omdat AppArmor alleen op ubuntu werkt werkt de sandboxing van snap alleen daar. Dat er geen expliciete waarschuwingen worden gegeven is slechts van snapd, maar ook dat wordt genoemd in het artikel.
Wat bedoel je met je laatste punt? Je kunt altijd toch bijvoorbeeld je code verspreiden zonder de elementen die als illegaal worden gezien? Vaak blijkt een rechter er echter niet mee eens als er geen realistisch ander doel voor de software is. Het heeft vast te maken met je opmerking over de nintendo emulator, maar ik kan in dat artikel of comments er niets over vinden.
Ik vermijd snaps en flatpacks eigenlijk altijd als de pest als er ook een native applicatie beschikbaar is. Zeker voor zaken als browsers, wordt de boel er gewoon merkbaar trager van wanneer het een verpakte app is. Soms kom je ook bugs tegen en (in het begin) liepen versies vaak achter.
Het prestatieverschil kan verklaard worden door die sandbox, ik wist niet dat dat er in zat. Maar alsnog, stoort het me dat (bijvoorbeeld) Firefox op Ubuntu standaard een package is, terwijl er ook een prima native versie is. In dat opzicht mag het wel wat minder gepushed worden en pragmatischer toegepast worden.
Ik gebruik ze liever ook niet. Zo had ik laatst een probleem met het programma krop, waarmee ik gescande pdf bestanden kan splitsen in even en oneven pagina's. Ik scan alles vanwege rugklachten twee pagina's tegelijk. Heel essentieel voor mij.
Ik heb toen flatpak geïnstalleerd en ben behoorlijk geschrokken omdat ik voor een relatief klein programma ineens 1,2 GB aan extra SSD ruimte nodig had.
Uiteindelijk heb ik toen maar Briss gebruikt, wat me java werkt.
Snap is dan ook geen optie omdat het ook veel SSD ruimte op vreet. Ik heb op mijn systemen ook pCloud wat met AppImage werkt. Dat vind ik zelf de meest elegante manier. Heb je een dergelijk tijdelijk nodig, even uitvoerbaar maken en draaien. Niet meer nodig, dan verwijderen en niet zoals bij Flatpak en Snap weer alles de-installeren.
Wat ik in dit verhaal eigenlijk mis is de snelheid van werking en geheugengebruik tussen flatpak en snap. Daar wordt namelijk wisselend over gedacht heb ik begrepen. Al met al wel een inzichtelijk artikel.
Ik denk dat je met deze redenatie de bedoeling van Flatpak en snap mist.
Een AppImage kan kleiner zijn omdat het 'context-aware' is, waarmee ik bedoel dat je alleen afhankelijkheden erin hoeft te verwerken die het programma ook echt nodig heeft. Bij een snap of flatpak trek je een hele runtime binnen waarmee talloze programma's gebruikt kunnen worden, deze kan best groot zijn.
Ja, dat neemt meer ruimte in voor die onderliggende runtime. Maar dat brengt wel andere voordelen mee aangezien je nu de base runtime los kan updaten van jouw app. Dus bijvoorbeeld security updates worden gedaan waar dat bij jouw AppImage niet zo hoeft te zijn (mits de runtime niet deprecated is natuurlijk).
Naast dat krijg je bij goed geconfigureerde Flatpaks en snaps ook de voordelen van een (relatief simpele) sandbox, wat je bij AppImages niet krijgt.
Niet meer nodig, dan verwijderen en niet zoals bij Flatpak en Snap weer alles de-installeren.
Omdat Flatpaks en Snaps in een sandbox kunnen werken heb je ook betere controle over waar apps hun "meuk" neerzetten. Dus, ja, een AppImage verwijderen is simpeler (mik hem in de prullenbak), maar een flatpak of snap verwijderen kan grondiger zijn.
Ok, ik ben eigenwijs. Maar waarom voor een simpel programma als krop een hele runtime en dergelijke installeren? Krop is maar 183 KB groot. Dat zou via AppImage veel makkelijker kunnen. Nu krijg je zo'n situatie dat je bijvoorbeeld bij een pure Gnome desktop voor dat ene KDE programma wat je nodig hebt een halve KDE moet installeren, of een KDE omgeving waar je voor dat ene GTK programma een halve Gnome installeert.
En veiligheid is een groot goed, dat ben ik wel met jou eens. Firejail is een goed alternatief en in mijn situatie draai ik een virtuele Debian multimedia met Chrome, Chromium en Firefox via Qemu.
Betere sandbox kun je niet krijgen en vreet niet extra resources als je het niet draait, ook niet op de achtergrond.
Zo draai ik pCloud via een AppImage, ik heb gekeken, 48 MB groot. Dat is toch heel anders dan een 1,2 GB voor Flatpak, en pCloud draait permament, ook via mijn virtuele Windows 10 cqow's.
Dus, ik snap de redenatie van Snap en Flatpak heus wel, maar is dat allemaal nodig? Dat is wat anders als je meerder flatpak (of snap) programma's draait die je veel nodig hebt.
[Reactie gewijzigd door WOteB2 op 22 juli 2024 13:19]
Flatpak weet niet dat jij maar één app wil gebruiken, Flatpak ziet alleen dat deze app een dependency heeft op een grote runtime en haalt deze braaf binnen. Je zou zo nog 20 andere apps kunnen installeren die geen extra runtimes meer nodig hebben, en die zouden dan maar een paar MB per stuk zijn. De meeste GNOME-specifieke apps hebben een dependency op de laatste GNOME runtime.
Dat is in contrast met AppImages, waar telkens dezelfde dependencies opnieuw binnen gehaald moeten worden, omdat deze in de image ingebouwd zijn. Ook moet je de image iedere keer opnieuw downloaden waar Flatpak delta upgrades kan doen (dus alleen de elementen binnen een 'pakket' updaten die ook echt bijgewerkt zijn).
Dat je voor de opslagvereisten een grens legt is jouw goed recht. Maar Flatpak is bedoeld om de Linux desktop toegankelijker te maken en het app distributie probleem te verhelpen en tegelijkertijd voegt het een eenvoudige sandbox toe. Voor de gemiddelde gebruiker is het een uitkomst en zou het nagenoeg transparant moeten zijn ten opzichte van 'native' applicaties. Het is niet bedoeld om kleine pakketten op te leveren.
Er zijn natuurlijk voor een sandbox veel wegen naar Rome, waarvan sommige effectiever en geïsoleerder dan anderen, maar ik vind dat Flatpak een uitstekende middenweg heeft wat integratie betreft. Dat ga je met jouw VM niet krijgen.
Ja, ik zag de grootte voor de download. Ze zijn bij mij 'last resort'. Wel mooi spul. Ook voor mensen die niet goed uit de voeten kunnen in Linux.
2023, het jaar van de Linux desktop. Echt dit keer.
Zelf heb ik vooral ervaring met flatpack, maar de belangrijkste reden waarom het iets langzamer zou kunnen zijn is dat libraries afwijken van wat standaard aanwezig is in memory en daardoor apart ingeladen moet worden. Dat zou meer IO kunnen veroorzaken. De andere technologieën (selinux/seccomp via bubblewrap) *zouden* weinig verschil moeten geven. In het verleden waren er nog wel eens wat issues in een runtime waardoor dingen niet altijd soepel liepen, maar dat wordt steeds beter. Gezien de voordelen (nieuwere versies en "containerisatie" van grafische applicaties) zou ik het persoonlijk aanraden om het nogmaals te proberen. Zeker als je nu een snelle ssd hebt en genoeg geheugen
Same here. Ik heb echt talloze applicaties die niet, trager of beperkt werken in snap vorm, maar als je m dan via de standaard package manager installeerd werkt het prima.
Voor de gebruiker is snap echt een stap terug. Ik snap dat het voor developers makkelijker is, en dat levert natuurlijk weer snellere iteraties op.
Het feit is dat het veiliger is om sandboxed te draaien. Dat is een keuze die je zelf maakt uiteraard, maar op mobile is het al de defacto standaard. Windows pusht het al heel lang maar komt niet echt door bij developers. Op linux lijkt dit een mooie oplossing opzich.
Blijft natuurlijk een ding dat het doel van snap/flatpack dependency management is, evt sandboxen is mooi meegenomen omdat dat makkelijk kan als je je dependencies bundeld maar is niet de reden van bestaan.
Ik ben op Fedora voor bepaalde packages over gegaan naar de Flatpak versie omdat ik vaak had dat een package of dependency uit de Fedora of Rpmfusion repo traag was met updaten waardoor die niet geüpdatet kon worden. Nadat meerdere malen was gebeurt heb ik maar de Flatpak variant geïnstalleerd, ik merk geen verschil in snelheid op mijn systeem tussen een native package en een Flatpak package. Maar in het algemeen gebruik ik ook liever de native package als die goed bijgehouden word.
[Reactie gewijzigd door Hydranet op 22 juli 2024 13:19]
Om die reden heb ik de standaard Snap-versie van Firefox (op in dit geval Ubuntu MATE 22.04 LTS op een net geupgrade HP desktop uit 2011) er ook meteen vanaf gemikt, de Firefox PPA toegevoegd aan het systeem en vervolgens de laatste versie op de traditionele manier geïnstalleerd. Als ik Firefox wil sandboxen gebruik ik wel Firejail. Daar heb je nauwelijks vertraging als je je browser in een sandbox gebruikt.
Nee, ik ben ook geen fan van Snap. Flatpak lijkt me wat snappier te reageren dan Snap, maar ik zal alleen Flatpak apps installeren (NIET op Ubuntu, want die ondersteunen Flatpak niet!) als het niet anders kan. Anders houd ik het wel bij de traditionele manier van installeren. Via APT dus in het geval van op Debian en Ubuntu gebaseerde systemen.
[Reactie gewijzigd door Qalo op 22 juli 2024 13:19]
Tuurlijk kun je Flatpaks draaien op Ubuntu, maar het wordt standaard niet ondersteund (meegeleverd dus) door Canonical. Daarvoor zul je eerst zélf Flatpak moeten installeren om Flatpak-apps op Ubuntu te kunnen laten draaien. De reden waarom Ubuntu dit niet out-of-the-box mee levert is omdat zij Snap willen pushen. Snap komt namelijk uit die hoek.
Dat weet ik uiteraard allemaal, alleen zoals je het formuleerde leek het net alsof het helemaal niet zou werken. En dat is natuurlijk niet het geval. Flatpak zelf installeren op Ubuntu is zo gedaan, net als Snap op bijv. Debian. Of je dat laatste moet willen is een tweede...
Op de Steam Deck zit een versie van Arch (steamOS) en daar kan je, met de standaard instellingen, alleen FlatPacks gebruiken.
Het werkt erg vlot en dat je alles gesandboxt heb draaien bevalt me wel.
Ik wist niet dat er zo'n duidelijk verschil was tussen de manier van updaten. Uiteraard in het verleden wel apt gebruikt, maar waar ik nooit bij stil stond dat daardoor mijn applicaties/programma's niet echt op de laatste versie zitten.
Nu met FlatPack is 't voor mij veel duidelijker qua versiebeheer en updates. Daardoor heb ik op de deck nog niet een keer in de console hoeven typen, wat ik echt voor de instapbaarheid van Linux wel een enorm pluspunt vind.
Al met al, interessant artikel over deze pakketmanagers. (is volgens mij de eerste keer dat ik over flatpack hier wat lees)
Waar ik me ook kapot aan erger is dat ze vaak niet zeggen welke versie erin de package manager -dus niet packs- wordt aangeboden. Dan noemen ze hun eigen waardeloze versie nummers maar de versie van de release van de software die er in zit mag je raden. Of van waneer de package is.
Dan zoek ik een keyword. Install iets. Zie het... en ziet er uit en IS gewoon meer dan 10 jaar oud. (Misschien is het Mint specifiek)
[Reactie gewijzigd door MrMonkE op 22 juli 2024 13:19]
Over welk stuk software heb je het dan specifiek? Want bij een netjes gemaakt apt of yum package hoort het wel degelijk duidelijk te zijn welke versie van de software er in zit. Voorbeeld:
$ apt show firefox
Package: firefox
Version: 106.0.5+build1-0ubuntu0.18.04.1
[...]
Zoals je kunt zien is uit het versienummer prima af te leiden dat het Firefox versie 106.0.5 betreft, wat een recente versie is. Vervolgens voegt het build system van Ubuntu ook nog een buildnummer toe en wat extra informatie over voor welk versie van Ubuntu het pakket gebouwd is, wat weer te maken heeft met op het systeem aanwezige afhankelijkheiden. Yum geeft de informatie op een iets andere manier weer:
$ yum info firefox
Name : firefox
Arch : x86_64
Version : 102.4.0
Release : 1.el7_9
[...]
Ook daar wordt het versienummer duidelijk weergegeven, het betreft hier de laatste ESR release van Firefox. Daarnaast is er een release veld, waar je wederom een build nummer terug vindt en een aanduiding voor welke versie van (in dit geval) Red Hat Enterprise Linux het pakket gebouwd is.
Je hebt gelijk ik heb het door elkaar gehaald. Mijn excuses. De 'show' staat ook in geheugen gegrift nu.
Bij de firefox staat inderdaad, ook in de GUI, maar geen datums. Het ging mij meer om datums omdat ik niet weet dat firefox 3.2 de nieuwste is of 3.2.2 of 3.1.1 maar als er zou staan dat de package uit 1912 is zou ik wel prettig vinden.
Een datum wordt niet weergegeven omdat dit niet zoveel zegt, het verteld je alleen wanneer een pakket is gemaakt. Neem de kernel van Debian stable als voorbeeld, die is recent nog vernieuwd met fixes voor recent uitgekomen kwetsbaarheden. De kernel van Debian Stable is echter gebaseerd op Linux kernel 5.10, terwijl 6.0 de meest recente versie is van de kernel zoals die door de Linux kernel ontwikkelaars als stabiel is vrijgegeven. Toevallig is gisteren kernel versie 5.10.154 uitgekomen dus het is correct om daarbij de datum 10-11-2022 te vermelden, maar dat zou onterecht de suggestie wekken dat je de meest recente versie van de Linux kernel gebruikt.
Voor recente packages. Maar ik heb al een paar keer gehad dat ik uit de package manager iets installeerde en het gewoon heel oud was. Maar ik zit nog niet zo diep in Linux dus ontbeer nog veel OS details. Reden overstap was python/Cuda wat gewoon vaker werkend te krijgen is in Linux dan in Windows.
Kernelversies enzo.. \_o_/ daar let ik niet op. Maar dat komt wel zodra ik het een beetje snap.
Zit nu meer te 'useren' op Linux Desktop
Eigenlijk is dat precies het probleem dat men met Snap en Flatpak probeert op te lossen. Soms bevatten de repositories van een distributie verouderde pakketten. Bij Flatpaks en Snaps is het vaak de ontwikkelaar zelf die een update doet, in geval van een distributie is er een beheerder verantwoordelijk.
Er kunnen verschillende redenen zijn dat een pakket uit de repositories verouderd is. Het kan bijvoorbeeld zijn dat er geen beheerder meer is om de nieuwe broncode te downloaden en een nieuw pakket te bouwen en te testen, maar dat de oude code nog wel in het geautomatiseerde proces gecompileerd en gebouwd kan worden. Als dan niemand het verwijderd blijft de oude versie dus beschikbaar. Ook kan het zijn dat er in repositories nog software zit die al jaren niet meer wordt onderhouden. Zolang het werkt, er geen beveiligingsproblemen zijn en de beheerlast laag is laten de beheerders van een distributie het dan meestal gewoon in de repo's zitten. In dat laatste geval helpt een Flatpak of Snap natuurlijk ook niet, want die zal dan gewoon dezelfde oude versie bevatten.
Ja, bij mij was het al jaren niet meer onderhouden. Samen met google, dat default gewooon zaken uit 1920 laat zien bij zoeken en je let niet op kan je zomaar een tool/package installeren dat al 12 jaar niet meer onderhouden wordt. Kan vooral als het commandline zaken zijn evengoed nog prima voldoen.
Nu let ik er erg op in posts wat de datum is, dus 1 maand of 1 jaar terug max.
Een voorbeeld.
Toen ik begon met Linux had ik gezocht wat goede GUI development tool is. Nou dat was dus mono develop volgens veel posts en videos. Dus ik installeren.. nou ja dat was a dus een hoop verspilde tijd. was al 4 jaar oud zo uit mijn hoofd. Maar goed.. baby steps
(Ik kom van visual studio dus ik ben erg verwend wat betreft GUI development.)
Ik ben ook erg benieuwd wat de impact is van SteamOS op de populariteit van Flat.
Ik vind het bijzonder dat zelfs Spotify ertussen staan. Voor de rest erg blij met de flatpaks. Je hoeft je minder zorgen te maken dat je OS kapot gaat. Ook FlatSeal is handig voor permissies. Wel mist er nog veel. Zo zou ik graag citrix willen installeren, maar die heeft nog geen Flatpak ondersteuning.
Het zijn inderdaad wel grote installaties. Beetje vergelijkbaar met Android.
[Reactie gewijzigd door Bliksem B op 22 juli 2024 13:19]
ik ben zelf al meer dan twee jaar een gebruiker van openSUSE MicroOS Desktop op mijn laptops met zowel Gnome als KDE en gebruik voornamelijk flatpaks erop.
openSUSE MicroOS is een immutable OS waardoor je moet rebooten in het nieuwe snapshot als je een native applicatie installeert, een flatpak is daarbij dus veel makkelijker in gebruik.
Heb over de afgelopen twee jaar wel af en toe problemen gehad met lettertypes in Firefox of dat mijn thema niet helemaal lekker werkte, maar die problemen heb ik al heel lang niet meer gehad. Qua snelheid van updates gaat het ook veel sneller op deze manier en ben er ook erg blij mee. Mits je de flatpaks ook in je /¬ home folder installeert, kan je ook makkelijk je .var folder kopieren naar een nieuwe installatie en dan heb je alles weer tot je beschikking.
Opensuse microos kende ik nog niet, bedankt daarvoor! Ik heb een lange tijd Arch gebruikt, maar nu sinds een poos op Fedora. Zat er aan te denken om gebruik te gaan maken van Fedora Silverblue, zover ik zie hetzelfde concept.
Heb je die ook overwogen? Tussen die twee wat is jou primaire reden om OpenSUSE MicroOS te gebruiken?
ja heb eerst een tijdje silverblue gebruikt, maar ben zelf meer fan van openSUSE dan fedora. (ben ook de treasurer van het openSUSE bestuur..).
belangrijkste verschillen zijn.
-SB is point release samen met fedora, MicroOS is volledig rolling en gebruikt dezelfde packages als Tumbleweed.
- SB is image based, waardoor iedere installatie (op extra packages na) precies hetzelfde is, maar daardoor moet je dus een package overlay’en om het te installeren, iedere nieuwe update is dus een totale nieuwe image waar je in opstart, waardoor je maar een paar images terug kan mocht er iets aan de hand zijn. MicroOS is transactie gebaseerd en gebruikt BTRFS om een snapshot te maken van de huidige applicaties en instellingen en past alleen de veranderingen toe. hierdoor kan ik zo’n 150 snapshots terug in de tijd als er iets mis is. daarnaast worden applicaties die je native wil installeren gewoon onderdeel van de host en zijn niet erbovenop geplakt.
- SB is meer dichtgetimmerd door die rpm-ostree images, terwijl je als het nodig is bij MicroOS ook een nieuwe snapshot kan aanpassen, dan open je een shell en kan je alle aanpassingen maken op het normaal read only deel van de mappen structuur, sluit je de snapshot en herstart je je machine om die te openen.
hierdoor kan je bij VirtualBox dus ook de extension pack installeren bij MicroOS, terwijl dat bij Silverblue niet persistent mogelijk is, alleen tijdelijk dat je /var op read/write zet, maar dat ben je kwijt bij een volgende reboot.
MicroOS desktop is overigens nog wel onderhevig aan een paar veranderingen, maar voor Gnome zijn ze bijna allemaal opgelost, alleen de geautomatiseerde snapshot installaties met een notificatie dat er een nieuwe update klaar staat is nog in aanbouw.
KDE is ook volledig werkend, maar heeft nog niet genoeg contributors die tijd hebben om te helpen.
mocht je meer vragen hebben, laat maar weten 😄
qua reboots overigens, er is vrijwel dagelijks wel een update beschikbaar voor MicroOS, waardoor je dus iedere dag een reboot zou kunnen doen, er zijn ook genoeg mensen die dat om de paar dagen, elke week of per maand een paar keer doen, wat allemaal prima is.
[Reactie gewijzigd door hsb85 op 22 juli 2024 13:19]
Lekker artikeltje, in mijn linux-ontdekkingsreis was het verschil tussen packages, snap, flatpack en appimage echt wel iets waarmee ik soms flink overhoop lag. Zeker het verschil in de versies van applicaties die aangeboden werden was niet altijd even duidelijk.
Overigens had ik wel echt het gevoel dat Snaps veel trager waren dan apt-packages. Bijvoorbeeld voor Firefox op Ubuntu, dat is ontzettend irritant voor een applicatie die vaak geopend en gesloten wordt.
Op het Ubuntu forum kom ik regelmatig dergelijke geluiden tegen. Vooral Firefox schijnt onder snap duidelijk een bron van problemen. Ik begrijp Canonical wel dat ze hun toko willen promoten, maar geef dan wel een keuze tussen de .deb en de snap toepassingen.
Docker is ook standaard onbruikbaar onder snap. Je moet de snap deinstalleren en direct van de Docker ppa installeren, anders heb je een Docker installatie die niet eens naar lokale bestanden kan wegschrijven!
Distributies zoals Fedora en Ubuntu brengen elk halfjaar een nieuwe release uit. Dat lijkt snel, maar dat betekent dat je tussen twee releases tot zes maanden moet wachten om nieuwe versies van applicaties uit hun repository’s te kunnen installeren. Tussen de releases van een distributie krijg je immers alleen maar beveiligingsupdates. Het probleem is nog groter bij de versies met long-termsupport; tussen twee Ubuntu LTS-releases ligt twee jaar, een eeuwigheid in softwareland. De gemakkelijkste manier om toch nog recentere applicaties te installeren, is dan Flatpak of Snap.
Eerlijk gezegd snap (no pun intended) ik dit stukje niet helemaal. Als ik updates installeer van Ubuntu krijg ik wel degelijk nieuwere versies van bijv Firefox. Dat kreeg ik ook al met de oude stores, gebaseerd op .deb packages.
Klopt. Maar dit moet per versie worden goedgekeurd. Soms kan je ook een custom repository hiervoor toevoegen.
Het loopt vaak daarom vaak ietsje achter en dit geldt dus niet voor alle software. In mijn speelperiode met Ubuntu (10 jaar geleden), kwam ik regelmatig software tegen die toch echt een stuk achterliep.
Als je Debian hebt, is dit probleem nog veel groter, zij nemen minder risico en voegen nieuwere versies maar beperkt toe.
Wat uiteindelijk voor servers prima is. Je wilt als server beheerder niet elke keer met major versie upgrades geconfronteerd worden. Vaak draaien servers een aantal jaar, krijgen updates en worden dan bijgewerkt naar de laatste versie van de distro. Als je echt state of the art wilt kun je altijd nog een docker opstarten.
Grappig, toen ik in het verleden mijn programma's statisch compileerde met de benodigde bibliotheken kreeg ik steeds commentaar omdat het meer geheugen gebruikt en de meegecompileerde bibliotheken niet automatisch bijgewerkt worden wanneer een systeem update is.
Hoe dan ook, bij mij komt er geen flatpak of snap in.
Laatst bij een familied was er een probleem met VLC op Ubuntu dat weigerde media af te spelen van een tweede interne harddisk. Blijkt dat VLC (van Ubuntu) alleen maar media kan afspelen vanuit voor geconfigureerde directories...
Of hier voor Snaps ook een grafische utility voor is weet ik niet, maar in het geval van Flatpaks kan je met de applicatie Flatseal andere Flatpak applicaties extra rechten geven, zoals toegang tot specifieke mappen of tot apparaten zoals webcams als die niet standaard zijn geconfigureerd.
Op de mainstream Linux distro's kies ik 99% van de tijd gewoon voor de deb's of tar.gztjes, die exclusief gebruik maken van de native dependencies op het systeem - daar werkt het meestal toch wel en op bv Debian-based systems is alles meestal wel beschikbaar. Naast het theoretische verschil in performance (meetbaar trager, maar niet traag) vind ik het helemaal niks om dependencies meerdere keren op mijn schijf te moeten hebben staan in welke vorm van bundel dan ook, ook als een aantal grote worden gedeeld binnen de afgesloten omgeving (zoals dus niet het geval is bij een AppImage). Maar voor zover ik weet staan de 'gedeelde' packages bij Snap en Flatpak ook naast je native aanwezige dependency, wat alsnog als onnodige verspilling voelt. Ook de sandbox kan een voordeel of nadeel zijn.
In mijn ogen is het vooral interessant voor de ontwikkelaars. Voor gebruikers kan het eenvoudig zijn als iets niet aan de praat te krijgen is, maar anders zou ik het niet persé aanraden. Of je moet van zijn van de stores, want eerlijk is eerlijk, iets als Flathub werkt wel gewoon lekker als je privé op een desktop zit. Het proces etc, daar heb ik ook niets tegen. Het is echt dat ik ná installeren niet blijer ben met een gebundelde applicatie dan met iets dat volledig native op het systeem draait.
Af en toe kies ik nog steeds voor een Snap of Flatpak wanneer dit echt wordt aangeraden door de ontwikkelaar, of wanneer een duidelijke voorkeur wordt aangegeven. Dit was eerder zo bij Spotify, alhoewel ze de apt repo nu op een gelijke manier promoten. Of zoals in de conclusie wordt aangegeven, soms moet je bijna wel ivm zeer gedateerde dependencies die clashen met wat al aanwezig is of lastig te installeren zijn.
Voor single user gebruik zijn AppImages prima, maar voor multi-user systemen vind ik AppImages ongeschikt. Het integreert standaard niet goed in je desktop, updates zijn vaak wankel etc.
Flatpak, Snap en AppImage worden grotendeels gebruikt om een probleem op te lossen dat al jaren niet meer zo heel erg speelt op de Linux desktop, namelijk recente versies van veelgebruikte software beschikbaar stellen aan gebruikers. Als ik 10 jaar geleden Debian op mijn desktop installeerde kreeg ik daarbij de versies van Firefox en OpenOffice die op dat moment courant waren en deze werden niet meer geupdate totdat er een nieuwe major versie van Debian uit kwam, wat destijds ruim 2 jaar kon duren. Dat terwijl de ontwikkeling van juist die software heel erg hard ging. Security fixes werden uiteraard wel toegepast door middel van "backporting", maar naar de nieuwste functionaliteit kon je fluiten.
Inmiddels is die situatie flink verbeterd. De populaire desktop Linux distributies leveren inmiddels sneller nieuwere versies van populaire software pakketten en ook zijn rolling distro's zoals Arch en afgeleiden meer populair geworden, die kennen dit probleem sowieso niet. Snaps en Flatpaks kunnen nog steeds voordelen bieden in termen van gebruiksgemak of beveiliging vanwege de sandbox of als je een "immutable" systeempartitie gebruikt, maar voor veel pakketten hebben de apt of yum versies ook nog steeds mijn voorkeur.
Ik vind het zoo jammer dat zodra het over applicaties in Linux gaat, er zoveel aandacht gaat naar Snaps. Niet alleen op Tweakers hoor. Dat in het kader van Snaps ook over Flatpak wordt gesproken is dan logisch.
Voor Linux-leken die wel open staan voor een eventuele switch van MacOS of Windows naar een Linux distro, wordt zo de indruk gewekt dat je met Snaps/Flatpaks zal moeten dealen dan. En daarnaast dat de default keuze wel Ubuntu zal zijn.
Een artikel dat de eenvoud belicht hoe simpel het kan zijn in Linux om apps te installeren, automatisch up to date houden en weer heel makkelijk verwijderen, vanuit 1 centrale "App Store", zonder gehannes met 3rd party repositories, zie ik niet zo gauw. Zeker niet de vergelijking met Windows of MacOS, waarbij je zeker bij Windows een stuk omslachtiger bezig bent (de App Store die er is, is beperkt en gratis apps kosten daar meestal geld).
Ben zelf 2 jaar terug overgestapt van Ubuntu op Manjaro (Gnome). Heb daarvoor 2 jaar Ubuntu gebruikt en daarvoor altijd Windows prive, MacOS voor werk. Manjaro heeft met afstand de beste out of the box ervaring en laat mij vooral enorm met rust: kan gewoon focusen op hetgeen ik wil doen, het OS doet de rest. En met redelijk wat gemak kan je het goed personaliseren/instellen, zonder af te vragen waar een bepaalde instelling verstopt zit.
De behoefte aan Flatpak of Snap is er dan helemaal niet, tenzij je iets wil testen en de geinstalleerde native versie daarnaast wil behouden oid.
[Reactie gewijzigd door Jazco2nd op 22 juli 2024 13:19]
Daarom gebruik je op Windows tegenwoordig dus Chocolatey. Voor mensen die gewend zijn aan repositories op Linux een uitkomst. Ook voor het updaten heel handig.
Chocolatey ken ik nog van mijn Windows tijd.
Mijn punt is dat vrijwel onderbelicht is dat je met Linux eerder een soort App Store/Play Store ervaring kan hebben, met de voordelen van zelf de controle hebben over wat precies wordt geïnstalleerd. Daar hoef je niet uit te wijken naar de 3rd party project. Het zit ingebakken.
Dit blijft in de meeste artikelen onderbelicht. In plaats daarvan gaat het altijd maar over Snap versus Flatpak of AppImages terwijl 99% van de consumenten dat eigenlijk niet eens nodig heeft als het OS al een goede package manager heeft.
Voor mij is de snappificatie van ubuntu wel de reden dat ik al een tijdje zit uit te kijken naar een andere distro. Ik wordt wat geremd doordat ik nogal wat familieleden (op leeftijd) heb wiens computer ik beheer. En die zitten allemaal op Ubuntu. Maar langzamerhand begint het wel echt te gek te worden. Aangezien snap zo ongeveer ubuntu-specifiek is is er vanuit gebruikers perspectief echt geen enkel voordeel tov een .deb. Sterker nog, .deb's zijn meer generiek, want de meeste debian .debs werkten altijd prima op ubuntu.
Ook die sandboxing is vaak een spelbreker. Op zich goed dat het er is, maar er zouden makkelijker manieren moeten zijn om de sandboxing als user uit te kunnen zetten of aan te kunnen passen voor sommige apps.
En dan de snap store als single-point-of failure ...
Urg.
Als ik dit artikel zo lees dan zijn flatpacks een pietsie beter, maar ik heb toch sterk het gevoel dat zowel snap als flatpack er niet in slagen om de problemen van .deb/.rpm op te lossen en meer het idee dat ze net zoveel problemen veroorzaken als oplossen.
Als je zou willen migreren van Ubuntu naar iets anders, dan zou ik je Sparkylinux aan kunnen raden. Zeker als je de repo's van bookworm naar testing zet. Dan heb je veel minder onderhoud omdat je dan een soort rolling-release Debian hebt.
De Aptus tool is erg handig, daarmee kun je allerlei beheerstaken uitvoeren zoals installeren, verwijderen van programma's, bijwerken van het systeem.
Ook is het installeren/de-installeren van Snap, Flatpak een eitje.
Sparky heb je in verschillende smaken, zoals Gnome, KDE, Cinnamon, XFCE en een minimal (Openbox). Ook kun je kiezen tussen de stable en testing versie.
Sparkylinux is een Debian testing distributie. Aptus is een van de tools die daar wordt gebruikt. MX-Linux heeft ook aparte tools, dus vergelijkbaar met MX-linux.
MX-Linux is gebaseerd op Debian stable.
Beide distributies zijn een soort Debian Plus, die plus bestaat uit het gegeven dat ze een goede hardware ondersteuning hebben, beter dan Debian out-of-the-box.
Persoonlijk vind ik Sparkylinux wat stabieler en omdat het roling-release is makkelijker te onderhouden.
Wat ik je nu schrijf is persoonlijke ervaring. De website van Sparkylinux heb ik (niet lachen) nooit geraadpleegd.
Dit zijn de klassieke pakketformaten die nog altijd de basis vormen van de meeste Linux-distributies. Een programma wordt verspreid in de vorm van een deb- of rpm-bestand, dat enerzijds de bestanden bevat die door de pakketbeheerder worden geïnstalleerd en anderzijds allerlei meta-informatie, waaronder afhankelijkheden (dependencies). Veel pakketten hebben immers andere pakketten nodig voor hun werking./i/2005439634.png?f=imagegallery)
/i/2005430302.png?f=imagenormal)
/i/2005430304.png?f=imagenormal)
/i/2005430306.png?f=imagenormal)
/i/2005430308.png?f=imagenormal)
:strip_icc():strip_exif()/i/2005493168.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005345950.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005342960.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2003555252.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2002665352.jpeg?f=fpa_thumb)
/i/2001689195.png?f=fpa_thumb)
/i/2004628228.png?f=fpa)
/i/2004764136.png?f=fpa)
/i/2005619696.png?f=fpa)
/i/2004781964.png?f=fpa)
/i/2000816656.png?f=fpa)
:strip_icc():strip_exif()/u/36378/crop5a3f931ecfec0_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/464616/wvo-porsch-gif.gif?f=community){kind=small}
:strip_exif()/u/516830/crop64b14f31b778a_cropped.webp?f=community){kind=small}
:strip_icc():strip_exif()/u/455986/crop60844ac5040b2_cropped.jpg?f=community){kind=small}
:strip_exif()/u/207263/crop67a9cab11ec52_cropped.gif?f=community){kind=small}
:strip_icc():strip_exif()/u/50980/onok-avatar60x60.jpg?f=community){kind=avatar}
:strip_icc():strip_exif()/u/317599/crop5d18b37261809_cropped.jpeg?f=community){kind=small}
:strip_icc():strip_exif()/u/45000/zardoz3-edit.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/583282/crop59ea0dd93a7e5_cropped.jpeg?f=community){kind=small}
/u/189401/crop5a5e7beb70a42_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/323414/crop59ad1bf65c549_cropped.jpeg?f=community){kind=small}
/u/375226/crop62effc38c6e6e.png?f=community){kind=small}
/u/189240/av70.png?f=community){kind=small}
:strip_icc():strip_exif()/u/6105/crop5864bdfc59eeb_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/5722/ocf81_avatar_3.gif?f=community){kind=avatar}