Ved sidste uges virtuelle konference,» Linus Torvalds
nutiden og fremtiden for Linux-kernen i en indledende samtale med Dirk Hohndel fra VMware. Under diskussionen blev emnet generationsskifte blandt udviklere berørt. Linus påpegede, at trods projektets næsten 30-årige historie, generelt er fællesskabet ikke så gammelt – blandt udviklerne er der mange nye mennesker, som endnu ikke er fyldt 50 år. Oldtimerne bliver ganske rigtigt gamle og grå, men dem, der har været involveret i projektet i lang tid, er som regel gået væk fra at skrive ny kode og beskæftiger sig med opgaver relateret til vedligeholdelse eller forvaltning.
At finde nye vedligeholdere er kendt som et stort problem. Der er mange aktive udviklere i fællesskabet, som er glade for at skrive ny kode, men få er villige til at bruge deres tid på at vedligeholde og gennemgå andres kode.
Ud over professionalisme skal vedligeholdere nyde ubestridelig tillid. Vedligeholdere er også forpligtet til løbende at være involveret i processen og konstant arbejde - vedligeholderen skal altid være tilgængelig, læse breve hver dag og svare på dem. At arbejde i et sådant miljø kræver en masse selvdisciplin, og derfor er vedligeholdere få og langt imellem, og at finde nye vedligeholdere, der kan gennemgå andres kode og videresende ændringer til vedligeholdere på højere niveau, bliver et af hovedproblemerne i fællesskabet .
Da Linus blev spurgt om eksperimenter i kernen, sagde Linus, at kerneudviklingsfællesskabet ikke længere har råd til nogle af de skøre ændringer, der blev foretaget i fortiden. Hvis tidligere udvikling ikke var obligatorisk, afhænger nu for mange systemer af Linux-kernen.
Da han blev spurgt om at omarbejde kernen i sprog som Go og Rust, da der er en risiko for, at C-udviklere i 2030 vil blive til det nuværende udseende af COBOL-udviklere, svarede Linus, at C-sproget forbliver i top ti populære sprog, men for ikke-kerneundersystemer, såsom enhedsdrivere tages i betragtning giver bindinger til udvikling i sprog som Rust. I fremtiden forventer vi at levere forskellige modeller til at skrive sådanne sekundære komponenter, ikke begrænset til brugen af C-sproget.
Apples brug af ARM-arkitekturprocessorer i stationære computere og bærbare computere Linus kommenterede med håbet om, at dette trin vil hjælpe med at gøre ARM mere tilgængelig for arbejdsstationer. I de sidste 10 år har Linus klaget over sin manglende evne til at finde et ARM-system, der passer til udviklerens system. Ligesom Amazons brug af ARM tillod det at fremme arkitekturen i serversystemer, er det muligt, at takket være Apples handlinger vil kraftfulde ARM-baserede pc'er blive tilgængelige om få år og kan bruges til udvikling. Angående din baseret på en AMD-processor nævnte Linus, at alt fungerer fint, bortset fra den meget støjende køler.
Linus sagde om at studere kernen, at det var både kedeligt og interessant. Det er kedeligt, fordi du skal håndtere rutinen med at rette fejl og sætte koden i orden, men det er interessant, fordi du hele tiden skal forstå nye teknologier, interagere med udstyr på et lavt niveau og kontrollere alt, hvad der sker.
Med hensyn til COVID-19 nævnte Linus, at pandemien og isolationsregimerne ikke påvirkede udviklingen, da interaktionsprocesserne er baseret på kommunikation via e-mail og fjernudvikling. Af de kerneudviklere, som Linus interagerer med, kom ingen til skade af infektionen. Bekymringen var forårsaget af en af hans kollegers forsvinden i en måned eller to, men det viste sig at være forbundet med begyndelsen af karpaltunnelsyndrom.
Linus nævnte også, at når han udviklede 5.8 kernen, ville han skulle bruge mere tid på at forberede udgivelsen og frigive en eller to yderligere testudgivelser, da denne kerne blev udgivet med antallet af ændringer. Men samlet set går arbejdet med 5.8 ret glat indtil videre.
I et andet interview, Linus , at han ikke længere betragter sig selv som programmør og er gået væk fra at skrive ny kode, da han i lang tid kun har skrevet kode i en e-mail-klient. Det meste af hans tid går med at læse mail og skrive beskeder. Arbejdet kommer ned til at gennemgå patches og pull-anmodninger sendt via mailingliste, samt deltage i diskussioner om foreslåede ændringer. Til tider forklarer han sin idé med pseudokode eller foreslår ændringer til patches, som han sender i et svar uden kompilering og test, og overlader arbejdet med at bringe det til det rigtige niveau til den oprindelige forfatter af patchen.
Kilde: opennet.ru