Rust in Linux: uno strumento potente, ma come trovare il giusto equilibrio?

L'acceso dibattito sull'inclusione di Rust nel kernel Linux è in corso da parecchio tempo nella comunità degli hacker. La maggior parte di noi riconosce sia l'entusiasmo che le esitazioni al riguardo. Finora, la maggior parte delle discussioni si è concentrata su questioni immediate, come i vantaggi di sicurezza di Rust e le sfide dell'integrazione nell'ecosistema basato su C esistente. Ora che Linus Torvalds è a bordo con questa idea , Rust ha già iniziato a farsi strada nel codice sorgente del nostro amato sistema operativo.

Quindi, la vera questione non è se usare Rust nel kernel Linux, ma come . Dopo tutto, Rust non è solo un altro linguaggio di programmazione; è anche una filosofia di progettazione a tutti gli effetti. Non è un aggiornamento di C con meno bug di corruzione della memoria, ma un sistema di scrittura del codice che impone un rigido set di regole, prevenendo così molti potenziali errori. Credo che questo sia l'aspetto chiave di cui dobbiamo essere consapevoli quando incorporiamo Rust nel kernel Linux.

Rimanere efficienti e adattabili

Secondo la ricerca sull'ambidestria organizzativa , progetti su larga scala come Linux devono impegnarsi costantemente in due tipi di attività per rimanere adattabili, rilevanti e di successo:

1. Exploitation: efficienza, perfezionamento ed esecuzione. In Linux, questo si riferisce ad attività come l'ottimizzazione delle funzionalità, la correzione di bug e la risoluzione di problemi degli utenti esistenti.
2. Esplorazione: sperimentazione, assunzione di rischi e innovazione. Queste attività consentono a progetti come Linux di sviluppare nuovi approcci, adattarsi a tecnologie dirompenti e soddisfare le mutevoli aspettative degli utenti.

La ricerca mostra anche che le attività di sfruttamento orientate al breve termine tendono a scacciare le attività di esplorazione orientate al lungo termine . È come voler imparare una nuova competenza o lavorare a un progetto non convenzionale, ma dare sempre la priorità alle attività quotidiane. Lo stesso vale per grandi progetti come Linux; se si concentrano troppo sull'efficienza a breve termine, rischiano di diventare obsoleti a lungo termine. Il mondo continua a cambiare mentre il progetto rimane lo stesso, rendendo le sue offerte sempre più irrilevanti per le mutevoli esigenze degli utenti.

Trovare il giusto equilibrio

Da un lato, adottare Rust è un esperimento molto non convenzionale che può essere considerato un'attività di esplorazione per Linux. Da questa prospettiva, l'inclusione di Rust è ben fondata. Tuttavia, d'altro canto, a differenza di C, che abbraccia a braccia aperte tutti i tipi di follia e comportamento indefinito, rendendolo il linguaggio di riferimento per l'hacking di basso livello, Rust ha una burocrazia interna che impone un certo modo strutturato di scrivere codice. In un certo senso, Rust funziona sia come linguaggio di programmazione che come sistema di gestione dei processi, simile a metodologie come Six Sigma. Un modo specifico e strutturato di scrivere codice può certamente aiutare a semplificare i processi e migliorare i risultati a breve termine, come vulnerabilità di sicurezza e problemi di affidabilità. Tuttavia, proprio come nei casi di altri sistemi di gestione dei processi , questa rigidità introduce anche rischi per l'agilità e l'adattabilità a lungo termine.

Pertanto, i meriti di Rust nello snellire i processi e renderli più sicuri brillerebbero in particolar modo nei componenti del kernel in cui l'adattabilità a lungo termine è meno critica. Ad esempio, i driver di dispositivo interagiscono direttamente con input esterni e sono componenti ad alto rischio in termini di sicurezza e affidabilità della memoria. Quindi, ha senso scriverli con Rust. Tendono anche ad avere durate di vita relativamente più brevi, poiché nuovi dispositivi sostituiscono frequentemente quelli vecchi. In altre parole, la preoccupazione che la metodologia Rust possa ridurre l'esplorazione, o la possibilità che alla fine potremmo voler abbandonare Rust a causa di cambiamenti nelle filosofie di scrittura del codice diventa meno rilevante. Quando un driver di dispositivo viene sviluppato con Rust, è in genere più sicuro e affidabile e altri componenti non vengono costruiti su questo codice. Di conseguenza, non costringe nessuno a un particolare modo di scrivere codice in pochi decenni.

Al contrario, i componenti principali del kernel, come lo scheduler, devono rimanere adattabili per adattarsi alle sfide future e ai nuovi paradigmi. L'uso di Rust in queste aree potrebbe introdurre rigidità che ostacolano l'esplorazione e portano all'obsolescenza. Pensatela in questo modo: il codice futuro deve basarsi sui componenti che vengono costruiti oggi e quando alla fine una filosofia diversa di scrittura del software si rivela più vantaggiosa in futuro, il codice C altamente flessibile può generalmente essere modificato in modo incrementale fino a quando non viene trasformato nel nuovo approccio (rinnovamento strategico incrementale). Al contrario, Rust insiste sul suo modo di scrivere il codice, quindi è probabile che ciò causi un dilemma tra continuare a sviluppare con il vecchio approccio e scriverlo da zero. Considerando che il software libero ha sempre avuto difficoltà a trovare un numero sufficiente di volontari qualificati e regolari, nonché una quantità sufficiente di finanziamenti regolari, il miglioramento incrementale è sempre molto più facile che decidere di intraprendere un progetto importante come buttare via un componente e scrivere da zero. Pertanto, qualsiasi linguaggio che insista su un particolare modo di scrivere il codice può diventare un problema in futuro, costringendo Linux a continuare con un vecchio modo di scrivere il codice e perdendo la sua posizione all'avanguardia.

In breve, propongo una strategia ibrida in cui Rust viene utilizzato maggiormente per i componenti a breve termine in cui la sicurezza è fondamentale, mentre C, il linguaggio più agile e non specifico per l'hardware, viene considerato prioritario per i componenti a lungo termine, per mantenere la flessibilità per paradigmi e approcci futuri.