🥇E ardhmja është këtu ose kodojmë drejtpërdrejt në shfletues

Do të flas për një situatë interesante që më ndodhi dhe se si të bëhesh kontribuues në një projekt të njohur.

Nuk është hera e parë që merrem me një ide: ngarkimi i Linux-it direkt nga UEFI…
Ideja nuk është e re dhe ekziston një numër manualesh mbi këtë temë. Një nga ato mund të shihet këtu

Prandaj, përpjekjet e mia të gjata për të zgjidhur këtë çështje rezultuan në një zgjidhje të shkruar mirë zgjidhje. Zgjidhja është plotësisht funksionale dhe unë e përdor atë në disa nga kompjuterët e mi të shtëpisë. Pak më hollësisht, kjo zgjidhje përshkruhet këtu.

Thelbi i UEFI-Boot është se ESP (EFI System Partition) përputhet me katalogun /boot. Pra, të gjitha bërthamat dhe imazhet e nisjes (initrd) vendosen në atë ndarje nga e cila UEFI mund të nisë skedarët ekzekutivë dhe në veçanti të nisë ngarkuesit e sistemit. Por bërthama e Linux-it tashmë në shumë distribuime ndërtohet me opsionin UEFISTUB, i cili lejon bërthamën të nisë nga UEFI.

Kyky i këtij zgjidhjeje ka një problem të pakëndshëm — ESP është formatuar në FAT32, mbi të cilin nuk është e mundur të krijosh lidhje të forta (të cilat sistemi i krijon rregullisht gjatë përditësimit të initrd). Dhe nuk ka asgjë të veçantë në këtë, por të shohësh paralajmërimet e sistemit gjatë përditësimit të komponentëve të kernel-it — nuk është shumë e këndshme...

Ka dhe një rrugë tjetër.

Menaxheri i ngarkesës UEFI (atë që duhet të shkruash për ngarkuesin e OS) mund të ngarkojë përveç ngarkuesve/kernel-eve Linux edhe drver të tjerë. Kështu që mund të ngarkosh drverin e asaj sistemi skedarësh, ku e ke /boot dhe përmes UEFI të ngarkosh direkt kernel-in. Drveri, natyrisht, duhet të vendoset në ndarjen ESP. Kështu në të vërtetë merret me këtë ngarkuesit si GRUB. Por gjëja interesante është se të gjitha funksionet e përdorura shpesh të GRUB janë tashmë të pranishme në UEFI. Më saktë, në menaxherin e tij të ngarkesës. Dhe nëse dëshiron të jesh edhe më i saktë, menaxheri i ngarkesës UEFI ka madje më shumë mundësi në disa çështje.

Duket si një zgjidhje e bukur, por ka një "POR" (më saktësisht kishte, por për këtë më vonë). E vërteta është se sistemi i drejtorëve UEFI është mjaft i thjeshtë. Nuk ka një koncept si montimi i sistemit të files apo lidhja e drejtuesit me një pajisje të veçantë. Ka një thirrje sistemore me një emër të kushtuar Map (angl.), i cili merr secilin drejtor një nga një dhe përpiqet ta lidhë atë me të gjitha pajisjet që përshtaten, më mirë ose më keq. Dhe nëse drejtori arriti të lidhet me pajisjen, krijohet një mapim — një regjistër lidhës. Kështu, drejtori i ri duhet të inicializohet në këtë grumbull me të gjithë të tjerët. Dhe vetëm kaq mjafton — në regjistrimin e ngarkesës së drejtuesit duhet të vendoset një bit (LOAD_OPTION_FORCE_RECONNECT) në 1 dhe UEFI pas ngarkimit të tij do të bëjë këtë rimapim global.

Por, ta bësh këtë nuk është aq e lehtë. Utilitari standard efibootmgr (me të cilin realizohet konfigurimi i menaxherit të ngarkesës UEFI) nuk di (më saktësisht, nuk dinte) të vendosë këtë bit. Duhej ta vendosja manualisht përmes një procedure mjaft të ndërlikuar dhe të rrezikshme.

Dhe kështu, për herë të fundit duke provuar ta bëj këtë manualisht, nuk e përballova dot dhe e organizova çështja në GitHub me një kërkesë për zhvilluesit për të shtuar këtë mundësi.

Kanë kaluar disa ditë, por askush nuk i ka kushtuar vëmendje kërkesës sime. Dhe nga kurioziteti, shikova burimet... e fork-ut, dhe mendoja se si mund ta shtoja këtë funksionalitet... "Në mënyrë rudimentare" sepse nuk kam instaluar diçka të tillë dhe redaktoja burimet direkt në shfletues.

C (gjuha e programimit) e njoh shumë pak, por përfunda një zgjidhje të përafërt (shumica kopjimi-ngjitje)... pastaj më erdhi në mendje — ndonjëherë kam sigurisht një mori gabimesh (përpjekjet e mia të kaluara për të rregulluar kodin e huaj C ishin e paktën të dhjetëta) do ta organizoj një Pull Request. Ndërsa e organizova.

Dhe aty u zbulua se kishte një Travis CI të lidhur për të kontrolluar pull requestet. Dhe ai me jepte këmbëngulësisht të gjitha gabimet e mia. Po nëse gabimet janë të njohura — përse të mos i rregulloj: përsëri direkt në shfletues, dhe në përpjekjen e katërt kodi u ndërtua (një arritje për mua).

Dhe kështu, pa dalë nga shfletuesi, organizova një Pull Request mjaft të vërtetë në utilitarin që përdoret pothuajse në të gjitha shpërndarjet moderne të Linux.

Më befasoi vetë fakti që unë, duke mos e ditur gjuhën mirë, dhe pa bërë asgjë në konfigurim (aty janë të nevojshme një sërë bibliotekash për ndërtimin) dhe pa e hapur kurrë ndihmën e zhvilluesit, thjesht në shfletues "programova" një mundësi tërheqëse e funksionale.

Megjithatë, kërkesa ime mbeti pa përgjigje që nga 19 marsi 2019, dhe unë tashmë po filloja ta harroja atë.

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

Çfarë është tregimi im? Ai është për atë se me teknologjitë moderne rezulton se kodi real mund të shkruhet tashmë në shfletues, pa ndihmën e asnjë instrumenti zhvillimi dhe varësish.

Duhet të pranoj se ky është pallati im i dytë i kërkesave në utilitarët e njohur (të paktën në rrethet e ngushta). Herën e kaluar, kërkesa ime për të korrigjuar shfaqjen e disa fushave në ndërfaqen web të SyncThing rezultoi në një korrigjim të vetëm rresht në një mjedis që unë nuk e dija fare.

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