Canonical på Ubuntu 'Bionic Beaver' 18.04 LTS og dens kontroversielle endringer
NyheterUtgivelsen av Ubuntu 'Bionic Beaver' 18.04 er viktig. Ikke bare er det LTS - med fem års støtte til støtte - som vil se at millioner av brukere installerer Ubuntu for første gang med GNOME fast plassert i skrivebordsmiljøsporet, men det kan være utgivelsen som ser Canonical, Selskapet bak Ubuntu, gjennom IPO. Vi snakket med Will Cooke, Canonicals skrivebordssjef og David Bitton, teknisk leder for Ubuntu Server, om de overordnede målene for Ubuntu 18.04 LTS og fremtidige planer.
Vil Cooke: Så vi er på en annen LTS-utgave, som kommer med fem års støtte til støtte. Og det er viktig for vår typiske brukerbase, fordi de ikke vil være nødt til å ... vel, de vil være sikre på at plattformen de jobber med, og at de stoler på, kommer til å bli Sikker og oppdatert, og skal fortsette å løpe i lang tid.
Les mer: Stellar Phoenix Windows Data Recovery
Vanligvis finner vi at de fleste av brukerne liker å installere den en gang, og la den være alene, og vet at det blir tatt vare på seg selv. Det er viktigere i skymiljøet enn det er på skrivebordet, kanskje. Men gleden av Ubuntu er at pakkene du kjører på skrivebordet ditt - la oss si at du er en webutvikler, og du vil kjøre en Apache-instans og en MySQL-forekomst, og du vil ha utviklerverktøyene der. Du kan gjøre all den utviklingen på maskinen din, og deretter distribuere den til skyen, kjøre den samme versjonen av Ubuntu, og vær sikker på at pakkene som er installert på skrivebordet, er nøyaktig det samme som de som er i bedriftens installasjon.
Og å ha de støttede i fem år betyr at du ikke trenger å fortsette å oppgradere maskinene dine. Og når du har tusenvis av maskiner utplassert i skyen på en eller annen måte, er det siste du vil gjøre, å opprettholde dem hvert eneste år og oppgradere det, og håndtere alt falloutet som skjer der.
Så det overordnede temaet for Ubuntu i 18.04 er denne evnen til å utvikle seg lokalt og distribuere til - enten den offentlige skyen, til din private sky, hva du vil gjøre - serverne dine. Men også kanten enheter, også.
Så vi har gjort mange fremskritt i våre Ubuntu Core-produkter, noe som er en veldig liten, nedslått versjon av Ubuntu, som skifter med bare det minste minimumet som du trenger å ta med en enhet og få den på nettverket.
Og så kan pakkene du kan distribuere til din tjeneste, til skrivebordet, også distribueres til IoT-enhetene, til kantenhetene, til nettverksbryterne dine - du vet, over hele linjen. Og det gir deg en virkelig enestående evne og pålitelighet til å vite at de ting du jobber med, kan pakkes opp, presses ut til disse andre enhetene, og det vil fortsette å fungere på samme måte som det fungerer på skrivebordet som det gjør på alle disse andre enhetene.
Og en sentral aktør i den historien er snappakker som vi har jobbet med. Dette er uavhengige binærfiler som ikke bare fungerer på Ubuntu, men også på Fedora eller CentOS eller Arch.
Så som en applikasjonsutvikler, for eksempel [...] kan du pakke opp alle disse avhengighetene i en selvstendig fortsatt pakke, og deretter trykke det ut på dine ulike enheter. Og du vet at det vil fungere, enten de kjører Ubuntu eller ikke.
Det er en veldig kraftig melding til utviklere: gjør jobben din på Ubuntu; pakke det opp; og skyv den ut til hvilken enhet som kjører Linux, og du kan stole på det og fortsette å jobbe de neste fem årene.
Ubuntu 18.04 har et sterkt fokus på snaps. Dette er et nytt pakkeformat, som gjør det mulig for apputviklere å pakke programvaren deres, inkludert alle avhengigheter, inn i en sikker sandkassettbeholder som kjører på Ubuntu Linux (og andre Linux-distribusjonsstøtte, som for eksempel Solus). Dette har ført til at mange høyprofilerte, men proprietære programvareprodukter, inkludert Slack og Skype, vises i Snap Store i tide for den nye utgivelsen.
Hva er det vanlige problemet utviklere har med DEBer og RPMer som har ført til utviklingen av snapsformatet?
TOALETT: Det er noen få. Packaging DEBs - eller RPM, for den saks skyld - er litt av en svart kunst. Det er en viss mengde magi involvert i det. Og læringsprosessen går gjennom den, for å forstå hvordan du kan pakke opp noe som en DEB eller RPM - barrieren for oppføring er ganske høy der. Så snaps forenkle mye av det.
Igjen, en del av faktum, egentlig, er denne evnen til å pakke alle avhengighetene med det. Hvis du pakker inn søknaden din og du sier, “OK, jeg er avhengig av denne versjonen av dette biblioteket for denne arkitekturen,” da kan avhengighetsoppløsningen ta vare på det for deg. Det ville nok gjøre.
Men så snart ditt underliggende operativsystem endrer det biblioteket, bryter pakken din. Og du kan aldri være helt sikker på hvor denne pakken skal distribueres, og hvilken versjon av hvilket operativsystem det kommer til å ende opp med.
Så ved å kombinere alt det til et øyeblikk, er du helt sikker på at alle dine avhengigheter sendes sammen med søknaden din. Så når den kommer til den andre enden, vil den åpne og kjøre riktig.
Den andre nøkkelfunksjonen, i mitt sinn, av snaps, er sikkerhetsinneslutningsaspektet. X.Org, for eksempel, er litt lang i tannen nå. Det var aldri virkelig designet med sikker databehandling i tankene. Så det er ganske enkelt - vel, ikke nødvendigvis X.Org faktisk, men hele OS; hvis noe kjører som en rot, eller det kjører som brukeren din, så har den tillatelsene til den brukeren som kjører den.
Så du kan installere et program der dev f.eks kan gå inn i hjemmekatalogen din, gå inn i SSH-nøkkelkatalogen din, lage en kopi av dem og sende dem et sted. Det vil gjøre det med samme tillatelser som brukeren som kjører den. Og ja, det er en reell bekymring.
Med snaps and confinements kan du si, “Denne applikasjonen, dette snapet, har ikke adgang til disse tingene.” Det vil fysisk ikke kunne lese disse filene fra disken. De eksisterer ikke så langt som det er bekymret.
Så fra brukerens perspektiv kan du laste ned denne nye applikasjonen fordi du hørte om det på internett. Du vet ikke hva det er, du vet ikke hvor det kommer fra, men du kan installere det, og du kan kjøre det, sikkert med tanke på at det ikke kommer til å bare gå over disken din og ha en se gjennom alle disse filene som du ikke nødvendigvis vil ha den til å ha tilgang til.
Så det er i mine tanker de to hovedhistoriene. Skrive en gang kjører hvor som helst siden av ting, og så inneslutningen sikkerhetsaspekt også.
- Dette er et utvidet utdrag fra et intervju som ble publisert i det månedlige Linux-bruker- og utviklermagasinet. For mer bransjeinnsiders innhold og det nyeste innen GNU / Linux og det frie og åpne kildeøkosystemet, kan du abonnere i dag og få 5 utgaver for £ 5 (kun i Storbritannia. Tilbudet slutter 30. april 2018).