Fedora Workstation 24 komt uit met pakketsysteem Flatpak

Samen met Fedora 24 komt ook Flatpak officieel uit. Flatpak, voorheen bekend als 'xdg-app', is een framework om desktopapplicaties voor Linux in een eigen sandbox te draaien en is beschikbaar voor verschillende Linux-distributies. Het is vergelijkbaar met Ubuntu's 'snap'.

Flatpak is een systeem om applicaties zo te verpakken dat ook alle afhankelijkheden meegeleverd worden. Het is in die zin vergelijkbaar met het onlangs door Canonical naar voren geschoven snap-pakketsysteem. Flatpak wil de fragmentatie op de Linux-desktop oplossen door in één pakket alle benodigde afhankelijkheden mee te leveren. Het systeem maakt gebruik van data-deduplicatie om ruimte te besparen. Net als bij snap is LibreOffice van de Document Foundation een van de eerste applicaties die met een Flatpak worden geleverd.

Omdat Flatpak van een sandbox gebruikmaakt, kan de app in principe alleen bij de benodigde bibliotheken en interfaces van het besturingssysteem. Er is nog wel een probleem bij sandboxing binnen een X11-omgeving; daarin zitten veiligheidsrisico's. Deze veiligheidsrisico's zitten volgens Fedora niet in Wayland, de grafische omgeving waarop Fedora en andere Linux-distributies hun grafische desktop willen laten draaien.

De grafische manager Wayland staat nog niet standaard aan, maar sinds XWayland goed genoeg is bevonden, ziet de community achter Fedora graag dat gebruikers toch voor een Wayland-sessie kiezen op het login-scherm. XWayland is de laag voor applicaties die niet native op Wayland draaien, maar eigenlijk X11 nodig hebben. Waarschijnlijk wordt Wayland de standaard vanaf Fedora 25.

Naast Flatpak zijn er enkele andere in het oog springende wijzigingen in Fedora 24, zoals het gebruik van een grafisch updatemechanisme vanuit de Gnome Software-app binnen de Gnome 3.20-desktop.

Reacties (45)

[MadEgg]

Jammer dat er hier nu, met dank aan Canonical, ook weer twee formaten voor zijn. Helpt niet echt voor de fragmentatie.

Geen idee hoe dit precies geïmplementeerd is. Ik ben zelf nogal fan van package managers om dependencies te installeren en dat werkt over het algemeen vrij goed. Een goede implementatie in een willekeurige distributie zou wat mij betreft kijken welke dependencies er in zo'n package ingebed zitten en vervolgens ook kijken in hoeverre de distributie zelf die dependencies kan aanbieden via de officiele repositories. Is dat mogelijk dan zou hij de ingebedde dependencies uit het package kunnen verwijderen en de linking omzetten om de op het systeem aanwezige libraries te gebruiken. Hiermee hou je de distributie in the loop zodat ook op een dergelijke manier verpakte packages automatisch kunnen meegenieten van updates aan populaire libraries.

Fijn dat dit in Fedora komt, ben benieuwd of er ook support voor dergelijke Flatpaks in Ubuntu zal belanden.

Verder ook een goede zaak dat Wayland stabiel genoeg bevonden is. Hoe zit dat eigenlijk met drivers? En dan met name nvidia, aangezien je met AMD / Radeon kaarten in veel gevallen al beter af bent met de open source drivers dan de closed source drivers. Ondersteund nvidia Wayland al?

[Q-collective]

Ondersteund nvidia Wayland al?

NVIDIA 364.12 Arrives With Wayland & Mir Support

Ik geloof wel dat Nvidia een versie van Wayland ondersteund die in maart nog niet uit was. Ik weet niet hoe dat inmiddels zit.

Edit:
Het is overigens te eenvoudig om "de schuld" te geven aan Canonical (of Redhat for that matter) for verdere fragmentatie. Het zit in dit geval niet in elkaar zoals de grap op XKCD

Snaps vinden hun oorsprong in het initiatief van Canonical om Ubuntu te lanceren als mobiel OS. Apt-get bleek namelijk niet geschikt om te worden gebruikt in een read-only omgeving. Er was iets nodig om de zaken via een veilige manier te updaten. Snaps waren geboren, aangezien er geen goed alternatief voorhanden was. Dit is dan vervolgens vertaald naar de desktop, wat gewoon een logische stap is in het "convergence" verhaal van Canonical. De daemon van snaps, snapd, is vervolgens geport naar verschillende andere distributie, wat een initiatief is geweest vanuit de gemeenschap.

En nu zitten we dan in deze "battle" tussen Snaps en Flatpack. Maar de twee zijn dus niet begonnen als concurrenten van elkaar, omdat Canonical per sé "anders" wilde zijn. Het is ontstaan uit een concrete behoefte.

[Reactie gewijzigd door Q-collective op 28 juli 2024 22:05]

[Kmphs]

De daemon van snaps, snapd, is vervolgens geport naar verschillende andere distributie, wat een initiatief is geweest vanuit de gemeenschap.

Niet waar. Snapd is volledig ontwikkeld door Canonical employees.
Zie het volgende comment van de auteur van het artikel op https://www.happyassassin...epartment/#comment-500434

The only committers I can find to snap-confine and snapd are zyga – profile says “Canonical”, jdstrand – no profile but almost certainly https://launchpad.net/~jdstrand , which lists an @canonical.com email, teknoraver – facebook (https://www.facebook.com/teknoraver ) and linkedin (https://it.linkedin.com/in/teknoraver ) list him as working for Canonical, mvo5 – profile says Canonical, Alberto Milone – https://wiki.ubuntu.com/AlbertoMilone says “I’m an employee of Canonical OEM Services Custom Engineering Group”, fgimenez – profiles says “@CanonicalLtd”, kyrofa – profile says “Canonical”, niemeyer – profile links to http://niemeyer.net/ which says “I’m part of the Canonical team since September of 2005”, chipaca – profile says “Canonical”, pedronis – profile links to http://www.lucediurna.net/ , which says “Working on the backends for services behind Ubuntu like Push Notifications & U1DB @Canonical”, pete-woods – profile says “Canonical”, caldav – David Callé, his posts in the snappy archives (http://comments.gmane.org....ubuntu.devel.snappy/1706 ) list a canonical.com address. How’m I doing so far?

[Q-collective]

Had ik het over de ontwikkelaars van snapd? Nee. Ik had het over diegenen die het hadden geport naar andere distributies:

Snap packages, or ‘Snaps’, made their desktop debut in Ubuntu 16.04 LTS. The Linux community response since then has been ‘unexpected’, Shuttleworth says. Developers from other Linux distributions have rallied around the format, porting it to run on other desktops and distributions.

Bron.

[Kmphs]

Shuttleworth zegt in de Press Call "the community" - daaruit interpreteer jij dat het dus persé niet om Canonical medewerkers gaat.

Kan je me ook een daadwerkelijke community-bron geven (niet een ubuntu-fan-site), waaruit deze community support ondubbelzinnig blijkt? Want zelf vind ik alleen maar het volgende:

Now, does Snappy actually have the cross-distribution buy-in that the press release claims (but never outright states) that it has? No. The press release sure sounds superficially impressive:

“Developers from multiple Linux distributions…Snaps now work natively on Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, and Xubuntu…Together, these distributions represent the vast majority of common Linux usage on the desktop, server and cloud.”

but it’s a pretty big mis-representation. The other distributions cited have not actually declared their support for Snappy and said ‘yes, this is how we want applications to be distributed in future’. Canonical employees have independently built and released Snappy packages for those distributions. This is the basis of all the press release’s claims. For instance, the Snappy packages for Fedora are in a COPR – COPR is a system like PPA that lets anyone build packages – maintained by a Canonical employee.

[Edit: toevoeging]
Sterker nog, ik vind veel tegenstand omdat Snaps onder Canonicals CLA vallen en niet onder de open-source licences (GPL, AGPL and LGPL).

Contributions are always welcome! Please make sure that you sign the Canonical contributor licence agreement at http://www.ubuntu.com/legal/contributors

En nee, Not all CLA's are equal

[Reactie gewijzigd door Kmphs op 28 juli 2024 22:05]

[Q-collective]

Ik had het in eerste instantie vernomen van Popey in de aflevering van Linux Unplugged van afgelopen week. Natuurlijk is dat ook geen onpartijdige bron, maar wel een andere.

[MadEgg]

Ah, ik had de 364.12+ driver al nodig om een stabiele laptop te hebben, dus dat komt goed. Dan zal ik binnenkort eens kijken in hoeverre ik Wayland aan de praat krijg

[sharkwouter]

Er is helaas geen enkele Wayland desktop die op dit moment met Nvidia's implementatie kan werken. Echte Wayland support gaat nog wel even duren.

[2green]

Het is niet dankzij canonical dat er twee pakketten zijn hoor, er bestonden al meer voor dit initiatief. En redhat werkt hier net zo hard aan mee. Appimage was er bijvoorbeeld als lang voordat deze twee er waren

Lekker artikel hier op tweakers, flatpak is vergelijkbaar met ubuntu's snap? Alleen als je oppervlakkig kijkt, inhoudelijk zijn er flinke verschillen.

Edit:
Toelichting: https://www.happyassassin...al-propaganda-department/

Persoonlijk neig ik van deze drie het meest naar flatpak, maar omdat ik voornamelijk debian gebruik hoop ik op een utopische vierde oplossing .

[Reactie gewijzigd door 2green op 28 juli 2024 22:05]

[idef1x]

Jammer dat er hier nu, met dank aan Canonical, ook weer twee formaten voor zijn. Helpt niet echt voor de fragmentatie.

Hmm ja geef Canonical maar de schuld. Waarom niet Docker? Dit zijn gewoon soort van docker containers en laat docker nu weer net afgeleid zijn van LXC (Linux containers). En waar komt LXC vandaan??? Yup..Canonical, dus....

[MadEgg]

Docker is meer richting VM dan Snap en Flatpak. AppImage biedt geen sandbox. Statisch linken was al lang en breed mogelijk dus zo bijzonder was AppImage niet.

Canonical heeft nogal last van NIH-syndroom... Wayland niet goed genoeg voor Canonical, dus Mir. xdg-app / flatpak niet goed genoeg voor Canonical, dus Snap. Ze gaan structureel een samenwerking voor standaardisatie uit de weg middels het Freedesktop initiatief. Ik kan dat niet echt waarderen. Ja, consensus bereiken in samenwerking met andere distributies kost wat meer tijd en inzet dan maar gewoon je eigen visie doordrukken en vervolgens halfbakken implementaties afleveren voor andere distributies om zo te claimen dat je platform universeel is (terwijl de vraag is hoe goed Snap gaat samenwerken met Wayland natuurlijk). Maar als je wél de moeite neemt om tot consensus te komen, wat echt niet onmogelijk is, dan heb je een bak meer developers die aan hetzelfde cruciale systeemonderdeel werken en zit er een stuk meer vaart in. En meer standaardisatie.

Canonical en Freedesktop zouden alsnog toenadering kunnen zoeken en de krachten bundelen door de beste features van beide systemen samen te voegen, maar ja, dan moet Canonical de touwtjes (deels) uit handen geven en dat zie ik niet gebeuren.

[Zer0]

Waarom zijn de ontwikkelaars van Gnome niet gewoon het KDE team gaan versterken, of andersom. Waarom Nginx terwijl er al Apache is. Apt vs RPM... En zo kan ik nog wel even door gaan. Afaik is het in Opensource land niet meer dan normaal dat als je denkt een "beter" product neer te kunnen zetten je je eigen gang gaat.

[Soldaatje]

Docker is vooral voor servers, snap en flatpak voor desktops, denk ik.

Als je een beetje gewend bent aan Docker wil je niks anders meer, echt geweldige software.

[Kmphs]

Voordat er Snappy en Flatpack waren, was er al AppImage.

Een mooi artikel over hoe Snap door Canonical gepresenteerd wordt, en hoe Flatpack dat anders doet:
https://www.happyassassin...al-propaganda-department/

En wat uitleg waarom Snap niet veilig is in X11 - hetzelfde gaat op voor Flatpack.
https://mjg59.dreamwidth.org/42320.html

[NanoSector]

Wanneer je de dependencies uit het pakket zou halen en de host zou updaten riskeer je dat die updates het pakket breken. Dat is nu net wat zo'n systeem probeert te vermijden

[Ibex]

Zolang het tight integrated is met hun system package manager zal het alleen maar voordelig zijn. Ik hoop echter niet dat het zoiets word als npm, jspm, easy_install, pip en tal van andere package managers die als extra op een systeem draaien zodat er geen correcte dependencies liggen tussen beiden met alle gevolgen vandien.

Zo had ik bvb met mijn distro's eigen package manager nooit problemen, maar doordat zowat elke taal met een eigen package manager afkomt, begint de dependency hell weer erger te worden.

[OrangeTux]

Onderdelen van je systeem die toevallig in Python of Javascript zijn prima up to date te houden je systeem package manager (ik ga er dan voor het gemak van uit dat deze pakketen in deze package manager zitten).

Maar tijdens development wil je niet je projectdepedencies globaal installeren en updaten via je system packagemanager. Dan krijg je inderdaad een depedency hell. Dan is het verstandig om per project alle dependencies te encapsuleren. Met Python doe je dat met virtualenv.

[Blokker_1999]

Ik begin weer een groot gevoel te krijgen van dat iedereen weer zijn eigen standaard aan het ontwikkelen is.

https://xkcd.com/927/

[Q-collective]

Bij Linux is het zo dat hun verafgode flexibiliteit en customization, meteen ook de reden is dat het grote publiek niet of nauwelijks met Linux werkt.

Hoe verklaar je dan dat Android (een stuk meer flexibel dan iOS en bovendien ook gebaseerd op de Linux kernel) op het moment meer dan 50% van de markt in beslag neemt? Blijkbaar is er dus wel een markt voor "customisation".

Voor een newb is het toch gewoonweg niet meer te behappen dat je bij de één met flatpack werkt en bij de ander SNAP en ook nog met RPMs kunt installeren of YUM of DEB.

Het idee van snaps en flatpacks is dat het niet meer uitmaakt. Je zou dus een systeem kunnen hebben waar je LibreOffice als deb hebt geïnstalleerd via de package manager, Firefox als flatpack en VLC als snap. Ze kunnen dus door elkaar worden gebruikt. Het zijn namelijk systemen die op zichzelf staan.

Voor de eindgebruiker maakt het dus geen reet uit, eerlijk gezegd. De "battle" gaat meer over dominantie bij de developers: deze gaan niet de moeite doen om én flatpacks en én snaps uit te geven. De vraag is dus wie dominant wordt.

Je zegt later:

Er is geen aanbod van Linux computers in de winkel.
Te complex en te duur om te ondersteunen als OEM.

Ik ken je leeftijd niet, maar dat is echt flauwekul. Microsoft heeft vele jaren geïnvesteerd in goede relaties met de grote OEM's. Tegenwoordig is dat minder nodig, vandaar m'n opmerking over je leeftijd want wellicht heb je die periode gewoon gemist. Het momentum van de bestaande verhoudingen op de desktop markt bepalen het aanbod.

Of het overigens zo "complex" of "duur" is om Linux te ondersteunen: Dell heeft project Sputnik wat met name de XPS Developer Edition heeft opgeleverd. En dan heb je nog kleinere spelers zoals System76 (die levenslange support biedt op hun producten) en Entroware die louter Linux desktops en laptops leveren (laatst had Tweakers nog een artikel over dat laatste bedrijf). En dan hebben we het niet eens over de vele aanbieders van Chromebooks die, jawel, ook Linux draaien.

Blijkbaar is het dus niet "complex" of "duur" genoeg om er geen geld mee te verdienen.

[Reactie gewijzigd door Q-collective op 28 juli 2024 22:05]

[matty___]

Hoeveel package managers heb je onder Android?

Het os ansich heeft geen keuze vrijheid en er is maar 1 app formaat.

Beetje appels met peren vergelijken. Het draait een Linux kernel maar daar houdt het ook bij op


Anyway dit hele idee is al mega oud. Apple gebruikt het. Freebsd/ pcbsd heeft het al al sinds ze zijn begonnen. Jaartje of 5 zo uit mijn hoofd.

[Reactie gewijzigd door matty___ op 28 juli 2024 22:05]

[35MHz OC]

.exe, .com, .msi, .zip. Just saying...

[Verwijderd]

.exe, .com, .msi, .zip. Just saying...

Ik kan ook zo maar wat in het wilde weg roepen.

klik er op en het werkt (meestal).
Bijna vanzelfsprekend geworden.

Die vanzelfsprekendheid is ver te zoeken bij Linux, is mijn ervaring.

[35MHz OC]

Ik kan ook zo maar wat in het wilde weg roepen.

Ja, dat heb je inderdaad gedemonstreerd.

Als het om dubbelklikken en installeren gaat, openen zowat alle mainstream distributies de grafische packagemanager als je op een los pakket voor de distributie klikt. Je moet tegenwoordig wel heel ver uit de gebaande paden gaan, wil je het moeilijk krijgen in Linux.

Enige voorwaarde is wel, dat je Linux draait op een systeem die volledige driver support heeft voor Linux. Dus niet zomaar even op een willekeurig (voormalig) Windows systeem neerzetten en dan verwachten dat het allemaal perfect gaat.

[Verwijderd]

Voor een newb is het toch gewoonweg niet meer te behappen dat je bij de één met flatpack werkt en bij de ander SNAP en ook nog met RPMs kunt installeren of YUM of DEB.

Een newb weet niet wat die dingen zijn en houdt zich daar dan ook verre van en gebruikt 'gewoon' de (fantastische) grafische omgeving.

Bij Linux is het zo dat hun verafgode flexibiliteit en customization, meteen ook de reden is dat het grote publiek niet of nauwelijks met Linux werkt.

Het grote publiek gaat naar de winkel en koopt wat daar te kiezen is, dus Apple of MS. Dát is de reden.

[BoringDay]

^{Totdat zijn printer, geluidskaart of Videokaart niet naar behoren werkt. Jammer maar dan mag je tekstbestanden editen en of alternatieve blobs installeren. En als er dan iets mis gaat ben je weer uren bezig om het recht te breien.}

Die zijn er ook uren mee bezig om het recht te breien onder windows/osx want veel verschil zit er niet in. Wanneer men er toch uren mee bezig is trekt men daar leer uit zodat ze het de volgende keer in 10 minuten kan oplossen?

[hackerhater]

Je kennis loopt ongeveer 10 jaar achter.
Ik beheer een gemengende omgeving en ik heb concequent meer problemen met de window-pc's dan met de Mac's of Linux pc's.

[springtouwtje]

concequent, dat is pas humor

[BoringDay]

_{Als het met Linux niet lukt moet je maar net iemand kennen die dit kan en die zijn er niet zoveel.}

Dan zoek je op internet, genoeg mensen met kennis of je gaat net zo lang door totdat je het snapt. Desnoods koop je een boek over Linux/Unix voor beginners.

^{Het is al moeilijk genoeg.}
Dat is het juist niet, het probleem ligt meer bij gebrek aan kennis.
Maar dat geld voor elk OS, als je was op gegroeid met Linux en nu ineens voor het eerst Windows moet gaan gebruiken, dan zal je ineens Windows heel onlogisch vinden.

[a153957]

Bij het artikel van Ars Technica waren ze deze keer dit soort comments al voor: http://arstechnica.co.uk/...tform-linux-app-packages/

[ameesters]

Dit is juist goed, hierbij zal de concurrentie tussen die 2 voor snelle verbetering zorgen. En .deb en .rpm leven ook al meer dan dan een decennia naast elkaar. Ik vind het juist goed dat distro's werken aan onderscheidend vermogen van de rest van de kudde, interessante ontwikkeling dus

[sam_vde]

Iedereen is wat overdreven, zelfs als flatpaks en snaps blijven bestaan is het al een felle verbetering tov nu.

Maar inderdaad, een gemiste kans om echt te standaardiseren.

[Blokker_1999]

Een verbetering zou ik deze technieken zelf niet durven noemen. Ik ben geen voorstander van het bundellen van externe libraries met een pakket maar zie liever dat men gebruik maakt van de libraries die aanwezig zijn op het systeem.

[goarilla]

Ik zie het niet als een verbetering van het opensource ecosysteem maar
als iets voor externe proprietary software. Om bv. flexlm gebaseerde license servers in een snap/flatpack te verdelen en draaien.

[sam_vde]

Het probleem is de wildgroei die dat met zich meebrengt. Linus himself maakt geen linux packages om die reden. Dus zo kan het ook niet verder.

Maar technisch gezien begrijp ik je wel. Het hoeft op zich geen probleem te zijn, maar het risico op slechte implementaties vergroot wel degelijk.

[Ed Vertijsment]

Tja, package managers bouwen schijnt tegenwoordig een ding te zijn. Voor elke technologie lijken er wel minstens 2 package managers beschikbaar te zijn.

[bbstreams]

ik geef nog altijd de voorkeur aan compilen vanuit soucre, hoe moeilijk kan het zijn. lastiger dan je denkt,groot probleem is dat tegenwoordig alleen daily distro's nog standaard make tools mee leveren , dus als je geen internet hebt en je moet een driver toevoegen moet eerst een hoop andere packages toevoegen aan een main stream distro.

[DLGandalf]

Compilen vanuit source is gewoon totaal niet triviaal. Kijk eens hoeveel moeite het de package managers van Debian kost om het builden enigszins een beetje conform te houden qua file hierarchy enz. Ten tweede kost het tijd.

[Xaphod]

Ik ben benieuwd of dit een oplossing is om oude 32 bits programma's onder linux 64 bits aan het werk te houden.
Ik heb een linux gebaseerde arcade cab en het wordt steeds lastiger om Daphne (de laserdisk emulator) aan het werk te krijgen op 64 bit linux.
Tot linux mint 17.3 Xfce lukt het zonder problemen, maar op Mint 18 (beta) niet zonder moeite.
Het lukt me wel door systeembreed 32 bit libs te installeren, maar dat is niet ideaal.

[sam_vde]

Tip: chroot. Dat gebruik om die reden voor een ouder programma dat ik nog gebruik. Wel 64-bit, maar op een Ubuntu 12.04 base.

[kim72]

Ik hoop nog altijd op een systeem waarbij het gewoon mogelijk is om meerdere versies van een package naast elkaar te kunnen installeren, waarbij de app aangeeft met welke versies hij werkt.