Hvorfor Canonical ser på Snap-økosystemet som en overbevisende distribusjons-agnostisk løsning

Hvordan installere Microsoft Visual Studio Code (VS Code) på Ubuntu Microsofts Visual Studio Code Editor vil nå kjøres på alle Linux-distribusjoner som støtter Snap. Følg disse trinnene for å installere VS-kode på Ubuntu.

I omtrent to tiår har Linux-distribusjoner vært det første valget for servere. Maskinvarestøtte for Linux på skrivebordet har historisk sett vært en heftelse for utbredt adopsjon, selv om støtte for moderne maskinvare på moderne distribusjoner har kommet slik at mesteparten av maskinvaren blir oppdaget og konfigurert riktig ved installasjon.

Med disse fremskrittene innen maskinvarestøtte er den siste viktige utfordringen brukere står overfor når de bytter fra Windows eller Mac til en Linux-distribusjon, appdistribusjon og installasjon. Mens distribusjonslager er nyttige for mest åpen kildekode-programvare, låser utgivelsesmodellen for distribusjoner som Ubuntu eller Fedora brukere i en større versjon for programmer i løpet av en bestemt utgivelse.

Som et eksempel ble LibreOffice 6.2 utgitt 7. februar 2019, selv om denne nye større versjonen bare ble levert til Fedora-brukere med utgivelsen av Fedora 30 30. april 2019, mens brukere av Fedora 29 fortsatte å motta sikkerhetsrettelser for LibreOffice 6.1 . Bruken av selvstendige applikasjoner, for eksempel Snaps i Ubuntu eller Flatpak i Fedora, gjør at applikasjoner og deres avhengigheter kan oppdateres utenfor båndet.

Hvordan velge mellom Windows, macOS og Linux (gratis PDF)

På samme måte er pakking av proprietære applikasjoner (f.eks. Skype) som fungerer pålitelig på tvers av distribusjoner en utfordring for programvareutviklere. Snaps og Flatpak er populære løsninger for programvareleverandører som støtter et bredt utvalg av distribusjoner uten behov for å kompilere applikasjoner individuelt for hver distribusjon.

Adopsjon av disse selvforsynte applikasjonspakkene er ikke uten forringere. På grunn av forskjeller i hvordan de samhandler med det underliggende systemet, er visse konfigurasjonsoppgaver forskjellige mellom Snaps eller Flatpaks enn for direkte installerte applikasjoner. På samme måte var de første forpliktelsene for Snap- og Flatpak-formatene med flere dager - mens formatene ble utviklet i hovedsak parallelt, har eksistensen av to "universelle" pakkeformater ført til uenighet om konkurrerende standarder.

TechRepublics James Sanders intervjuet Martin Wimpress, ingeniørsjef for Snapcraft på Canonical, om Ubuntu langsiktige planer for Snaps, dets vedtak og støtte i andre Linux-distribusjoner, Canonicals posisjon som operatør av Snap Store, og fordelene Snaps gir over Flatpak.

(Dette intervjuet ble lett redigert for klarhet.)

Hva er de praktiske fordelene med Snaps?

TechRepublic: Det er praktisk talt to konkurrerende standarder for tverrplattform-applikasjonsemballasje - tre, hvis du teller AppImage. Hva er den praktiske fordelen som Canonicals Snap-format gir i forhold til Flatpak eller AppImage?

Martin Wimpress: Hvis du ser på de innledende forpliktelsene til begge disse prosjektene, har Snaps en avstamning tilbake til Click-pakker, som opprinnelig ble utviklet for Ubuntu Phone. Snap-prosjektet utviklet seg ut fra det man hadde lært ved å gjøre telefonene, med tanke på å løse problemer i IoT. Selv om teknisk sett har snapd- og xdg-apper - og følgelig Flatpak - ser ut som de dukket opp på samme tid, kan Snaps spore avstamningen tilbake til Click-prosjektet fra flere år tidligere.

Hvis vi ser på Flatpak spesifikt, kan vi sannsynligvis inkludere AppImage i de fleste av disse sammenligningene. Noen av likhetene er at Snaps er selvstendige programvarepakker, noe som Flatpak og AppImage også prøver å være. Jeg tror at Flatpak oppnår det bedre enn AppImage. Jeg tror AppImage fortsatt gjør noen antagelser om hva som er installert i vertsoperativsystemet. Det pakker ikke alt inne i AppImage.

Tilsvarende fungerer Snaps, Flatpak og AppImage på tvers av alle de store Linux-distribusjonene uten endring. Vi har ikke alle kommet til denne løsningen ved en tilfeldighet. Vi har helt klart, uavhengig, alle innsett at dette er et problem som vi må løse for å oppmuntre programvareleverandører til å publisere applikasjonene sine på Linux, fordi Linux er en veldig bred plattform å målrette mot. Hvis du kan senke hindrene for å få programvaren foran brukere på Linux, er det en god ting. Og vi har alle som mål å gjøre det samme der.

Der Snaps skiller seg ut fra Flatpak og AppImage er, med en Snap, kan du målrette deg mot hvilken som helst applikasjonsklasse - være et skrivebordsapplikasjon, eller noe for server og sky, eller noe for IoT.

Vi ser absolutt mye suksess rundt Snaps på skrivebordet, med mange store ISV-er som publiserer overskriftsprogrammet deres som Snaps, og jeg er veldig stolt over at vi har tiltrukket oss slike som Spotify, Skype, Slack og Visual Studio Kode til snaps.

Så har du flere serverorienterte utgivere som Nextcloud og Plex som også publiserer Snaps. Alle de store offentlige skyplattformene publiserer alle Snaps av sitt essensielle verktøy også, som brukes på daglig basis, i stor skala, for deres drift og for sine kunder.

Så har vi IoT-historien. Dette er interessant, fordi IoT-historien for Snaps virkelig er opprinnelsen til det Snaps ble designet for å løse. I takt med Ubuntu Core — vår Ubuntu-versjon som er spesielt designet for å gjøre det mulig for enhetsprodusenter å raskt bringe IoT-enheter på markedet, og opprettholde sikkerhetsprofilen til disse enhetene på lang sikt, noe som har vært en kamp for den typen enhetsprodusenter og leverandører for å overvinne i fortiden. De følte at de har måttet gjøre mye av det tunge løftet for seg selv for å opprettholde sikkerhetsprofilen til disse enhetene.

Så det er ett område der Snaps er forskjellige. Hvis du ser på noe som Nextcloud, har Snap mange bevegelige deler inni seg. Som bruker er det et enkelt klikk for å installere gjennom det grafiske brukergrensesnittet, eller det er snapinstall nextcloud på kommandolinjen.

Som forbruker av den snapen trenger du ikke å ha noen forståelse for det faktum at det er en MySQL-server som har fått sitt skjema satt opp for deg. Det er en Redis-server der, load balancer, PHP, og en hel haug med andre ting som også gjør at Snap kan fungere.

Så en av fordelene er at snap installere navnet på applikasjonen, du kan gjøre det for enkle apper og veldig kompliserte apper, og det gjør virkelig sluttbrukerdokumentasjonen veldig enkel.

Det er flott for utgivere fordi det betyr at tilgjengeligheten til programvaren deres har en liten inngangsbarriere for brukerne som vil bruke den. Nå, for noen Linux-brukere, vil de være ganske glade, mer enn glade for å spinne opp en Docker-beholder eller LXD-beholder eller en virtuell maskin og legge alle de tingene inni den. Men ikke alle Linux-brukere er sysadmins om dagen. Så vi lar en hel klasse brukere få tilgang til kompleks programvare på en lettbrukbar måte.

TechRepublic: Vil du karakterisere Snap som enklere enn Docker?

Martin Wimpress: Snap er ikke nødvendigvis en erstatning for Docker. Snaps kan gjøre noen av de samme tingene som Docker kan gjøre. Så må du vurdere at du kan klikke på å installere Docker, Kata Containers og LXD. Snaps bruker container-primitiver - de samme container-primitivene som Docker og LXD og andre ting bruker - så de deler noen av disse egenskapene. Men jeg vil ikke si at Snap konkurrerer med Docker eller erstatter Docker.

Er det lettere for en sluttbruker som aldri har brukt Docker før? Jeg vil si det, ja.

Hvem har redaksjonell kontroll over Snap-butikken og plattformen?

TechRepublic: Med Flatpak er du egentlig ikke knyttet til Flathub. Hvorfor ville Canonicals tilnærming til å ha en sentralisert Snap-butikk være en fordel?

Martin Wimpress: Det er flere årsaker, og disse grunnene er som et resultat av å ha levert programvare til Linux- og Ubuntu-brukere i mange år, og lære av de tingene vi har gjort riktig, og også de tingene vi har gjort galt .

Den sentrale app-butikken er noe folk generelt er komfortable med nå. Telefonen i lommen har en sentral app-butikk bak seg. Hvis du kjøper en datamaskin som er forhåndsinstallert med Windows eller Mac OS, er det en sentral app-butikk bak det. Ja, det er mekanismer som du kan installere programvaren din på andre måter, men det er en sentral app-butikk tilgjengelig for deg der. Det vi har lært er oppdagelse er veldig viktig for utgivere og også sluttbrukere.

Et av fenomenene som vi virkelig var interessert i å oppdage - vi oppdaterer de aktuelle applikasjonene i Snap-butikken på en vanlig kadens. Hver gang vi introduserer en applikasjon i "Editor's Picks", som presenteres gjennom skrivebordets programvaresenter, har de en enorm topp i installasjoner og adopsjon. Det vi har lært her, er at sluttbrukere ... aktivt åpner programvaresenteret, og bruker det som et middel til å finne nye og interessante applikasjoner.

Nå gjør vi litt mer der for å bedre sammenligne den erfaringen for bedre å sette søkelyset på de gode tingene som finnes i butikken, slik at folk kan finne tingene de er interessert i med en større letthet. Det vi lærte av PPA-er, er at det er en dårlig brukeropplevelse, det å måtte koble til en tredjeparts ting for deretter å installere programvare.

Hvis du bare kan få tilgang til app store - Linux app store i dette tilfellet - og installere programvaren du ønsker, er det en veldig god brukeropplevelse for brukeren. det betyr at ISV-ene, det være seg store organisasjoner eller uavhengige utviklere, som er helt ansvarlige for programvarens leveringssyklus for applikasjonen deres. De velger når de vil publisere. De velger når applikasjonen skal inn i den stabile kanalen slik at den er tilgjengelig for de fleste brukere. De kan velge når det går inn i kandidat- og betakanaler. De kan koble CI til kantkanalene slik at de kontinuerlig kan publisere programvare og få folk til å velge disse forskjellige risikokanalene basert på om de vil ha det nyeste build, eller de er konservative og de bare vil ha stallen frigjøres når det sildrer ned til dem.

Hele forestillingen om oppdagelse er ekstremt viktig, og en som vi ikke satte pris på da vi startet. Når vi snakker med ISV-er, utgivere og utviklere nå, fører vi med historien om app-butikken fordi dette gir mye resonans med dem enn en forenkling av emballasje eller innesperring eller automatiske deltaoppdateringer.

Det de bryr seg om er å kunne publisere på utgivelseskadens, å kunne sette programvaren sin foran så mange mennesker som mulig, forenkle oppdagelsen og installasjonen av den programvaren og ha full kontroll over når de slipper.

Mer om Open Source

  • 8 av tiårets verste open source-innovasjoner
  • Åpen kilde i 2020: Fremtiden ser lys ut
  • Linus Torvalds: "Git beviste at jeg kunne være mer enn et en-rart."
  • 20 raske tips for å gjøre Linux-nettverk enklere (gratis PDF)

Den andre tingen med å slippe er at i det siste vil du gi ut søknaden din på din egen webside. Jeg vil ikke bruke merkenavn, men forestill deg at du er en utgiver av litt programvare og legger en .deb på nettstedet ditt - og det er bra for Ubuntu-brukere - men du installerer den .deben som kjører Ubuntu 16.04, og deretter Ubuntu 18.04 kommer ut og du oppgraderer. Nå eksisterer ikke lenger avhengigheter som applikasjonen trengte, fordi det er en flaggdag, underliggende biblioteker har blitt oppdatert, og at applikasjonen går i stykker.

Når du bruker Snaps med alt selvstendig, har du ikke disse flaggdagene der alt går i stykker, fordi Snaps vil løpe tilbake til distribusjoner tidligere, og den samme Snap vil rulle fremover for å jobbe med distribusjoner i fremtiden — Uten endringer — fordi alt er inneholdt og isolert.

TechRepublic: Medlemmer av samfunnet har uttrykt bekymring for at Snap-serveren er egen programvare. Hva vil være nødvendig for at en tredjepart skal betjene sin egen Snap-server, hvis den ville gjøre det?

Martin Wimpress: Da butikken opprinnelig ble opprettet, utviklet den seg fra Click-butikken. Årsaken til at Snap-butikken er proprietær skyldes delvis den arven. I de første dagene av overgangen fra Clicks til Snaps var butikk-iterasjonene noe eksperimentelle for å se hva som fungerte bra for folk og hva som ikke var, og det utviklet seg ganske organisk.

Som et resultat integreres Snap-butikken nå med andre områder av den Canonical-infrastrukturen. Så Snap-butikken er ikke en eneste ting. Det er ikke som denne ene programvaren som du enkelt kan koble fra resten av maskinen som driver infrastrukturen på Canonical. Så vi kan ikke bare trekke den fra hverandre og skille den fra og si: "Her går du, her er open source Snap-butikken." Selv om vi kunne det, må vi nøye vurdere å ta initiativet fordi vi har vært her før. Vi ble kritisert for Launchpad, som opprinnelig var under en proprietær lisens og opererte helt på den Canonical infrastrukturen, og kildekoden var ikke tilgjengelig.

Launchpad er også en stor og kompleks applikasjon som krever omfattende infrastruktur. Folk trekker paralleller til GitHub, det er ikke GitHub. Det har kildekodevert og sporing av problemer, men det er bare en veldig liten del av det den gjør. Den driver en gård med build-servere som faktisk kan gjenoppbygge på tvers av flere arkitekturer og sy ISO-er sammen for alle Ubuntu og dens smaker og produsere disse i løpet av få minutter på forespørsel. Så det er en kompleks maskin. Men til slutt svarte vi disse anropene til open source Launchpad, og vi tok på oss kostnadene for å gjøre dette arbeidet. Så vidt jeg vet, er det fremdeles bare en distribuert forekomst av Launchpad, og det er den som Canonical er vert for, og det har ikke kommet betydelige bidrag til Launchpad fra ansatte som ikke er Canonical siden Launchpad er blitt gjort til åpen kildekode.

Så hvis vi skulle åpne kildekoden Snap-butikken, kommer det faktisk til nytte for oss på noen meningsfull måte? Historien viser at det kanskje ikke gjør det. Det er ikke til å si at vi kanskje ikke har åpen kildekode i fremtiden. Vi må bare se.

Slik fungerer Snap-butikken i andre Linux-distribusjoner

I juli kalte Linux Mint hovedutvikler Clément Lefèbvre ut Snap som "en trussel" etter planer om å tilby åpen kildekode Chromium-nettleseren (som er Google Chrome, minus Flash og proprietære Google-komponenter) bare som en Snap .

Lefèbvre tar også opp forholdet mellom Snap-butikken og Ubuntu som Canonical-produkter, og sier at "brukere ikke skal fortelles om Ubuntu og Ubuntu One når du laster ned programvare, " og "programvare bør ikke utformes og testes først og fremst med et annet skrivebordsmiljø og distribusjon i tankene, og når han ser på skjermbilder, skulle han ikke se Ubuntu overalt, og legger til at "Det er galt av Spotify å gjøre det, og det er galt for enhver leverandør å tro at en slik butikk kan være den eneste butikken for alle Linux-brukere. For at dette skal fungere, må det styres av oss alle, med klare mål, uten skjevhet og uten interessekonflikt. "

Martin Wimpress: Vi har gått veldig langt for å sikre oss at Snaps, Snapcraft og Snap-butikken er helt tilknyttet Ubuntu. Det er klart - som andre prosjekter som er sponset av Canonical - det er et Canonical-produkt i bunnteksten på sidene.

Du kan også legge LXD, Juju, MAAS, microk8s og mange andre i den bøtta. Men fra begynnelsen var vi veldig forsiktige med å ikke få Snaps og Snapcraft og Snap-butikken til å se ut som en Ubuntu-eiendom, og har nylig til og med gått så langt - for hver av forlagssidene, hvis du publiserer en Snap i lagre, genererer den automatisk en distro-spesifikk side.

The Snap Store offers distribution-specific branding and instructions even for non-Canonical distributions.

" data-credit="Screenshot: James Sanders/TechRepublic" rel="noopener noreferrer nofollow">

Snap Store tilbyr distribusjonsspesifikk merkevarebygging og instruksjoner selv for ikke-kanoniske distribusjoner.

Skjermbilde: James Sanders / TechRepublic

For å illustrere dette, her er en lenke for å installere Spotify på Fedora eller Linux Mint , samt en generisk side som dekker alle støttede distribusjoner .

Martin Wimpress: Hvis vi blar nedover den generiske innledende utgiver-siden, er det en liste over brukere etter distribusjon. Vi gjør det veldig tydelig hvilke brukere av hvilke distribusjoner som har denne programvaren installert, og i hvilken grad. Du kan se etter alt Ubuntus, Linux Mint er den neste på listen, etterfulgt av Elementary, og deretter eldre versjoner av Ubuntu, og så har du Fedora og KDE Neon og mer Linux Mint der inne.

Vi prøver vårt beste for å samarbeide med disse distribusjonssamfunnene på ingeniørnivå. Vi holder et Snapcraft-topp to ganger i året der vi inviterer bidragsytere fra samfunnet, folk fra open source-samfunnet og folk fra industri til å jobbe sammen med oss. Den siste var i Montreal, og det var for rundt fem uker siden. Jeg synes det var ekstremt vellykket.

Folk føler at vi er onde på noen måte ved å tilby denne programvaren som vi har hjulpet med å samle, og bringe utgivere til, og gjøre den trivielt tilgjengelig for andre distribusjoner også. Jeg føler virkelig at dette er et flott eksempel på "stigende tidevann løfter alle skip." For eksempel er hele produktpakken fra JetBrains tilgjengelig i Snap-butikken. Det er virkelig overbevisende utviklerprogramvare der inne, og det er nå tilgjengelig for alle de store Linux-distribusjonene.

Vi kunne ha gjort snaps til en eneste Ubuntu-ting, men det er de ikke. De er designet for å være kryssdistro og tilgjengelig for alle.

Vil Ubuntu droppe .deb-pakker til fordel for Snap-pakker?

TechRepublic: Ser du en fremtid for Ubuntu på skrivebordet - eller for Linux på skrivebordet generelt - der brukervendte programmer distribueres primært som Snaps, mens interne komponenter forblir i tradisjonelle lagringsplasser?

Martin Wimpress: For desktop-distribusjoner som de eksisterer for tiden - og absolutt for smakene - vil det være en beslutning for hver av disse smakene å ta for seg. Det er ingen agenda innen Ubuntu for å gå til den modellen for øyeblikket.

Det er en viss appetitt å flytte noen raske applikasjoner til Snaps fordi det reduserer den tekniske belastningen på oss, og pakker programvare flere ganger for flere utgivelser. Du publiserer ett blunk - i dette tilfellet vil jeg bruke Chromium, fordi det er det som er diskutert blant brukerfellesskapet vårt nylig. Vi publiserte en versjon av Chromium som går helt tilbake til 14.04, og den vil fungere helt inn i fremtiden med påfølgende utgivelser av Ubuntu, slik at minimerer ingeniørarbeidet vårt betydelig.

Så jeg kan se at det er en appetitt å gjøre slike ting. Med Ubuntu Core, som jeg snakket om tidligere, som er vårt uforanderlige IoT-fokuserte operativsystem der alt er et blunk. Kjernen er et blunk, det underliggende operativsystemet er et blunk, og alle applikasjonene du installerer er snaps. Men dette er virkelig for IoT.

Men så, som en spin-off for å få skjermservere som fungerer for kunder med digital skilting og kioskkunder, har vi begynt å se disse begynnelsen av proto-desktop-miljøer som kan kjøres på toppen av Ubuntu Core. Jeg vet at det begeistrer en rekke mennesker, ikke bare i Canonical, men i det større Ubuntu-samfunnet.

Å ha et veldig sabotasjesikkert skrivebordsmiljø er ganske overbevisende, også når folk blir mer bevisste på deres digitale rettigheter og personvern, ettersom vi lærer mer og mer om hva som skjer i verden rundt oss og kanskje noen organisasjoner som ikke behandler våre data med den aktsomhet de skal.

Så jeg kunne forutse at en Ubuntu-smak - kanskje ikke engang en av de eksisterende - men en ny dukker opp som er bygget rundt Ubuntu Core og som bruker snaps for å sette det hele sammen.

TechRepublic: Noe parallelt, som Fedora Silverblue?

Martin Wimpress: Ja. Ligner på det. Vi var her før - telefonprosjektet og nettbrettprosjektet. Slik fungerte Unity 8 på disse plattformene, det hele var innesperret. Jeg kan absolutt se at det skjer, og det er noen få manglende brikker for å gjøre det lettere for øyeblikket. Jeg tror vi ser noe lignende det som dukker opp for generell bruk for øyeblikket, og ikke bare med Linux-brukere, som er denne ideen om å flytte arbeidsmengden og applikasjonene dine i containere, spesielt blant utviklere som fyrer opp containere for din utvikling, miljø, arbeidsområde og prosjekter slik at du kan få isolert alle disse tingene.

Utviklere har gjort dette i flere tiår med ting som virtualenv for å skille ut Python-utviklingsmiljøer. Vi ser pluginene som nå kommer inn Visual Studio Code som lar deg koble til eksterne forekomster. Jeg tror det er en klar kjøreretning hit og blant et visst publikum, det er en retning de vil ønske å gå i. Det er ingen veikartplaner for det for øyeblikket, men jeg tror det vil skje organisk og jeg tror det vil skje i fellesskapet først.

Ubuntu bruker GNOME-programvare og GNOMEs Snap-plugin

TechRepublic: Canonical kommer ikke til å sende GNOME-programvare (standardinstallasjonsprogrammet i GNOME) i Ubuntu 20.04. Følgelig planlegger Fedora å deaktivere snap-plugin-en for GNOME-programvare. Denne pluginen ble ikke installert som standard, så Fedoras beslutning vil påvirke relativt få mennesker. Hva skjer med disse to retningene?

Martin Wimpress:
Det kommer virkelig til dette: Vi utvikler funksjoner i Snap-butikken - når det gjelder API-er som driver Snap-butikken - med en rask kadens. Å tilbakeportere disse funksjonene til Snapcraft-plugin-en for GNOME-programvare, og deretter backportere alt dette til de forskjellige støttede versjonene av GNOME-programvaren som går igjen i Ubuntu-historien, blir en teknisk overhead som er vanskelig å opprettholde.

Hovedmotivasjonen for å gå våre egne veier på dette er å lette den tekniske byrden, slik at vi kan flytte stasjonær butikk i samme tempo som nettbutikken og låne alt formspråket vi har i nettbutikken, i den nye desktop applikasjon. Det vil bare bli mer strømlinjeformet for oss å gjøre det.

Det som er viktig å påpeke er at vi er opptatt av å opprettholde snapd-glib, biten som snakker med snapd, og Snap-plugin for GNOME-programvare, slik at hurtigflyttende distribusjoner som Fedora og Arch Linux alltid har nåværende versjoner. Vanskeligheten for oss var kontinuerlig backporting til eldre versjoner av Ubuntu for å holde tritt med vår andre utvikling. Å ha GNOME-programvare til å få tilgang til Snaps er viktig for oss for de menneskene som ikke er på Ubuntu - hvorav det er mange - som ønsker å få tilgang til Snaps, og overraskende nok er det mange av dem også.


For mer, sjekk ut Ubuntu: Hvordan ser fremtiden ut etter Unity? og utviklere: Hvordan PINE64 skaper et fellesskap for å konkurrere med Raspberry Pi's på TechRepublic.

Merk: Etter publiseringen av dette intervjuet, sa en representant fra Canonical til TechRepublic at "Canonical ikke har bekreftet en endelig avgjørelse rundt utviklingen av Snap Store. Canonical er opptatt av å utvikle og vedlikeholde snappluggen for GNOME-programvaren."

Ukens nyhetsbrev med åpen kildekode

Du vil ikke gå glipp av våre tips, opplæringsprogrammer og kommentarer til Linux OS og open source applikasjoner. Leveres tirsdager

Registrer deg i dag

© Copyright 2021 | mobilegn.com