Officiële Ubuntu-flavors stoppen vanaf 23.04 met standaard ondersteunen Flatpak

Ubuntu-ontwikkelaars hebben ermee ingestemd om softwaredistributiesysteem Flatpak niet langer standaard beschikbaar te stellen in de officiële Ubuntu-'flavors'. Dat gebeurt vanaf Ubuntu 23.04. Flatpak kan vanaf dan nog wel handmatig geïnstalleerd worden door gebruikers.

Vanaf de volgende grote release worden Flatpak en de bijbehorende plug-ins niet langer standaard geïnstalleerd in de officiële Ubuntu-flavors. Dat maakt Canonical bekend in een bericht op zijn forum. De verandering gaat daarmee in vanaf Ubuntu 23.04 'Lunar Lobster', die in april uitkomt. Flatpak is een systeem waarmee ontwikkelaars Linux-applicaties kunnen distribueren naar gebruikers. Na de wijziging kunnen gebruikers van bepaalde Ubuntu-varianten dergelijke apps niet langer standaard installeren.

Ubuntu-gebruikers die Flatpak al gebruikt hebben en willen upgraden naar 23.04, behouden hun Flatpak-installaties wel gewoon na de migratie. Gebruikers die 'niet eerder geïnteracteerd hebben met Flatpak', krijgen vanaf 23.04 standaard alleen nog software uit de Ubuntu-repositories en Canonicals eigen Snap Store aangeboden.

De wijziging geldt voor alle acht de officiële Ubuntu-'flavors'. Het gaat daarbij om Ubuntu-varianten als Kubuntu en Xubuntu en Ubuntu MATE, die beschikken over andere desktopomgevingen en voorgeïnstalleerde apps dan de gewone versie van het OS. Ubuntu zelf bood standaard al geen Flatpak-ondersteuning, maar bepaalde flavors deden dat wel. Gebruikers kunnen Flatpak ook na de wijziging handmatig blijven installeren, benadrukt Canonical. Dat kan via de installatie-instructies die Flatpak aanbiedt.

Canonical claimt in zijn blogpost dat de wijziging 'de out-of-the-box Ubuntu-ervaring voor nieuwe gebruikers zal verbeteren' en 'tegelijkertijd respecteert hoe bestaande gebruikers hun eigen ervaringen personaliseren'. Ubuntu en zijn flavors beschouwen debs en snaps als de 'standaardervaring' voor het OS, aldus het bedrijf.

Door Daan van Monsjou

Nieuwsredacteur

22-02-2023 • 17:56

68

Submitter: Sando

Lees meer

Reacties (68)

Sorteer op:

Weergave:

Ik heb het even nagezocht, want het werd mij ook niet helemaal duidelijk. (bron)
Flatpak, Snap en AppImage het zijn 'universele verpakkingssystemen'.
Flatpak is een hulpprogramma voor pakketbeheer waarmee u software kunt distribueren, installeren en beheren zonder dat u zich zorgen hoeft te maken over afhankelijkheden, runtime of de Linux-distributie. Omdat je software zonder problemen kunt installeren, ongeacht de Linux-distributie (of het nu een op Debian gebaseerde distro of een op Arch gebaseerde distro is), wordt Flatpak universeel pakket genoemd.
Het is eigenlijk heel erg simpel. Het is te vergelijken met apps op iOS en Android die je installeert via een app store.

Net als op mobiele apparaten, kun je permissies instellen van de apps en hebben deze standaard al bepaalde permissies toegekend in veel gevallen. Ook draaien ze net als mobiele apps, allemaal in hun eigen sandbox.

Flatpak is vooral gericht op de Linux desktop, en heeft bijvoorbeeld plugins voor Gnome Software en KDE Discover (beide app stores), die het halen van Flathub waar ontwikkelaars hun app naar toe kunnen sturen.

Voor developers is het makkelijker. Linux-distros hebben buiten flatpak, ook hun eigen package manager (o.a. voor software en libs). Maar je moet dus als ontwikkelaar het allemaal porten: apt, RPM, PKG, etc. (dan vergeet ik nog als nix).

Met een Flatpak bouw je dus een universeel installatie bestand, met daarin alles wat het nodig heeft om te werken. Voordelen zijn gemak, nadelen zijn schijfruimte die het inneemt.

Persoonlijk ben ik enorm fan van Flatpak (Fedora Silverblue), absoluut niet van snap. Ubuntu snapt gewoon niet dat andere zitten te wachten op hun zooi (persoonlijke mening).
Ik ben al jaren geleden overgestapt op Mint omdat ik het beleid van Ununtu niet meer ondersteunde.

Ik snap je beklag over Ubuntu niet. Er zijn 1000 andere distro’s en de Ununtu developers zijn de baas over die van hen.

Als je het er niet mee eens bent, kan je je bemoeien in de community of voor een andere distro kiezen.
Maar (uitgezonderd de Debian Edition) Mint heeft wel gewoon Ubuntu als basis.

Dus vele Ubuntu beleidsbeslissingen hebben ook wel onrechtstreekse gevolgen voor Mint, normaal niet als het over packages gaat want daar kiest Mint zelf wat ze doen.

Overigens geef ik je gelijk dat er genoeg alternatieven zijn als iets je niet aan staat, maar ook bij Ubuntu blijven en gewoon zelf de nodige aanpassingen doen is uiteraard mogelijk. Je kan perfect heel snap er uit gooien en voor flatpack gaan
Probleem is dat vrijwel alle software development handleidingen uitgaan van een Ubuntu of Debian basis. Anders is het volgen van voorgeschreven tutorials en scripts ineens een stuk meer werk dan copy paste. Moet ik ineens alle apt-get vervangen door pacman ofzo en vervolgens heeft het weer een andere naam etc etc.
een van de belangrijkste redenen waarom ik wel mint en niet ubuntu ondersteun is idd snap. mint kiest wel voor flathub en daarbij is het vooral ook veel duidelijker of je een distro-versie of een flathub versie voor je kiezen hebt. voor bepaalde software is flathub ontzettend fijn, in andere gevallen heb je gewoon liever de ppa van de developer en in andere gevallen volstaat de versie van je distributie.
Ik ben dan wel benieuwd naar wélke software je/men liever via Flatpak installeert dan via de native package manager. Ik kan me dat enigszins voorstellen bij ontwikkelomgevingen, maar verder?
Okular, PDFArrange, RNote, ... om er enkele te noemen. Als je de functionaliteit van de laatste versies nodig hebt, heb je weinig keuze.
het liefst gebruik ik helemaal geen containers, behalve dan misschien voor zaken zoals wine (wine is echt een clusterfuck.. helaas gebeurt het bij sommige software dat men juist tegen bepaalde versie-compileert (vooral closed source meuk) en die draai ik dan wel liever in aeen container zowel omdat ik weet dat bepaald libs dan slecht worden bijgehouden alsook omdat enige isolatie van de rest van je systeem altijd weer een beetje meer afstand tot je data creeert.

als ik dan moet kiezen tussen snapd en flatpack dan is de keuze snel gemaakt.

voor normale (opensource) software zou ik zeggen dat zelfs een custom-build (tegen jouw systeem) te preferen is boven een pre-made container, mits je over de kennis beschikt om dat pakket optimaal werkend te krijggen, alternatieven zijn dan natuurlijk nog ppa's en de mainline distro packagges.

[Reactie gewijzigd door i-chat op 22 juli 2024 16:07]

Interessant is dat Alan Pope na zijn vertrek bij Canonical een tool heeft gemaakt om de migratie van Snapcraft naar Flatpak te automatiseren: unsnap. Daarvóór waren het voornamelijk veel positieve blogs over Snap.

[Reactie gewijzigd door Sando op 22 juli 2024 16:07]

Wel fijn dat Tweakers even uitlegt wat Flatpak is. Iets met apps zo te zien. Vergelijkbaar met Electron??
Flatpak draait om software die je op nagenoeg elke distributie kunt installeren zonder gezeik met dependencies. Alles zit erin.

Ubuntu sloopt het eruit omdat ze met Snap iets vergelijkbaars hebben, en dan met een eigen appstore.
Dat gezeik was er ook al niet met apt zolang je binnen de repositories blijft (met meer dan 10k+ softwarepakketten voor de meeste gebruikers afdoende). Voor software die niet in de repos staan is het de schone taak van de developer om na te denken over de dependencies en de boel goed te packagen. Ik ga met een grote boog om snap/flatpak heen omdat het voor mij betekent dat de depencies zo'n grote bende zijn dat de ontwikkelaar het zelf ook niet meer snapt/er geen tijd in wil steken. De inefficientie van meerdere verschillende versies van libXYZ in het gebeugen vind ik zonder van mijn computer, dus of ik loop je fanatastische software mis of ik compile het lokaal en zet het in /opt of /usr/local buiten het package management om. Tot op heden nog geen problemen mee ervaren (dit in tegenstelling tot issues met snap/flatpak)
Spotify kan je niet zelf compileren omdat het propietary software is en die geven ze alleen uit als Deb.
https://www.spotify.com/us/download/linux
Dus de enige andere mogelijkheid om die gebruiken als je niet op een Deb based distro zit is de Flatpak, Snap(of via de AUR als je op Arch zit). Mij is ook opgevallen dat sommige Flatpaks zelfs beter bijgehouden worden als sommige packages uit Rpmfusion.

Voor de software die opensource is die je wel kan compileren is dat ook niet echt optimaal omdat je dan ook nog is allemaal build, devel packages en devel libraries moet installeren om die software te kunnen compileren.

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

Of Alien: converteer .deb naar .rpm en omgekeerd. Hercompileren is vaak niet nodig. Repackagen dan wel. Ik zie meer in een dpkg/rpm hybride om de brug tussen beide te overbruggen dan hacky flatpacks/snaps.
over het artikel
ik moet eerlijk zeggen dat ik de kwaliteit (diepgang) van dit artikel wel wat tekort vind schieten, vooral als we kijken naar wat flatpack is wat snap is, en hoe cononical het voor gebruikers verziekt om een goed eenduidig en stabiel systeem te draaien. [spoiler] men probeert vooral snap nog meer voorsprong te geven op flathub, en dat terwijl je als ontwikkelaar voor snap aan cononcial moet betalen terwijl flathub in principe free (as in beer) te gebruiken is. [/spoiler]

over containers de voor- en nadelen
snapd, flatpack en appImage zijn 3 nagenoeg identieke manieren waarop je software onder linux kunt draaien zonder het in feite op je system te installeren. een beetje zoals je bij windows soms portable-software kunt gebruiken, alles staat dan in feite in één mapje of één zip-bestand

het grote voordeel van zoiets is natuurlijk dat de maker van de software veel invloed heeft op de inhoud van zo'n bestand, je komt dus nooit in de knoei met in deze versie zit een bug waardoor precies dit stukje software ineens niet meer werkt, dat kan soms namelijk tot vervelende situaties leiden waarbij: software a gebruik maat van lib-blabla versie 1.21 en daar heel stabiel op gaat, maar software b werkt sinds de nieuwe release alleen nog maar met lib-blbla versie hoger dan 1.30 die incompatible is met software a. door in zo'n geval dus alles in een apart container te hebben kun je voor beide stukjes software hun eigen lib-blabla versie gebruiken.

er zijn daarbij wel 3 grote nadelen.
1: software in een container integreert lang niet zo goed (of eigenlijk vrij slecht) met de rest van je systeem, dat wil zeggen dat toegankelijkheids opties, niet of slecht werken, dat documenten printen vanuit een app in een container extra problemen kan veroorzaken, dat het ene stukje software moeilijker kan samenwerken met een ander stukje software.
2: doordat software in een container van alles hun eigen versie moet draaien, betekend dit dat er een bepaalde overhead ontstaat, je dus meer ram en meer cpu nodig hebt, dat je laptop korter gaat op z'n batterij, en dat je systeem over-all gewoon slechter presteert.
3: als elk container zijn eigen versie van lib-blabla draait, dan betekent dat ook, dat elke container onafhankelijk moet worden geupdated, wanneer er een kritieke bug wordt gevonden in dat stukje software.. waar je normaal afhankelijk bent van 1 of 2 partij(en) (namelijk het lib-blabla development team, en in een sommige gevallen wellicht de package beheerder van je distributie. wordt dat aantel verhoogt voor elke container waarin dat stukje software wordt gebruikt.

stel je dan eens voor dat lib-blabla op een dag het QT of GTK framework is, dan mag je in 1 klap niet 1 package in apt-get updaten, maar in plaats daarvan wellicht 10 pakketen in snapd of flathub. dan ben je niet allen meer resourse kwijt, maar ook, meer update tijd en een veelvoud aan bandbreedte.

over Ubuntu en snapd / flatpack
Nu je wellicht wat beter begrijpt wat snap- en flatpack- packages zijn, zul je misschien snappen dat het weliswaar heel handige tools zijn, maar dat je ze tegelijkertijd ook heel spaarzaam zou moeten gebruiken, heb je bijvoorbeeld één stukje legacy software dat echt afhankelijk is van een oudere versie van bijv QT of een ander pakket, dan zijn dit soort containers een ideale manier om de software toch bruikbaar te houden zonder dat de rest van het systeem daar onder lijdt. ook wanneer je software draait in vreemde configuraties of met apps en libs die je verder nergens voor kunt gebruiken kan een container een handige optie zijn. het is ook heel handig voor de distributie van zeer gevoelige software waarbij de configuratie nauw luistert.

voorbeelden van software die goed in een snap-pack zou passen is bijvoorbeeld microsoft office of wellicht bepaalde andere windows software, waar dan ook direct de juiste wine-versie bij zit met de juiste configuratie en de nodige andere tweaks of bestanden.

bij bij ubuntu is het de laatste jaren helaas een beetje anders geworden, ubuntu is zo noob-vriendelijk (lees: transparant) geworden dat je met een paar clicks in de software-center niet eens meer (zeker) weet of je nu de distro-versie of de snapd versie van een bepaald programma te pakken hebt... dus voor je het weet heb je google chrome in een container, en snap je maar niet waarom je schermlezer er niks mee kan. - nu zullen er mensen zijn die meteen blij worden van een browser in een container, maar die keuze zou wel bij de gebruiker en dus niet bij random toeval moeten liggen...

voor je het weet staat je pc vol met containers waarvan je bij sommigen niet eens weet of ze wel op tijd de juiste updates krijgen, van lib-blabla bijvoorbeeld en niet alleen van het pakket waar het om draait.

bekenende voorbeelden hiervan zijn onder andere: google chrome, en libre-office en Firefox waarbij de snap versie soms hoger in de lijst met aanbevelingen staan dan de distro-versies. en vooral voor libre-office kan dat soms een probleem zijn, als blijkt dat je bepaalde bijlages in je mailclient ineens niet kunt openen omdat libreoffce als snap-package geïnstalleerd was


offtopic:
met lib-blabla bedoel ik hier dus een stukje sofware waar andere programma's van afhankelijk kunnen zijn (bij windows denk je dan misschien aan het .NET-framework) maar bij linux kan zoiets bijna alles zijn: van GTK of QT tot bijvoorbeeld ook lib_ssl of lib_decrypt

[Reactie gewijzigd door i-chat op 22 juli 2024 16:07]

Bedankt voor je uitleg. Het is jammer dat de redactie niet gewoon het volgende artikel gelinkt had:
gelinkt had: review: Flatpak of Snap? - Distro-onafhankelijke pakketten voor Linux
over het artikel
ik moet eerlijk zeggen dat ik de kwaliteit (diepgang) van dit artikel wel wat tekort vind schieten, vooral als we kijken naar wat flatpack is wat snap is, en hoe cononical het voor gebruikers verziekt om een goed eenduidig en stabiel systeem te draaien. [spoiler] men probeert vooral snap nog meer voorsprong te geven op flathub, en dat terwijl je als ontwikkelaar voor snap aan cononcial moet betalen terwijl flathub in principe free (as in beer) te gebruiken is. [/spoiler]
over je feedback
Er staat boven elk artikel een feedback-knop staat. Daarmee kom je op een forum waarmee je feedback kan geven. Ik vind dat zelf erg omslachtig, als je dat met me eens bent nodig ik je uit een duimpje bij mijn verbetervoorstel. Dat scheelt
  • De redactie heel veel tijd in het vinden van goede feedback zoals de jouw
  • De communitie-leden heel veel tijd met het aanmaken van nieuwe topics waar allerlei data ingekopieer dmoet worden.
edit:
Herschreven omdat @i-chat het als niet opbouwende-kritiek heeft ervaren.

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:07]

Meer inhoudelijk, ik denk dat Tweakers weldegelijk zijn best heeft gedaan uit te leggen wat Snap en Flatpak zijn:
review: Flatpak of Snap? - Distro-onafhankelijke pakketten voor Linux
Dat is waar, maar daar hadden ze dan wel even naar mogen linken in het artikel.
Zou die link met n de intro hebben gestaan als verklaring van wat snap etc doet dan zou ik mogelijk mn hele post niet persé hebben hoeven schrijven

Echter als ik naar het niveau van de overige reacties kijk dan zijn er of weinig mensen die goed snappen wat snapd doet

Als ik naar de datum van dat artikel kijk dan gok ik dat het destijds een plusartikel was en dus nog onbekend bij een groot deel van de community

Dus ga ik mee met de opmerking van gekkeprutser Als iets niet in het artikel staat dan staat het er niet en als die wel relevant dan is een opmerking gewoon ter zake

Je kunt als groep dan wel blijven roepen dat het op het forum moet maar gezien het aantal keer dat het geroepen moet worden zegt dat kennelijk ook iets over de gebruiksvriendelijkheid Begin eens met een fatsoenlijke inline feedback tracker waarbij je de pagina niet hoeft te verlaten

Of misschien een @redactie tag zodat men ze automatisch te zien krijgt


Dus in plaats van aanvallend te reageren met verwijten kun je ook dankbaar zijn Voor de aanvullende informatie en je afvragen waarom je zovaak nieuwe topics moet openen kennelijk is het proces dan niet goed

Maar goed als we het dan over de inhoud hebben dan mis ik vooral deze punten

- Wat zijn flatpack en snap
- Welke achterliggende reden zit er achter deze beslissing
- is het misschien een verdere verplichting / push richting snapd en wat zijn de reactie ls if any hierop

Als ik even snel naar dat artikel kijk dan gok ik dat je met een korte alinea en een paar anchor tags al ver gaat komen

Dat maakt het lezen zoveel makkelijker
Dus in plaats van aanvallend te reageren met verwijten kun je ook dankbaar zijn Voor de aanvullende informatie en je afvragen waarom je zovaak nieuwe topics moet openen kennelijk is het proces dan niet goed
Ik ben blij met je aanvullende informatie en het spijt me dat ik dat oorspronkelijk er niet bij zei. De reden dat ik wees op het feedback forum is juist omdat ik wil dat dit soort feedback bij de redactie terecht komt. Ook had ik al vermeld dat ik het feedback-forum omslachtig vind. Juist daarom reageer ik, zodat je een bijdrage kunt leveren aan het verbetervoorstel waar ik naar verwees.

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:07]

nogmaals, hou op met zo passief agressief te doen..

ik reageer inhoudelijk op het onderwerp, ik geef aanvullingen waar nodig, leg dingen uit aan het grote publiek, en geef toch wel duidelijk aan hoe ik (met mijn expertise) denk dat het artikel beter kon...

als je vindt of vond dat ik dat verkeerd aanpak kun je vragen (in plaats van eisen, of sneren), om dat anders te doen. als ik vervolgens aangeef waarom ik dat niet doe (met duidelijke reden: namelijk het is onhandig, ingewikkeld, tijdrovend etc). kun je 2 dingen doen, of de feedback negeren (zodat tweakers subobtimaal blijft) of je kunt er iets mee doen. als je vervolgens vind dat je teveel tijd kwijt bent met het posten van die topics - dan begrijp je wellicht ook waarom ik ervoor kies die ook niet meer te openen.. het is simpelweg teveel werk en tweakers.net dan daar vrij eenvoudig iets op verzinnen... (ik zou zeggen klaag erover, misschien dat ze naar jou wel luisteren ;) )


maar nogmaals kom dan niet in zo'n topic / thread als dit de zwartepiet spelen en mij van alles verwijten, dat heb ik bij jouw ook niet gedaan. - het enige waar ik jou op aansprak was je aanvallende toon en daar blijf je kennelijk mee doorgaan... ik snap ook niet waaraan ik dat volgens jij verdien.

van alle berichten die ik in dit topic heb geplaats ging dat stuk over ongeveer 1 alinea van +/- 5 zinnen. nog geen 10% van wat ik heb getypt en toen ben je me alleen daarop aan het aanvallen - met geen woord over de rest.
nogmaals, hou op met zo passief agressief te doen..
Het spijt me dat je het zo ervaart. Dat was niet mijn bedoeling, ik weet dat je daar niets mee bereikt. Misschien kun je mij vertellen hoe ik het beter had kunnen verwoorden.
. (ik zou zeggen klaag erover, misschien dat ze naar jou wel luisteren ;) )
Door deze opmerking krijg ik het idee dat je mijn post helemaal niet gelezen hebt. Ik heb meerdere keren aangegeven wat ik heb gedaan. In plaats van te klagen heb ik een verbetervoorstel geschreven. ik nodig iedereen uit om hier een duimpje voor te geven en met succes, het is de tweede in de lijst meest gevraagde features geworden. Helaas zie ik nog geen enkel resultaat van de kant van Tweakers (dat frustreert me). Toch suggereer jij dat ik alleen maar naar jou klaag:
Je kunt als groep dan wel blijven roepen dat het op het forum moet maar gezien het aantal keer dat het geroepen moet worden zegt dat kennelijk ook iets over de gebruiksvriendelijkheid Begin eens met een fatsoenlijke inline feedback tracker waarbij je de pagina niet hoeft te verlaten
Dat is precies wat ik ook vind, maar in plaats van het hier, in de diepe krochten van een discussie onder een artikel te posten, heb ik het al drie keer genoemde verbetervoorstel geschreven. Ik snap niet wat je nog meer van mij verwacht.
met geen woord over de rest.
Het spijt me dat we hierover van mening verschillen, maar zo werkt een conversatie toch? Je bent het eens met een groot deel, en zet de discussie voort om de overblijvende meningsverschillen te overbruggen.
edit:
Originele post aangepast
Ik heb mijn post inmiddels aangepast door te beginnen met een compliment over jouw post. Hopelijk vind je het nu prettiger lezen.

[Reactie gewijzigd door 84hannes op 22 juli 2024 16:07]

Niet op dezelfde manier als 'appimage' bestanden doen. Die werken meteen op alle versies van Linux (dus Debian/Ubuntu, RedHat, Gentoo, Arch, OpenSUSE enz.) zonder dat er software zoals FlatPack, Snap geinstalleerd hoeft te worden.

Alleen een dubbel-klik is voldoende om de applicatie te starten (in zijn eigen 'zandbak').

Ubuntu Server edities zeuren met 22.04 ook al steeds meer om Snap dit, Snap dat. Ik wil helemaal geen Snap (of Flatpak).
- edit- never mind

[Reactie gewijzigd door hackerhater op 22 juli 2024 16:07]

FlatPak en Snap zijn sandboxing technieken waarbij alle libraries worden gebundeld met de app. Zodat de ontwikkelaar geen rekening hoeft te houden met de specifieke eigenschappen van elke Linux distributie. Het heeft ook nadelen zoals het niet meer automatisch upgraden van kwetsbare libraries en het kunnen delen hiervan in het geheugen.

Het is een beetje te vergelijken met portable apps op Windows. Maar niet helemaal, omdat Windows apps sowieso op elk Windows systeem met dezelfde architectuur te gebruiken zijn. Dus de techniek an sich is daar gewoon niet nodig.

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

Portable windows apps zijn zeker niet te vergelijken hiermee, want flatpak is eerder een soort installer die ervoor zorgt dat de dependencies geïnstalleerd zijn.
Pwa's hebben nog steeds frameworks en libraries nodig die je dan zelf moet installeren. Je hoeft pwa’s alleen niet zelf te installeren.
Precies. Ikzelf raakte het spoor alleen maar verder bijster bij flavors, debs en snaps. Dit had zo een 1 april artikel kunnen zijn voor mij als niet-Ubuntu-kenner.
Het is vergelijkbaar met snap, wat Canonical heeft ontwikkeld, en hiermee probeert te pushen naar de gebruikers. Hier een uitleg in het Engels over de verschillen tussen flatpak, snap & het "normale" apt.
AuteurAverageNL Nieuwsredacteur @DhrRob22 februari 2023 18:20
Dank voor de feedback! Ik heb in de inleiding het woord 'softwaredistributiesysteem' en verder in het artikel een beknopte uitleg toegevoegd :)
Of ze hadden promininter naar hun eigen artikel kunnen verwijzen: review: Flatpak of Snap? - Distro-onafhankelijke pakketten voor Linux

Staat nu ook wel onderaan het artikel, heb het vorige maand gelezen en gaf een duidelijk beeld van hetgeen je nu vraagt.
Zou je niet over ieder artikel kunnen zeggen dat er termen in staan die een significant deel van de lezers even moet opzoeken?

Bv: nieuws: Corsair introduceert Vengeance DDR5-geheugensets van 48, 96 en 192GB

- dimms
- cl38 en cl40
- XMP 3.0-overklokprofielen
- DDR5-5200
Dit is geen verdiepend artikel natuurlijk, het is gewoon nieuws. Basic Linux software zoals snap en Flatpak zou de doelgroep wel moeten kennen toch?
Zucht. Die snaps moeten en zullen doorgedrukt worden. Ongetwijfeld meer commerciële motieven omdat de snap store niet open is, je kan niet je eigen repo of store opzetten. Canonical is de sleutelhouder.

Ik denk dat het motief vooral is om uiteindelijk betaalde apps aan te bieden en een percentage te pakken, zoals Apple immers ook doet met hun app store. Maarja iets dat helemaal open is speelt daar niet lekker mee dus dan niet je het wiel opnieuw uitvinden.

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

Dan moeten ze wel eens snap ondersteunen voor commerciële systemen.

Momenteel als je installatie maar een beetje afwijkt van de standaard (zoals een home directory die niet in /home/user zit, of er zit een ampersand (domein) in je username, je UID is te hoog of paswoord-loze opstellingen) dan werkt snap al niet meer. En dat is al een bekend probleem sinds snap uitkwam.

[Reactie gewijzigd door Guru Evi op 22 juli 2024 16:07]

Ik heb begrepen dat ze het vooral zien als een manier om een greep te krijgen op de IoT markt, meer dan op de desktop markt. Vandaar ook Ubuntu Core. Hun strategie lijkt daar erg hard op ingezet, al zie ik er minder nadruk op nu de hele "IoT" hype een beetje begint in te zakken.

De desktop markt boeit ze blijkbaar niet zo. Ik krijg regelmatig een telefoontje van weer een nieuwe canonical account manager die weer hetzelfde blahblah verhaal begint over hun landscape beheerspul met allemaal mooie bullet points. En altijd stel ik de vraag: Kan je er ook andere distro's mee beheren dan ubuntu? Dan wordt het gelijk stil.

Ik ga geen heel beheerplatform inrichten voor een 'wagenpark' wat maar 25% van onze linux PC's beslaat (en die op zich zijn maar 1 a 2% van onze totale werkplekken). We hebben 160.000 werkplekken in totaal dus absolute aantallen zijn nog wel wat, maar dit is gewoon niet echt bruikbaar. Inmiddels ga ik hier niet meer over maar mijn opvolger wil er al helemaal niks mee doen wat niet standaard via Intune kan :)

Zoals @HollowGamer zegt, ja RedHat probeert je ook aan hun intellectueel eigendom te binden, met gnome en mono enzo. Vind ik net zo vervelend maar het verschil is dat RedHat wel succesvol is hierin en wel standaarden neer te zetten waardoor je jezelf niet zo isoleert.

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

snap is precies bedoeld voor de desktop, het grootste voordeel van Snap/Flatpack is om dingen die een GUI nodig hebben zoals browsers (voor gebruikers) te isoleren. Voor IoT heb je al heel lang Docker/Kubernetes etc maar integratie met desktop applicaties in Docker/K3s is er gewoon niet.

Wij hebben ook een groot deel Linux desktops/workstations/servers die we ondersteunen, en hebben beiden Ubuntu Pro en RHEL, het verschil tussen de twee is dat RedHat inderdaad op de 'enterprise' markt gokt, terwijl Canonical blijkbaar meer achter klein bedrijf en thuis-gebruikers (zoals onafhankelijke developers) gaat.

De integratie met AD/LDAP/Samba of zelfs OpenSCAP in Ubuntu is enorm belabberd en de ondersteuning/documentatie/integratie/monitoring in Landscape bestaat bijna niet (hier is onze API zeggen ze dan), terwijl je bij RedHat een mooie dashboard krijgt en zonder zelf veel van Linux te kennen kun je wel zien waar je organisatie problemen heeft met patches en configuratie veranderingen.
Nou dat is het verschil tussen Snap en FlatPak, FlatPak is idd vooral voor GUI bedoeld, met snap hadden ze echt IoT in het achterhoofd, heb ik begrepen van een insider. Zo was het begonnen in elk geval. Maar inmiddels is IoT al niet meer zo gehypt dus wellicht zijn ze een beetje omgegaan op dit punt. Vergeet niet: De strategie van Canonical is altijd om hun eigen intellectueel eigendom populair te maken. Daarom is het punt van "er bestaat al docker" gewoon niet relevant in hun ogen.

En idd, wij hebben ook vooral RHEL om die reden. Het probleem bij ons is dat we als een idioot hippe bedrijfjes opkopen en die zitten vaak helemaal verankerd in hun ecosysteem (tot het punt dat vaak zelfs hun software oplossingen erop gebaseerd zijn) dus die willen niet zomaar veranderen naar 1 distributie binnen het bedrijf. Daarom hebben we een hele lappendenken van van alles wat.

Het verbaast me eigenlijk dat het nog niet is opgekocht door Microsoft. Microsoft en Canonical zijn zo klef samen in hun marketing uitingen dat je echt denkt van "Jezus, get a room".

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

Distrobox is een wrapper tussen docker/podman en de desktop OS.
En er is al een package manager in de maak hiervoor: apx.
Er zit niet alleen een commerciële gedachten achter, ze hebben zelf snap ontwikkeld, dus gaan ze het ook gebruiken. Hetzelfde doen ze met Mir en voorheen met Unity.

Allemaal leuke concepten, maar buiten Ubuntu, gebruikt vrijwel geen enkele distro snap en iets als Mir.
Inderdaad, UpStart was ook zo'n dingetje.

En Mir is inmiddels ook alweer afgeschreven. Ik denk dat het met snap ook wel gebeurt op zijn tijd, maar momenteel zijn ze nog helemaal vastgebeten hierin, zoals dit artikel ook wel aangeeft.
Dat zal meespelen. Maar ook: deze Ubuntu-smaken dragen de naam Ubuntu. Eventuele problemen hebben dus ook hun weerslag op Ubuntu als merk.

Hoewel Flathub voor mij goed werkt is het in principe een onveilige bron. Er vind nauwelijks controle plaats.

Ik kan me voorstellen dat Ubuntu niet graag ziet dat potentieel onveilige apps per default worden aangeboden aan nietsvermoedende gebruikers.
Ik kan me voorstellen dat Ubuntu niet graag ziet dat potentieel onveilige apps per default worden aangeboden aan nietsvermoedende gebruikers.
Snap ik, maar het helemaal onmogelijk maken om zelf een eigen repository op te zetten gaat wel heel ver, zeker voor Linux waar je toch een zekere kennis verwacht.

Ik denk meer dat ze het lucratieve app store model van Apple voor ogen hebben op langere duur. Canonical is altijd zoekende geweest naar een verdienmodel.

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

Ik draai op mijn werk systeem nu nog wel Ubuntu zonder Snaps omdat ik Flatpaks fijner vind wanneer ik iets niet uit de normale repos kan installeren. Ik begin er erg moe van te worden hoe Canonical Snaps er door probeert te drukken, ik ben bang dat je op gegeven moment geen Ubuntu meer kan draaien zonder Snaps. Waarom gewoon niet de keuze geven tijdens installaties of je van Snaps gebruik wil maken of niet i.p.v het er standaard in stoppen. Zodra er geen keuze meer is m.b.t Snaps ga ik Ubuntu wel verlaten voor een andere distributie voor mijn werk systeem.
Omdat Canonical liever hun eigen tech. pushed. Red Hat doet dit ook, maar t.o.v. Canonical, worden deze wel breed gedragen door de community.

Een keuze gaan ze niet doen, het liefst willen ze het zo niet ingewikkeld maken voor de user, zie dat ze Firefox al heel lang pushen via snap.
Je kan ervoor zorgen dat Snaps standaard niet de voorkeur krijgen en dat standaard Deb packages geïnstalleerd worden, dat doet Linux Mint ook.
Linux Mint heeft standaard snap niet geïnstalleerd en je moet er wat extra voor doen als je wel snaps wilt gebruiken. Zie https://blog.linuxmint.com/?p=3906 waarom ze dit hebben besloten.

Ubuntu heeft een aantal APT packages vervangen door snaps zoals Chronium en Firefox. Hierdoor op mijn werklaptop Firefox handmatig geïnstalleerd zodat het niet erg lang duurt voordat de Firefox snap opstart en tegen andere beperkingen aanloop.
Dat klopt, ik heb datzelfde gedaan op mijn Ubuntu systeem.
cat /etc/apt/preferences.d/nosnap.pref
# To prevent repository packages from triggering the installation of Snap,
# this file forbids snapd from being installed by APT.
# For more information: https://linuxmint-user-gu...cs.io/en/latest/snap.html

Package: snapd
Pin: release a=*
Pin-Priority: -10
Snap is het eerste wat ik er altijd af gooi. Flatpaks zijn echter ook niet zaligmakend door een gebrek aan goede repositories.

Iedereen gebruikt Flathub, maar die doet maar weinig om de veiligheid en kwaliteit te waarborgen.

Je moet echt zelf uitzoeken welke Flatpaks op Flathub "officieel" zijn en welke door random figuren in elkaar gedraaid zijn.
Flatpaks zijn fijn als optie om te hebben omdat bepaalde packages alleen als Debs worden uit gegeven, ie: Signal en Spotify.
https://news.itsfoss.com/verified-flatpak-apps/

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

Naar mijn mening (zonder expert te zijn) kan Ubuntu best focussen op één package manager, en die optimaliseren.

De focus zal liggen op snap en apt, waarbij je niet om apt heen kunt. Waarom dan niet de vermeende tekortkomingen in apt oplossen, of de vermeende voordelen van snap in apt implementeren?

Mijn ervaringen met snap op Ubuntu 22.04 LTS zijn mager. De apps starten (de eerste keer na een boot) trager op. Firefox als snap kan niet communiceren met mijn kaartlezer, dus heb ik alsnog Firefox als apt-package moeten installeren. Spotify als app dacht ik lekker dicht te kunnen timmeren, maar de permissies die ik kan instellen zijn zo breed dat ik ze alsnog bijna allemaal moet toestaan als ik het programma effectief wil gebruiken. Daarmee vallen een heel aantal van de voordelen van snaps weg: de containerization is te strikt, en tegelijk niet strikt genoeg.

Daarnaast maak ik me zorgen om de security: als snap bevat ieder programma een heel groot deel van zijn eigen dependencies, wat 'dependency hell' zou moeten minimaliseren. Dat betekent ook dat sommige veelgebruikte libraries in veel snaps tegelijk aanwezig zullen zijn. Om opslagruimte maak ik me geen zorgen, maar hoe update ik die libraries in geval van een vulnerability? Vroeger kon je het package updaten, en gezien de meeste andere packages daarop bouwden, was je vulnerability (grotendeels) opgelost. Bij snaps dus niet zo. Het voordeel van minder dependency management en library incompatibility/multiple versions is dus een vergiftigd geschenk.

[Reactie gewijzigd door NoControl op 22 juli 2024 16:07]

Apt heeft geen beperkingen die flatpack of snap applicatie installatie onmogelijk maakt. Een snap of flatpack applicatie zou je ook via apt vanuit een debian repository kunnen installeren.
Snap en flatpack hebben een support runtime nodig voor de applicaties, wat gewoon een dependency is voor elke snap/flatpack applicatie die je vanuit een debian stijl repo zou zillen installeren. Verder zaken zoals "permissie toestemming" krijgen kan je afhandelen via debconf. Of vanuit de flatpack runtime als je de applicatie start.
Dit gaat voor een groot deel ook op voor RPM.

[Reactie gewijzigd door elmuerte op 22 juli 2024 16:07]

Ik weet niet hoe het zit bij Snap, maar bij Flatpak kunnen libraries wel gedeeld worden tussen apps, dat scheelt weer wat ruimte, als die libraries exact dezelfde zijn.
Wat wel een pluspunt is van Snap, Flatpak en Appimage is dat er verschillende versies van dezelfde app op de computer gebruikt kunnen worden zonder problemen, dat lijkt me wel een voordeel.
Firefox als snap kan niet communiceren met mijn kaartlezer
Misschien moet je iets toestaan als:

snap connect firefox:???
Zie
snap connections firefox
Heb je de Firefox tarball al geprobeerd? Die is altijd up to date itt de .deb.
Dan is er eindelijk een store die én open source is en het installeren van applicaties gemakkelijk maakt en dan gaan de grote uitgevers ala Canonical weer hun best doen om hun eigen rommel er door te drukken. Ik vind zelf flatpacks echt geweldig werken, maak daarnaast ook veel gebruik van appimages (SteamOS gebruiker).

Wat dat betreft is Valve overigens geweldig bezig om te zorgen dat zo veel mogelijk compatibel is met Linux d.m.v. Proton. Daar kunnen andere distro's echt nog wel een puntje aan zuigen. Ik heb het idee dat alleen Valve snapt hoe je het beste met Windows kunt concurreren.
Die was er al 20+ jaar in de vorm van de Apt/Deb repos. Ze hadden ook al 3rd party repo support erin zitten (voor bijv. Google Chrome). Die flatpack/snap meuk werkt alleen maar in de hand dat je een dikke zip met alle libs + binary installeert om vervolgens de gebruiker te irriteren met een hoger geheugen verbruik en libraries die gierend achterlopen t.o.v. upstream (met alle CVEs die daarbij komen kijken). Het gebruiksgemakt van Apt/Rpm was al zo hoog dat iedereen software kon installeren zonder de overhead van snap/flatpak. Dus ik snap nog steeds niet welk probleem ze hier op proberen te lossen.
Er zijn gelukkig heel goede alternatieven op Ubuntu.

Met Manjaro heb je 1 enkele app store die ook je systeem up to date houdt en waar je geen repositories voor hoeft toe te voegen. Updaten gaat ook nog eens veel sneller dan met Ubuntu.

Dat gezeur over Snap altijd. Als mensen dat echt vervelend vinden stappen ze over (genoeg opties) en als genoeg mensen dat doen leert Ubuntu het vanzelf
Nou is Manjaro alles behalve een "goed" alternatief, maar ok. Je punt staat, er zijn zat prima alternatieven. Ik snap ook niet echt waarom mensen niet gewoon een andere distro pakken die wel bij hen past, al blijf ik het zonde vinden dat Canonical Ubuntu zo verpest.
Zo is hetzelfde over Ubuntu te zeggen..over de jaren heen zijn er genoeg posts of zelfs hele sites opgezet om te benadrukken hoe fout het ene Linux systeem is en hoe fout het andere is. Erg vermoeiend. Als je kijkt naar wat er nu staat, zijn er weinig out-of-the-box opties die gewoon echt zo simpel werken als je zou willen. Zonder hoop configuratie.

Is de reden dat ik na aantal jaren Ubuntu ben overgestapt. Scheelt me zooveel tijd. Dat is een luxe gewoon.
Technische redenen om een distro slecht te noemen zijn er voor elke distributie wel en daar moet iedereen zijn eigen oordeel in maken. Met Manjaro is er echter meer aan de hand, wat vooral neer komt op heel slecht management. Ik ga alle foute keuzes die zij gemaakt hebben niet noemen, die kun je prima zelf vinden, maar ik zou mijn systeem in ieder geval niet aan hen toe vertrouwen.
Ik geloof je meteen hoor.
Maar na 2 jaren Manjaro op homeserver (2 adressen) laptops en een paar NUCs, waar ik vrijwel 0.0 ommekijk naar heb, vind ik het echt top.
Daarvoor met Ubuntu moest ik regelmatig wel iets doen.

Nu kan ik gewoon altijd wel via RDP verbinden en ouders helpen, zonder daarvoor 3rd party apps te installeren. En dit kan al meer dan een jaar nog voordat het in de Gnome UI zit. En ook via Wireguard VPN.
Dingen die gewoon snel out of the box werken of waar je in 1 "App Store" iets vind en installeert en klaar, het werkt, met hoge performance.
Dat miste ik altijd in Ubuntu.

Dus ze doen vast een hoop slecht, maar voor mij meer goed dan Ubuntu..
Dit is toch een opmerkelijke actie van Ubuntu.

Als je namelijk in Firefox Snap gebruik wil maken van een extensie met native-messaging, dan heb je Flatpak nodig, sterker nog dan moet je het handmatig instellen via Flatpak.
flatpak permission-set webextensions org.keepassxc.keepassxc_browser snap.firefox yes
https://discourse.ubuntu.com/t/call-for-testing-native-messaging-support-in-the-firefox-snap/29759/70

Maar misschien hebben ze daar ook iets nieuws voor bedacht.

Hoe dan ook, ik blijf flatpak (naast snap) gebruiken

[Reactie gewijzigd door Jan121 op 22 juli 2024 16:07]

Flatpak zelf is het probleem niet denk ik. Het probleem is de bron van de flatpaks. Flatpaks zijn potentieel onveilig en Ubuntu heeft daar geen zicht op.

Dan zou Ubuntu zelf een flatpak repository moeten openen, en daar zullen ze weinig zin in hebben aangezien ze reeds met snap in de weer zijn.
Mijn laatste Ubuntu installatie zal ruim voor die tijd verdwenen zijn, dus enige impact zal het toch niet meer hebben. Het hele gedoe van het achterhouden van esm-apps updates, tenzij je Ubuntu Pro hebt, is ook al vervelend. Het zijn maar een paar installaties voor familie en mezelf, dus dat is geen groot punt.
Flatpak is een directe open source concurrent van Snap, wat proprietary onzin van Canonical is. Heel jammer dit.

Ik ga op de lange termijn toch maar op zoek naar een ander Debian smaakje want Canonical beweegt steeds meer richting een walled garden.

Op dit item kan niet meer gereageerd worden.