Розділ 11. Linus проти Танненбаума
Перед битвою
Січень 1992 року. Лінус Торвальдс, 22-річний студент з Гельсінкі, працює над своїм хобі-ядром Linux уже п’ять місяців. Перша версія — 0.01 — вийшла у вересні 1991-го. До січня 1992-го це вже версія 0.12, з підтримкою віртуальної пам’яті, з мережею, з робочою файловою системою. Кілька десятків добровольців у різних країнах допомагають з кодом.
Linux ще нікому не відомий. Не лідер ринку. Не загроза комусь. Просто ще одна спроба зробити безкоштовний Unix для PC. У світі їх кілька — є MINIX (про який зараз буде мова), є 386BSD (нащадок Berkeley Unix), є Coherent. Усі вони борються за невеликий ринок ентузіастів.
А MINIX має особливе місце. Її автор — Ендрю Танненбаум, професор Vrije Universiteit в Амстердамі, голландський комп’ютерний учений, автор підручників, за якими вчилося ціле покоління програмістів (“Operating Systems: Design and Implementation”, “Modern Operating Systems”, “Computer Networks”). Танненбаум написав MINIX як навчальну ОС — щоб студенти могли вчити дизайн ОС не теоретично, а на реальному коді. MINIX був безкоштовним, з повним вихідним кодом, працював на IBM PC. До 1991 року MINIX був стандартом у курсах ОС в університетах.
Лінус Торвальдс сам учився за підручником Танненбаума і використовував MINIX вдома. Власне, його Linux частково надихнувся MINIX-ом — він хотів зробити “MINIX, але без обмежень”. Танненбаум жорстко контролював, що додається в MINIX (свідомо тримав його простим — це навчальна ОС, не продакшн). Лінус хотів свободи.
29 січня 1992 року, у новинній групі comp.os.minix з’являється повідомлення від професора Танненбаума. Його заголовок: “LINUX is obsolete” (“Linux застарілий”).
І почалося.
Аргументи Танненбаума
Танненбаум писав:
“Як, можливо, всі знають, MINIX є невеликою системою, яку я написав кілька років тому як інструмент навчання. Зараз з’явилося кілька клонів MINIX. Один з них називається LINUX, написаний Лінусом Торвальдсом. Хоча сам я не використовував LINUX, я прочитав про нього і поговорив з людьми, які його використовують. Я хотів би висловити кілька думок.”
Його думки були гострими. Три головні аргументи:
Аргумент №1: Linux — моноліт, а це застаріла архітектура.
Танненбаум писав, що монолітні ядра (де всі підсистеми — драйвери, файлова система, мережа, пам’ять — живуть у одному великому ядрі) — це архітектурний релікт 1970-х. Сучасний підхід — мікроядра (microkernels), де ядро — мінімальне (керування пам’яттю, перемикання процесів, обмін повідомленнями), а всі інші підсистеми — це звичайні програми, які спілкуються з ядром через повідомлення.
“Як я писав у своєму підручнику ОС у 1987-му, мікроядра — майбутнє. Що б Лінус не казав, MINIX не є застарілим у 1992-му. Linux — є.”
Аргумент №2: Linux — непереносний, прив’язаний до 386.
“Лінус написав Linux прямо для процесора 80386. Він не переноситься на інші архітектури. Через два роки, коли 386 буде виглядати як копійчана іграшка, Linux буде застарілим. MINIX портується на десятки архітектур, від 8088 до Sun SPARC.”
Аргумент №3: Linux керується однією людиною без стратегії.
“Лінус робить що йому хочеться, без плану, без архітектурної концепції. Це може бути цікаво для нього, але це не спосіб робити серйозне програмне забезпечення.”
І насамкінець, Танненбаум закінчив із покровительським тоном:
“Тож вибачте, що я виставив MINIX як кращий, але я просто намагаюся допомогти людям зрозуміти, що ми тут робимо. Linux — цікавий експеримент, але він застаріватиме швидко, як старі автомобілі.”
Лінус відповідає
Через декілька годин Лінус Торвальдс відповів. Стиль його був… менш академічним.
“Ну ось знов почалось. Перш ніж я скажу щось ще, скажу: я знаю, що Andrew Tanenbaum написав MINIX, і він написав про неї підручники. Я поважаю його за це. Але це не означає, що його думка тут — закон.”
“Я погоджуюсь, що мікроядра гарні. Але вони не для всього. У реальному світі люди хочуть швидкі ОС. Linux швидкий. MINIX повільний. Це факт. Можеш сидіти у вежі зі слонової кістки і теоретизувати — а я тут пишу систему, на якій люди РЕАЛЬНО ПРАЦЮЮТЬ.”
“Так, Linux зараз тільки на 386. Але ти знаєш чому? Тому що 99% людей мають 386. Не Sun SPARC. Не VAX. 386.”
“І так, я роблю Linux як хочу. Тому що це МОЯ робота, і люди приєднуються тому, що їм подобається результат, а не тому, що я підкоряюсь академічній моді.”
Це був несподівано різкий, але переконливий тон. Лінус не злякався імені Танненбаума.
Танненбаум відповів. Лінус відповів знову. Дискусія розгорталася. До неї приєдналися інші — інженери з Sun, з MIT, з університетів, кілька знаменитостей індустрії. Деякі підтримували Танненбаума (“так, мікроядра — це майбутнє”). Інші — Лінуса (“Танненбаум не розуміє реального світу”).
Це продовжувалося тижнями. Перетворилося у легендарний обмін повідомленнями, відомий як “Linus vs. Tanenbaum debate”. Сьогодні архіви усієї дискусії доступні в інтернеті. Багато програмістів вважають це чи не найважливішою публічною технічною дискусією в історії індустрії.
Чому? Бо вона була не про деталі — а про філософію. Як треба будувати програмне забезпечення?
Що таке моноліт і що таке мікроядро
Перш ніж говорити, хто переміг, треба зрозуміти, про що сперечалися.
Моноліт. Усі функції операційної системи (керування процесами, пам’яттю, файлова система, мережа, драйвери, шифрування, тощо) живуть у одному великому ядрі, у тому самому адресному просторі, з повними правами на залізо. Виклики між підсистемами — це звичайні виклики функцій, швидкі і прямі.
Приклади монолітних ядер: Linux, FreeBSD, OpenBSD, NetBSD, традиційний AIX, Solaris.
Мікроядро. Ядро містить тільки мінімум — базові примітиви для: - керування пам’яттю (виділяти, звільняти), - перемикання процесів, - передавання повідомлень між процесами (IPC).
Усе інше — драйвери, файлові системи, мережеві стеки — це звичайні процеси користувацького простору, які спілкуються через повідомлення.
Приклади: MINIX, MACH (CMU, 1985), L4 (різні варіанти), QNX, GNU Hurd (теоретично), seL4.
Гібриди. macOS і Windows — формально гібриди. Microsoft Windows NT був задуманий як мікроядро (під впливом MACH), але з часом для швидкості багато коду перенесли в ядро. macOS теж — XNU-ядро, нащадок MACH, але з BSD-моноліт-частиною всередині.
Чому Танненбаум вважав мікроядра кращими
З академічної точки зору, мікроядра мають очевидні переваги:
Надійність. Якщо драйвер у моноліті падає — впаде вся система. Якщо драйвер у мікроядрі падає — це звичайний процес, його можна перезапустити. ОС не помічає.
Безпека. Драйвер у моноліті має повні права. Помилка у драйвері = повний доступ до системи (привіт, CVE). У мікроядрі драйвер ізольований — він має доступ тільки до своєї пам’яті.
Модульність. Можна замінити одну підсистему, не торкаючи інших. У моноліті всі тісно пов’язані.
Менший trusted computing base. Ядро менше — менше коду, який має повні права. Це принципово важливо для безпеки. У Linux — 30 мільйонів рядків з повними правами. У seL4 — 10 тисяч.
Формальна верифікація можлива. Маленьке ядро можна математично довести правильним. seL4 саме це і зробив. Великий моноліт — теоретично неможливо.
Усе це звучить чудово. Чому ж тоді мікроядра не перемогли?
Чому моноліт переміг (на практиці)
З практичної точки зору, у мікроядра є один великий мінус: продуктивність.
Кожен виклик у моноліті — це звичайний function call,
кілька наносекунд. У мікроядрі це обмін повідомленнями між
процесами — десятки мікросекунд (тисячі наносекунд). У
сотні-тисячі разів повільніше.
На простих задачах різниця непомітна. На складних задачах (бази даних, веб-сервери, файлові операції) це падіння продуктивності у 5-20 разів.
Для академічної ОС (як MINIX) це не страшно. Для продакшн-ОС (як Linux) — катастрофа.
У 1990-ті, коли йшла дискусія, був ще один проект — MACH. Університет Карнегі-Меллон робив “правильне” мікроядро з академічною строгістю. NeXT (компанія Стіва Джобса після його вигнання з Apple) використала MACH для своєї NeXTSTEP ОС. GNU Project обрав MACH для свого ядра — Hurd. Ось-ось мав вибухнути світ мікроядер.
Не вибухнув. NeXTSTEP виявився повільним і важким. Стів Джобс, повернувшись у Apple у 1997-му, привіз NeXTSTEP як основу майбутньої macOS — але інженери Apple пішли і поступово переписали більшість швидких частин у моноліт-стилі. Сучасне macOS-ядро (XNU) — формально гібрид з MACH-нащадком всередині, але насправді працює як майже-моноліт.
GNU Hurd ніколи не був закінчений. Тридцять років розробки, ще не вийшов 1.0. Вже легенда у спільноті: “буде готовий наступного року” з 1990-го.
Linux, з його грубим монолітом, перемагав на всіх фронтах. Швидший. Простіший. Надійний “на практиці”, якщо не на папері. Розробників більше. Драйверів більше. Хмарні провайдери обирали Linux. Android вибрав Linux. Embedded-світ вибрав Linux.
До 2010-х було очевидно: моноліт переміг для general-purpose computing.
Але мікроядра не вмерли
Однак — і це важливо — мікроядра виграли в одному дуже специфічному, дуже важливому світі: критично важливі системи (safety-critical, mission-critical, secure-critical).
Подивимось, де живуть мікроядра сьогодні:
QNX — мікроядерна ОС від канадської компанії QNX Software Systems (зараз належить BlackBerry). Працює в: - Більшості автомобілів (BMW, Audi, Mercedes — інфо-розважальні системи на QNX, але також у деяких системах безпеки). - Атомних електростанціях. - Медичному обладнанні. - Військовій техніці.
INTEGRITY — мікроядро Green Hills Software. Сертифіковане для авіоніки (літак Boeing 787 використовує INTEGRITY у деяких підсистемах).
L4 і його варіанти (OKL4, PikeOS, Fiasco) — у мобільних телефонах. Майже кожен мобільний телефон у світі має L4-мікроядро у своєму baseband-чіпі (саме він відповідає за зв’язок з мережею). Це окрема ОС від основної (Android чи iOS), яка керує радіо. Працює на L4 саме тому, що radio-firmware має бути надійною — телефон не може втратити зв’язок із 911.
seL4 — формально верифіковане мікроядро (про яке ми говорили на початку книги). Використовується у DARPA-проектах, у деякому військовому обладнанні, у дослідницьких проектах автономних систем.
Symbian — стара мобільна ОС (Nokia, до iPhone) — теж була мікроядерна.
Тобто мікроядра виграли там, де надійність важливіша за швидкість. А моноліт — там, де швидкість важливіша за надійність (тобто скрізь у звичайному обчисленні).
Танненбаум був правий, що мікроядра — кращі архітектурно. Лінус був правий, що для більшості задач прагматизм перемагає академічну чистоту.
Обидва праві у своїй сфері.
Mea culpa Танненбаума, через 14 років
У 2006 році Танненбаум опублікував у журналі Computer статтю “Can We Make Operating Systems Reliable and Secure?” — у якій з усмішкою визнав:
“Я програв дискусію 1992 року. Linux переміг. Моя помилка була в тому, що я не зрозумів, наскільки прагматика переможе академічні цінності у короткостроковій перспективі.”
Але потім додав:
“Однак моя позиція не була неправильною. Просто моноліт виграв тимчасово. У довгостроковій перспективі ми побачимо, що більшість критичних систем повернеться до мікроядер. Це вже починається — у автомобілях, в медицині, в авіації. Колись повернеться і до серверів та десктопів. Прагматика виграє битву, але не війну.”
Через 18 років після цієї статті, у 2024-му, бачимо: - Мікроядра дійсно проникли в усі критичні системи. - Linux все ще домінує на серверах і десктопах. - Питання “коли ми зможемо довірити автономному ШІ керувати ядерним реактором?” — це питання про мікроядра. Бо моноліт у 30 мільйонів рядків коду неможливо верифікувати.
Танненбаум, можливо, отримає друге дихання саме зараз.
Що з цього винести
- У 1992-му Лінус Торвальдс і Ендрю Танненбаум провели публічну дискусію, яка визначила ментальну карту операційних систем на наступні тридцять років.
- Танненбаум аргументував за мікроядра — менший trusted computing base, краща ізоляція, надійність, можливість формальної верифікації.
- Лінус аргументував за моноліт — простіше, швидше, працює сьогодні.
- На практиці моноліт переміг для загальних обчислень — Linux, BSD, навіть macOS і Windows фактично моноліти всередині.
- Мікроядра виграли для критично важливих систем — автомобілі (QNX), літаки (INTEGRITY), мобільні baseband (L4), верифіковані системи (seL4).
- Дискусія триває і набуває нової актуальності зараз, коли ми хочемо довіряти автономному ШІ керувати реальним залізом. Великий моноліт довірити неможливо. Маленьке верифіковане мікроядро — можна.
- Найважливіший урок — це не “хто був правий”. А те, що архітектурні дискусії визначають реальність на десятиліття вперед. Програмування — не “просто інженерія”. Це філософські вибори, наслідки яких тривають довше за людське життя.
У наступному, останньому розділі Частини III, поговоримо про мови програмування. Чому їх так багато — більше семисот? Чому навіть прості задачі мають десятки несумісних рішень? І чи буде колись “одна мова, яка переможе всі”?
Спойлер: ні. Але причини цієї відмови — самі по собі цікаві.