Fremtiden er allerede her eller kode direkte i browseren

Jeg vil fortælle dig om en sjov situation, der skete for mig, og hvordan man bliver en bidragyder til et berømt projekt.

For ikke længe siden puslede jeg med en idé: at starte Linux direkte fra UEFI...
Ideen er ikke ny, og der er en række manualer om dette emne. Du kan se en af ​​dem her

Faktisk resulterede mine langvarige forsøg på at løse dette problem i en fuldstændig formaliseret beslutning. Løsningen virker ret godt, og jeg bruger den på nogle af mine hjemmemaskiner. Denne løsning er beskrevet lidt mere detaljeret. her.

Essensen af ​​UEFI-Boot er, at ESP (EFI System Partition)-partitionen er kombineret med /boot-mappen. De der. alle kerner og bootstrap-billeder (initrd) er placeret på den samme partition, hvorfra UEFI kan starte eksekverbare filer og især starte systemopstartsindlæsere. Men selve Linux-kernen i mange distributioner er allerede samlet med muligheden UEFISTUB, som tillader selve kernen at blive lanceret fra UEFI.

Denne løsning har et ubehageligt øjeblik - ESP-partitionen er formateret i FAT32, hvor det er umuligt at oprette hårde links (som systemet opretter regelmæssigt ved opdatering af initrd). Og der er ikke noget særligt kriminelt ved dette, men at se systemadvarsler ved opdatering af kernekomponenter er ikke særlig behageligt...

Der er en anden måde.

UEFI boot manager (den samme hvor du skal registrere OS bootloaderen) kan udover bootloadere/Linux kerner også indlæse drivere. Så du kan indlæse driveren til filsystemet, hvor du har /boot og indlæse kernen direkte derfra ved hjælp af UEFI. Driveren skal selvfølgelig placeres i ESP-partitionen. Dette er nogenlunde, hvad bootloadere som GRUB gør. Men højdepunktet er, at alle de ofte brugte GRUB-funktioner allerede er i UEFI. Mere præcist i sin downloadmanager. Og for at være endnu mere kedelig, har UEFI boot manager endnu flere muligheder i nogle spørgsmål.

Det ser ud til at være en smuk løsning, men der er et "MEN" (eller rettere, det var det, men mere om det senere). Faktum er, at UEFI-driversystemet er ret simpelt. Der er ikke sådan noget som at montere et filsystem eller knytte en driver til en bestemt enhed. Der er et systemkald med det konventionelle navn Map, som tager hver chauffør på skift og forsøger at forbinde den med alle, i det mindste passende enheder. Og hvis chaufføren var i stand til at afhente enheden, oprettes en kortlægning - en forbindelsespost. Det er præcis sådan, den nyindlæste driver skal initialiseres i en fælles bunke med alle de andre. Og alt hvad du behøver er at indstille en bit (LOAD_OPTION_FORCE_RECONNECT) til 1 i driverens boot-record, og UEFI vil lave denne globale remap efter indlæsning af den.

Men det er ikke så nemt at gøre. Standardværktøjet efibootmgr (som bruges til at konfigurere UEFI-offload-manageren) ved ikke, hvordan (eller rettere, vidste ikke hvordan) man indstiller denne bit. Jeg var nødt til at installere det manuelt gennem en ret kompliceret og farlig procedure.

Og endnu en gang, efter at have prøvet at gøre det med mine hænder, kunne jeg ikke holde det ud og formaliserede mig problem på GitHub beder udviklere om at tilføje denne funktion.

Der gik flere dage, men ingen var opmærksomme på min anmodning. Og af nysgerrighed kiggede jeg på kildekoden... jeg gaflede den og fandt på mine knæ ud af, hvordan man tilføjer denne funktion... "På mine knæ", fordi jeg ikke installerede noget lignende og redigerede kilden kode direkte i browseren.

Jeg kender C (programmeringssproget) meget overfladisk, men jeg skitserede en omtrentlig løsning (for det meste copy-paste)... og så tænkte jeg - jeg har i det mindste sikkert mange fejl der (mine tidligere forsøg på at redigere en andens C-koden blev udfyldt omkring 10. gang) Jeg udsender en Pull-anmodning. Godt designet.

Og dér viste Travis CI sig at være knyttet til at kontrollere pull-anmodninger. Og han fortalte mig flittigt alle mine fejl. Nå, hvis der er kendte fejl, er der ingen grund til at rette det: igen, lige i browseren, og på det fjerde forsøg virkede koden (en præstation for mig).

Og bare sådan, uden at forlade browseren, formaterede jeg en meget ægte Pull Request til et hjælpeprogram, der bruges i næsten alle moderne Linux-distributioner.

Jeg blev overrasket over det faktum, at uden rigtig at kunne sproget, uden at sætte noget op (afhængigheder kræver en del biblioteker til samling), og uden nogensinde at køre compileren, "kodede" jeg simpelthen en fuldstændig fungerende og nyttig funktion i browser.

Min anmodning forblev dog ikke reageret siden den 19. marts 2019, og jeg var allerede begyndt at glemme det.

Men i går blev denne anmodning tilføjet til master.

Så hvad handler min historie om? Og han taler om det faktum, at det inden for rammerne af moderne teknologier viste sig, at rigtig kode allerede kan skrives i browseren uden at implementere udviklingsværktøjer og afhængigheder lokalt.

Desuden må jeg indrømme, at dette allerede er min anden pull-anmodning for velkendte (i hvert fald i snævre kredse) hjælpeprogrammer. Sidste gang resulterede min anmodning om at rette visningen af ​​nogle felter i SyncThing-webgrænsefladen i min bogstaveligt talt en-linje redigering i et miljø, som jeg slet ikke kender.

Kun registrerede brugere kan deltage i undersøgelsen. Log ind, Vær venlig.

Skal jeg skrive mere eller ej?

  • ja

  • ikke det værd

294 brugere stemte. 138 brugere undlod at stemme.

Kilde: www.habr.com

Tilføj en kommentar