Na prejšnjem virtualnem konferenci „“ je Linus Torvalds
o sedanjosti in prihodnosti jedra Linux v uvodnem govoru z Dirkem Hohndelom iz podjetja VMware. Med razpravo je bila obravnavana tema spremembe generacij med razvijalci. Linus je opozoril, da kljub skoraj 30-letni zgodovini projekta skupnost ni tako stara — med razvijalci je veliko novih obrazov, ki še niso dopolnili 50 let. Stari mački resnično ostarevajo in ošivejijo, vendar tisti, ki so dolgo vključenih v projekt, imajo običajno manj opravka z novim kodiranjem in se ukvarjajo bolj s podporo ali upravljanjem.
Iskanje novih vzdrževalcev se omenja kot velika težava. V skupnosti je veliko aktivnih razvijalcev, ki so pripravljeni pisati nov kodo, a malo kdo je pripravljen posvetiti svoj čas vzdrževanju in preverjanju tuje kode.
Poleg profesionalnosti morajo vzdrževalci uživati neomajen ugled. Od vzdrževalcev se tudi zahteva stalna angažiranost v procesu in neprekinjeno delo — vzdrževalec mora biti vedno na voljo, vsak dan brati elektronska sporočila in nanje reagirati. Delo v takšnih razmerah zahteva veliko samodiscipline, zato je vzdrževalcev malo in jih primanjkuje, iskanje novih vzdrževalcev, ki so sposobni pregledovati tujo kodo in usmerjati spremembe višjim vzdrževalcem, postaja ena glavnih težav v skupnosti.
Na vprašanje o eksperimentih v jedru je Linus dejal, da si skupnost razvijalcev jedra zdaj ne more privoščiti nekaterih norišč, ki so se dogajala v preteklosti. Če je bila prej razvojna pot brez obveznosti, je zdaj od jedra Linux odvisno preveč sistemov.
Na vprašanje o prenosu jedra na jezike, kot sta Go in Rust, ker obstaja tveganje, da bodo programerji v jeziku C postali podobni današnjim programerjem v COBOL-u do leta 2030, je Linus odgovoril, da ostaja jezik C med desetimi najbolj priljubljenimi jeziki, vendar se za manj kritične podsisteme, kot so gonilniki naprav, preučuje možnost zagotavljanja vezij za razvoj na jezikih, kot je Rust. V prihodnosti se pričakuje ponudba različnih modelov za pisanje takih sekundarnih komponent, ki ne bodo omejene na uporabo jezika C.
podjetja Apple, da bi v namiznih računalnikih in prenosnikih uporabljalo procesorje ARM arhitekture, je Linus komentiral z upanjem, da bo ta korak pomagal ARM postati bolj dostopen za delovne postaje. V zadnjih 10 letih se je Linus pritoževal, da ni mogel najti ARM-sistema, ki bi bil primeren za razvojni sistem. Tako kot je uporaba ARM-a s strani podjetja Amazon omogočila napredek te arhitekture v strežniških sistemih, ni izključeno, da bodo zahvaljujoč dejanjem podjetja Apple čez nekaj let dostopni tudi zmogljivi računalniki ARM, ki jih bo mogoče uporabiti za razvoj. Glede svojega na osnovi procesorja AMD je Linus omenil, da vse deluje normalno, razen hrupnega hladilnika.
Glede dela na jedru je Linus povedal, da je to hkrati dolgočasno in zanimivo. Dolgočasno, ker se mora nenehno ukvarjati z rutino odpravljanja napak in urejanjem kode, in zanimivo, ker se mora stalno učiti novih tehnologij, komunicirati z opremo na nizki ravni in nadzorovati vse, kar se dogaja.
O COVID-19 je Linus omenil, da pandemija in izolacijski ukrepi niso vplivali na razvoj, ker so postopki sodelovanja temelji na komunikaciji po elektronski pošti in oddaljenem razvoju. Med razvijalci jedra, s katerimi sodeluje Linus, nihče ni trpel zaradi okužbe. Zaskrbljenost je vzbudilo izginotje enega od sodelavcev za mesec ali dva, vendar je bilo to povezano z nastankom sindroma tunela.
Linus je prav tako omenil, da bo pri razvoju jedra 5.8 potrebno več časa za pripravo različice in izdajati eno ali dve dodatni testni izdaji, saj je to jedro bilo po številu sprememb. Vendar pa delo na 5.8 zaenkrat poteka precej gladko.
V drugem intervjuju je Linus , da se ne smatra več programerjem in se je umaknil od pisanja novega kode, saj že dolgo piše kodo le v poštnem odjemalcu. Vse svoje osnovno čas porabi za branje pošte in pisanje sporočil. Njegovo delo se omejuje na recenziranje poslanih preko poštne pošiljke popravkov in pull zahtevkov, prav tako pa sodeluje v razpravah o predlaganih spremembah. Občasno pojasnjuje svojo idejo s pseudokodo ali predlaga popravke na popravkih, ki jih pošlje v odgovoru brez kompilacije in testiranja ter pušča delo za dodelavo prvotnemu avtorju popravka.
Izvor: opennet.ru
