Na virtualni konferenci prejšnji teden,» Linus Torvalds
sedanjost in prihodnost jedra Linuxa v uvodnem pogovoru z Dirkom Hohndelom iz VMware. Med razpravo se je dotaknila teme menjave generacij med razvijalci. Linus je poudaril, da kljub skoraj 30-letni zgodovini projekta skupnost na splošno ni tako stara - med razvijalci je veliko novih ljudi, ki še niso dopolnili 50 let. Starodobniki se sicer postarajo in osivijo, a tisti, ki so v projektu sodelovali že dlje časa, so se praviloma oddaljili od pisanja nove kode in se ukvarjajo z nalogami, povezanimi z vzdrževanjem ali upravljanjem.
Iskanje novih vzdrževalcev je označeno kot velik problem. V skupnosti je veliko aktivnih razvijalcev, ki z veseljem pišejo novo kodo, le redki pa so pripravljeni posvetiti svoj čas vzdrževanju in pregledovanju kode drugih ljudi.
Poleg strokovnosti morajo vzdrževalci uživati neizpodbitno zaupanje. Od vzdrževalcev se zahteva tudi stalna vključenost v proces in nenehno delo – vzdrževalec mora biti vedno dosegljiv, vsak dan prebirati pisma in nanje odgovarjati. Delo v takšnem okolju zahteva veliko samodiscipline, zato je vzdrževalcev malo in iskanje novih vzdrževalcev, ki lahko pregledajo kodo drugih ljudi in posredujejo spremembe vzdrževalcem na višji ravni, postane ena glavnih težav v skupnosti. .
Ko so ga vprašali o poskusih v jedru, je Linus dejal, da si razvojna skupnost jedra ne more več privoščiti nekaterih norih sprememb, ki so bile narejene v preteklosti. Če prej razvoj ni bil obvezen, je zdaj preveč sistemov odvisnih od jedra Linuxa.
Na vprašanje o predelavi jedra v jezikih, kot sta Go in Rust, saj obstaja tveganje, da se bodo leta 2030 razvijalci C spremenili v trenutno podobo razvijalcev COBOL, je Linus odgovoril, da jezik C ostaja med desetimi najbolj priljubljenimi jeziki, vendar se upoštevajo nejedrni podsistemi, kot so gonilniki naprav zagotavljanje vezav za razvoj v jezikih, kot je Rust. V prihodnosti pričakujemo, da bomo zagotovili različne modele za pisanje takšnih sekundarnih komponent, ki ne bodo omejene na uporabo jezika C.
Appleovo uporabo procesorjev arhitekture ARM v namiznih in prenosnih računalnikih je Linus komentiral z upanjem, da bo ta korak pripomogel k temu, da bo ARM bolj dostopen za delovne postaje. Zadnjih 10 let se je Linus pritoževal nad svojo nezmožnostjo najti sistem ARM, ki bi ustrezal sistemu razvijalca. Tako kot je Amazonova uporaba ARM-ja omogočila napredek arhitekture v strežniških sistemih, je možno, da bodo Applovi ukrepi v nekaj letih omogočili dostop do zmogljivih osebnih računalnikov, ki temeljijo na ARM-ju in jih bo mogoče uporabiti za razvoj. Glede vašega temelji na procesorju AMD, Linus je omenil, da vse deluje v redu, razen zelo hrupnega hladilnika.
Linus je o preučevanju jedra rekel, da je dolgočasno in zanimivo. Dolgočasno je, ker se morate ukvarjati z rutino popravljanja napak in urejanja kode, vendar je zanimivo, ker morate nenehno razumeti nove tehnologije, komunicirati z opremo na nizki ravni in nadzorovati vse, kar se dogaja.
V zvezi s COVID-19 je Linus omenil, da pandemija in izolacijski režimi niso vplivali na razvoj, saj interakcijski procesi temeljijo na komunikaciji prek e-pošte in razvoju na daljavo. Od razvijalcev jedra, s katerimi Linus sodeluje, okužba ni poškodovala nikogar. Zaskrbljenost je povzročilo izginotje enega od njegovih sodelavcev za mesec ali dva, a se je izkazalo, da je povezano z nastankom sindroma karpalnega kanala.
Linus je tudi omenil, da bi moral pri razvoju jedra 5.8 porabiti več časa za pripravo izdaje in izdati eno ali dve dodatni testni izdaji, saj je bilo to jedro izdano po številu sprememb. Toda na splošno delo na 5.8 zaenkrat poteka precej gladko.
V drugem intervjuju, Linus , da se nima več za programerja in se je oddaljil od pisanja nove kode, saj kodo že dolgo piše samo v elektronskem odjemalcu. Večino časa porabi za branje pošte in pisanje sporočil. Delo se zmanjša na pregledovanje popravkov in zahtevkov za vleko, poslanih prek poštnega seznama, ter sodelovanje v razpravah o predlaganih spremembah. Včasih razloži svojo idejo s psevdokodo ali predlaga spremembe popravkov, ki jih pošlje v odgovoru brez prevajanja in testiranja, pri čemer prepusti delo pripeljevanja na ustrezno raven izvirnemu avtorju popravka.
Vir: opennet.ru