At last week's virtual conference "Β» Linus Torvalds
the present and future of the Linux kernel in an introductory talk with Dirk Hohndel of VMware. During the discussion, the topic of generational change among developers was touched upon. Linus pointed out that despite the almost 30-year history of the project, in general, the community is not so old - there are many new people among the developers who are not yet 50 years old. Old-timers do get old and grey-haired, but those who have been involved in a project for a long time tend to move away from writing new code and into tasks related to maintenance or management.
The search for new maintainers is noted as a big problem. There are many active developers in the community who are happy to write new code, but few are willing to devote their time to maintaining and checking someone else's code.
In addition to professionalism, maintainers must enjoy unquestioning trust. Maintainers are also required to be constantly involved in the process and work constantly - the maintainer must always be available, read letters every day and respond to them. Working in such an environment requires a lot of self-discipline, so maintainers are few and far between, and finding new maintainers who can review other people's code and push changes to higher maintainers becomes one of the main problems in the community.
When asked about experimentation in the kernel, Linus said that the kernel community can no longer afford some of the crazy changes that used to be made. If earlier development was not obligatory, now too many systems depend on the Linux kernel.
Asked about reworking the core in languages ββsuch as Go and Rust, as there is a risk that in the 2030s C developers will turn into the current kind of COBOL developers, Linus answered that the C language remains in the top ten popular languages, but for non-core subsystems, such as device drivers is considered providing bindings for development in languages ββsuch as Rust. In the future, it is expected to provide different models for writing such secondary components, not limited to using the C language.
Apple to use ARM architecture processors in desktops and laptops Linus commented with the hope that the move will help make ARM more accessible to workstations. For the past 10 years, Linus has been complaining about the inability to find an ARM system that would fit the developer's system. Similar to how Amazon's use of ARM allowed the architecture to be promoted in server systems, it is possible that thanks to Apple's actions, powerful ARM PCs will become available in a few years, which can be used for development. About your based on the AMD processor, Linus mentioned that everything works fine, except for a very noisy cooler.
Linus said about core classes that it was both boring and interesting at the same time. Boring, because you have to deal with the routine of fixing errors and putting the code in order, but interesting, because you constantly need to deal with new technologies, interact with equipment at a low level and control everything that happens.
About COVID-19, Linus mentioned that the pandemic and isolation regimes did not affect the development, since the interaction processes are based on email communication and remote development. Of the kernel developers with whom Linus interacts, no one was affected by the infection. The concern was caused by the disappearance of one of the associates for a month or two, but it turned out to be associated with the occurrence of carpal tunnel syndrome.
Linus also mentioned that the development of the 5.8 kernel will take more time to prepare the release, and release one or two additional test releases, since this kernel has turned out by the number of changes. But in general, work on 5.8 is going pretty smoothly so far.
In another interview with Linus that he no longer considers himself a programmer and has moved away from writing new code, since he has been writing code for a long time only in an email client. Most of his time is spent reading mail and writing messages. The work is reduced to reviewing patches and pull requests sent via the mailing list, as well as participating in discussions of proposed changes. At times, he explains his idea with pseudocode or proposes edits to patches that he sends in a response without compiling and testing, leaving the work of bringing it up to the proper level on the original patch author.
Source: opennet.ru