La maggior parte degli utilizzatori GNU/Linux risponderà affermativamente quando gli si chiederà se il proprio sistema operativo preferito è stabile, ma Steven H. VanderLeest (Boeing) e Peter Brink (Underwriter Laboratories) non sono dello stesso avviso e in un recente talk hanno discusso del perché GNU/Linux è inadatto al loro ambiente… ossia quello aerospaziale!
Su Phoronix c’è stata una levata di scudi a difesa del pinguino e sul fatto che è già stato utilizzato in diversi ambiti real-time. Oltretutto, qualche giorno fa, l’elicottero Ingenuity ha fortunatamente rotto 63 giorni di silenzio e festeggiato, così, il cinquataduesimo volo nella rarefatta atmosfera marziana. E il software di controllo di Ingenuity viene eseguito con Linux come sistema operativo.
VanderLeest e Brink, tuttavia, hanno le loro buone ragioni.
Non ce ne vogliano i SysOp che leggono l’articolo: immaginiamo abbiate avuto il vostro carico di weekend passati a sistemare un aggiornamento andato male. Ma cosa può significare un problema inaspettato quando in palio ci sono miliardi di euro o vite umane?
In questi casi estremi il fallimento non è un’opzione: qualsiasi cosa accada, bisogna sempre avere il controllo per riportare in brevissimo tempo il sistema in uno stato sicuro e, secondo loro, Linux non ha questa caratteristica poiché non ha:
- Dei requisiti ben definiti.
- Certificazioni ogni suo singolo driver.
- Una cultura della sicurezza e nemmeno una della qualità.
- Un micro – Kernel dove i driver vengano eseguiti con i più bassi privilegi possibili.
Specialmente l’ultimo punto, dicono, è praticamente un errore di progettazione, poiché Linux è monolitico e un driver che vada in errore può mandare in crash il Kernel. La cosa può ricordare un po’ la diatriba tra Torvalds e Tanenbaum negli anni novanta.
Un crash catastrofico può essere recuperato solo se c’è un watchdog hardware, ossia un contatore che ciclicamente viene azzerato da un nostro programma e, se raggiunge il valore massimo previsto, effettua un riavvio hardware del sistema.
Ma questa è davvero l’ultima spiaggia ed è considerata come il lanciarsi con il paracadute da un aereo di linea: cosa può accadere se il ciclo crash-reboot-pronto di un sistema impiega un minuto?
Immaginate di trovarvi su una macchina a guida autonoma che viaggia a 130 km/h in autostrada e che improvvisamente tutti gli schermi e indicatori diventino neri per un minuto. Vi sembra una situazione pericolosa? Ora capite come mai non vogliamo succeda su un caccia che viaggia a Mach 1.6 (1900 km/h circa).
Vanderleest e Brink, tuttavia, indicano a come rimediare agli inconvenienti indicati, anche se si tratterebbe di un lavoro davvero molto impegnativo. Sfortunatamente, un video del loro intervento non è disponibile, ma consigliamo di leggere le slide che hanno prodotto: possono dare un’idea di quanto sia diverso l’ambito aerospaziale da quelli cui siamo abituati: un mondo di certificazioni e test continui, dove il fallimento non è un’opzione e dove parametri come pressione, velocità e tempi di reazioni hanno priorità che non ci verrebbero subito in mente quando si parla di software.
Appassionato di GNU/Linux dal 2000, tento disperatamente di tenermi distante dalla programmazione web e di sviluppare in C/C++ e Python i software che mi vengono commissionati.
Lascia un commento