For et par uger siden annoncerede Canonical understøttelse på tværs af distributionerne for Snap-programleveringsmekanismen, som kunne understøtte mobile, desktop- og serverbaserede applikationer. Annonceringen vakte opsigt i Linux-fællesskabet, som ikke så mange beviser på, at andre Linux-distroer understøtter Snaps.
Snap er Canonicals forsøg på at forfine pakkemekanismen og leveringsmekanismen for apps på Linux-platformen. Oprindelsen af Snap finder sine rødder i Click, en løsning, som Canonical skabte til sin mobilplatform tilbage i 2014 for at håndtere kompleksiteten ved at levere apps til Ubuntu-telefon- og tabletbrugere, et økosystem, der er meget forskelligt fra desktops og servere. Derudover havde mobilen også brug for at begrænse apps og sandboxe dem, så de ikke kompromitterede hele platformen.
Click gjorde det muligt for udviklere at samle alle afhængigheder i en enkelt app-pakke, så brugere og udviklere ikke behøvede at bekymre sig om modstridende systemer og app-biblioteker. Det gjorde det muligt for udviklere at bruge de nyeste biblioteker i deres apps, så de kunne tilbyde nye funktioner, da de var afkoblet fra de biblioteker, der var installeret på systemet.
Beyond Mobile to Servers and IoT
Click udviklede sig til Snap, og Canonical udvidede dens potentielle anvendelse til server-, cloud-, Internet of Things (IoT) og desktop-områder. Med udgivelsen af Ubuntu 16.04 i april bragte Canonical officielt Snap til Ubuntu-skrivebordet.
Canonical er også ved at udvikle Snappy Ubuntu Core, et lillebitte Linux-baseret styresystem til store cloud-containerudrulninger, IoT-enheder og meget mere, og alt, der har brug for overgangsopdateringer og et lille fodaftryk. Snappy Ubuntu Core fungerer mere eller mindre som Googles Chrome OS og CoreOS, hvor det tilbyder midlertidige image-baserede opdateringer til systemet og apps, der kan rulles tilbage. Samtidig tilbyder den den begrænsning, der er kendt i containerverdenen.
Snap er sjælen i den teknologi.
Linux-rod i forbindelse med levering af apps
Den eksisterende model for levering af apps på Linux har mange fejl. Linux-verdenen er for det meste opdelt i to lejre af app-pakning: rpm og deb. Der er også forskellige versioner af de samme distributioner, der bruger forskellige biblioteker, så det bliver en stor udfordring for app-udviklere at pakke apps til Linux.
Dermed kan app-udviklere ikke drage fordel af de nyeste biblioteker og tilbyde flere funktioner til deres brugere, hvis distributionen stadig bruger ældre biblioteker.
I de fleste tilfælde pakker open source-app-udviklere ikke deres apps til distributioner. Populære eller veletablerede apps pakkes normalt af distro-udviklerne. Nyere eller mindre populære apps pakkes enten af opstrømsudvikleren for hver distro, de ønsker at understøtte, eller de tilbydes slet ikke som en distropakke. Når der udgives en ny version af en app, tester disse udviklere appen og gør den derefter tilgængelig for distroen. Som du kan se, er der i stedet for at app-udvikleren kun skriver én app til hele platformen, som i dette tilfælde er Linux, mange mennesker, der bringer denne app ud til brugerne.
Det tilføjer mere kompleksitet.
Der er tilfælde, hvor Windows og MacOS får de nyeste versioner med det samme, da apps pakkes af de primære udviklere, hvorimod Linux-distroer kan tage et stykke tid. Det er ikke alt; nogle distroer får dem hurtigt, og andre skal vente i uger eller måneder.
Hvis det gælder kommercielle apps som Skype, Dropbox og Chrome, er det den primære udviklers opgave at pakke apps og tilbyde binære filer til forskellige distributioner. Mange apps fungerer ikke på ældre, men understøttede versioner af mange distributioner.
Med et ord er det et rod.
Selv Linux’ skaber, Linus Torvalds, er ikke tilfreds med den eksisterende model for levering af apps på Linux. Han tilbyder ikke binære filer af sine apps til Linux-platformen med henvisning til dette rod. Dirk Hohndel, vedligeholder af Subsurface (et projekt startet af Linus), forklarede: “Den nuværende situation med dusinvis af distributioner, hver med forskellige regler, hver med forskellige versioner af forskellige biblioteker, nogle med visse manglende biblioteker, hver med forskellige pakningsværktøjer og pakningsformater … det fortæller i bund og grund app-udviklere ‘gå væk, fokuser på platforme, der interesserer sig for applikationer.'”
“Applikationspakning er enormt vigtigt, men det samme er proveniens og vedligeholdelse af alle de involverede dele,” er Gunnar Hellekson, direktør for produktstyring for Red Hat Enterprise Linux, enig i.
Snap blev designet til at bringe lidt orden i denne situation. Men om det vil blive vedtaget er et helt andet spørgsmål.
Hellekson hævdede, at værktøjer som Snap ikke “på magisk vis løser interoperabilitetsproblemer mellem Linux-distributioner og faktisk flytter mere ansvar for vedligeholdelse og sikkerhed over på applikationsleverandørerne”. På den måde kan de gøre det endnu sværere at udvikle på Linux på trods af de mange fordele for brugerne.”
“Snap’s fordele hænger direkte sammen med dets ulemper … i bund og grund svarer Snap til statisk linking – på den ene side er det praktisk, på den anden side skaber det dobbeltarbejde og udfordringer med hensyn til sikkerhed (og sikkerhedsrettelser),” sagde Gerald Pfeifer, SUSE’s vicepræsident for produkter og teknologiprogrammer.
Det er dog ikke alle, der er af samme opfattelse. Brandon Philips, medstifter og teknologichef for CoreOS, fortalte os, at containere er fremtiden for apps på Linux. Men Docker-containere kan ikke bruges overalt. De har deres begrænsninger. Det, vi har brug for, er en containerlignende løsning, noget i stil med Snap.
I et andet interview fortalte den førende Linux-kerneludvikler Greg Kroah-Hartman, at Android har lavet containere “til dine applikationer i otte eller ni år nu. Hvert program kører i sit eget namespace. Den kan ikke se uden for det. Det er den måde, man er nødt til at gøre det på. Det er fremtiden for Linux og den måde, systemer fungerer på.” Han sagde, at Snap er det samme koncept, den samme idé.
Snap går på tværs af platforme
Snap’s succes afhænger i høj grad af, om det bliver vedtaget af det større open source-fællesskab. Hvad er et app-format værd, hvis ingen bruger det? Som en teknologi, der kun findes i Ubuntu, og som måske ikke engang bliver officielt understøttet af dets derivater som Linux Mint, KDE neon eller elementært OS, kan Snap stå over for en knap så succesfuld karriere.
Da Canonical annoncerede Snap, hævdede de på en pressekonference, at de har arbejdet sammen med forskellige distributioner om at tilføje understøttelse af Snap.
Canonical sagde, at Snaps er nativt tilgængelig for Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity og Xubuntu. Canonical arbejder også på at validere Snaps på CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt og Red Hat Enterprise Linux.
Canonical og SUSE er i øjeblikket ikke involveret i udviklingen omkring samarbejdet om Snaps, og faktisk ser det ud til, at dette ikke var resultatet af et åbent fællesskabsdesign og -udvikling,” Gerald Pfeifer, SUSE.
Canonical’s meddelelse om, at de arbejdede sammen med andre distributioner, tiltrak sig en del kritik fra nogle medlemmer af open source-fællesskabet. Fedora-udviklere tog ikke godt imod denne meddelelse og kritiserede Canonical med henvisning til, at der ikke var noget som helst samarbejde mellem de to projekter.
Da vi fulgte op med Canonical-stifter Mark Shuttleworth for at spørge om disse anklager, svarede han: “Vi har briefet med Red Hat desktop-teamet og er altid åbne for at arbejde sammen med alle Linux-distributioner for at muliggøre Snaps.”
Dette viste sig dog at være en nyhed for Red Hat, som er hyrde for Fedora-distributionen.
“Selv om vi samarbejder med Canonical i flere fællesskaber, blev vi lige så overraskede som alle andre, da de annoncerede vores involvering i dette særlige initiativ. Vi er åbne for flere diskussioner om dette og for at se, hvordan Linux-fællesskabet generelt ønsker at arbejde sammen,” sagde Hellekson.
SUSE-embedsmænd nedtonede også ethvert samarbejde. “Canonical og SUSE er i øjeblikket ikke involveret i udviklingen omkring samarbejdet om Snaps, og faktisk ser det ud til, at dette ikke var resultatet af et åbent fællesskabsdesign og -udvikling,” sagde Pfeifer.
Det, der tilsyneladende er sket, er, at Canonical arbejdede med nogle udviklere, måske kun en håndfuld, af andre projekter, og de hjalp med at pakke Snaps til andre distributioner.
Canonical er ikke perfekt
En del af den modstand, som Canonical kan have fået, kan være et biprodukt af den måde, som virksomheden driver forretning på.
For det første opretholder andre Linux-virksomheder, såsom Red Hat og SUSE, en meget klar adskillelse af beføjelser, når det gælder Fedora og openSUSE. Fedora og openSUSE er forholdsvis uafhængige, fællesskabsdrevne projekter, hvor beslutningerne træffes af medlemmerne af fællesskabet og ikke af de sponsorerende virksomheder.
I modsætning hertil er Ubuntu et Canonical-produkt, som også er et fællesskabsprojekt. På grund af det har Canonical i modsætning til openSUSE og Fedora direkte kontrol over Ubuntu. Vi har allerede lært det i forbindelse med ownCloud; det er virkelig svært at opretholde en balance mellem fællesskabets og virksomhedens behov; det ender ofte i en katastrofe som ownCloud.
Det rejser sig spørgsmålet om, hvordan man “arbejder” med et projekt?
Også mange føler, at der mangler gennemsigtighed med Ubuntu. Til tider har mange ledende Ubuntu-bidragydere udtrykt frustration over, at Canonical har holdt vigtige meddelelser omkring Ubuntu hemmelige, skjult selv for kernemedlemmerne. Ubuntu-medlemmer havde ingen anelse om Ubuntu til Windows eller det ulykkelige Edge-projekt.
“Vi holder ikke tingene tilbage,” svarede Red Hat-direktør Jim Whitehurst på et spørgsmål om virksomhedens tilgang til open source. “Når vi bygger ting, skjuler vi det ikke for folk for at lave en stor afsløring og sige ‘her er koden’. Det gør vi ikke. Vi arbejder i fællesskaber fra dag ét, hele tiden. Jeg tror, at vi forsøger at være rigtig gode deltagere, og jeg tror, at det kommer til udtryk.”
Oven i disse forskelle er Canonical også kendt for at lave nogle fejltrin, når det kommer til at frigive oplysninger. Dette synes i hvert fald at være tilfældet i forbindelse med annonceringen af understøttelse af Snap på tværs af distributioner; ordlyden, der irriterede Fedora-udviklere, var “Developers from multiple Linux distributions.” For at gøre det klart, så har Canonical aldrig eksplicit sagt i sin pressemeddelelse, at den arbejdede sammen med Fedora. Og baseret på de oplysninger, vi har indsamlet, var der ikke noget “officielt” engagement med Linux-distributioner som Fedora, Red Hat, SUSE eller andre.
Det sagt, opstår spørgsmålet om, hvordan man “arbejder” med et projekt? Hvis en udvikler, der arbejder på en app, samarbejder med en Ubuntu-udvikler, en Fedora-udvikler og en openSUSE-udvikler for at bringe appen til disse platforme, ville det så være forkert at sige, at udvikleren arbejdede med flere distributioner for at bringe appen til dem? Eller skal udvikleren have et officielt samarbejde med projektlederne for disse distributioner for at kunne komme med en sådan udtalelse? Det er trods alt et distribueret open source-fællesskab.
Hvor er Snap?
Det større spørgsmål er, om Snap vil blive officielt adopteret af andre distroer? Det er her, at tingene bliver lidt komplicerede. Det bliver et teknologisk og politisk spørgsmål.
Først og fremmest er Snap ikke den eneste løsning, der findes. Der er mange projekter, der har forsøgt at tilbyde distro agnostiske pakkeøkosystemer til Linux-økosystemerne. Men det kan være svært at finde konsensus inden for Linux-distro-verdenen. Der er AppImage og Flatpak, som tilbyder egnede alternativer til Snap; disse projekter har eksisteret meget længere end Snap.
Så hvorfor har Canonical ikke vedtaget disse løsninger i stedet for at starte Click eller Snap?
“Vi kiggede på det og fandt ud af, at AppImage fungerer perfekt til “leaf-node”-desktopapplikationer,” sagde Shuttleworth. En leaf-node-applikation er en applikation, der ikke har brug for at integrere med andre apps. Snap blev mere designet til at pakke apps med afhængigheder og relaterede applikationer. “Snaps har en række muligheder for at beskrive disse forbindelser – grænseflader, stik og slots samt delte filer og så videre.”
Dertil kommer, at Shuttleworth fortalte, at Snap blev designet til højere sikkerhedsniveauer sammenlignet med AppImage, dels fordi holdet, der arbejdede på mobiltelefonen, var fokuseret på sikkerhed og effektivitet, og dels fordi Snap bruger nyere kernefunktioner.
Flatpak blev angiveligt offer for rivaliseringen mellem Canonical og Red Hat, da det blev udviklet af Fedora-folk. Da jeg spurgte, afviste Shuttleworth det som et projekt, der blev udviklet af en enkelt udvikler.
Det forklarer, hvorfor Canonical gik videre med Snap.
Nu, vil andre distroer adoptere det? Fedora-udviklerne har allerede erklæret, at de ikke vil bruge Snap. En Fedora-udvikler skrev på mailinglisten: “Vi har naturligvis ingen planer om at indføre Snappy i Fedora, og faktisk arbejder flere Fedora-udviklere på en konkurrerende løsning, Flatpak.”
Red Hat har tidligere taget et Canonical-projekt til systeminitialisering kaldet Upstart til sig. Hellekson sagde: “Det er meget tidlige dage for alle disse pakkeringsbestræbelser, og vi ser frem til at arbejde sammen med alle de relaterede fællesskaber for at gøre livet så nemt som muligt for Linux-brugere.”
Bortset fra rivaliseringen mellem Red Hat og Canonical er der nogle tekniske problemer, som kan afholde andre projekter fra at samarbejde om Snap. En af disse grunde er, at udviklere skal underskrive en CLA (Contributor License Agreement), hvis de bidrager til Snap-projektet. Michael Hall, en Canonical-udvikler, sagde, at en “CLA er nødvendig, når en udvikler ønsker at bidrage til selve Snap-projektet. Der er ikke behov for en CLA for at oprette eller distribuere Snaps af applikationer.”
CLA’er giver Canonical mulighed for at ændre projektets licens. Det er en fordel for Canonical, da de kan give en ny licens til et projekt, så det kan bruges med ikke-fri eller inkompatible licenser. Udviklere bryder sig normalt ikke om CLA’er.
Frank Karlitschek fra Nextcloud fortalte os, at de opsiger CLA’er fra Nextcloud, da han mente, at CLA’er ikke har et særligt godt ry i open source-fællesskabet.
Da vi spurgte Red Hat, om CLA’er ville dæmpe samarbejdet omkring Snap, svarede Hellekson: “Contributor License Agreements gør det vanskeligt for os at deltage. Vi mener, at ligefrem open source-licensering er en bedre og mere inkluderende tilgang.”
Svaret fra SUSE var nogenlunde det samme. Pfeifer sagde: “SUSE-ingeniører og -medarbejdere fortsætter med at bidrage til et væld af open source-projekter, både i virksomhedens tid og i vores egen tid, og hvor det er nødvendigt, har vi underskrevet CLA’er. Men uanset hvor og hvornår vi igangsætter eller påvirker projekter, forsøger vi at holde os fra CLA’er. Vi bryder os generelt ikke om CLA’er, der tildeler en ophavsret, som gør det muligt for organisationer at genlicensere open source-kode ved hjælp af en ikke-open source-licens.”
Da vi spurgte Shuttleworth, om han ville overveje at droppe CLA’er fra Snap for at få bredere støtte fra andre distro’er, startede han med at forklare, hvorfor CLA’er er gode, men sagde så også, at “hvis det ville gøre en forskel, så ja, så ville vi finde en måde at droppe det på.”
Og så var der én?
Med tiden kan modenhed, popularitet og teknisk overlegenhed af den ene frem for den anden måske efterlade os med én løsning. Det har vi set før med Upstart og systemd, hvor systemd viste sig som en overlegen teknologi og blev standard i alle tre førende Linux-distroer: Ubuntu, RHEL og SUSE.
I begge tilfælde befinder begge teknologier sig på et meget tidligt udviklingsstadie, og det er svært at sige, hvilket projekt der vil få succes. Det er dog ret klart, at Linux i den container-centrerede verden har brug for en ny appleveringsmekanisme.
Mange virksomheder og fællesskaber har udtrykt støtte til løsninger som Snap. Samsung og Dell sluttede sig til Canonical i presseopkaldet og erklærede, at der er behov for en sådan løsning. På desktop-området har projekter som LibreOffice og Firefox allerede udtrykt støtte til Snap.
Tiden vil vise, om Snap vil blive indført uden for Ubuntu eller ej. Uanset hvad fremtiden bringer for Snap, bør vi give Canonical behørig kredit for at have skubbet til grænsen og tvunget resten af Linux-fællesskabet til endelig at fokusere på at løse et problem, som vi enten var blevet så komfortable med, eller som vi måske aldrig havde haft motivation til at løse.
CoreOS og Red Hat er sponsorer af The New Stack.