Наталя Зарудня
Наталя ЗарудняГоловна редакторкаГоловна редакторка та засновниця CyberCalm. Має понад 10-річний досвід у сфері кібербезпеки та технологічної журналістики. Пише про захист інформації, безпеку мобільних пристроїв, штучний інтелект та соціальні мережі.Слідкуйте: 17.07.2026Поділитися13 хв. читання
Засновник Linux, Лінус Торвальдс, під час свого виступу на конференції Open Source Summit India 2026 у Мумбаї, поділився своїми думками щодо того, чому він вважає себе скоріше керівником розробки, ніж програмістом. Він також розповів, як ШІ-інструменти одночасно допомагають і створюють виклики для спільноти розробки ядра, і пояснив причини поступової відмови від підтримки застарілого обладнання в Linux. Цю інформацію передає видання ZDNET.
Зміст
- Linux 7.1: повільний, стабільний поступ без помпезних анонсів
- Час злиття коду, внесення виправлень та міжособистісні нюанси
- «Я не програміст, а керівник розробки»
- NTFS та позбавлення від «музейних експонатів»
- Git, C, Rust та філософія «рубай і ріж»
- 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 та філософія «рубай і ріж»
Щодо своїх робочих інструментів, Торвальдс був небагатослівний: «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Лінус ТорвальдспрограмуванняПоділитисяFacebookThreadsКопіювати посиланняДрукЩо думаєте?В захваті1Сумно0Смішно0Палає0Овва!0Попередній матеріал
5 причин, чому електронна пошта ніколи не помреНаступний матеріал
Як відновити пошкоджену флешку: інструкція
Актуальне
ШІ визначає місце зйомки фото у 9 випадках із 10 — і шахраї вже будують на цьому фішинг
17.08.2026
Як підписати PDF на смартфоні: інструкція для iPhone та Android
14.08.2026
Комбінації клавіш у Windows 11: повний довідник
18.08.2026
Apple закрила майже 30 вразливостей в iOS 26.6.1 та macOS Tahoe 26.6.2 — третє оновлення безпеки за три тижні
18.08.2026
Як змінити обліковий запис Google за замовчуванням на Android
16.08.2026
Рекомендовано
Комп’ютер
Як встановити WSL у Windows 11 і Windows 10: покрокова інструкція
30.07.2026
Огляди
Чому Linux наздоганяє Windows: порівняння двох операційних систем
23.03.2026
Комп’ютер
Вийшов Linux 6.19 з анонсом майбутньої версії 7.0
10.02.2026
Огляди
Kali Linux проти Parrot OS: який дистрибутив краще для кібербезпеки?
05.02.2026