At last week's virtual conference “” Linus Torvalds
the present and future of the Linux kernel in an introductory talk with Dirk Hohndel from VMware. During the discussion, the topic of generational change among developers was raised. Linus pointed out that despite the project’s nearly 30-year history, the community is not that old overall — there are many new people among the developers who are not even 50 yet. The veterans are indeed aging and turning gray, but those who have long been involved in the project have generally moved away from writing new code to handling maintenance or management tasks.
The search for new maintainers is noted as a major problem. There are many active developers in the community who are eager to write new code, but few are willing to dedicate their time to maintenance and reviewing others' code.
Besides professionalism, maintainers must have unquestionable trust. Maintainers are also required to be continuously engaged in the process and to work consistently — they must always be available, reading emails every day and responding to them. Working under such conditions demands high self-discipline, which is why there are few maintainers and they are lacking; the search for new maintainers who can review others' code and direct changes to senior maintainers is becoming one of the main problems in the community.
When asked about experiments in the kernel, Linus remarked that the kernel developer community can no longer afford some of the crazy changes that were made in the past. While earlier development was not binding, now too many systems depend on the Linux kernel.
In response to a question about rewriting the kernel in languages like Go and Rust, as there is a risk that by the 2030s C developers will become like current COBOL developers, Linus replied that C remains among the top ten popular languages, but for non-core subsystems, such as device drivers, the possibility is being considered. providing bindings for development in languages such as Rust. In the future, different models for writing such secondary components are expected to be offered, not limited to the use of the C language.
Apple's plan to use ARM architecture processors in desktop computers and laptops has prompted Linus to express hope that this move will make ARM more accessible for workstations. For the last 10 years, Linus has complained about the inability to find an ARM system suitable for a developer's system. Just as Amazon's use of ARM has helped advance this architecture in server systems, it is possible that thanks to Apple's efforts, powerful ARM PCs usable for development will become available in a few years. based on an AMD processor, Linus mentioned that everything works fine, except for a very noisy cooler.
Regarding core development, Linus expressed that it is both boring and interesting. Boring because it involves the routine of bug fixes and code tidying, but interesting because it constantly requires engaging with new technologies, interacting with hardware at a low level, and overseeing everything that happens.
Regarding COVID-19, Linus noted that the pandemic and isolation periods did not affect development since the interaction processes are based on email communication and remote development. None of the kernel developers that Linus interacts with were affected by the infection. There was concern over one colleague's disappearance for a month or two, but it turned out to be related to the onset of tunnel syndrome.
Linus also mentioned that when developing kernel 5.8, more time will need to be spent preparing the release, and one or two additional test releases will need to be issued, as this kernel turned out to be in terms of changes. But overall, work on 5.8 is currently going quite smoothly.
In another interview, Linus , that he no longer considers himself a programmer and has moved away from writing new code, as he has long only written code in the email client. Most of his time is spent reading emails and writing messages. His work mainly involves reviewing patches and pull requests sent via email newsletter, as well as participating in discussions of proposed changes. Occasionally, he explains his idea using pseudocode or suggests edits to patches, which he sends in response without compilation and testing, leaving the task of refining it to the original author of the patch.
Source: opennet.ru
