Verspreiding van software

Software kan op diverse manieren worden verspreid. De meest directe methode is gewoon via een website van de maker van de software. Bij Linux is het echter gebruikelijk om de software te verspreiden via zgn. repositories ofwel softwaremagazijnen. Dat zijn plekken op het internet waar softwarepakketten worden verzameld en opgeslagen.

Van oudsher heeft vrijwel elke Linux-distributie zijn eigen repositories. De erin opgenomen software wordt door de Linux-distributie heel specifiek voor de verschillende versies van de distributie samengesteld en beheerd. Hij is dan ook gegarandeerd virus- en malwarevrij. De ervoor benodigde broncode wordt door de maker van de software aangeleverd. De Linux-distributie heeft een zgn. pakketbeheersysteem, waarmee software vanuit de repositories kan worden geïnstalleerd en zonodig bijgewerkt. Eenmaal geïnstalleerd kan de software ook weer via dat beheersysteem worden verwijderd.

De software in de repositories is door de Linux-distributie geselecteerd en bestaat vrijwel helemaal uit opensource-software. Daarnaast is er vaak nog enige gratis closedsource-software die voor de werking van een systeem nodig kan zijn, zoals drivers. Software die niet is geselecteerd zal door de makers van die software vooral via hun eigen website of via een ontwikkelsite als github of sourceforge worden aangeboden. Zo’n ontwikkelsite biedt ontwikkelaars van opensource-software de mogelijkheid hun software te ontwikkelen, te plaatsen en te verspreiden. Aanbieders van commerciële closedsource-applicaties voor Linux zullen niet in een Linux-repository worden opgenomen en zijn dan ook aangewezen op andere middelen van verspreiding, zoals via de eigen website.

Aanbieders van niet-geselecteerde Linux-software, zowel opensource als closedsource, hebben echter een probleem. Alle software in een versie van een Linux-distributie is nauwkeurig op elkaar afgestemd. Een externe applicatie (toepassing ofwel programma) moet daar wel in passen. Dat zou kunnen betekenen dat voor elke ondersteunde versie van elke distributie een pakket met de applicatie zou moeten worden samengesteld. Dat is onwerkbaar. Aanbieders van opensource-software volstaan daarom nogal eens met het aanbieden van de broncode, die de gebruiker zelf maar tot een werkende applicatie moet compileren. Waar dat niet gebeurt, of waar dat niet kan, zoals bij closedsource-software, zal de applicatie maar voor enkele belangrijke distributies en versies daarvan ter beschikking worden gesteld, of wordt er maar helemaal van een Linux-versie afgezien.

Daarom zijn nu universele systemen voor de verspreiding en het beheer van software in opkomst. Ook deze systemen bieden software aan via één of meer repositories, maar die software kan in elke Linux-distributie via een eigen pakketbeheersysteem worden geïnstalleerd en vervolgens gebruikt. De makers van de software behoeven maar één pakket met de applicatie samen te stellen en naar zo'n repository te uploaden om van een zo groot mogelijke verspreiding onder Linux-gebruikers verzekerd te zijn. Zo wordt het voor hen veel aantrekkelijker om hun applicatie niet alleen voor Windows en MacOS, maar ook voor Linux aan te bieden.

De belangrijkste universele systemen zijn Flatpak en Snap. Flatpak is volledig opensource en niet aan een leverancier gebonden. Snap is weliswaar deels opensource, maar is voor de verspreiding van software afhankelijk van Canonical, dat het systeem ontwikkelde en in beheer heeft. Dat is de belangrijkste reden dat steeds meer Linux-distributies Flatpak ondersteunen in plaats van Snap. Ook de desktopomgevingen KDE en Gnome ondersteunen Flatpak als geprefereerde en aanbevolen wijze van softwaredistributie. Zij denken er over te gaan samenwerken bij de uitbouw van de Flathub-appstore (bron). Het lijkt er dan ook op dat Flatpak voor wat betreft de distributie van software voor Linux een belangrijke rol zal gaan spelen. De Linux-distributies Ubuntu en zijn officiële varianten zoals Kubuntu, ondersteunen het eigen Snap in plaats van Flatpak. Ondersteuning van Flatpak kan echter wel worden toegevoegd. Hoe dat moet lees je op de Flathub website.

Programmabeheer

Vrijwel alle Linux-distributies kennen grafische applicaties om vanuit de repositories gemakkelijk software te installeren, vervolgens te beheren en eventueel te de-installeren. Deze kunnen door zowel de Linux-distributie als de desktopomgeving in die distributie worden aangeboden.  De desktopomgevingen KDE en Gnome hebben een eigen applicatie die resp. ‘Ontdekken’ en ‘Gnome Software’ heet. Linux Mint heeft ‘Programmabeheer’, Ubuntu en officiële varianten, zoals Kubuntu en afgeleiden, zoals Zorin, hebben ‘Software’, openSUSE heeft ‘YaST Software’. Linux-distributies met KDE en Gnome hebben soms meerdere applicaties voor programmabeheer, zowel die van KDE of Gnome als hun eigen applicatie. Voortaan zal ik al deze applicaties scharen onder de term ‘programmabeheer’.

Programmabeheer is eenvoudig in het gebruik, maar verbergt heel wat complexiteit. Er liggen een of meer zgn. pakketbeheersystemen aan ten grondslag, die ten doel hebben de te installeren applicatie te voorzien van alle benodigde basis- en hulpsoftware, in het bijzonder softwarebibliotheken (libraries) die door de applicatie wordt gebruikt.

We kunnen twee soorten pakketbeheersystemen onderscheiden: specifieke en universele.

Specifieke pakketbeheersystemen

Specifieke pakketbeheersystemen werken met pakketten die specifiek voor een versie van een distributie zijn samengesteld. Specifieke systemen zijn veelal door een bepaalde Linux-distributie ontwikkeld, en worden door die distributie en ervan afgeleide distributies gebruikt. Er zijn echter ook distributies die een elders ontwikkeld systeem gebruiken. Een voorbeeld daarvan is SUSE Linux / openSUSE, dat het systeem van Red Hat gebruikt. De twee belangrijkste en meest gebruikte specifieke pakketbeheersystemen zijn:

Het Debian systeem. De Debian-softwarepakketten hebben een naam met extensie .deb. Dit systeem wordt gebruikt door Debian en alle ervan afgeleide distributies, zoals Ubuntu en daarvan afgeleiden zoals Kubuntu, Linux Mint en Zorin. De programma's voor pakketbeheer zijn apt voor de CLI (Command Line Interface ofwel de opdrachtregel) en synaptic voor de GUI (Graphical User Interface ofwel de grafische gebruikersinterface).

Het Red Hat systeem (RPM, ofwel Red Hat Package Manager). De RPM pakketten hebben een naam met extensie .rpm. Dit systeem wordt gebruikt door Red Hat Enterprise Linux (RHEL) en afgeleide distributies zoals Fedora, CentOS, Almalinux, en onafhankelijk daarvan ook door SUSE Linux Enterprise Desktop (SLED) en -Server (SLES) en afgeleide distributie openSUSE. In RHEL etc. is het programma voor pakketbeheer yum, opgevolgd door dnf (allebei voor de CLI). Er is een grafische schil genaamd yumex. In SLED etc. is het zypper voor de CLI en yast sw_single voor de GUI.

Voor applicaties benodigde basis- en hulpsoftware die ook door andere applicaties kan worden gebruikt, wordt apart verpakt. Het belangrijkste voorbeeld hiervan zijn gedeelde bibliotheken (shared libraries). Zo blijven de pakketten zo klein mogelijk, en wordt heel wat schijf- en geheugenruimte bespaard. Elk pakket bevat meta-informatie met onder andere een lijst van pakketten waarvan het pakket in kwestie afhankelijk is. Het pakketbeheersysteem zorgt ervoor dat bij installatie van een applicatie aan zijn afhankelijkheden wordt voldaan door de benodigde basis- en hulpsoftware ook te installeren, als die al niet geïnstalleerd is. Natuurlijk kan ook basis- en hulpsoftware afhankelijk zijn van andere basis- en hulpsoftware.Ook al is een verzameling pakketten specifiek voor een versie van een distributie, toch kunnen distributies die van een bepaalde distributie zijn afgeleid vaak ook de pakketten van de ouderdistributie gebruiken. Zo gebruikt Linux Mint allerlei pakketten van Ubuntu. Ook veel Debian-pakketten zullen bruikbaar zijn. Maar deze Debian-pakketten zijn onbruikbaar op RPM-systemen, en omgekeerd. En pakketten voor RHEL, Fedora, etc., zijn veelal niet bruikbaar in SLED en openSUSE, en omgekeerd. Dat komt omdat veel pakketten anders zijn ingedeeld en anders heten.

Wat zijn de voor- en nadelen van deze specifieke beheersystemen? Voordelen zijn:

1. Dank zij het feit dat applicaties softwarebibliotheken delen wordt efficiënt met schijf- en geheugenruimte omgegaan. Bovendien blijven de pakketten daardoor relatief klein en zal bij de installatie van een applicatie alleen datgene nog moeten worden gedownload dat nog niet in het systeem aanwezig is.
   
   
2. Pakketten worden onderhouden en getest door de distributie. Daardoor zijn ze allemaal goed op elkaar afgestemd, en zullen ze geen virussen en malware bevatten. Let wel dat dit laatste niet per se hoeft te gelden voor pakketten van derden, zoals bijvoorbeeld de pakketten uit Personal Package Archives (ppa’s) bij Ubuntu en afgeleiden.

Maar er zijn ook nadelen:

1. Zoals bij de verspreiding van software al aan de orde kwam, is het voor leveranciers van applicaties een probleem dat voor elke nog ondersteunde versie van elke distributie een pakket zou moeten worden samengesteld. In het bijzonder geldt dat voor commerciële leveranciers, omdat hun software niet via de opensource-repositories van de distributies kan worden aangeboden. Dat is zo veel werk dat ze, als ze al pakketten leveren, dat alleen doen voor op zijn hoogst enkele distributies, in het bijzonder die welke ook commercieel aan de weg timmeren zoals Red Hat, openSUSE en Ubuntu. Dit probleem zou wel eens een belangrijke rol kunnen spelen bij het feit dat allerlei commerciële software, denk aan Adobe Photoshop, wel voor Windows en MacOS wordt geleverd, maar niet voor Linux. Het is gewoon te veel werk voor een relatief geringe opbrengst.
   
   
2. Het onderhouden en bijwerken van pakketten door een distributie is zoveel werk dat distributies er vaak voor kiezen om nieuwere versies van applicaties alleen te leveren in nieuwere versies van de distributie. Als gebruiker blijf je dan zitten met oudere versies van applicaties, tenzij je overstapt op de nieuwere versie van de distributie. Of je zo'n overstap zou willen maken alleen maar om van een bepaalde applicatie een nieuwere versie te kunnen gebruiken is de vraag. En je kunt dan een probleem hebben als je van een andere applicatie de oudere versie zou willen blijven gebruiken.
   
   
3. Dat alle pakketten ter wille van gedeeld gebruik van bibliotheken nauwkeurig op elkaar zijn afgestemd heeft ook een belangrijk nadeel. Als je van een applicatie een oudere of nieuwere versie zou willen installeren, kan het zijn dat die versie een oudere of nieuwere versie van gedeelde bibliotheken nodig heeft. Maar die biedt het systeem helaas niet. En mocht het bij installatie van zo’n afwijkende versie van een applicatie toch lukken om de benodigde gedeelde bibliotheken op te halen en te installeren, dan kunnen al geïnstalleerde applicaties worden geconfronteerd met de foute versie van een of meer gedeelde bibliotheken. Ook kan het zo zijn dat je een applicatie gebruikt die niet door de distributie, maar door derden geleverd is. Dan is het mogelijk dat die applicatie niet meer werkt als je op de volgende versie van de distributie over gaat, omdat hij afhankelijk is van een bepaalde versie van een bibliotheek die in de nieuwe versie van de distributie niet meer beschikbaar is.
   Dit probleem staat wel bekend onder de naam ‘hel van afhankelijkheden’ (dependency hell).
   
   
4. Elk pakket dient met rootrechten te worden geïnstalleerd. Dat betekent dat een pakket bij installatie van alles met je systeem kan doen. Zolang een pakket uit een vertrouwde bron komt, zoals de repositories van de distributie, is dat geen probleem, maar een pakket uit een onbekende bron zou malware kunnen installeren zonder dat je het in de gaten hebt.

Universele pakketbeheersystemen

Om aan de nadelen van specifieke beheersystemen tegemoet te komen hebben in de loop van de tijd verscheidene initiatieven het licht gezien om een universeel pakketbeheersysteem te ontwikkelen. De volgens zo'n systeem samengestelde pakketten zou je in principe in elke versie van iedere distributie moeten kunnen installeren en gebruiken. Met pakketten van de bestaande specifieke beheerssystemen is dat, zoals we zagen, heel vaak niet mogelijk. Op het ogenblik hebben we de keus uit een aantal van deze systemen, waarvan de belangrijkste zijn:

Flatpak (www.flatpak.org) is ontwikkeld door een onafhankelijke gemeenschap van vrijwilligers en ondersteunende organisaties, en geheel opensource. Een volgens dit systeem samengesteld pakket met een applicatie noemen we een flatpak. Meerdere repositories zijn mogelijk. De centrale repository met bijna 2300 applicaties is Flathub (flathub.org/nl), maar onder meer de desktopomgevingen KDE en Gnome hebben ook eigen repositories. Vrijwel alle erin aangeboden applicaties zijn grafisch, er zijn er maar enkele voor de terminal (opdrachtregel). Ongeveer 10% van de beschikbare applicaties zijn propriëtair (zie eindnoot 1). Voorbeelden daarvan zijn Opera (web-browser), Microsoft Edge, Skype, Steam (platform voor games) en Vuescan (scanner software). Er zijn verschillende distributies waarin de ondersteunende software van Flatpak standaard geïnstalleerd is, onder meer Fedora, Linux Mint en Zorin. Dat geldt niet voor Ubuntu en zijn officiële varianten zoals Kubuntu, want daarin is standaard Snap geïnstalleerd.
Een enkele opdracht (flatpak update) is voldoende om alle flatpaks op een systeem bij te werken naar de nieuwste versie.

Snap (snapcraft.io) is ontwikkeld door Canonical (de onderneming achter Ubuntu). Het pakketformaat en de ondersteunende software zijn opensource, maar er is maar één centrale repository (de Snap Store: snapcraft.io) onder de hoede van Canonical, waarvan de broncode niet openbaar is. Een volgens dit systeem samengesteld pakket met een programma noemen we een snap. Snap was oorspronkelijk bedoeld voor cloud-, server-en en IoT-tools en applicaties, maar ondersteunde later ook desktop-applicaties.. Het totaal aantal applicaties is enkele duizenden (eind 2018 al ca. 4000), maar het aantal desktop-applicaties lijkt achter te blijven bij dat van Flatpak.
Alleen Ubuntu en zijn officiële varianten hebben de ondersteunende Snap-software standaard geïnstalleerd. Snaps (Snap-applicaties) worden standaard automatisch bijgewerkt, maar gebruikers kunnen aangeven wanneer en hoe dit moet gebeuren, en het tegenhouden voor geselecteerde snaps.

AppImage (appimage.org) bestaat al sinds 2004 onder de naam Klik, werd vanaf 2011 PortableLinuxApps genoemd en vanaf 2013 AppImage. Het is ontwikkeld door Simon Peter en is geheel opensource.  De centrale repository is AppImageHub (appimagehub.com) met circa 1300 applicaties.
Ondersteunende software is niet nodig. Een AppImage-pakket behoeft niet echt te worden geïnstalleerd, maar kan naar believen ergens worden geplaatst, bijvoorbeeld in de map /usr/local/bin, en uitvoerbaar worden gemaakt. AppImages zijn daarom gemakkelijk overdraagbaar (portable).
Elke AppImage bevat alle hulpsoftware (met name bibliotheken) die nodig is om de applicatie te draaien en deelt geen hulpsoftware met andere AppImages. Desondanks nemen AppImages minder ruimte op de schijf in dan je zou denken omdat de software erin is gecomprimeerd.
AppImages moeten door de gebruiker zelf aan het menu worden toegevoegd. Er is geen mechanisme om AppImages bij te werken. Dat kan alleen handmatig door de nieuwe versie van zo'n AppImage te downloaden en de oude er door te vervangen. Eigenlijk is AppImage dan ook geen echt pakketbeheersysteem. Het beheer wordt immers volledig aan de gebruiker overgelaten.

Archief voor installatie in map /opt. Sommige aanbieders van software leveren een archiefpakket (bijvoorbeeld .tar.gz), dat alle basis- en hulpsoftware bevat die voor de applicatie nodig zijn, ook al is die software mogelijk al elders op het systeem aanwezig. Zo’n pakket kan onder de naam van de applicatie in de map /opt worden uitgepakt, waarna aan de map /usr/local/bin een symbolische link naar het hoofdprogramma kan worden toegevoegd om het gemakkelijk te kunnen starten. Ook moet zo'n applicatie door de gebruiker nog aan het menu worden toegevoegd. Voorbeelden van software die zo wordt aangeboden zijn Firefox, Seamonkey, Thunderbird.
Dit soort software is dan ook voor vrijwel alle Linux-distributies geschikt. Het moge duidelijk zijn dat dit net als AppImage eigenlijk geen pakketbeheersysteem is.

Conclusie

Zoals we al zagen wordt Flatpak al door heel wat Linux distributies ondersteund. Snap blijft beperkt tot Ubuntu en zijn officiële varianten zoals Kubuntu. AppImage kan een rol spelen als leverancier van overdraagbare applicaties. Al deze systemen kunnen, indien gewenst, naast elkaar worden gebruikt.