🥇Viitorul este deja aici sau codăm direct în browser

Voi vorbi despre o situație amuzantă care mi s-a întâmplat și despre cum să devii contributor la un proiect cunoscut.

Nu cu mult timp în urmă, m-am ocupat de o idee: încărcarea Linux direct din UEFI…
Ideea nu este nouă și există un număr considerabil de manuale pe această temă. Unul dintre ele poate fi vizionat aici

Așadar, încercările mele de mult timp de a rezolva această problemă s-au transformat într-o soluție oarecum clară soluție. Soluția este pe deplin funcțională și o folosesc pe o parte din mașinile mele de acasă. O descriere mai detaliată a acestei soluții este prezentată aici.

Esenta UEFI-Boot este că ESP (EFI System Partition) se combină cu directorul /boot. Adică toate nucleele și imaginile de încărcare inițială (initrd) sunt plasate pe acelasi partiție din care UEFI poate rula fișiere executabile și, în special, poate lansa bootloader-ul sistemului. Însă nucleul Linux este deja compilat cu opțiunea UEFISTUB în multe distribuții, care permite nucleului să pornească din UEFI.

Există un aspect neplăcut al acestei soluții - partiția ESP este formatată în FAT32, care nu permite crearea de linkuri tari (pe care sistemul le creează regulat la actualizarea initrd). Și nu este nimic deosebit de grav în asta, dar a vedea avertizările sistemului la actualizarea componentelor nucleului nu este chiar plăcut...

Există și o altă cale.

Managerul de boot UEFI (acela în care trebuie să înscrii bootloader-ul OS) poate, pe lângă bootloader-e / nucleele Linux, să încarce și drivere. Astfel, poți încărca driverul sistemului de fișiere unde se află /boot și să încarci nucleul direct din UEFI. Desigur, driverul trebuie plasat în partiția ESP. Aproape de asta se ocupă bootloader-e de tip GRUB. Dar esența este că toate funcțiile folosite frecvent ale GRUB sunt deja disponibile în UEFI. Mai exact, în managerul său de boot. Și dacă vrei să fi și mai tehnic, managerul de boot UEFI are chiar mai multe capacități în anumite privințe.

Pare că este o soluție atractivă, dar există un "DAR" (de fapt a fost, dar despre asta mai târziu). Problema este că sistemul de drivere UEFI este relativ simplu. Nu există un concept de montare a sistemului de fișiere sau de legare a driverului de un anumit dispozitiv. Există un apel de sistem cu un nume convențional Map (eng.) care ia, pe rând, fiecare driver și încearcă să-l asocieze cu toate dispozitivele care se potrivesc, mai mult sau mai puțin. Și dacă driverul a reușit să se conecteze la dispozitiv, atunci se creează un mapping — o înregistrare de legătură. Exact așa, împreună cu toate celelalte, trebuie să fie inițializat un driver nou încărcat. Și tot ce trebuie să faci este să pui un bit (LOAD_OPTION_FORCE_RECONNECT) în 1 în înregistrarea de boot a driverului, iar UEFI va efectua acest remap global după ce l-a încărcat.

Numai că nu este atât de simplu de realizat. Utilitarul standard efibootmgr (prin intermediul căruia se realizează configurarea managerului de boot UEFI) nu poate (de fapt nu putea) să pună acest bit. A fost necesar să-l setez manual printr-o procedură destul de complicată și riscantă.

Și așa, după ce am încercat din nou să fac acest lucru manual, nu am mai rezistat și am deschis o problemă pe GitHub cu o solicitare către dezvoltatori de a adăuga această opțiune.

Au trecut câteva zile, dar nimeni nu a observat cererea mea. Și din curiozitate m-am uitat la sursele… le-am fork-uit și am calculat "pe genunchi" cum să adaug această funcție… "Pe genunchi" pentru că nu am instalat nimic și am editat sursele direct în browser.

C (limbajul de programare) îl cunosc foarte superficial, dar am schițat o soluție (în principal prin copiere și inserare)… apoi m-am gândit — chiar dacă am acolo cu siguranță o mulțime de erori (tentativele mele anterioare de a modifica codul C al altora s-au adunat începând cu a zecea încercare), voi deschide un Pull Request. Ei bine, l-am deschis.

Și acolo s-a dovedit că era integrat Travis CI pentru verificarea pull request-urilor. Și mi-a dat cu atenție toate erorile mele. Ei bine, dacă știu de erori — ce-ar fi să le corectez: din nou direct în browser, iar la a patra încercare codul s-a compilat (un realizare pentru mine).

Și așa, fără a ieși din browser, am deschis un Pull Request destul de real pentru utilitarul care este folosit în practic toate distribuțiile moderne de Linux.

M-a surprins că, fără să cunosc bine limba și fără să configurez nimic (deoarece pentru compilare este necesar un set considerabil de biblioteci), am reușit să „scriu” o funcționalitate utilă și funcțională direct în browser, fără să deschid niciodată compilatorul.

Cu toate acestea, cererea mea a fost în așteptare fără reacție din 19 martie 2019 și deja începutese să o uit.

Dar ieri, această cerere a fost adăugată în master.

Despre ce este povestea mea? Ea este despre cum, datorită tehnologiilor moderne, codul real poate fi scris în browser, fără a necesita instalarea de instrumente de dezvoltare sau dependențe local.

Trebuie să recunosc că acesta este deja al doilea meu pull request pe utilitare cunoscute (cel puțin în cercuri restrânse). Data trecută, cererea mea de a corecta afisarea unor câmpuri în interfața web a SyncThing s-a rezolvat printr-o modificare de o singură linie, într-un mediu pe care nu îl cunosc deloc.

Numai utilizatorii înregistrați pot participa la sondaj. Conectați-vă, vă rugăm.