🥇Il futuro è già qui o stiamo programmando direttamente nel browser

Vi racconterò di una situazione curiosa che è accaduta a me e di come diventare un contributore in un progetto noto.

Non molto tempo fa, stavo lavorando su un'idea: il caricamento di Linux direttamente da UEFI...
L'idea non è nuova e ci sono alcune guide su questo tema. Una di esse può essere consultata qui

Le mie lunghe tentativi di risolvere questa questione si sono tradotti in un qualcosa di ben definito risultato. La soluzione è pienamente funzionante e la utilizzo su alcune delle mie macchine domestiche. Questa soluzione è descritta in modo più dettagliato qui.

Il punto principale dell'UEFI-Boot è che la partizione ESP (EFI System Partition) si combina con la directory /boot. Cioè, tutti i kernel e le immagini di avvio iniziale (initrd) vengono collocati nella stessa partizione da cui UEFI può eseguire file eseguibili e, in particolare, avviare i caricamenti di sistema. Ma il kernel Linux stesso è già compilato in molte distribuzioni con l'opzione UEFISTUB, che permette al kernel di avviarsi da UEFI.

C'è un aspetto spiacevole in questa soluzione: la partizione ESP è formattata in FAT32, sulla quale non è possibile creare link rigidi (che il sistema crea regolarmente durante l'aggiornamento di initrd). Non c'è nulla di particolarmente criminale in questo, ma vedere avvisi di sistema durante l'aggiornamento dei componenti del kernel non è granché piacevole...

Esiste anche un'altra via.

Il gestore di avvio UEFI (quello in cui è necessario specificare il caricatore del sistema operativo) è in grado di caricare, oltre ai caricamenti/kernel Linux, anche i driver. Quindi è possibile caricare il driver di quel file system dove hai la tua directory /boot e caricare direttamente il kernel tramite UEFI. Il driver, ovviamente, deve essere collocato nella partizione ESP. Circa questo si occupano i caricatori come GRUB. Ma il punto interessante è che tutte le funzioni frequentemente utilizzate di GRUB sono già disponibili in UEFI. Più precisamente, nel suo gestore di avvio. E se vogliamo essere ancora più precisi, il gestore di avvio UEFI ha anche più opzioni su alcune questioni.

Sembra una soluzione elegante, ma c'è un «MA» (anzi, c'era, ma ne parlerò dopo). Il fatto è che il sistema di driver UEFI è piuttosto semplice. Non c'è un concetto di montaggio del file system o di collegamento del driver a un dispositivo specifico. C'è una chiamata di sistema con un nome provvisorio, Map, che prende il controllo di ogni driver e cerca di collegarlo a tutti i dispositivi più o meno adatti. E se il driver riesce a collegarsi al dispositivo, allora viene creato un mapping — una voce di collegamento. È così che il nuovo driver deve essere inizializzato insieme a tutti gli altri. Bastano solo due cose: impostare un bit (LOAD_OPTION_FORCE_RECONNECT) a 1 nella voce di avvio del driver e UEFI farà questo famoso remapping globale dopo il caricamento.

Solo che fare tutto ciò non è così semplice. L'utility standard efibootmgr (con la quale si configura il gestore di avvio UEFI) non riesce (o meglio, non riusciva) a impostare questo bit. Era necessario impostarlo manualmente attraverso una procedura piuttosto complessa e pericolosa.

E così, provando ancora una volta a farlo a mano, non ho retto e ho aperto un'issue su GitHub con la richiesta agli sviluppatori di aggiungere questa funzionalità.

Sono passati alcuni giorni, ma nessuno ha prestato attenzione alla mia richiesta. E così, per curiosità, ho dato un'occhiata al codice sorgente… l'ho forkato, e ho iniziato a pensare come aggiungere questa funzione… "pensando" perché non avevo installato nulla e modificavo il codice sorgente direttamente nel browser.

Con il C (linguaggio di programmazione) conosco abbastanza poco, ma ho abbozzato una soluzione (principalmente copiando e incollando)… poi ho pensato: e sebbene ci siano sicuramente un sacco di errori (le mie precedenti tentativi di modificare codice C di altri erano andate a buon fine dopo circa dieci tentativi), perché non presentare un Pull Request. E così l'ho presentato..

E là c'era Travis CI attaccato per controllare i pull request. E mi ha restituito con diligenza tutti i miei errori. Beh, se ci sono errori noti, perché non correggerli: di nuovo direttamente nel browser e, con il quarto tentativo, il codice è stato compilato (un successo per me).

E così, senza uscire dal browser, ho presentato un Pull Request piuttosto concreto per l'utility utilizzata praticamente in tutte le moderne distribuzioni Linux.

Sono rimasto sorpreso dal fatto che, pur non conoscendo bene la lingua e senza configurare nulla (lì servono diverse librerie per la compilazione), e senza nemmeno avviare il compilatore, sono riuscito a scrivere nel browser una funzionalità completamente funzionante e utile.

Tuttavia, la mia richiesta è stata in attesa di risposta dal 19 marzo 2019, e stavo per dimenticarmene.

Ma ieri questa richiesta è stata aggiunta nel master.

Di cosa parla quindi la mia storia? Riguarda il fatto che, nell’ambito delle tecnologie moderne, si è scoperto che è possibile scrivere codice reale direttamente nel browser, senza dover installare localmente strumenti di sviluppo e dipendenze.

Va detto che questo è già il mio secondo pull request a strumenti noti (almeno in cerchie ristrette). L'ultima volta la mia richiesta di correggere la visualizzazione di alcuni campi nell'interfaccia web di SyncThing si è tradotta in una modifica letteralmente di una riga in un ambiente che non conoscevo affatto.

Solo gli utenti registrati possono partecipare al sondaggio. Accedi, per favore.