«Я більше не розробник»: Лінус Торвальдс про два єдині інструменти, якими він користується | CyberCalm

Наталя ЗарудняНаталя ЗарудняГоловний редакторГоловний редактор та засновниця CyberCalm. Має понад 10-річний досвід роботи у сфері кібербезпеки та технологічної журналістики. Пише про захист даних, безпеку мобільних пристроїв, штучний інтелект та соціальні мережі.Слідкуйте: 17.07.2026 Поділитися 13 хвилин на прочитання

Засновник Linux, Лінус Торвальдс, виступаючи на конференції Open Source Summit India 2026 у Мумбаї, розповів, чому вважає себе скоріше керівником розробки, ніж програмістом. Він також поділився думками щодо того, як ШІ-інструменти одночасно допомагають та виснажують спільноту розробників ядра, і пояснив причини видалення підтримки застарілого обладнання з Linux. Про це повідомляє видання ZDNET.

Зміст

Linux 7.1: поступовий розвиток без зайвого ажіотажу
Періоди злиття коду, виправлення помилок та людський фактор
«Моя роль — керівник розробки, а не програміст»
NTFS та звільнення від застарілих компонентів
Git, C, Rust та філософія «hack and slash»
Rust не є панацеєю від логічних помилок
ШІ, LLM та «шум» проти реальних проблем
Неприємні помилки та принцип «не карати гінця»
«Linux не є проєктом проти ШІ»: якщо не подобається – створюйте форк
Ґодзілла, Індія та «хобі-проєкти»

Торвальдс не бачить сенсу в підтримці архаїчного обладнання чи програмного забезпечення.
Rust є важливим, але не вирішує всіх проблем з логічними помилками.
Розробники Linux вже активно використовують ШІ-інструменти для підтримки коду.

Linux 7.1: поступовий розвиток без зайвого ажіотажу

Розмову розпочав давній колега Торвальдса, Дірк Гондель, запитуючи про враження від випуску Linux 7.1. Нова нумерація ядра стартувала на початку 2026 року після версії 6.19. Торвальдс зазначив, що не мислить категоріями гучних релізів: «Для мене найважливіше – це послідовний, стабільний прогрес без раптових змін».

Він підкреслив, що з моменту створення команди системи контролю версій Git підхід залишається незмінним: «Ми не випускаємо релізи з гучними, ефектними новими функціями, і я свідомо уникаю такої моделі. Наша мета – безперервне, поступове вдосконалення та стабільний прогрес».

Проте, розвиток ШІ створює додатковий тиск на цей робочий процес. «Останнім часом це стало трохи складніше, оскільки ШІ виявляє неочікувані помилки, що додає стресу учасникам спільноти», – зізнався Торвальдс. Незважаючи на це, ядро продовжує дотримуватися стабільного графіка випусків кожні дев’ять-десять тижнів.

Періоди злиття коду, виправлення помилок та людський фактор

Торвальдс описав свій робочий ритм під час періодів злиття коду: «За два тижні я обробляю приблизно 200 злиттів. Це доволі приблизна кількість».

Навіть після десятиліть довіри до мейнтейнерів, він уникає змін в останній момент: «Якщо це не критично важливе виправлення, будь ласка, відкладіть його до наступного випуску, замість надсилати мені на фінальному етапі». Причина проста: виправлення може не коштувати навіть мінімального ризику спричинення нової проблеми.

Технічні аспекти його турбують менше, ніж людський чинник: «Новий код – це технічна задача, її можна виправити. Те, що справді викликає стрес – це проблеми взаємодії між людьми, які час від часу виникають. Повірте, виправити код значно легше, ніж вирішити конфлікти між особистостями».

«Моя роль — керівник розробки, а не програміст»

Ще одна зміна: Торвальдс більше не вважає себе програмістом. «Будьмо відвертими. Я вже майже не переглядаю код. Я не програміст, а керівник розробки», — заявив він.

Він досі пише невеликі патчі, але це радше пропозиції, ніж готові рішення: «Я все ще створюю код у тому сенсі, що надсилаю людям патчі, але чітко наголошую: це пропозиція, яка не була протестована. Я очікую, що саме відповідальні мейнтейнери коду запропонують мені виправлення у відповідь. Тому я дуже рідко самостійно комітую код».

Найважливішим для нього є розуміння загальної концепції: «При обробці pull request’ів я хочу бачити ширшу картину. Це одна з причин, чому я наполягаю на якісних поясненнях до pull request’ів: я їх читатиму. Мені важливо розуміти, що відбувається».

Він заглиблюється в код переважно тоді, коли це викликано необхідністю — збоями компіляції або конфліктами при злитті: «Я вирішував стільки конфліктів за ці роки, що, мабуть, міг би це робити уві сні. І доволі часто саме під час аналізу коду я виявляю проблеми».

NTFS та звільнення від застарілих компонентів

Щодо давно проблемної підсистеми Microsoft NTFS, Торвальдс пожартував: «NTFS роками був своєрідною „проблемною дитиною“ – знайти розробників для його підтримки бувало непросто».

«У нас є дві різні команди, які підтримують дві різні версії NTFS. Обидві працюють, і я просто дозволяю їм з’ясувати, хто з них виявиться успішнішим. Або ж обидві можуть існувати паралельно», – додав він.

«Я не надто сентиментальний щодо технологій. Ми активно намагаємося відмовлятися від підтримки обладнання, яким вже фактично ніхто не користується, хіба що в музеях», – зазначив Торвальдс.

Він залишається «переконаним прихильником підтримки обладнання, доки воно має користувачів», однак «в певний момент вартість підтримки застарілого устаткування стає надмірним тягарем». Як приклад він навів рішення про те, що з версії 7.2 ядро більше не підтримуватиме x86-машини без апаратної підтримки операцій з рухомою комою, як-от процесор 486 SX, випущений понад 30 років тому. Раніше з ядра вже було вилучено підтримку процесорів i486 та частини i586.

Це частина ширших зусиль з очищення Linux від застарілого коду: зокрема, поступово припиняється підтримка мережевих стандартів ISDN та ATM. Водночас, власники старої техніки зможуть продовжувати використовувати попередні версії ядра.

Git, C, Rust та філософія «hack and slash»

Говорячи про власні робочі інструменти, Торвальдс був небагатослівним: «Git та електронна пошта – це фактично єдині два інструменти, якими я користуюсь. Google я використовую для пошуку інформації». Він додав: «Я нетиповий. Більшість інших мейнтейнерів використовують значно більше інструментів, і, гадаю, багато з них починають застосовувати ШІ для перевірки патчів». Сам же він працює «на більш високому рівні»: «Я взаємодію з людьми, а не з інструментами».

На запитання про Rust – як у Git, так і в ядрі – він відповів стримано: «Я не впевнений, що Rust стане домінуючим. Я все ще вважаю Rust дуже цікавим, але C для мене – значно простіший інструмент».

Торвальдс продовжив: «Мене набагато більше захоплюють усі інструменти, які ми маємо для роботи з C», включаючи «автоматизовані засоби перевірки патчів» та «системи автоматичної перевірки електронних листів для патчів, такі як Sashiko».

Підсумовуючи, Торвальдс звернувся до аудиторії в Мумбаї: «Я людина, яка більше схильна до прямолінійного підходу, і мені все ще подобається чиста та проста сила C, і я не думаю, що це зміниться».

Rust не є панацеєю від логічних помилок

Торвальдс також застеріг від надмірної оцінки переваг Rust: «Rust допомагає уникнути деяких простих помилок, які можна зробити в C, але він не виправляє логічні помилки. Він не мислить за розробника: коли пишеться некоректний код, назва мови не має значення – результат буде некоректним».

Щодо змішаних кодових баз C/Rust, він зазначив, що гарантії є обмеженими: «Гарантії, які надає Rust, поширюються лише на частини кодової бази, написані виключно на Rust. А там, де є взаємодія з кодом на C, жодних гарантій немає». При цьому значна частина коду на Rust в Linux взаємодіє з основним кодом ядра на C, який, за словами Торвальдса, «значно кращої якості, оскільки тестувався в усіх можливих умовах».

«Деякі з наших найсерйозніших і найгучніших багів у ядрі останнім часом були саме логічними помилками. Це було просто неякісне програмування, яке, на жаль, трапляється навіть у ретельно підтримуваних підсистемах та важливих модулях, що потребують високого рівня захисту», – додав він.

ШІ, LLM та «шум» проти реальних проблем

Тільки на 26-й хвилині розмова перейшла до теми ШІ та великих мовних моделей (LLM). Спочатку Торвальдс уточнив свої нещодавні заяви про «десятикратне» зростання продуктивності завдяки LLM: за його словами, ця цифра була «не науковою» – він, зізнавшись, взяв її «зі стелі».

«Сьогодні ми, сподіваюся, досягли точки, де це створює більше продуктивності, ніж споживає», – продовжив він. «Але приблизно до початку цього року ми точно спостерігали більше „шуму“, згенерованого LLM, ніж корисного коду». Особливою проблемою стали неправдиві звіти: «Надходять звіти про помилки, які виглядають цілком правдоподібно, і потребують значних зусиль для з’ясування, що це була просто галюцинація. Коли люди витрачають багато часу на перевірку неправдивого звіту, згенерованого машиною, це серйозно виснажує ресурси».

Навіть зараз, каже він, «більшість якісних звітів вимагають більше, ніж просто LLM»: «Нам довелося докласти чимало зусиль. Якщо хтось виявив баг за допомогою LLM, недостатньо просто попросити модель скласти звіт і переслати його нам. Ми хочемо бачити запропонований патч, і щоб людина, яка використовувала LLM, брала участь у подальшому діалозі».

Чимало згенерованих ШІ патчів Торвальдс охарактеризував як «бездумні латки»: «Вони можуть виправити безпосередню проблему, але сам тип помилки нікуди не зникає – він просто чекає свого часу, щоб проявитися в іншому місці».

Для власних невеликих проєктів він використовує LLM як інструмент прототипування: «Досить часто код у такому вигляді непридатний для використання, але це чудовий спосіб швидко щось протестувати». Водночас для виправлень рівня ядра, за його досвідом, LLM «ще не досягли такого рівня».

Неприємні помилки та принцип «не карати гінця»

Торвальдс визнав, що деякі проблеми, виявлені ШІ, виявилися «абсолютно приголомшливими – цікавими у болісному сенсі», особливо вразливості безпеки, які «з’являються у технічних новинах через два дні».

Незважаючи на незручності, наголосив він, «я точно не з тих, хто карає гінця. Вважаю, нам значно краще, коли LLM знаходять помилки – навіть неприємні, навіть ті, які нам, можливо, варто було знайти ще два десятиліття тому».

За останні місяці, додав Торвальдс, «LLM вказали на кілька взаємопов’язаних багів»: різні розробники досліджували одні й ті самі ділянки ядра, «і саме тому ми мали три-чотири дуже тісно пов’язані баги, які стали предметом широкого обговорення протягом кількох тижнів».

«Linux не є проєктом проти ШІ»: якщо не подобається – створюйте форк

Вже після виступу в Мумбаї дискусія про роль ШІ в розробці ядра набула гостроти. 14 липня в розсилці ядра, де обговорювали інтеграцію системи Patchwork із Sashiko, Торвальдс відповів на закиди про «анти-LLM позицію» максимально прямо: «Я розумію, що деякі люди дуже не люблять ШІ, але це сфера, де я готовий твердо відстояти свою позицію як мейнтейнер найвищого рівня. Linux не є проєктом, що виступає проти ШІ, і якщо когось це не влаштовує – можна діяти за принципами відкритого коду і створити форк. Або просто піти».

«ШІ – це інструмент, як і будь-які інші, якими ми користуємося. І він очевидно корисний», – написав Торвальдс. «Ще рік тому це, можливо, не було настільки очевидно, але сьогодні це питання вже не стоїть. Той, хто в цьому сумнівається, очевидно, просто ним не користувався».

Він визнав, що ШІ може бути «болісним інструментом» – як через навантаження на мейнтейнерів, так і через те, що «він постійно знаходить складні баги». Але, за його словами, «рішення – не ховати голову в пісок і не кричати „ля-ля-ля, я вас не чую“. Рішення – зробити так, щоб LLM-інструменти допомагали мейнтейнерам, а не лише створювали їм проблеми».

«Ми нікого не змушуємо ним користуватися, але я буду дуже голосно ігнорувати тих, хто намагається відмовляти від нього інших», – додав він. «І, ні, ШІ не ідеальний. Але той, хто вказує на недоліки ШІ, хай водночас подивиться в дзеркало і побачить себе. Бо природний інтелект теж не завжди такий вже й блискучий».

Підсумок Торвальдса – квінтесенція його підходу: «У спільноті ядра ми працюємо з відкритим кодом, бо це забезпечує кращі технології, а не з ідеологічних міркувань. Тому рішення ми приймаємо насамперед виходячи з технічних переваг. А не через страх перед новими інструментами».

Сам привід для суперечки також показовий: Sashiko – повністю відкрита система на Rust, яка, за даними розробників, виявляє 53% помилок у невідфільтрованій вибірці з 1000 останніх виправлених комітів ядра. Причому всі ці помилки свого часу залишилися непоміченими людськими рецензентами. Назва походить від японської техніки вишивки сасіко – «маленькі стібки», якою традиційно укріплювали тканину в місцях зношування.

Ґодзілла, Індія та «хобі-проєкти»

Виступ у Мумбаї Торвальдс завершив на легкій ноті, розповівши, що використовує ШІ «для власних хобі-проєктів», зокрема для сімейних фотографій: «Щоразу, коли я відвідую нове місце – а це мій перший візит до Індії – я надсилаю дітям фотографії звідти. І з якоїсь дивної причини Ґодзілла, здається, супроводжує мене і з’являється на цих знімках».

«У ШІ є багато корисних і менш корисних застосувань», – підсумував він. «І, гадаю, Ґодзілла – чудова тема для завершення».

Будь ласка, залиште це поле порожнім

О, привіт
Приємно познайомитися!

Ми не розсилаємо спам! Ознайомтеся з нашою політикою конфіденційності для отримання додаткової інформації.

Перевірте свою поштову скриньку або папку зі спамом, щоб підтвердити підписку.

ТЕГИ:LinuxЛінус Торвальдспрограмування Поділитися Facebook Threads Копіювати посилання Друк Попередня публікація 5 причин, чому електронна пошта ніколи не помре Наступна публікація Як відновити пошкоджену флешку: інструкція