Muutama viikko sitten Canonical ilmoitti jakelurajat ylittävästä tuesta Snap-sovellusten jakelumekanismille, joka voisi tukea mobiili-, työpöytä- ja palvelinpohjaisia sovelluksia. Ilmoitus herätti närää Linux-yhteisössä, joka ei nähnyt juurikaan näyttöä siitä, että mikään muu Linux-jakelu tukisi Snapia.
Snap on Canonicalin yritys jalostaa sovellusten paketointi- ja jakelumekanismia Linux-alustalla. Snapin alkuperä juontaa juurensa Clickistä, ratkaisusta, jonka Canonical loi mobiilialustaansa varten vuonna 2014 käsittelemään sovellusten toimittamisen monimutkaisuutta Ubuntu-puhelinten ja -tablettien käyttäjille, ekosysteemiin, joka eroaa huomattavasti pöytätietokoneista ja palvelimista. Lisäksi mobiilikäyttöön tarvittiin myös sovellusten rajaaminen ja hiekkalaatikko, jotta ne eivät vaarantaisi koko alustaa.
Clickin avulla kehittäjät pystyivät niputtamaan kaikki riippuvuudet yhteen sovelluspakettiin, joten käyttäjien ja kehittäjien ei tarvinnut huolehtia ristiriitaisista järjestelmistä ja sovelluskirjastoista. Sen ansiosta kehittäjät pystyivät käyttämään uusimpia kirjastoja sovelluksissaan ja tarjoamaan uusia ominaisuuksia, kun ne oli irrotettu järjestelmään asennetuista kirjastoista.
Mobiilin lisäksi palvelimiin ja IoT:hen
Click kehittyi Snapiksi, ja Canonical laajensi sen käyttömahdollisuuksia palvelimiin, pilvipalveluihin, esineiden internetiin (Internet of Things, IoT) ja työpöytätiloihin. Ubuntu 16.04:n julkaisun myötä huhtikuussa Canonical toi Snapin virallisesti Ubuntun työpöydälle.
Canonical kehittää myös Snappy Ubuntu Corea, pientä Linux-pohjaista käyttöjärjestelmää laajamittaisiin pilvipalvelinkonttien käyttöönottoihin, IoT-laitteisiin ja paljon muuhun sekä kaikkeen, mikä tarvitsee siirtymäaikaisia päivityksiä ja pientä jalanjälkeä. Snappy Ubuntu Core toimii suurin piirtein samalla tavalla kuin Googlen Chrome OS ja CoreOS, joissa se tarjoaa siirtymäkauden kuvapohjaisia päivityksiä järjestelmälle ja sovelluksille, jotka voidaan palauttaa. Samalla se tarjoaa konttimaailmassa tunnettua rajallisuutta.
Snap on tuon tekniikan sielu.
Sovellusten toimituksen Linux-sotku
Linuxin nykyisessä sovellusten toimitusmallissa on monia puutteita. Linux-maailma on enimmäkseen jakautunut kahteen sovelluspakkausleiriin: rpm ja deb. Lisäksi samoista jakeluista on olemassa eri versioita, jotka käyttävät eri kirjastoja, joten sovelluskehittäjien on melko haastavaa paketoida sovelluksia Linuxille.
Tuloksena sovelluskehittäjät eivät voi hyödyntää uusimpia kirjastoja ja tarjota enemmän ominaisuuksia käyttäjilleen, jos jakelu käyttää vielä vanhempia kirjastoja.
Useimmissa tapauksissa avoimen lähdekoodin sovelluskehittäjät eivät paketoi sovelluksiaan jakeluille. Suosittuja tai pitkään käytössä olleita sovelluksia paketoivat yleensä jakelukehittäjät. Uudemmat tai vähemmän suositut paketoidaan joko esivirran toimesta jokaista distroa varten, jota ne haluavat tukea, tai niitä ei tarjota distropakettina lainkaan. Kun sovelluksesta julkaistaan uusi versio, nämä kehittäjät testaavat sovelluksen ja asettavat sen sitten jakelupaketin saataville. Kuten näet, sen sijaan, että sovelluskehittäjä kirjoittaisi vain yhden sovelluksen koko alustalle, joka tässä tapauksessa on Linux, on monia ihmisiä, jotka tuovat kyseisen sovelluksen käyttäjille.
Se lisää monimutkaisuutta.
On tapauksia, joissa Windows- ja MacOS-käyttöjärjestelmät saavat uusimmat versiot heti, koska sovellukset paketoidaan ensisijaisten kehittäjien toimesta, kun taas Linux-distrojen kohdalla voi kestää jonkin aikaa. Tämä ei ole kaikki; jotkut distrot saavat ne nopeasti, ja jotkut joutuvat odottamaan viikkoja tai kuukausia.
Kaupallisten sovellusten, kuten Skypen, Dropboxin ja Chromen kohdalla ensisijainen kehittäjä on vastuussa sovellusten paketoinnista ja binääritiedostojen tarjoamisesta eri jakeluille. Monet sovellukset eivät toimi monien jakeluiden vanhemmissa, mutta tuetuissa versioissa.
Sanalla sanoen, se on sekasotku.
Jopa Linuxin luoja Linus Torvalds ei ole tyytyväinen Linuxin nykyiseen sovellusten toimitusmalliin. Hän ei tarjoa sovellustensa binäärejä Linux-alustalle vedoten tähän sotkuun. Dirk Hohndel, Subsurface-projektin (Linuksen aloittama projekti) ylläpitäjä, selitti: ”Nykytilanne, jossa on kymmeniä jakeluja, joilla kullakin on erilaiset säännöt, joilla kullakin on erilaiset versiot erilaisista kirjastoista, joillakin tietyt kirjastot puuttuvat, joilla kullakin on erilaiset paketointityökalut ja pakkausmuodot… se periaatteessa kertoo sovelluskehittäjille: ’Menkää pois, keskittykää alustoihin, jotka välittävät sovelluksista’.'”
”Sovellusten pakkaaminen on valtavan tärkeää, mutta niin on myös kaikkien asiaan liittyvien osien alkuperä ja ylläpito”, Gunnar Hellekson, Red Hat Enterprise Linuxin tuotehallintajohtaja, on samaa mieltä.
Snap on suunniteltu tuomaan järjestystä tähän tilanteeseen. Mutta se, otetaanko se käyttöön, on kokonaan toinen kysymys.
Hellekson väitti, että Snapin kaltaiset työkalut eivät ”ratkaise maagisesti Linux-jakeluiden välisiä yhteentoimivuusongelmia, vaan ne itse asiassa siirtävät enemmän vastuuta ylläpidosta ja tietoturvasta sovellusten toimittajille”. Näin ne voivat tehdä Linux-kehittämisestä entistäkin vaikeampaa huolimatta monista käyttäjille koituvista eduista.”
”Snapin edut liittyvät suoraan sen haittoihin … pohjimmiltaan Snap vastaa staattista linkitystä – se on toisaalta kätevä, toisaalta luo päällekkäisyyksiä ja haasteita tietoturvan (ja tietoturvakorjausten) suhteen”, sanoi SUSEn tuotteista ja teknologiaohjelmista vastaava varapresidentti Gerald Pfeifer.
Kaikki eivät kuitenkaan ole samaa mieltä. CoreOS:n toinen perustaja ja teknologiajohtaja Brandon Philips kertoi, että kontit ovat sovellusten tulevaisuus Linuxissa. Docker-kontteja ei kuitenkaan voi käyttää kaikkialla. Niillä on rajoituksensa. Tarvitsemme konttien kaltaisen ratkaisun, jotain Snapin kaltaista.
Johtava Linux-ytimen kehittäjä Greg Kroah-Hartman kertoi toisessa haastattelussa, että Android on tehnyt kontteja ”sovelluksia varten jo kahdeksan tai yhdeksän vuotta. Jokainen sovellus toimii omassa nimiavaruudessaan. Se ei näe sen ulkopuolelle. Se on tapa, jolla se on tehtävä. Se on Linuxin tulevaisuus ja tapa, jolla järjestelmät toimivat.” Hänen mukaansa Snap on sama konsepti, sama ajatus.
Snap Goes Cross Platform
Snapin menestys riippuu paljolti siitä, miten laajempi avoimen lähdekoodin yhteisö hyväksyy sen. Mitä hyötyä on sovellusformaatista, jos kukaan ei käytä sitä? Ubuntu-only-tekniikkana, jota sen johdannaiset, kuten Linux Mint, KDE neon tai elementary OS, eivät välttämättä edes tue virallisesti, Snapilla voi olla edessään ei kovin menestyksekäs ura.
Kun Canonical julkisti Snapin, se väitti lehdistötilaisuudessa, että se on työskennellyt eri jakeluiden kanssa tuen lisäämiseksi Snapille.
Canonical sanoi, että Snapit ovat natiivisti saatavilla Archille, Debianille, Fedoralle, Kubuntulle, Lubuntulle, Ubuntu GNOME:lle, Ubuntu Kylinille, Ubuntu MATE:lle, Ubuntu Unitylle ja Xubuntulle. Canonical työskentelee myös Snapsin validoimiseksi CentOS-, Elementary-, Gentoo-, Mint-, OpenSUSE-, OpenWrt- ja Red Hat Enterprise Linux -käyttöjärjestelmissä.
Canonical ja SUSE eivät tällä hetkellä osallistu Snapsin yhteistyön ympärillä tapahtuvaan kehitystyöhön, ja itse asiassa näyttää siltä, että tämä ei ole tulosta avoimen yhteisön suunnittelusta ja tuotekehityksestä”, Gerald Pfeifer, SUSE.
Canonicalin ilmoitus yhteistyöstä muiden jakeluiden kanssa herätti kritiikkiä joissakin avoimen lähdekoodin yhteisön jäsenissä. Fedoran kehittäjät eivät ottaneet ilmoitusta suopeasti vastaan ja kritisoivat Canonicalia todeten, että näiden kahden projektin välillä ei ollut minkäänlaista yhteistyötä.
Kun otimme yhteyttä Canonicalin perustajaan Mark Shuttleworthiin kysyäksemme näistä syytöksistä, hän vastasi: ”Teimme tiedotustilaisuuden Red Hatin työpöytäryhmän kanssa ja olemme aina avoimia työskentelemään kaikkien Linux-jakeluiden kanssa Snapsin mahdollistamiseksi.”
Tämä osoittautui kuitenkin uutiseksi Red Hatille, joka paimentaa Fedora-jakelua.
”Vaikka työskentelemme Canonicalin kanssa useissa yhteisöissä, olimme yhtä yllättyneitä kuin kaikki muutkin, kun he ilmoittivat osallistumisestamme juuri tähän aloitteeseen. Olemme avoimia lisäkeskustelulle tästä ja näkemään, miten Linux-yhteisö ylipäätään haluaa tehdä yhteistyötä”, Hellekson sanoi.
SUSE:n edustajat vähättelivät myös mahdollista yhteistyötä. ”Canonical ja SUSE eivät tällä hetkellä osallistu Snaps-yhteistyön ympärillä tapahtuvaan kehitystyöhön, ja itse asiassa näyttää siltä, että tämä ei ollut avoimen yhteisön suunnittelun ja kehityksen tulos”, Pfeifer sanoi.
Mitä näytti tapahtuneen, on se, että Canonical työskenteli joidenkin kehittäjien, ehkä vain kourallisen, muiden projektien kanssa, ja he auttoivat Snapsin paketoimisessa muihin jakeluihin.
Canonical ei ole täydellinen
Osittain Canonicalin mahdollisesti saama vastareaktio voi olla sivutuote sen tavasta, jolla se harjoittaa liiketoimintaa.
Yksi, muut Linux-yhtiöt, kuten Red Hat ja SUSE, ylläpitävät hyvin selkeää vallanjakoa Fedoran ja openSUSEn suhteen. Fedora ja openSUSE ovat melko itsenäisiä, yhteisölähtöisiä projekteja, joissa päätökset tekevät yhteisön jäsenet eivätkä sponsoroivat yritykset.
Ubuntu sen sijaan on Canonicalin tuote, joka sattuu olemaan myös yhteisöprojekti. Tästä johtuen toisin kuin openSUSE ja Fedora, Canonicalilla on suora määräysvalta Ubuntuun. Olemme jo oppineet ownCloudin tapauksessa; on todella vaikeaa säilyttää tasapaino yhteisön ja yrityksen tarpeiden välillä; se päättyy usein ownCloudin kaltaiseen katastrofiin.
Kysymykseksi nousee, miten projektin kanssa ”työskennellään”?
Myös monet kokevat, että Ubuntun kohdalla puuttuu avoimuus. Ajoittain monet johtavat Ubuntun avustajat ovat ilmaisseet turhautuneisuutensa, kun Canonical on pitänyt Ubuntuun liittyviä tärkeitä ilmoituksia salassa, piilossa jopa ydinjäseniltä. Ubuntun jäsenillä ei ollut aavistustakaan Ubuntu for Windowsista tai epäonnisesti päättyneestä Edge-projektista.
”Emme pidä asioita salassa”, Red Hatin toimitusjohtaja Jim Whitehurst vastasi kysymykseen yhtiön lähestymistavasta avoimeen lähdekoodiin. ”Kun rakennamme asioita, emme piilottele niitä ihmisiltä tekemällä suurta paljastusta ja sanomalla ’tässä on koodi’. Emme tee niin. Työskentelemme yhteisöissä alusta alkaen, koko ajan. Uskon, että yritämme olla todella hyviä osallistujia, ja uskon, että se näkyy.”
Näiden erojen lisäksi Canonical on myös tunnettu siitä, että se on tehnyt virheitä tietojen julkaisemisessa. Näin näyttää varmasti olevan Snapin jakelurajat ylittävän tuen ilmoittamisessa; Fedora-kehittäjiä ärsyttänyt sanamuoto oli ”Developers from multiple Linux distributions”. Selvyyden vuoksi mainittakoon, että Canonical ei koskaan nimenomaisesti ilmoittanut lehdistötiedotteessaan, että se työskenteli Fedoran kanssa. Ja keräämiemme tietojen perusteella ei ollut mitään ”virallista” sitoutumista Linux-jakeluiden, kuten Fedoran, Red Hatin, SUSEn tai muiden kanssa.
Tämän sanottuaan herää kysymys, miten projektin kanssa ”työskennellään”? Jos sovelluksen parissa työskentelevä kehittäjä tekee yhteistyötä Ubuntu-kehittäjän, Fedora-kehittäjän ja openSUSE-kehittäjän kanssa tuodakseen sovelluksen näille alustoille, olisiko väärin sanoa, että kehittäjä työskenteli useiden jakeluiden kanssa tuodakseen sovelluksen niille? Vai tarvitseeko kehittäjän olla virallisesti tekemisissä näiden jakeluiden projektipäälliköiden kanssa voidakseen antaa tällaisen lausunnon? Kyseessä on kuitenkin hajautettu, avoimen lähdekoodin yhteisö.
Mihin Snap jää?
Suurempi kysymys on, otetaanko Snap virallisesti käyttöön muissa distroissa? Tässä kohtaa asiat muuttuvat hieman monimutkaisiksi. Siitä tulee teknologinen ja poliittinen kysymys.
Aluksi Snap ei ole ainoa ratkaisu, joka on olemassa. On monia projekteja, jotka yrittivät tarjota distro-agnostisia pakkausekosysteemejä Linux-ekosysteemeihin. Mutta voi olla vaikeaa löytää yhteisymmärrystä Linux-jakelumaailman sisällä. On olemassa AppImage ja Flatpak, jotka tarjoavat sopivia vaihtoehtoja Snapille; nämä projektit ovat olleet olemassa paljon pidempään kuin Snap.
Miksi Canonical ei siis ottanut näitä ratkaisuja käyttöön sen sijaan, että olisi aloittanut Clickin tai Snapin?
”Katsoimme asiaa ja huomasimme, että AppImage toimii täydellisesti ’leaf-node’ -työpöytäsovelluksille”, Shuttleworth sanoi. Leaf-node-sovellus on sovellus, jonka ei tarvitse integroitua mihinkään muuhun sovellukseen. Snap suunniteltiin enemmänkin pakkaamaan sovelluksia, joilla on riippuvuuksia ja niihin liittyviä sovelluksia. ”Snapissa on erilaisia ominaisuuksia näiden yhteyksien kuvaamiseen – rajapintoja, pistokkeita ja aukkoja sekä jaettuja tiedostoja ja niin edelleen.”
Tämän lisäksi Shuttleworth kertoi, että Snap suunniteltiin korkeammalle tietoturvatasolle AppImageen verrattuna, osittain siksi, että kännykän parissa työskentelevä tiimi keskittyi tietoturvaan ja tehokkuuteen, ja osittain siksi, että Snapissa käytetään uudempia kernel-ominaisuuksia.”
Flatpakin väitettiin joutuneen Canonicalin ja Red Hatin välisen kilpailun uhriksi, kun Fedoran väki kehitti sitä. Kun kysyin, Shuttleworth hylkäsi sen yksittäisen kehittäjän kehittämänä projektina.
Tämä selittää, miksi Canonical meni Snapin kanssa eteenpäin.
Nyt, ottavatko muut distrot sen käyttöön? Fedoran kehittäjät ovat jo ilmoittaneet, että he eivät tule käyttämään Snapia. Eräs Fedoran kehittäjä kirjoitti postituslistalla: ”Meillä ei tietenkään ole mitään suunnitelmia ottaa Snappya käyttöön Fedorassa, ja itse asiassa useat Fedoran kehittäjät työskentelevät kilpailevan ratkaisun, Flatpakin, parissa.”
Red Hat otti aiemmin käyttöön Canonicalin projektin järjestelmän alustukseen nimeltä Upstart. Hellekson sanoi: ”Nämä ovat hyvin varhaisia päiviä kaikille näille paketointipyrkimyksille, ja odotamme innolla yhteistyötä kaikkien asiaan liittyvien yhteisöjen kanssa, jotta Linux-käyttäjien elämä olisi mahdollisimman helppoa.”
Red Hatin ja Canonicalin välisen kilpailun lisäksi on joitakin teknisiä ongelmia, jotka saattavat estää muita projekteja tekemästä yhteistyötä Snapin kanssa. Yksi tällainen syy on se, että kehittäjien on allekirjoitettava CLA (Contributor License Agreement), jos he osallistuvat Snap-projektiin. Michael Hall, Canonicalin kehittäjä, sanoi, että ”CLA:ta tarvitaan, kun kehittäjä haluaa osallistua itse Snap-projektiin. Sovellusten Snapien luomiseen tai jakeluun ei tarvita CLA:ta.”
CLA:n avulla Canonical voi muuttaa projektin lisenssiä. Tästä on hyötyä Canonicalille, sillä he voivat lisensoida projektin uudelleen, jolloin sitä voidaan käyttää muiden kuin vapaiden tai yhteensopimattomien lisenssien kanssa. Kehittäjät eivät yleensä pidä CLA:ista.
Frank Karlitschek Nextcloudista kertoi, että se lopettaa CLA:t Nextcloudista, koska hänen mielestään CLA:illa ei ole kovin hyvää mainetta avoimen lähdekoodin yhteisössä.
Kun kysyimme Red Hatilta, heikentäisivätkö CLA:t Snapin ympärillä tehtävää yhteistyötä, Hellekson sanoi: ”Contributor License Agreements tosiaankin hankaloittavat meidän osallistumistamme. Uskomme, että suoraviivainen, avoimen lähdekoodin lisensointi on parempi ja osallistavampi lähestymistapa.”
SUSEn vastaus oli pitkälti sama. Pfeifer sanoi: ”SUSEn insinöörit ja henkilökunta osallistuvat edelleen lukuisiin avoimen lähdekoodin projekteihin sekä yrityksen omalla että omalla ajalla, ja tarvittaessa olemme allekirjoittaneet CLA-sopimuksia. Pyrimme kuitenkin aina ja kaikkialla, missä käynnistämme hankkeita tai vaikutamme niihin, pysymään erossa CLA-sopimuksista. Emme yleensä pidä CLA:ista, jotka antavat tekijänoikeuden, joka antaa organisaatioille mahdollisuuden lisensoida avoimen lähdekoodin uudelleen käyttämällä muuta kuin avoimen lähdekoodin lisenssiä.”
Kun kysyimme Shuttleworthilta, harkitsisiko hän CLA:iden pudottamista Snapista saadakseen laajemman tuen muilta jakelupalveluilta, hän aloitti selittämällä, miksi CLA:t ovat hyvä asia, mutta sitten hän sanoi myös, että ”jos se vaikuttaisi asiaan, niin kyllä, löytäisimme tavan pudottaa ne.”.”
And Then There was One?
Ajan mittaan kypsyys, suosio ja yhden teknisen paremmuus toiseen nähden saattaa jättää meille yhden ratkaisun. Olemme nähneet tämän aiemmin Upstartin ja systemd:n kohdalla, jossa systemd nousi ylivoimaiseksi tekniikaksi ja siitä tuli oletus kaikissa kolmessa johtavassa Linux-distrossa: Ubuntu, RHEL ja SUSE.
Kummassakin tapauksessa molemmat teknologiat ovat hyvin varhaisessa kehitysvaiheessa, ja on vaikea sanoa, kumpi hanke menestyy. On kuitenkin melko selvää, että konttipohjaisessa maailmassa Linux tarvitsee uuden sovellusten jakelumekanismin.
Monet yritykset ja yhteisöt ovat ilmaisseet tukensa Snapin kaltaisille ratkaisuille. Samsung ja Dell liittyivät Canonicalin lehdistöpuheluun ja totesivat tällaisen ratkaisun tarpeellisuuden. Työpöytäpuolella LibreOfficen ja Firefoxin kaltaiset projektit ovat jo ilmaisseet tukensa Snapille.
Aika näyttää, otetaanko Snap käyttöön Ubuntun ulkopuolella vai ei. Mitä tahansa Snapin tulevaisuus tuo tullessaan, meidän pitäisi antaa Canonicalille kunnia siitä, että se on työntänyt kuorta ja pakottanut muun Linux-yhteisön keskittymään vihdoinkin ratkaisemaan ongelman, jonka kanssa olimme joko tottuneet tai jolla ei ehkä koskaan ollut motivaatiota ratkaista sitä.
CoreOS ja Red Hat ovat The New Stack -lehden sponsoreita.