Torvalds: по-здрав модел за AI приносите в ядрото

Линус Торвалдс пусна на 1 ноември първия release candidate на Linux 7.4 и използва съобщението, за да каже нещо, което звучи почти като промяна на позицията му: потокът от AI генерирана работа вече не се излива върху ядрото по време на стабилизацията, а идва навреме — в merge window. „Мисля, че това е много по-здрав модел“, пише той в анонса на 7.4-rc1, цитиран и от The Register.

Рекорд в цифри

Merge window-ът на 7.4 е най-големият в историята на ядрото. Phoronix отчита 19 671 комита срещу 16 267 за същата фаза на 7.3 — около 21% повече, или 18 591 changeset-а, ако не броите merge комитите. Торвалдс го описва по-просто: „почти 20 000“ при обичайни „около 15 000“.

Приносителите също са рекордни — 2678 разработчици, от които 625 за първи път изпращат код в ядрото. И всичко това без отсрочката от една седмица, която Торвалдс беше оставил като опция при излизането на 7.3; двуседмичният прозорец затвори по график, при това докато той е бил в отпуска.

Какво точно каза Торвалдс

Ключовият абзац си заслужава да се прочете цял:

This is a *BIG* merge window. I think the reason is the by now obvious
one, but I'm actually taking it as a good sign: I'm *much* happier with
the flood of AI triggered work going into the merge window than it
showing up mainly as extra fixes during the -rc period.

Разликата е в тайминга, не в технологията. Когато AI намерените дефекти пристигат в merge window, те минават през нормалното ревю заедно с всичко останало и имат седмици да се утаят. Когато пристигат като поток от поправки в -rc периода, те се състезават за внимание точно с работата, която трябва да стабилизира release-а — а това е най-лошият възможен момент.

Торвалдс не твърди, че машините вече пишат ядрото. Самият той уточнява, че релийзът е „голям и пълен с поправки на проблеми, намерени от AI (и все по-често патчовете също са предложени от AI, макар че често ги пренаписваме)“. Тоест предложението е отправна точка; кодът, който влиза в git, минава през човек.

Скритата уговорка: едната трета „шум“

Около една трета от промените в 7.4 са register offsets и bit masks за GPU-тата на AMD — автоматично генерирани хедъри, които надуват статистиката, без да значат нищо за ревюто. Коментарът на Торвалдс е кратък: „Just ignore the noise.“

Това е важно уточнение за всеки, който се готви да обяви, че AI е утроил производителността на kernel разработката. Рекордът е реален, но не всеки комит тежи еднакво. Отделен проблем, който не изчезва: броят на maintainer-ите не расте с темпото на патчовете, а именно те носят тежестта на ревюто.

Какво носи 7.4 освен статистика

Съдържанието е солидно и за крайни потребители:

• AMD: HDMI 2.1 е включен по подразбиране в amdgpu, подготвена е основата за Zen 6, а функцията PerfOpt цели AI и LLM натоварвания на вградената графика.
• Apple: първи device tree файлове за M4 и A18 Pro — базово разпознаване, не готова за ежедневна употреба поддръжка.
• Google: mainline поддръжка за Tensor G5 и Pixel 10.
• Intel и Qualcomm: IPU8 за лаптопите с Nova Lake, Rugged Panther Lake и допълнителна работа по Snapdragon X2.
• Файлови системи: опционален buffered iomap за EXT4, оптимизации в Btrfs и XFS, премахната е остарялата BFS.
• Плюс по-бърза компилация на самото ядро и поддръжка за 10-инчовия монитор на Raspberry Pi.

Защо всички гледат точно този релийз

7.4 се очаква да бъде LTS версията за 2026 г. — тази, която ще стои в дистрибуциите и в embedded устройства години напред. Част от обема се обяснява именно с това: разработчиците бутат функционалност, за да я хванат в дългосрочно поддържаното ядро. Финалът е насрочен ориентировъчно за 20 декември, с резервна дата 27 декември, ако -rc цикълът поиска още една седмица. За сравнение, kernel.org в момента показва 7.3.1 като stable от 30 октомври.

Заключение: Торвалдс не е станал ентусиаст на AI — той е прагматик, който е открил работещ процес. Инструментите намират истински дефекти, хората пренаписват предложенията им, а потокът е насочен към фазата, в която ядрото го понася. Същият въпрос, който стои пред отворените AI модели, стои и тук: не дали машината може да произведе код, а кой има капацитета да го прегледа. Засега отговорът на kernel общността е „хората, но по-рано в цикъла“.