Rust i Linux: Et kraftfuldt værktøj – men hvordan finder vi den rigtige balance?

Den ophedede debat om at inkludere Rust i Linux-kernen har været i gang i et stykke tid i hackersamfundet. De fleste af os genkender både hypen og tøven omkring det. Hidtil har de fleste diskussioner fokuseret på umiddelbare problemer, såsom Rusts sikkerhedsfordele og udfordringerne ved at integrere det i det eksisterende C-baserede økosystem. Nu hvor Linus Torvalds er med på denne idé , er Rust allerede begyndt at finde vej til kildekoden til vores elskede operativsystem.

Det rigtige spørgsmål er således ikke, om man skal bruge Rust i Linux-kernen, men hvordan . Rust er trods alt ikke bare endnu et programmeringssprog; det er også en fuldgyldig designfilosofi. Det er ikke en opgradering af C med færre hukommelseskorruptionsfejl, men et system til at skrive kode, der fremtvinger et strengt regelsæt, og derved forhindrer mange potentielle fejl. Jeg tror, at dette er nøgleaspektet, vi skal være opmærksomme på, når vi indlejrer Rust i Linux-kernen.

Forbliv effektiv og tilpasningsdygtig

Ifølge forskning om organisatorisk ambidexterity skal meget store projekter som Linux kontinuerligt engagere sig i to typer aktiviteter for at forblive tilpasningsdygtige, relevante og succesrige:

1. Udnyttelse: Effektivitet, forfining og udførelse. I Linux refererer dette til aktiviteter såsom optimering af funktioner, rettelse af fejl og adressering af eksisterende brugeres bekymringer.
2. Udforskning: Eksperimentering, risikotagning og innovation. Disse aktiviteter giver projekter som Linux mulighed for at udvikle nye tilgange, tilpasse sig forstyrrende teknologier og imødekomme skiftende brugerforventninger.

Forskning viser også, at kortsigtede udvindingsaktiviteter har en tendens til at drive langsigtede efterforskningsaktiviteter ud . Det er som at ville lære en ny færdighed eller arbejde på et utraditionelt projekt, men altid prioritere daglige opgaver i stedet for. Det samme gælder for store projekter som Linux; hvis de fokuserer for meget på kortsigtet effektivitet, risikerer de på længere sigt at blive forældede. Verden bliver ved med at ændre sig, mens projektet forbliver det samme, hvilket gør dets tilbud mere og mere irrelevante i forhold til de skiftende brugerbehov.

At finde den rigtige balance

På den ene side er brugen af Rust et meget ukonventionelt eksperiment, der kan betragtes som en udforskningsaktivitet for Linux. Ud fra dette perspektiv er Rusts inklusion velbegrundet. Men på den anden side, i modsætning til C – som omfavner alle former for vanvid og udefineret adfærd med åbne arme, hvilket gør det til det foretrukne sprog for hacking på lavt niveau – har Rust et internt bureaukrati, der håndhæver en bestemt struktureret måde at skrive kode på. I en vis forstand fungerer Rust både som et programmeringssprog og et processtyringssystem, svarende til metoder som Six Sigma. En specifik, struktureret måde at skrive kode på kan helt sikkert hjælpe med at strømline processer og forbedre kortsigtede resultater, såsom sikkerhedssårbarheder og pålidelighedsproblemer. Men ligesom i tilfælde af andre processtyringssystemer introducerer denne rigiditet også risici for langsigtet smidighed og tilpasningsevne.

Derfor vil Rusts fordele ved at strømline processer og gøre dem sikrere skinne især i kernekomponenter, hvor langsigtet tilpasningsevne er mindre kritisk. For eksempel interagerer enhedsdrivere direkte med eksterne input og er højrisikokomponenter med hensyn til hukommelsessikkerhed og pålidelighed. Derfor giver det mening at skrive dem med Rust. De har også en tendens til at have relativt kortere levetid, da nye enheder ofte erstatter gamle. Med andre ord bliver bekymringen for, at Rust-metodologien kan mindske udforskningen, eller muligheden for, at vi i sidste ende måske ønsker at bevæge os væk fra Rust på grund af ændringer i kodeskrivningsfilosofier, mindre relevant. Når en enhedsdriver udvikles med Rust, er den typisk sikrere og mere pålidelig, og andre komponenter er ikke bygget på denne kode. Som et resultat tvinger det ikke nogen til en bestemt måde at skrive kode på om et par årtier.

I modsætning hertil skal kernens kernekomponenter, såsom skemalæggeren, forblive tilpasningsdygtige for at imødekomme fremtidige udfordringer og nye paradigmer. Brug af rust i disse områder kan introducere stivheder, der hindrer udforskning og føre til forældelse. Tænk på det på denne måde: Fremtidig kode skal bygge på de komponenter, der bygges i dag, og når en anden filosofi om at skrive software viser sig at være mere fordelagtig i fremtiden, kan den meget fleksible C-kode generelt ændres trinvist, indtil den omdannes til den nye tilgang (inkrementel strategisk fornyelse). I modsætning hertil insisterer Rust på sin egen måde at skrive kode på, så dette vil sandsynligvis forårsage et dilemma med at fortsætte med at udvikle sig med den gamle tilgang versus at skrive den fra bunden. I betragtning af at fri software altid har haft svært ved at finde et tilstrækkeligt antal kvalificerede og regelmæssige frivillige samt en tilstrækkelig mængde regelmæssig finansiering, er trinvise forbedringer altid meget nemmere end at beslutte sig for at påtage sig et større projekt som at smide en komponent væk og skrive fra bunden. Derfor kan ethvert sprog, der insisterer på en bestemt måde at skrive kode på, blive et ansvar i fremtiden, hvilket tvinger Linux til at fortsætte med en ældre måde at skrive kode på og miste sin banebrydende position.

Kort fortalt foreslår jeg en hybrid strategi, hvor Rust bruges mere til kortsigtede komponenter, hvor sikkerhed er afgørende, mens C – det mest agile sprog, der ikke er specifikt for hardware – prioriteres til langsigtede komponenter for at bevare fleksibiliteten til fremtidige paradigmer og tilgange.