Минулого тижня віртуальної конференції «» Лінус Торвальдс
сьогодення та майбутнє ядра Linux у вступній бесіді з Дірком Хонделом (Dirk Hohndel) з компанії VMware. Під час обговорення було порушено тему зміни поколінь серед розробників. Лінус зазначив, що попри майже 30-річну історію проекту, загалом, спільнота не така й стара — серед розробників багато нових людей, яким ще не виповнилося й 50 років. Старожили дійсно старіють і стають сивими, але ті, хто давно залучений до проекту, як правило, пішли від написання нового коду і займаються завданнями, пов'язаними із супроводом або управлінням.
Пошук нових мейнтейнерів відзначається як велика проблема. У співтоваристві багато активних розробників, які раді писати новий код, але мало хто готовий присвятити свій час на супровід та перевірку чужого коду.
Крім професіоналізму, мейнтейнери повинні мати беззаперечну довіру. Від мейнтейнерів також вимагається безперервне залучення до процесу та постійна робота — супроводжуючий завжди має бути доступним, щодня читати листи та реагувати на них. Робота в подібних умовах потребує великої самодисципліни, тому мейнтейнерів мало і їх не вистачає, а пошук нових мейнтейнерів, здатних рецензувати чужий код і спрямовувати зміни вищим мейнтейнерам, стає однією з головних проблем спільноти.
На питання про експерименти в ядрі Лінус висловився, що спільнота розробників ядра тепер не може дозволити собі деякі божевільні зміни, які робилися раніше. Якщо раніше технологія ні до чого не зобов'язувала, то тепер від ядра Linux залежить дуже багато систем.
На питання про переробку ядра такими мовами як Go і Rust, оскільки є ризик, що в 2030 роках Сі-розробники перетворяться на нинішню подобу розробників на COBOL, Лінус відповів, що мова Сі залишається в десятці популярних мов, але для неосновних підсистем, таких як драйвери пристроїв, розглядається надання прив'язок для розробки такими мовами як Rust. У майбутньому очікується надання різних моделей написання подібних вторинних компонентів, які не обмежуються застосуванням мови Сі.
компанії Apple використовувати в настільних комп'ютерах та ноутбуках процесори архітектури ARM Лінус прокоментував з надією, що цей крок допоможе зробити ARM доступнішим для робочих станцій. Останні 10 років Лінус скаржився на неможливість знайти ARM-систему, яка б підходила для системи розробника. За аналогією з тим, як використання ARM компанією Amazon дозволило просунути цю архітектуру в серверних системах, не виключено, що завдяки діям Apple через кілька років стануть доступними і потужні ПК на ARM, який можна використовувати для розробки. З приводу свого на базі процесора AMD Лінус згадав, що все працює нормально, якщо не вважати кулера, що сильно шумить.
Про заняття ядром Лінус висловився, що це водночас і нудно та цікаво. Нудно, тому що доводиться стикатися з рутиною виправлення помилок і упорядкування коду, а цікаво, оскільки постійно необхідно розбиратися з новими технологіями, взаємодіяти з обладнанням на низькому рівні і контролювати все, що відбувається.
Про COVID-19 Лінус згадав, що пандемія та режими ізоляції не вплинули на розробку, оскільки процеси взаємодії засновані на спілкуванні електронною поштою та віддаленою розробкою. З розробників ядра, з якими взаємодіє Лінус, ніхто не постраждав від інфекції. Занепокоєння викликало пропадання на місяць чи два одного з соратників, але воно виявилося пов'язаним із виникненням тунельного синдрому.
Лінус також згадав про те, що при розробці ядра 5.8 доведеться витратити більше часу на підготовку релізу, і випустити один або два додаткові тестові випуски, оскільки дане ядро видалося за кількістю змін. Але загалом робота над 5.8 поки що проходить досить гладко.
В іншому інтерв'ю Лінус , що він не вважає себе програмістом і відійшов від написання нового коду, оскільки давно пише код лише у поштовому клієнті. Весь основний час у нього йде на читання пошти та написання повідомлень. Робота зводиться до рецензування патчів і pull-запитів, що відправляються через поштову розсилку, а також участі в обговореннях пропонованих змін. Часом він пояснює свою ідею псевдокодом або пропонує редагування в патчі, які відправляє у відповіді без компіляції та тестування, залишаючи роботу з доведення до належного рівня на початкового автора патчу.
Джерело: opennet.ru