Win32 проти glibc: чому найстабільніший Linux‑юзерспейс приніс Valve
Українське техношоу УТ‑2, яке ведуть розробники Саня та Ілля, зазвичай обговорює кібератаки, інфраструктуру й інструменти для девелоперів. Але в одному з останніх випусків розмова вийшла далеко за межі чергових вразливостей і торкнулася фундаментальної теми: що таке бінарна сумісність, чому Linux так ревно її тримає в ядрі — і водночас легко ламає в user space, та як у цю картину раптово вписалися Microsoft, Valve і Win32.
Це історія про те, як консервативність API може стати стратегічною перевагою, чому GNU‑світ сам собі стріляє в ногу через glibc — і чому найстабільнішим середовищем для застосунків на Linux виявляється не нативний POSIX‑юзерспейс, а шар емуляції Windows‑API від Valve.
Лінус, який не дозволяє ламати ядро
У світі Linux є одна майже сакральна константа: бінарна сумісність ядра. Лінус Торвальдс роками послідовно відстоює правило, яке для багатьох розробників драйверів і системного софту звучить як догма: kernel ABI не можна ламати.
Йдеться не про вихідний код, а саме про бінарний інтерфейс: як виглядають системні виклики, які структури даних очікує ядро, як воно взаємодіє з драйверами та модулями. Якщо колись зібраний бінарник очікує певної поведінки ядра, ця поведінка має зберігатися й надалі. Навіть якщо всередині все давно переписано.
Це рішення має дуже прагматичні наслідки.
По‑перше, воно дозволяє роками тримати в продакшені закриті драйвери й модулі, які ніхто не перекомпілює при кожному оновленні ядра. Ідеться не лише про відеодрайвери на кшталт NVIDIA, а й про внутрішні модулі в ентерпрайз‑інфраструктурі, де оновлення SDK або перескладання — це окремий проєкт.
По‑друге, це створює передбачуваність для дистрибутивів і вендорів. Можна оновлювати ядро в межах мажорної лінійки, не боячись, що половина системних утиліт або драйверів раптом перестане працювати через зміну ABI.
По‑третє, це дисциплінує розробників ядра. Будь‑яка зміна, яка потенційно ламає ABI, зустрічає жорстку критику. Торвальдс неодноразово публічно «розносив» патчі, що намагалися змінити поведінку існуючих інтерфейсів замість додати нові. У результаті Linux‑ядро еволюціонує радше шляхом розширення, ніж переписування контрактів.
Цікаво, що така консервативність ядра співіснує з дуже агресивним розвитком функціональності: нові системні виклики, підсистеми, драйвери з’являються постійно. Але старі інтерфейси залишаються, часто в напівзаконсервованому вигляді, лише для того, щоб не зламати старі бінарники.
З погляду архітектурної «чистоти» це може виглядати як технічний борг. З погляду екосистеми — це фундаментальна гарантія, на якій тримається довіра до Linux як до платформи.
Там, де все ламається: glibc і нестабільний user space
Парадокс у тому, що ця жорстка стабільність закінчується рівно на межі user space. Далі починається світ, де бінарна сумісність — не догма, а побічний ефект, який часто жертвують заради розвитку.
Ключовий гравець тут — glibc, стандартна C‑бібліотека, яку надає проєкт GNU і яка історично стала основою Linux‑юзерспейсу. Саме через неї проходить більшість системних викликів, саме вона реалізує стандартні функції роботи з пам’яттю, файлами, потоками, локалями, часом.
На відміну від ядра, glibc не має настільки жорсткої політики щодо ABI. Бібліотека еволюціонує, змінює внутрішні структури, іноді — поведінку функцій, додає й видаляє символи. Формально розробники glibc намагаються зберігати сумісність, але на практиці старі бінарники нерідко перестають працювати коректно на нових системах.
Це проявляється в кількох вимірах.
По‑перше, зміни в glibc можуть ламати програми, зібрані під старі версії дистрибутивів. Класичний сценарій: є закритий або просто давно не оновлюваний застосунок, який чудово працював на, скажімо, Ubuntu 14.04. На сучасній системі він раптом падає з дивними помилками лінкера або поводиться некоректно через зміну поведінки якоїсь функції.
По‑друге, дистрибутиви Linux часто рухаються різними темпами. Одна версія glibc у Debian, інша — в Fedora, третя — у якомусь embedded‑дистрибутиві. Це ускладнює поширення бінарників «одним файлом» без контейнерів чи статичної лінковки.
По‑третє, сам підхід GNU історично був орієнтований на вільну реалізацію Unix‑подібної системи, а не на жорстку комерційну стабільність API. У світі, де вихідний код доступний, очікується, що розробник просто пересбере свій застосунок під нову систему. Для open source це працює. Для закритого софту, який ніхто не чіпав 10–15 років, — уже ні.
У результаті виникає дивна ситуація: ядро Linux гарантує, що старий бінарний драйвер або системна утиліта зможе працювати й через багато років, але user space, через який проходить майже все, що бачить розробник, такої гарантії не дає. Для довготривалого запуску старих бінарників це перетворюється на мінне поле.
Саме тому частина сучасних мов і рантаймів намагається мінімізувати залежність від glibc, використовуючи альтернативні бібліотеки або власні реалізації системних викликів. Але це вже інша історія, яка виходить за межі цієї розмови.
Win32 як еталон: чому старі Windows‑програми досі живі
На цьому тлі Win32 API від Microsoft виглядає майже анахронізмом — у хорошому сенсі. Цей інтерфейс, який з’явився ще в епоху Windows 95, досі зберігає бінарну сумісність на сучасних версіях Windows.
Наслідок простий і дуже відчутний: програми, зібрані під Windows 95/98, часто можна запустити на Windows 10 чи 11 без будь‑яких змін і перекомпіляції. Так, іноді потрібні сумісні режими, іноді — дрібні обхідні маневри, але загалом Win32 залишається неймовірно стабільним контрактом між ОС і застосунком.
Це не випадковість, а свідомий стратегічний вибір Microsoft.
По‑перше, компанія десятиліттями будувала екосистему навколо Win32. Ламати її означало б втратити величезний пласт бізнес‑софтів, ігор, промислових систем, які ніхто не буде переписувати тільки тому, що вийшла нова версія ОС.
По‑друге, стабільність Win32 стала конкурентною перевагою Windows у корпоративному сегменті. Коли IT‑відділ планує міграцію з Windows 7 на Windows 10, аргумент «усі ваші старі програми продовжать працювати» важить дуже багато.
По‑третє, Microsoft інвестувала в шари сумісності, емуляцію старих поведінок і навіть у збереження деяких історичних «багів», на які покладалися старі програми. Це дорого й технічно неелегантно, але з точки зору бізнесу — виправдано.
У підсумку Win32 перетворився на один із найстабільніших публічних API у масовому софті. І саме ця властивість раптово зробила його ключовим гравцем… у світі Linux.
Proton і SteamOS: як Valve принесла стабільний Win32 у Linux
Valve, будуючи SteamOS і екосистему Steam Deck, зіткнулася з класичною проблемою Linux: більшість ігор написані під Windows. Переконати ігрову індустрію масово портити тайтли під Linux — завдання майже безнадійне. Натомість компанія пішла іншим шляхом: зробила Windows‑ігри «рідними» для Linux через шар сумісності.
Цим шаром став Proton — технологія, яка поєднує Wine, DXVK та інші компоненти, створюючи для гри ілюзію, що вона працює в знайомому Win32‑середовищі. З погляду бінарника гра бачить Windows‑API, хоча насправді виклики йдуть у Linux‑ядро та Linux‑стек.
Ключовий момент: Proton емулює саме Win32, а Win32 — надзвичайно стабільний. Це означає, що Valve може зосередитися на коректній реалізації цього API поверх Linux, не боячись, що Microsoft завтра радикально змінить контракт.
У результаті виникає парадоксальна ситуація: на Linux з’являється user space, який поводиться стабільніше, ніж нативний GNU‑юзерспейс.
Win32‑шар через Proton майже не ламається, тому що:
- сам Win32 API змінюється дуже обережно;
- Proton орієнтується на зворотну сумісність із величезним зоопарком ігор;
- будь‑яке оновлення, яке ламає популярні тайтли, миттєво помічається спільнотою геймерів.
На цьому тлі нативний Linux‑user space, що спирається на glibc і дистрибутивні бібліотеки, виглядає більш крихким. Оновлення системи може зламати старий нативний застосунок, тоді як Windows‑гра через Proton продовжить працювати, бо її контракт — Win32 — залишився незмінним.
Фактично Valve створила поверх Linux стабільний Win32‑шар, який для багатьох користувачів став основним способом запуску складного софту (ігри — це дуже вимогливий клас застосунків) без страху, що чергове оновлення системи все зламає.
Найстабільніший Linux‑юзерспейс — не Linux
Якщо подивитися на це з відстороненої перспективи, картина виходить майже іронічною.
З одного боку, є Linux‑ядро з жорсткою політикою збереження kernel ABI. Воно забезпечує стабільність на найнижчому рівні, дозволяючи роками запускати старі драйвери й системні утиліти.
З іншого боку, є GNU‑юзерспейс із glibc, який історично розвивався як частина вільної Unix‑подібної системи, де вихідний код завжди поруч, а перескладання — нормальна практика. У цьому світі бінарна сумісність у user space не була абсолютним пріоритетом, і це відчувається.
І нарешті, поверх усього цього з’являється Win32 через Proton — шар, який не має жодного відношення до історичного Unix‑або GNU‑спадку, але який виявляється найстабільнішим середовищем для запуску застосунків на Linux.
Фактично Win32 стає де‑факто найстабільнішим user space для Linux:
- Win32 API майже не ламається з часів Windows 95;
- Proton ретельно відтворює цю стабільність поверх Linux;
- нативний Linux‑user space, навпаки, може змінюватися разом із glibc та іншими бібліотеками.
Це створює дивний, але практично важливий ефект: якщо ви хочете максимальної бінарної стабільності на Linux для складного десктопного софту, найнадійніший шлях — не писати нативний Linux‑клієнт, а триматися Win32 і запускати його через Proton або подібні шари.
Для геймінгу це вже стало нормою. Для інших класів застосунків — CAD‑систем, наукового софту, промислових інструментів — така стратегія теж виглядає привабливою, хоча й не завжди прийнятною з точки зору ліцензій і підтримки.
Як GNU програло гонку ядра, але виграло user space
Щоб зрозуміти, чому Linux‑світ опинився саме в такій конфігурації, варто згадати історичний контекст. Проєкт GNU з самого початку ставив за мету створити повністю вільну Unix‑подібну систему: компілятори, утиліти, бібліотеки, ядро. Саме GNU надало glibc як основну C‑бібліотеку для user space, а також величезний набір інструментів, які сьогодні сприймаються як «стандартні» в Linux‑середовищі.
Але власне ядро GNU — Hurd — так і не стало достатньо готовим для широкого використання. Воно залишилося радше дослідницьким проєктом, тоді як Linux‑ядро, створене Торвальдсом, стрімко набирало популярність завдяки практичності, простоті й активній спільноті.
У якийсь момент стало очевидно: найшвидший шлях до повноцінної вільної ОС — поєднати Linux‑ядро з user space від GNU. Так народилася архітектура, яку сьогодні всі називають «Linux‑системою», хоча формально це радше «GNU/Linux»: ядро від Торвальдса, оточення — від GNU.
Це історичне рішення визначило й сучасні проблеми.
З одного боку, Linux успадкував від GNU потужний, але не надто консервативний у плані ABI user space. З іншого — отримав ядро з дуже жорсткою політикою стабільності, сформованою особистою позицією Торвальдса.
У результаті маємо гібрид: стабільне ядро плюс відносно ламкий user space. І на цей гібрид тепер накладається ще один шар — Win32 через Proton, який приносить у Linux зовсім іншу філософію сумісності, сформовану Microsoft.
Висновок: стабільність як політичне рішення, а не технічна властивість
Історія з Linux, glibc, Win32 і Proton добре показує, що бінарна сумісність — це не стільки технічна характеристика, скільки політичне й організаційне рішення.
Торвальдс зробив ставку на незламний kernel ABI — і це сформувало культуру розробки ядра. GNU зробило ставку на вільний код і еволюцію user space — і це призвело до меншої уваги до довготривалої бінарної стабільності. Microsoft зробила ставку на збереження Win32 будь‑якою ціною — і тепер цей API живе вже третє десятиліття, стаючи фундаментом навіть для Linux‑екосистеми через Proton.
Valve, у свою чергу, продемонструвала, що стабільний API можна «перенести» на іншу платформу, якщо достатньо інвестувати в шар сумісності. І вийшло так, що найстабільніший user space на Linux сьогодні — це не POSIX‑оточення з glibc, а Win32‑світ, який прийшов із Windows.
Для розробників це означає кілька речей.
По‑перше, вибір платформи й API — це вибір довгострокового контракту, а не лише технічних можливостей тут і зараз. По‑друге, open source не гарантує бінарної стабільності сам по собі — потрібна свідома політика, подібна до тієї, яку проводить Торвальдс для ядра. По‑третє, шари сумісності на кшталт Proton можуть стати не тимчасовим костилем, а повноцінним стратегічним рішенням, якщо під ними стоїть стабільний API на кшталт Win32.
І, нарешті, історія GNU Hurd і Linux нагадує: те, що не встигло дозріти вчасно, може назавжди залишитися на периферії, навіть якщо ідеї в ньому були цікавими. Архітектура сучасних систем — це завжди компроміс між технічною елегантністю, політикою сумісності й тим, що реально працює «тут і зараз».
Джерело
Обговорення в епізоді «Гейб радує Лінуса, GitHub губить ваш код, і чому RAG більше не потрібен. Все горить. mvc #27» на каналі УТ‑2:
https://www.youtube.com/watch?v=7D_zB5jkoJ8