Të ardhmen e kemi këtu ose po kodojmë direkt në shfletues

Do të flas për një situatë të çuditshme që më ka ndodhur dhe se si të bëhesh kontribues në një projekt të njohur.

Koha e fundit jam marrë me një ide: ngarkimi i Linux-it direkt nga UEFI...
Ideja nuk është e re, dhe ekziston një numër i caktuar manualesh mbi këtë temë. Një nga ato mund të shihet këtu

Pra, përpjekjet e mia të vjetra për të zgjidhur këtë çështje përfunduan në një zgjidhje të mirëfilltë. vendim. Zgjidhja funksionon dhe unë e përdor në disa nga kompjuterët e mi shtëpiakë. Disa detaje më të hollësishme për këtë zgjidhje janë përshkruar këtu.

Thelbi i UEFI-Boot është që ESP (EFI System Partition) ndarja bashkohet me katalogun /boot. Pra, të gjitha bërthamat dhe imazhet e ngarkimit fillestar (initrd) vendosen në atë ndarje nga e cila UEFI mund të ngarkojë skedarë ekzekutivë dhe, në veçanti, të ngarkojë menaxherët e sistemit. Por vetë bërthama Linux tani kërkohet në shumë distribucione me opsionin UEFISTUB, i cili lejon që vetë bërthama të ngarkohet nga UEFI.

Kjo zgjidhje ka një moment të pakëndshëm - ndarja ESP është e formatuar në FAT32, ku nuk është e mundur të krijohen lidhje të forta (të cilat sistemi i krijon rregullisht gjatë përditësimit të initrd). Dhe nuk ka asgjë të veçantë të keqe në këtë, por të shohësh paralajmërime të sistemit gjatë përditësimit të komponentëve të bërthamës - nuk është shumë e këndshme...

Ka edhe një rrugë tjetër.

Menaxheri i ngarkimit UEFI (ai që duhe të regjistrohet ngarkuesi i OS) di të ngarkojë përveç ngarkuesve/bërthamave Linux, edhe drejtuesit. Pra, është e mundur të ngarkohet drejtuesi i sistemit të skedarëve ku ndodhet /boot dhe të ngarkohet bërthama direkt nga aty me mjetet UEFI. Drejtuesi, natyrisht, duhet të vendoset në ndarjen ESP. Kjo është, në thelb, ajo që bëjnë ngarkuesit e tipit GRUB. Por thelbi është që të gjitha funksionet e përdorura shpesh të GRUB janë tashmë në UEFI. Saktësisht në menaxherin e tij të ngarkimit. Dhe po të jemi edhe më të hollësishëm, menaxheri i ngarkimit UEFI ka madje edhe më shumë mundësi në disa aspekte.

Duket se Ă«shtĂ« njĂ« zgjidhje e bukur, por ka njĂ« "PO" (mĂ« saktĂ«, ka qenĂ«, por pĂ«r kĂ«tĂ« mĂ« vonĂ«). Çështja Ă«shtĂ« se sistemi i drejtuesve UEFI Ă«shtĂ« i organizuar mjaft thjesht. Nuk ka njĂ« koncept si montimi i sistemit tĂ« skedarĂ«ve apo lidhja e njĂ« drejtuesi me njĂ« pajisje tĂ« veçantĂ«. Ka njĂ« thirrje sistemore me emrin e kushhtĂ«zuar Map (angl.) qĂ« merr pĂ«r radhĂ« çdo drejtues dhe pĂ«rpiqet ta lidhĂ« atĂ« me tĂ« gjitha pajisjet pĂ«rafĂ«rsisht tĂ« pĂ«rshtatshme. Dhe nĂ«se drejtuesi arrin tĂ« lidhet me pajisjen, krijohet njĂ« mapim — njĂ« shkallĂ« lidhĂ«se. KĂ«shtu si nĂ« pĂ«rgjithĂ«si me tĂ« gjitha tĂ« tjerat, duhet tĂ« inicializohet drejtuesi i ri i ngarkuar. E vetĂ«m kjo nevojitet — nĂ« regjistrin e ngarkimit tĂ« drejtuesit tĂ« vendosni njĂ« bit (LOAD_OPTION_FORCE_RECONNECT) nĂ« 1 dhe UEFI pas ngarkimit tĂ« tij do tĂ« bĂ«jĂ« kĂ«tĂ« rimapim global.

Vetëm se nuk është aq e lehtë ta bësh këtë. Utiliteti standard efibootmgr (me anë të cilit konfigurohet menaxheri i shkarkimeve UEFI) nuk dinte (më saktë nuk dinte) të vendoste këtë bit. Duhej ta vendosja manualisht përmes një procedure mjaft të komplikuar dhe të rrezikshme.

Dhe kështu, duke provuar përsëri ta bëj këtë manualisht nuk e përballova dhe bëra një problem në GitHub me një kërkesë për zhvilluesit për të shtuar këtë mundësi.

Kaluan disa ditë, por askush nuk vuri re kërkesën time. Dhe nga kurioziteti, shikova në burimet
 e forkuova, dhe e mendova "në gjunjë" si ta shtoj këtë funksionalitet
 "në gjunjë" sepse nuk kisha vendosur ndonjë gjë të tillë dhe po redaktoja burimet drejtpërdrejt në shfletues.

C (gjuha e programimit) e njoh shumĂ« sipĂ«rfaqĂ«sisht, por pĂ«r njĂ« zgjidhje bĂ«ra njĂ« skicĂ« (pjesĂ«risht duke kopjuar dhe ngjitur)
 pastaj mendova — pse tĂ« mos e bĂ«j njĂ« Pull Request. Dhe e bĂ«ra.

Dhe atje u zbulua se ishte shtuar Travis CI pĂ«r kontrollin e pull requesteve. Ai mĂ« dha me kujdes tĂ« gjitha gabimet e mia. NĂ«se dihen gabimet — çfarĂ« mund tĂ« rregullohet: pĂ«rsĂ«ri drejtpĂ«rdrejt nĂ« shfletues, dhe me pĂ«rpjekjen e katĂ«rt kodi u pĂ«rmbledh (njĂ« arritje pĂ«r mua).

Dhe kështu, pa dalë nga shfletuesi, bëra një Pull Request mjaft reale në utilitetin që përdoret praktikisht në të gjitha shpërndarjet moderne të Linux.

Më vuri vetë në siklet fakti që unë, pa e njohur mirë gjuhën, dhe pa bërë ndonjë konfigurim (në varësi ka shumë biblioteka për ndërtim), dhe asnjëherë nuk kam hapur kompajlerin, thjesht në shfletues "kodoja" një funksionalitet mjaft të dobishëm dhe funksional.

Megjithatë, kërkesa ime ishte pa përgjigje që nga 19 marsi 2019, dhe unë fillova të harroja për të.

Por dje, kjo kërkesë u shtua në master.

Pra për çfarë po flas. Histori ime ka të bëjë me faktin se në kuadrin e teknologjive moderne, kodin real tashmë mund ta shkruash në shfletues, pa e parë ndonjëherë lokal asnjë mjet zhvillimi dhe varësi.

ËshtĂ« e vĂ«rtetĂ«, duhet ta pranoj qĂ« kjo Ă«shtĂ« kĂ«rkesa ime e dytĂ« pĂ«r njĂ« utilitare tĂ« njohur (tĂ« paktĂ«n nĂ« qarqet e ngushta). HerĂ«n e kaluar kĂ«rkesa ime pĂ«r tĂ« pĂ«rmirĂ«suar pamjen e disa fushave nĂ« ndĂ«rfaqen web tĂ« SyncThing rezultoi nĂ« njĂ« rregullim nja njĂ« rresht nĂ« njĂ« mjedis qĂ« nuk e njoh fare.

Vetëm përdoruesit e regjistruar mund të marrin pjesë në anketë. Hyni, ju lutem.

A duhet të shkruaj më shumë apo jo?

  • po

  • nuk rekomandohet

294 përdorues votuan. 138 përdorues abstenuan.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster