Page cache в Linux - це дуже важлива штука: коли система читає файл з диска, вона не хоче кожного разу йти на диск знову, тому тримає копію сторінок файлу в пам'яті. Запустили su, прочитали бінарник, поклали сторінки в кеш. Наступного разу можна взяти з пам'яті, а не бігать на диск.

І от уявімо баг, який дозволяє користувачу без root-доступу підмінити кілька байтів не у файлі на диску, а в цій закешованій копії. На диску все чесно. Хеші здається чесні. Права доступу здається чесні. Але коли система бере сторінку з пам'яті, там уже лежить трошки інший код. Не треба хачити всю ОС. Іноді достатньо дуже маленької щілини в дуже правильній оптимізації.

Звідси починається клубок про контейнери, linux, jvm, lisp і багато іншої шизофренії. Бо якщо баг живе в ядрі, то питання вже не "чи оновив я пакет усередині контейнера". Питання простіше і неприємніше: а чи контейнер взагалі спасе мені? Якщо ні, то де закінчується його ізоляція?

Copy Fail: чотири байти і спільне ядро​

У квітні 2026 року дослідники Xint Code/Theori публічно описали вразливість Copy Fail, CVE-2026-31431. Якщо сильно спростити, це локальна ескалація привілеїв у Linux kernel: користувач без root-доступу міг через AF_ALG, splice() і баг у криптографічному модулі який може дати можливість контрольованого запису кількох байтів у page cache файлу. Ubuntu у своєму бюлетені теж описує це як LPE в algif_aead і дає severity HIGH, CVSS 7.8: Fixes available for CVE-2026-31431. NVD окремо веде сторінку CVE-2026-31431 з посиланнями на патчі ядра.

"О боже, Linux небезпечний", але це ціна оптимізації. Десь у ядрі є шлях для zero-copy, щоб не ганяти байти туди-сюди. Десь є криптографічний інтерфейс, який повинен пришвидшити нормальні речі. Десь є page cache, без якого система була б тупо повільнішою. А потім ці три системи зустрічаються, дивляться одна на одну і кажуть: "А давайте дамо користувачу писати туди, куди він не мав би писати".

Контейнери в цій історії з'являються не тому, що Docker якось пов'язаний із AF_ALG чи splice(). Ні. Він з'являється тому, що контейнерні платформи часто запускають недовірений або напівдовірений код на спільному ядрі. І якщо в цьому спільному ядрі є локальна ескалація привілеїв, то "воно ж у контейнері" перестає бути заспокійливою фразою.

Багато людей досі думають, що контейнер - це така маленька віртуальна машина, тільки легша. Ну, типу, "я ж у Docker, значить, я в будиночку". Ні. Docker-контейнер - це процеси на тому самому ядрі Linux, просто їм підкрутили видимість світу і поставили парканчики.

Офіційна документація Docker прямо каже, що при docker run створюються namespaces і control groups. Namespaces дають ізоляцію видимості: свій список процесів, своя мережа, свій hostname, свої mount points. Cgroups дають контроль ресурсів: скільки CPU, пам'яті, I/O і так далі. Linux man pages окремо описують namespaces і cgroups.

Але ядро - спільне. Якщо у спільному ядрі є локальний privilege escalation, то контейнер не стає повноцінною security boundary рівня VM. Контейнер може суттєво зменшити поверхню атаки за рахунок capabilities, seccomp, AppArmor/SELinux, user namespaces і нормальної конфігурації. Але якщо ваша модель безпеки звучить як "у нас untrusted код, але він у Docker, тому норм", то це не модель безпеки, це надія.

Повноцінна VM має окреме ядро гостьової ОС. Контейнер - ні.

І саме тому розмова про Docker дуже швидко стає розмовою про Linux kernel. Контейнер може намалювати процесу окремий світ, але закон фізики в цьому світі все одно пише ядро. А в Linux kernel є одна майже релігійна ідея, без якої вся ця екосистема розсипалася б значно швидше: не ламай те, на що покладаються програми.

Лінус і головна релігія Linux​

У Лінуса Торвальдса прикольна історія з прізвищем. Torvalds - це сконструйоване шведсько-фінське родинне ім'я, яке створив його дід, журналіст і поет Оле Торвальдс, зробивши його зі свого середнього імені. Про це є коротка довідка навіть у Wikipedia: Torvalds. Сам Лінус - фінський програміст зі шведськомовної меншини Фінляндії. Тобто коли хтось каже "відомий фін", а хтось уточнює "ну як би фінський швед", обидва не повністю неправі. Це вже хороший початок для операційної системи.

Але важливіше не прізвище. Важливіше правило, яке стало однією з причин успіху Linux: не ламати userspace.

Linux kernel має стабільний інтерфейс між ядром і userspace. Офіційна документація ядра прямо описує Linux ABI між kernel і userspace. Системні виклики, задокументовані stable-частини /proc і /sys, поведінка, на яку покладаються програми, - це все не можна просто взяти і поламати, бо "нам так архітектурно красивіше". Debug-інтерфейси, Kconfig і внутрішні символи ядра - інша історія, на них таку обіцянку не поширюють.

Але Linux kernel не має стабільного внутрішнього ABI для драйверів і модулів. Це інший рівень. Є навіть знаменита документація Грега Кроа-Гартмана з прекрасною назвою The Linux Kernel Driver Interface, де пояснюється, чому стабільний internal kernel API/ABI для Linux не є метою. Якщо ваш драйвер у дереві ядра, його поправлять разом зі зміною внутрішнього API. Якщо ви принесли зовнішній binary blob, то це вже ваші пригоди.

І от тут видно характер Linux. Для користувача: "не ламайте". Для внутрішньої кухні ядра: "ламаємо, якщо треба, бо інакше система закам'яніє".

Це дуже прагматична позиція - що мільйони машин мають продовжувати працювати після оновлення ядра.

І тут починається головний прикол. Ядро Linux у цьому сенсі поводиться консервативніше, ніж багато хто очікує від open source-проєкту. Але більшість людей не запускає програми "на ядрі". Вони запускають їх у дистрибутиві, а дистрибутив - це вже не тільки kernel. Це цілий userspace-зоопарк.

Чому ж тоді Linux-десктоп іноді відчувається як квест?​

Бо "Linux" як ядро і "Linux" як дистрибутив - це не одне й те саме.

Ядро може не ламати userspace ABI, але ваша програма живе не напряму на голому syscall interface. Вона живе серед динамічних бібліотек, loader-ів, пакетних менеджерів, OpenSSL, Qt, GTK, libstdc++, драйверів, systemd, PulseAudio/PipeWire, Mesa і ще купи всього, що не контролює Лінус.

glibc тут дуже зручний кандидат на роль головного винуватця, але картинка трохи ширша. GNU C Library справді фундаментальна: це стандартна C-бібліотека GNU-світу, через яку більшість програм ходить до системних викликів і базових функцій. Вона має symbol versioning і серйозно думає про сумісність, але реальна проблема Linux-дистрибутивів не зводиться до одного пакета: немає одного стабільного "Linux userland ABI", який би всі вендори тримали десятиліттями як контракт для будь-якого бінаря.

У Windows цей контракт історично значно жорсткіший. Microsoft десятиліттями тягне за собою Win32 і application compatibility. Про це дуже добре писав Реймонд Чен у книзі The Old New Thing: backwards compatibility для Windows - одночасно суперсила і тягар.

У Linux-дистрибутивах ситуація інша. У вас може бути бінарник, який прекрасно працює на конкретній версії RHEL, але не заводиться на новішій Ubuntu без правильної версії бібліотеки. І це не тому, що ядро зламалось. Це тому, що весь userland - це федерація проєктів, а не одна компанія з одним великим контрактом сумісності.

Звідси й народжуються три способи виживання. Всі вони насправді відповідають на одне й те саме питання: як зробити так, щоб програма не розвалилася від чужого userspace?

1. Статично лінкувати все, що можна.
2. Писати на Go або Zig-подібних інструментах, де легше отримати самодостатній бінарник.
3. Запакувати весь ваш маленький світ у контейнер.

Перший варіант найелегантніший на папері: зібрати один файл і перестати залежати від зовнішнього світу. Але саме тут починається той технічний біль, через який Docker потім виглядає не таким уже й дурним.

Статична лінковка: стара мрія про один файл​

Статична лінковка - це коли всі потрібні шматки коду вшиваються у ваш executable під час збірки. Не "при запуску знайди мені libssl.so.3, libc.so.6, правильний loader і молись, щоб воно було сумісне", а "ось один бінарник, запускай". Звучить як очевидна перемога здорового глузду.

Динамічна лінковка свого часу теж була здоровим глуздом. Диски маленькі, пам'яті мало, одна копія бібліотеки може шаритися між процесами, security update бібліотеки прилетів - і всі програми отримали фікс без перекомпіляції. У світі Unix-дистрибутивів це дуже логічна модель: пакетний менеджер тримає систему як цілісний набір взаємно сумісних пакетів.

Проблема починається тоді, коли ви хочете взяти один бінарник і понести його в інший Linux. Не "інший kernel", а інший userspace. Там інша glibc, інший OpenSSL, інший libstdc++, інший dynamic loader, інші шляхи, інші патчі від дистрибутива. І раптом ваш "просто executable" виявляється списком вимог до археологічного шару операційної системи.

Тут хочеться сказати: "Ну то статично залінкуймо glibc і забудьмо". І от на цьому місці Linux починає дивитися в підлогу.

glibc не дуже любить бути просто вшитою в один самодостатній файл. Частина її поведінки історично розрахована на динамічний світ: Name Service Switch для користувачів, груп і DNS, nsswitch.conf, модулі на кшталт libnss_files, libnss_dns, локалі, resolver-и, dlopen. Ви можете отримати "статичний" бінарник, який при певному виклику все одно хоче shared objects тієї ж версії glibc, з якою його лінкували. Це той момент, де слово "статичний" перестає заспокоювати.

Тому для справді самодостатніх Linux-бінарників часто дивляться в бік musl. musl прямо позиціонується як libc, зручна для robust static-linked applications; в офіційному musl how-to це одна з базових історій, а musl FAQ згадує окремий libc.a для static linking. Через це Alpine Linux і musl-based toolchains стали популярними в маленьких контейнерах і static builds.

Але тут немає безкоштовного сиру. musl - не glibc. Десь може відрізнятися поведінка resolver-а, локалей, threading details, performance characteristics, сумісність із софтом, який неявно очікує саме GNU-екосистему. Тобто "перелінкуй на musl" - це не магічна кнопка, а інженерне рішення з trade-off-ами.

Go став популярним частково тому, що для багатьох задач дає відчуття "ось тобі один бінарник". Якщо не тягнути cgo, Go runtime і стандартна бібліотека можуть дати дуже portable executable. Але щойно ви вмикаєте cgo, підключаєте C-бібліотеки або покладаєтесь на системний resolver, ви знову в світі libc. У Go навіть у коді net прямо видно розділення між pure Go resolver і cgo resolver: net/conf.go. Тому CGO_ENABLED=0 стало майже заклинанням для людей, які хочуть деплоїти прості Go-сервіси одним файлом.

Zig іде ще цікавіше: він хоче бути не тільки мовою, а й toolchain-ом, який контролює cross-compilation, libc, linker і багато деталей, які в C/C++ світі розмазані між системними пакетами. Zig прямо підкреслює, що постачається з підтримкою багатьох libc/targets: Zig overview. Це не просто зручність. Це відповідь на той самий біль: "я хочу зібрати бінарник під іншу систему і не влаштовувати шаманство з sysrootами".

Тобто статична лінковка - це не дрібна технічна деталь. Це філософська альтернатива Docker-образу. Один шлях каже: "зробімо програму самодостатньою". Другий каже: "зробімо самодостатнім усе середовище". Якщо перший шлях працює - чудово, у вас маленький артефакт і простий деплой. Якщо не працює, Docker приходить із валізою userspace і каже: "Не сваріться, я просто заберу всю квартиру".

І от тепер Docker перестає бути "модною штукою для DevOps". Він стає відповіддю на дуже старе питання: що робити, якщо ABI на рівні ядра стабільний, а середовище навколо програми все одно нестабільне гівно?

Docker як статична лінковка для людей, які вже втомилися​

Docker не з'явився тому, що людство раптом захотіло "мікро-віртуалки". Він став масовим тому, що вирішив дуже побутову проблему: "у мене працює, а на сервері ні".

Контейнерний образ - це не просто ваш бінарник. Це шматок файлової системи з вашими бібліотеками, runtime, конфігами, Python-ом, Node-ом, OpenSSL-ом і всією цією шафою, яка потрібна програмі, щоб не розвалитися від першого ж apt upgrade.

Тобто Docker у певному сенсі - це статична лінковка на рівні середовища. Не можете нормально вкомпілювати glibc? Не хочете пояснювати, яка саме версія libssl.so потрібна? Окей, беріть весь userspace із собою.

З архітектурної точки зору це трохи смішно. Замість "давайте зробимо чистий, стабільний runtime-контракт" людство сказало: "та давайте просто носити весь сарай із собою". Але з інженерної точки зору це працює. А коли щось працює і знімає біль мільйонам людей, воно перемагає.

Технічно Docker сьогодні - це вже не одна магічна штука. Docker Engine використовує container runtime, нижче живуть containerd, runc, OCI images/specs і Linux primitives. Сам containerd - окремий open source runtime-проєкт. Kubernetes свого часу мав спеціальний dockershim, бо ранній Kubernetes говорив із Docker Engine напряму; потім Kubernetes перейшов до Container Runtime Interface, і в v1.24 dockershim прибрали.

Але "Kubernetes більше не використовує Docker" не означає "Docker-образи померли". Образи лишилися. Ідея лишилася. Просто замість Docker Engine як посередника Kubernetes говорить із containerd або іншим CRI-compatible runtime.

Тобто Docker як бренд може втрачати центральність, але контейнерна модель нікуди не дівається. Бо проблема, яку вона вирішує, нікуди не зникла.

Тут важливо не переплутати дві різні ролі контейнера. Перша - packaging: принести з собою свій userspace. Друга - isolation: зробити вигляд, що процес живе в окремому світі. Перша роль зробила Docker масовим. Друга часто продається в голові людей сильніше, ніж реально гарантується ядром.

Cgroups, namespaces і чому це не VM​

Якщо розкласти контейнер на деталі, там немає "контейнерної магії". Там є набір давно земних Linux-механізмів:

• Namespaces: процес бачить не весь світ, а свій namespace. Свій PID tree, свій network stack, свої mount points, свій hostname.
• Cgroups: процесу обмежують ресурси. Ось тобі CPU quota, ось memory limit, ось I/O.
• Capabilities: root більше не є всемогутнім монолітом, його права можна нарізати.
• Seccomp: можна заборонити частину системних викликів.
• LSM: AppArmor, SELinux та інші політики доступу.
• Overlay filesystems і images: спосіб зібрати файлову систему шарами.

Docker зібрав ці штуки у продукт, який нормальні люди могли використати без PhD з Linux internals. І це вже велика справа.

Але саме тому контейнер і не дорівнює VM. VM емулює або віртуалізує машину з окремим ядром. Vagrant, наприклад, історично часто використовував VirtualBox, VMware, Hyper-V, QEMU/libvirt або інші провайдери для керування повними VM. Docker запускає процеси на тому самому kernel. Тому Docker легший, швидший і зручніший. І тому ж він не має тієї самої ізоляції, що повна віртуалізація.

Коротше: Docker - це не "віртуальний комп'ютер". Docker - це добре замаскований(лол шо), по суті, процес.

І отут Docker стає ідеальним прикладом старої фрази, яка звучить як виправдання поганого коду, але насправді описує пів історії комп'ютерів: worse is better.

Worse is better: чому гнусний хак іноді кращий за правильну систему​

Тут ідеально лягає есе Річарда Ґабріеля Worse Is Better. Це один із тих текстів, які варто читати не тому, що там "істина", а тому, що після нього ви починаєте бачити повторюваний патерн у всій історії софту.

Ґабріель протиставляв умовний MIT/Stanford style і New Jersey/Berkeley style. Перший хоче "зробити правильно": повно, красиво, консистентно. Другий хоче "щоб працювало, було простим і можна було швидко рознести по світу". І потім раптом виявляється, що Unix і C, які виглядали як прості, місцями грубі, неідеальні інструменти, розповзлися всюди. А красиві Lisp-машини, попри всю їхню технічну сміливість, лишилися в музеї.

Це не означає, що якість не потрібна. Це означає, що adoption - окрема сила. Якщо технологія достатньо проста, щоб її можна було зрозуміти, перенести, зламати, полагодити і запустити на дешевому залізі, вона отримує шанс стати стандартом де-факто. А потім стандарт де-факто починає формувати реальність.

Docker - майже карикатурно хороший приклад. Замість розв'язати проблему сумісності userspace красиво, він сказав: "покладемо userspace у коробку". Замість пояснити всім, як збирати portable Linux binaries, він дав Dockerfile. Замість змусити runtime-екосистеми бути нормальними, він зробив нормальним тягати runtime із собою.

Це не "правильне" рішення з точки зору естетики. Але воно настільки корисне, що всі перестали сміятися і почали будувати на ньому продакшен.

Оце і є worse is better у дикій природі.

А щоб відчути, наскільки це не нова драма, треба подивитися на іншу гілку історії: світ, де люди намагалися зробити не "простий C поверх дешевого заліза", а майже ідеальну машину під ідеальне середовище.

Lisp-машини: коли комп'ютер був зроблений під мову, а не навпаки​

Lisp-машини - це не просто "компи для програмістів, які любили дужки". Це була спроба зробити всю машину під високорівневу мову: залізо, операційну систему, середовище розробки, garbage collection, інтроспекцію, все. MIT AI Lab почав цю лінію ще в 1970-х; потім були Symbolics, Lisp Machines Inc., Texas Instruments, Xerox. Короткий історичний огляд є в Lisp machine, а Common Lisp HyperSpec теж згадує, що Lisp Machine Lisp виріс із MacLisp і працював на ранніх MIT Lisp Machines: CLHS 1.1.2.

CADR Lisp Machine кінця 1970-х у MIT Museum. Фото: Daderot, Wikimedia Commons, CC0.

Ідея була дуже красива. Замість того, щоб писати на C, потім компілювати в машинний код, потім вручну менеджити пам'ять і ловити segfault-и, ти живеш у середовищі, де програма - майже живий об'єкт. Можна інспектити runtime, міняти код на льоту, дебажити систему зсередини системи. Для AI-досліджень того часу це було дуже природно: Lisp був не просто мовою, а способом думати про символи, програми і дані як про одне середовище.

Space-cadet keyboard від Symbolics LM-2. Оце не просто клавіатура, а артефакт культури, де середовище розробки було майже окремою цивілізацією. Фото: Dave Fischer / Retro-Computing Society of Rhode Island, Wikimedia Commons, CC BY-SA 3.0/GFDL.

Проблема була в тому, що майбутнє коштувало як майбутнє! Lisp-машини були дорогими спеціалізованими воркстейшонами, а поруч дешевшали Unix-машини і персональні комп'ютери. C був грубіший, Unix був грубіший, але вони працювали на масовішому залізі. І коли дешеве залізо почало швидко прискорюватися, спеціальна машина під прекрасну модель світу стала виглядати не як майбутнє, а як дуже дорога бокова гілка еволюції.

Оце болючий момент у worse is better: "краще" може програти не тому, що воно гірше технічно, а тому, що його складніше купити, складніше поширити і складніше втягнути в уже наявну економіку.

Але ідея керованого, переносимого, багатого runtime-світу не померла разом із Lisp-машинами. Вона просто перестала вимагати спеціальний комп'ютер. Наступна масова версія цієї ідеї приїхала вже як віртуальна машина поверх звичайної операційної системи.

JVM: контейнер, але для байткоду​

Після Docker легко подивитися на JVM новими очима. JVM теж каже: "мені не подобається ваш хаос із платформами, я принесу свій світ". Тільки Docker приносить filesystem image з userspace-залежностями, а JVM приносить віртуальну машину, class file format, bytecode verifier, garbage collector, JIT і великий runtime-контракт. Офіційна специфікація прямо описує JVM як абстрактну машину з власним форматом класів і runtime-структурами: The Java Virtual Machine Specification.

У цьому сенсі JVM - більш "правильна" відповідь на частину тієї самої проблеми. Ти не пакуєш весь Linux userspace у контейнер, а компілюєш програму в portable bytecode і запускаєш її там, де є сумісна JVM. Звідси старий лозунг Java про write once, run anywhere. На практиці, звісно, було write once, debug everywhere, бо реальність завжди приходить із мокрою ганчіркою. Але сама архітектурна ідея гарна.

Цікаво, що люди за Java були зовсім не дурні. Джеймс Гослінг до Java зробив Gosling Emacs, ранню реалізацію Emacs на C для Unix. Тобто це людина з тієї ж культури інтерактивних середовищ, редакторів, runtime-ів і "система має бути живою". Але результатом стала не Lisp-машина 2.0, а Java: доволі консервативна мова, зате з VM, GC, bytecode і дуже сильним deployment story для enterprise.

Це теж схоже на компроміс із реальністю. JVM взяла частину мрії Lisp-машин - керований runtime, переносимість, garbage collection, багате середовище - і запакувала її так, щоб це можна було поставити на звичайний комп'ютер, поверх звичайної ОС, без спеціального заліза за космічні гроші. Тобто мрія вижила, але в менш чистому, більш промисловому вигляді.

Docker і JVM стоять поруч не випадково. Це дві відповіді на питання "як зробити так, щоб моя програма не залежала від хаосу навколо". JVM відповідає: "дамо стабільну абстрактну машину". Docker відповідає: "запакуємо хаос у коробку". Перша відповідь красивіша. Друга часто простіша для вже існуючого софту. І тому обидві живі.

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

Zig, Windows і старі API, які раптом кращі за нові​

Є ще один смішний поворот у цій же темі: Zig. На Windows він дивиться в бік нижчих API замість того, щоб завжди користуватись "офіційно красивими" Win32-обгортками. І це не просто байка. У Zig Devlog є запис Bypassing Kernel32.dll for Fun and Nonprofit, де Andrew Kelley пояснює, що kernel32.dll часто є вищим wrapper-ом, а реальна робота йде через ntdll.dll. У деяких місцях нижчий API дає менше алокацій, менше прихованих failure mode-ів і чесніші error codes.

Це прекрасно лягає в нашу ABI-історію. У Linux головний стабільний контракт - між userspace і kernel. Ви можете напряму думати про syscalls, і це культурно нормальна частина платформи. У Windows офіційна стабільність для більшості розробників живе вище: Win32, kernel32, user32, вся ця велика compatibility-залупа. Нижче є Native API / ntdll, але Microsoft історично не продає його як головний публічний контракт для всіх задач.

І тут приходить Zig і каже: "А ми подивилися, і нижче місцями чистіше". Це дуже в стилі системного програмування: офіційно правильний шар може бути не найкращим для runtime, який хоче мінімум залежностей, контроль I/O і передбачувану поведінку.

Сюди ж додається ще один культурний факт: Zig у 2025 році офіційно переніс основний репозиторій із GitHub на Codeberg, про що написав у Migrating from GitHub to Codeberg. Це вже не прямо про ABI, але дуже про ту саму інженерну нервову систему: менше залежати від великої платформи, яку ти не контролюєш; менше магії; більше прозорості; тримати toolchain ближче до себе.

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

І тут варто повернутися до початку Linux-історії. Бо вся ця драма з ABI, libc, userland і toolchain-ами не взялася з повітря. Linux як масова система народився не як завершена операційна система, а як робоче ядро, яке з'єднали з уже наявним GNU-світом.

GNU, Hurd і момент, коли історія пішла не за планом​

Щоб зрозуміти Linux, треба пам'ятати, що Linux спочатку був ядром, а не повною операційною системою. Повну вільну Unix-like систему хотів зробити GNU. Проєкт GNU Річард Столлман запустив у 1983 році як спробу створити повністю вільну Unix-сумісну ОС; це описано в офіційному тексті GNU in a Nutshell.

DEC PDP-11/20 у Computer History Museum. На таких машинах добре видно, чому Unix і C були не академічною красою, а способом вижити на реальному залізі. Фото: Don DeBold, Wikimedia Commons, CC BY 2.0.

GNU мав компілятори, утиліти, shell, libc і купу іншого добра. Але ядро GNU Hurd довго не ставало практично готовим для масового використання. І тут приходить студент Лінус із ядром для 386, яке "just a hobby", і раптом у GNU-userland з'являється робочий kernel.

Це знову історія про правильне проти робочого. Hurd був архітектурно амбітнішим. Linux був простішим, монолітнішим, менш красивим для частини академічних людей. Але Linux працював, швидко розвивався, приймав драйвери, підтримував залізо і не ламав користувачів. А цього достатньо, щоб перемогти.

Сюди ж проситься Таненбаум. Його Operating Systems: Design and Implementation з MINIX - класична книжка для розуміння ОС. А знаменитий Tanenbaum-Torvalds debate - це майже мем про мікроядра, монолітні ядра і різницю між "правильніше в теорії" та "злетіло в реальному світі".

І тепер можна оцінити найіронічніший поворот. Linux довго страждав від того, що не має одного стабільного desktop/application ABI рівня "пишеш програму і вона живе десятиліттями". Але на Linux приходить чужий, дуже старий і дуже стабільний світ Windows API - і раптом саме він може стати клеєм для масового десктопу.

Proton: Linux-десктоп може перемогти, запустивши Windows​

Найсмішніший поворот у цій історії: можливо, найстабільніший userspace для масового Linux-десктопу - це Win32 через Proton.

Звучить як жарт, але жарт непоганий. Valve зробила Steam Deck і сильно вклалася в Proton - compatibility layer, який дозволяє Windows-іграм запускатися на Linux. Базово Proton - це Wine плюс купа патчів і компонентів для ігор; короткий технічний опис є на сторінці Proton, а код живе в ValveSoftware/Proton.

Steam Deck - конкретний шматок заліза, який зробив Proton масовою історією. Фото: Liam Dawe / GamingOnLinux, PNG version by VulcanSphere, Wikimedia Commons, CC BY-SA 4.0.

Чому це важливо? Бо Windows-екосистема десятиліттями звикала, що старі програми мають запускатися. Win32 - це не просто API. Це культурний договір: якщо ти написав програму багато років тому, є шанс, що її все ще можна якось запустити. І цей договір настільки сильний, що Linux може отримати кращу desktop-сумісність, запускаючи Windows-програми через шар сумісності.

Тобто Microsoft роками тягнула backwards compatibility як тягар, а Valve взяла цей тягар і зробила з нього аргумент на користь Linux.

Windows це єдиний стабільний ABI для Linux завдяки Valve!

Смішно? Дуже. Логічно? Теж дуже.

То що, Docker - поганий?​

Ні. І так. Нормальна відповідь у системному програмуванні майже завжди така.

Docker поганий, якщо ви думаєте, що це повноцінна безпекова межа для недовіреного коду. Для цього існують VM, sandbox-и, gVisor, Firecracker, Kata Containers, seccomp-профілі, user namespaces, LSM-політики і нормальна threat model, а не віра в слово "container".

Docker хороший, якщо вам треба відтворюване середовище, контроль залежностей і нормальна доставка софту між машинами. Він бере хаос userspace і робить з нього артефакт, який можна зібрати, підписати, покласти в registry і запустити приблизно там, де треба.

Docker поганий, якщо ви пакуєте в образ 2 GB випадкового мотлоху і потім дивуєтесь, чому CI повільний. Docker хороший, якщо ви чесно визнаєте: "Linux userspace сумісність складна, залежності складні, production складний, тому я зафіксую світ хоча б на рівні image".

Docker поганий як архітектурний ідеал. Docker прекрасний як інженерний компроміс.

І от це, здається, головний висновок. Історія софту - це не парад ідеальних архітектур. Це кладовище прекрасних ідей, які програли простішим, дешевшим, грубішим і більш переносимим рішенням. Unix, C, Linux, Docker, Win32 compatibility, Proton - усі вони в різні моменти виглядали як "ну камон, можна ж красивіше". А потім виявлялося, що красивіше можна, але люди вже поїхали на тому, що працює.

І в цьому немає простого моралізаторства. Красиві системи потрібні. Стабільні ABI потрібні. Нормальні runtime-контракти потрібні. Просто реальна індустрія завжди живе в компромісі між тим, як мало б бути, і тим, що можна поставити в продакшен у четвер до обіду.

Тому коли наступного разу хтось скаже "це просто хак", варто спитати: хак, який нікому не потрібен, чи хак, на якому через п'ять років буде стояти пів індустрії?

Бо це дуже різні хаки.

Що почитати далі​

• Copy Fail: 732 Bytes to Root on Every Major Linux Distribution - технічний write-up Xint Code/Theori.
• Ubuntu: fixes available for CVE-2026-31431 - практичний погляд дистрибутива на Copy Fail.
• Linux ABI description - офіційна документація про ABI між kernel і userspace.
• The Linux Kernel Driver Interface - чому Linux не обіцяє стабільний internal kernel API/ABI.
• Docker Engine security - що Docker реально робить для ізоляції.
• cgroups(7) і namespaces(7) - базові Linux primitives, на яких стоять контейнери.
• containerd docs - що таке containerd і де він живе в стеку.
• Kubernetes Dockershim Removal FAQ - чому Kubernetes прибрав dockershim, але Docker images нікуди не зникли.
• Richard P. Gabriel: Worse Is Better - текст, після якого Docker стає набагато менш дивним.
• Lisp machine - коротка історія спеціалізованих машин під Lisp.
• Common Lisp HyperSpec: History - контекст про MacLisp, Lisp Machine Lisp і ранні Lisp-машини.
• The Java Virtual Machine Specification - офіційна специфікація JVM.
• Gosling Emacs - рання Unix-реалізація Emacs від Джеймса Гослінга до Java.
• Zig Devlog: Bypassing Kernel32.dll for Fun and Nonprofit - чому Zig дивиться на ntdll замість частини Win32-обгорток.
• Zig: Migrating from GitHub to Codeberg - приклад сучасної боротьби за контроль над інфраструктурою розробки.
• GNU in a Nutshell - коротко про GNU, Столлмана і Unix-сумісну вільну ОС.
• GNU C Library - glibc як фундаментальна частина GNU/Linux userspace.
• musl: How to Use - чому musl часто вибирають для static-linked Linux-бінарників.
• musl FAQ - деталі про libc.a, libc.so і модель musl.
• Go net resolver source - pure Go resolver проти cgo resolver у стандартній бібліотеці.
• Zig overview - Zig як toolchain із cross-compilation і bundled libc-підходом.
• Linus Torvalds and David Diamond: Just for Fun - автобіографічна історія Лінуса і Linux.
• Andrew S. Tanenbaum: Operating Systems: Design and Implementation - класика про ОС і MINIX.
• Raymond Chen: The Old New Thing - Windows compatibility як окремий жанр інженерного болю.
• ValveSoftware/Proton - той самий шар сумісності, через який Windows-ігри живуть на Linux.

Вам не потрібні скіли!

Нещодавно читав про Thiele Machine, цікавий твіст на машину тюрінга який додає щось типу "душі" в обчислення. Прикольний ребіт хол. але мене це штовхнуло подумати про практичну штуку.

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

тому я почав дивитись на формальну верифікацію. конкретно TLA+ для написання специфікацій і Lean для їх доведення.

чому це відрізняється від просто "кращого промптінгу". в Lean є proof kernel. це маленький детермінований чекер який або приймає твій доказ, або відхиляє. ніякого "майже правильно". ніякого статистичного вгадування. LLM фізично не може пробрехатись через Lean proof, ядро просто скаже ні. та сама історія з TLA+, TLC model checker вичерпно перевіряє твої інваріанти проти всіх досяжних станів. модель чекер не переконаєш красивими словами.

але ось що цікаво. я спробував генерувати тести з TLA+ специфікацій до того як будь який бізнес-код існує. LLM яка пише тести взагалі не бачить імплементацію. потім окремо, бізнес код генерується в рамках обмежень теореми Lean. два повністю ізольовані контексти. генератор тестів і генератор коду нічого не знають один про одного.

це не TDD. в TDD ти пишеш тести на основі свого розуміння того що код має робити. тут тести приходять з математичної моделі системи. вони кодують інваріанти і властивості, а не приклади вхідних даних і очікуваних результатів. TDD тест каже "коли я викликаю f(2) отримую 4". тест з TLA+ каже "для всіх досяжних станів ця властивість виконується і цей перехід валідний". покриття фундаментально інше тому що воно іде з семантики системи, а не з уяви розробника про крайні випадки.

отже маємо: формальний доказ який не дає LLM відхилятись від цілі + бізнес тести написані до того як код взагалі почав існувати + повна ізоляція між генерацією тестів і генерацією коду. модель не може зґеймити те чого не бачить.

і тут сьогодні я бачу ось це: https://mistral.ai/news/leanstral mistral щойно випустив Leanstral, опенсорс агент побудований спеціально для формальної верифікації в Lean 4. буквально вчора.

моя думка: всі ці скіли і спек файли які ми пишемо сьогодні, це перехідний період. протягом наступного року SOTA моделі стануть достатньо розумними і формальна верифікація стане нативною частиною код агентів. коли це станеться, це буде приблизно як колись C піднявся над асемблером. тобі все ще треба розуміти що під капотом, але ти працюєш на зовсім іншому рівні.

p.s. Мене трохи лякає що ідеї які я пишу декотрим в особисті потім через кілька тижнів стають реальністю. може вони це ключ до виходу з симуляції?

p.p.s. а ще подумайте про erlang/otp. він так довго чекав на свій момент і ось зараз встає з попелу. OTP буквально проєктували і готували для цього. він ідеально лягає на сучасний світ ai агентів. я навіть зробив кілька реалізацій сам, а потім прийшов openai з https://github.com/openai/symphony (elixir на BEAM) і інші хлопці випустили https://jido.run/blog/jido-2-0-is-here і робити своє стало якось не цікаво =(

Поки заголовки щодня обіцяють то сингулярність, то кінець людства, Карпатій дивиться на все це тверезіше. Чувак працював в OpenAI, керував автопілотом у Tesla - він знає, як ця кухня працює зсередини. В інтерв'ю Дваркешу Пателю він каже речі, які збігаються з тим, що я сам думаю: трансформери¹ - тупик, RL - лайно, а ШІ загалом переоцінений.

Коли всі кричать "рік агентів", Карпатій каже - ні, це буде декада агентів, бо моделі зараз просто недостатньо надійні. Він прямо називає навчання з підкріпленням (RL) жахливим підходом, який видавлює результати по краплі. І навіть статистично модель вважає за краще промовчати, ніж відповісти - бо штраф за помилку більший, ніж за "я не знаю".

Він розповідає про досвід у Tesla, де прогрес - це поступове "вигризання" надійності, і про свою нещодавню роботу над Nanochat², щоб пояснити: код-агенти досі не можуть замінити архітектора. Далі розбираємо головне з цієї розмови - чому справжній інтелект не зводиться до запам'ятовування, чому Карпатій не вірить у різкий "вибух" продуктивності, і навіщо він будує "Starfleet Academy" для освіти людства.

Про поточний стан ШІ та "Декаду агентів"​

• Десятиріччя, а не рік: Карпатій називає цей час "декадою агентів", а не "роком агентів", реагуючи, на його думку, на надто оптимістичні прогнози в індустрії.
• Чому не зараз: Поточні агенти "просто не працюють" достатньо надійно, щоб замінити співробітника чи навіть джуна.
• Ключові проблеми: Їм бракує інтелекту, мультимодальності, а головне - "безперервного навчання" (continual learning), тобто здатності пам'ятати та інтегрувати нову інформацію.

Про навчання з підкріпленням (RL) та аналогії з людиною​

• RL жахливий: Карпатій каже: "Навчання з підкріпленням жахливе. Просто так сталося, що все, що ми мали до нього, набагато гірше".
• "Висмоктування через соломинку": Проблема RL у тому, що він "висмоктує результат через соломинку". Один єдиний сигнал винагороди (наприклад, "завдання виконано") поширюється на тисячі попередніх дій, що робить навчання дуже "шумним" і неефективним.
• Люди так не вчаться: Люди не використовують RL для складних інтелектуальних завдань. Натомість ми маємо складний процес "огляду" (review) та аналізу своїх дій.
• Ми будуємо "привидів": Він обережно ставиться до аналогій з тваринами, оскільки вони є продуктом еволюції, що докорінно відрізняється від нашого процесу навчання. "Ми насправді не будуємо тварин. Ми будуємо привидів" - цифрові сутності, що імітують дані, створені людьми.
• "Когнітивне ядро" проти пам'яті: Попереднє навчання (pre-training) дає моделям дві речі: фактичні знання (пам'ять) та інтелект ("когнітивне ядро"). Карпатій вважає, що надмірна пам'ять насправді стримує моделі. Він хотів би "видалити пам'ять" і залишити лише чисті алгоритми мислення.
• Забудькуватість - це перевага: Те, що люди погано запам'ятовують дослівно, - це "особливість, а не вада", оскільки це змушує нас узагальнювати. LLM, навпаки, надто добре запам'ятовують, що їм заважає.

Про кодування, Nanochat² та обмеження агентів​

• Агенти не допомогли: При створенні Nanochat² код-агенти йому майже не допомогли.
• Де агенти корисні: Вони корисні для шаблонного (boilerplate) коду або для вивчення нових мов програмування (він використовував їх для Rust).
• Де вони провалюються: Агенти погано справляються з кодом, який ніколи раніше не був написаний та інтелектуально складними, унікальними завданнями. Для такої роботи він надає перевагу автодоповненню (autocomplete).
• Як вчитися: Найкращий спосіб вчитися - це "створювати код... змусити його працювати". Він не радить писати блоги чи робити слайди, бо так "бракує знань".

Про майбутнє, AGI та "Вибух інтелекту"​

• ШІ як продовження обчислень: Карпатій бачить ШІ не як окрему магічну технологію, а як "продовження обчислень" та неперервний процес автоматизації, що триває століттями.
• Вибух уже відбувається: Він вважає, що "ми вже перебуваємо у вибуху інтелекту, і це буде тривати десятиліттями".
• Без різкого стрибка ВВП: Він не очікує, що ШІ спричинить раптовий, різкий стрибок у зростанні ВВП. Натомість як і комп'ютери чи інтернет, він плавно інтегрується в економіку, і ми залишимося на тій самій експоненційній кривій зростання.
• Ризик - втрата контролю: Найімовірнішим негативним сценарієм він вважає не повстання машин, а "поступову втрату контролю та розуміння" того, що відбувається в ускладнених автоматизованих системах.

Уроки з досвіду в Tesla​

• Демо - це не продукт: Досвід роботи над безпілотними автомобілями навчив його, що існує величезний "розрив від демо до продукту", особливо у сферах, де "ціна помилки занадто висока".
• "Марш дев'яток": Прогрес - це "march of nines" (тобто досягнення 90%, 99%, 99.9% надійності). "Кожна дев'ятка - це однаковий обсяг роботи".
• Скепсис до демо: Через це він тепер "дуже не вражений демо-версіями" будь-яких технологій.

Про свій новий проєкт Eureka​

• Місія: Його головний страх - що людство "втратить повноваження" і стане пасивним, як у фільмах WALL-E або Idiocracy. Він хоче "розширити можливості людей" через освіту.
• "Starfleet Academy": Він описує Eureka Labs як "Starfleet Academy"- елітний інститут для передових технічних знань.
• Мета - ідеальний репетитор: Кінцева мета - створити ідеального ШІ-репетитора, але Карпатій визнає, що "можливостей ще немає". Він наводить приклад свого репетитора корейської мови як планку якості, якої ШІ ще не досяг.
• "Рампи до знань": Наразі він зосереджений на створенні "рамп до знань"- ідеально структурованих навчальних матеріалів (як Nanochat²), що максимізують "Eurekas per second".
• Освіта після AGI: Він висуває тезу: "До AGI освіта корисна. Після AGI освіта - це розвага".
• Освіта як спортзал: Після AGI люди будуть вчитися не заради роботи, а з тих самих причин, з яких ходять у спортзал: для самовдосконалення, здоров'я, статусу та задоволення.
• Розкриття потенціалу: Карпатій вважає, що "генії сьогодення ледве торкаються поверхні того, на що здатний людський розум", і ідеальний ШІ-репетитор зможе допомогти людям досягти набагато більшого.

Авантюра на $3 трильйони​

Революція штучного інтелекту — це не просто технологічний зсув. Це найбільша і, мабуть, найшаленіша інвестиційна лихоманка за всю історію. До 2030 року людство планує вбухати в інфраструктуру ШІ близько $3–4 трильйони. Тільки у США капітальні витрати на обчислення вже дали понад 1.1% зростання ВВП у першій половині 2025-го, випередивши навіть споживчі витрати.

Поки ринок зосереджений на експоненціальному зростанні обчислювальних потужностей і можливостей, він ігнорує фатальну ваду: вся ця екосистема є дивом фінансової інженерії, побудованим на кругових залежностях, нестійкій економіці та неминучому зіткненні з жорсткими фізичними обмеженнями нашої глобальної енергетичної мережі. Бум ШІ — це не просто спекулятивна бульбашка, що нагадує 2000 рік, а системно крихка структура з відлунням кризи 2008 року, де найбільший ризик полягає не у відсутності інновацій, а у відсутності електроенергії.

Позолочена екосистема: Анатомія кругової поруки​

Мережа взаємного страхування​

Щоб зрозуміти крихкість нинішнього буму, необхідно проаналізувати його фінансову архітектуру. Це не традиційний ланцюг постачання, а складна мережа взаємних зобов'язань, де успіх кожного учасника залежить від безперервного потоку капіталу в системі. Візуальним якорем для цього аналізу слугує схема капітальних потоків від Morgan Stanley, що розкриває складні взаємозв'язки.

У гравітаційному центрі цього нового промислового комплексу знаходиться OpenAI. Попри своє некомерційне походження та величезні збитки, компанія стала сонцем, навколо якого обертаються інші планети. Найбільшим сателітом є Microsoft, чиї відносини з OpenAI є симбіотичними. Інвестиції Microsoft у розмірі $13 мільярдів значною мірою переробляються назад у Microsoft як оплата за обчислювальні послуги Azure. Це створює замкнений цикл, де інвестиційні долари негайно з'являються як дохід, штучно роздуваючи історію зростання хмарного підрозділу Microsoft і виправдовуючи початкові інвестиції.

Для диверсифікації обчислювальних потужностей та створення важелів впливу OpenAI підписала гігантські довгострокові контракти з іншими інфраструктурними супутниками, такими як Oracle та CoreWeave. Йдеться про угоди на $300 мільярдів з Oracle та $22 мільярди з CoreWeave, які майже повністю залежать від майбутньої життєздатності OpenAI. Ці угоди подаються ринку як стабільний, довгостроковий дохід, але насправді є концентрованими ставками на єдину, високоризикову компанію. За даними Morgan Stanley, близько 66% майбутніх контрактних зобов'язань Oracle і 40% CoreWeave залежать від OpenAI.

Домінантність Nvidia, постачальника ключового обладнання, посилюється не лише через продаж чіпів, але й через участь у фінансуванні власних клієнтів. Наприклад, Nvidia володіє понад 5% акцій CoreWeave. Ця система «взаємно гарантованого процвітання» функціонує як фінансовий вічний двигун. Вона призначена для підтримки імпульсу та роздування оцінок через самопідсилювальні капітальні потоки, що маскують фундаментальну збитковість у її ядрі.

RPO — нові CDO​

Ключовим фінансовим інструментом, що лежить в основі цієї структури, є зобов'язання щодо виконання, що залишилися (Remaining Performance Obligations, RPO). Це багатомільярдні зобов'язання, які юридично є "нескасовуваними", але в реальності легко переглядаються, коли настають проблеми.

Ринок розглядає ці RPO як гарантовані, безризикові потоки доходів, подібно до того, як перед кризою 2008 року розглядалися іпотечні свопи з рейтингом ААА. Непрозорість цих контрактів приховує екстремальну концентрацію ризику. Загальна вартість зобов'язань за купівлю та оренду інфраструктури операторами гіпермасштабованих дата-центрів досягла $330 мільярдів та $340 мільярдів відповідно, і всі ці витрати окупляться лише за умови постійного зростання попиту на ШІ.

Логіка цієї замкненої системи виглядає так:

1. Microsoft інвестує в OpenAI.
2. OpenAI використовує ці гроші для оплати послуг Microsoft Azure, збільшуючи дохід Azure і підтверджуючи правильність інвестицій Microsoft.
3. Для диверсифікації OpenAI підписує масивні RPO з Oracle та CoreWeave.
4. Oracle та CoreWeave використовують ці RPO як заставу для залучення мільярдних боргів на будівництво дата-центрів, наповнених графічними процесорами Nvidia.
5. Nvidia, своєю чергою, інвестує в CoreWeave, фактично допомагаючи фінансувати купівлю власних чіпів.

Результатом є замкнений цикл, де попит, дохід та інвестиції генеруються та переробляються всередині невеликої групи компаній. Це створює ілюзію величезного, органічного ринку, але насправді це теплична квітка — неймовірно яскрава, але винятково крихка і залежна від безперервного надходження зовнішнього капіталу для покриття величезних збитків.

Відлуння 2000 року: Вендорне фінансування та ілюзія попиту​

Повторення сценарію доткомів​

Фінансовий сценарій буму ШІ не є новим, це вдосконалена версія стратегій бульбашки доткомів, що використовує більш складні інструменти та правила бухгалтерського обліку для досягнення тієї ж мети. Аналітики Morgan Stanley відкрито вказують на повернення "стратегій вендорного фінансування минулих епох", коли продавці допомагають фінансувати купівлю покупцем їхніх товарів. Інвестиції Nvidia у своїх клієнтів та фінансові схеми Microsoft є сучасними версіями практик, які використовували такі компанії, як Nortel та Lucent, що роздували доходи, позичаючи гроші клієнтам, які потім купували їхню продукцію.

Бухгалтерія для оптимістів​

Окрім прямого фінансування, існують і більш тонкі бухгалтерські практики, що нагадують "креативний облік" епохи доткомів. Найважливішим прикладом є подовження термінів амортизації графічних процесорів (GPU). Гіперскейлери, такі як Microsoft і Google, подвоїли термін корисного використання серверів у своїх балансах з приблизно 3 до 6 років.

Ця бухгалтерська зміна має величезний вплив: вона штучно знижує щорічні амортизаційні витрати, тим самим збільшуючи звітний прибуток та видиму рентабельність інвестованого капіталу (ROIC) від їхніх багатомільярдних програм капітальних витрат. Однак це суперечить реальності швидкого технологічного старіння та високого рівня відмов GPU при інтенсивних навантаженнях ШІ. Досвід інженерів Google показує, що GPU при завантаженні 60--70% витримують 1--2 роки, максимум 3 роки, а Meta під час тренування Llama 3 зафіксувала щорічний рівень відмов GPU у 9%.

Основна проблема полягає в тому, що капітальні витрати на ШІ величезні, а рентабельність інвестицій невизначена і віддалена в часі. Щоб виправдати ці витрати перед акціонерами, компанії повинні демонструвати високу короткострокову прибутковість. Подовженя терміну амортизації GPU вартістю $40,000 з 3 до 6 років вдвічі зменшує щорічні витрати у звіті про прибутки та збитки. Це потужний, негрошовий важіль для збільшення прибутку на акцію. Одночасно вендорне фінансування гарантує, що попит на ці GPU залишається високим, що підтверджує масштабне виробництво. Це створює петлю зворотного зв'язку: бухгалтерські зміни роблять інвестиції більш прибутковими, що виправдовує більші витрати, які, своєю чергою, полегшуються вендорним фінансуванням, що стимулює дохід виробника чіпів і підтверджує весь цикл. Це саме той тип проциклічного, наративного фінансування, який визначав пік доткомів.

Міраж прибутковості: Проблема OpenAI на $100 мільярдів​

Нерозв'язуване рівняння​

У центрі цієї крихкої системи знаходиться OpenAI, і її фінансова модель є ключем до розуміння системного ризику. Хоча заголовки святкують прогнозоване "потроєння" доходу OpenAI до $12.7 мільярдів у 2025 році, ця цифра тьмяніє на тлі її структури витрат.

У 2024 році OpenAI витратила $9 мільярдів, щоб втратити $5 мільярдів(чистого збитку). На 2025 рік, з прогнозованими витратами на обчислення лише у Microsoft у розмірі $13 мільярдів, плюс інші величезні угоди та операційні витрати, загальні видатки можуть перевищити $28 мільярдів. Це ставить компанію на шлях до приголомшливих збитків у $14+ мільярдів за 2025 рік.

Згідно зі звітом Bloomberg, OpenAI не очікує досягнення позитивного грошового потоку доти, доки не досягне $125 мільярдів доходу у 2029 році. Це не бізнес-план; це заклик до десятиліття майже ідеального виконання та безперервних, масивних капітальних вливань.

Бізнес-модель OpenAI більше схожа не на технологічну компанію, що масштабується, а на державний інфраструктурний проєкт, як-от програма "Аполлон". Вона є фундаментально нерентабельною на самостійній основі і функціонує як науково-дослідний підрозділ, що спалює капітал для Microsoft та ширшої екосистеми ШІ. Її виживання повністю залежить від її стратегічної важливості для її спонсорів, а не від власної фінансової життєздатності.

Звичайний бізнес, що масштабується, бачить, як його граничні витрати зменшуються зі зростанням. OpenAI, навпаки, бачить, як її граничні витрати зростають зі зростанням, оскільки кожен новий користувач і кожна потужніша модель вимагають більше найдорожчого ресурсу: часу обчислень на GPU. Компанія потрапила в пастку: щоб виправдати свою оцінку і продовжувати залучати капітал, вона повинна демонструвати експоненціальне зростання користувачів і доходів. Але саме це зростання прискорює спалювання готівки до астрономічних рівнів. Це означає, що OpenAI ніколи не зможе "вирости" до прибутковості в рамках поточної парадигми. Прибутковість може бути досягнута лише через фундаментальний, на порядок величини, прорив в алгоритмічній ефективності або обвал вартості енергії/обчислень — жодне з яких не очікується найближчим часом.

Велика стіна фізики: Коли експоненційний ШІ зустрічає лінійну мережу​

Кінцеве вузьке місце​

Справжнім, непереборним обмеженням для буму ШІ є не капітал, не таланти і не регулювання, а енергія. Вся фінансова модель індустрії ШІ базується на тихому, невисловленому припущенні: що енергія є рясним, відносно дешевим і масштабованим товаром. Це припущення є фундаментально хибним.

Прогнози попиту вражають. Глобальний попит на електроенергію з боку дата-центрів має більш ніж подвоїтися до 2030 року, досягнувши приблизно 945 ТВт-год, що більше, ніж усе споживання Японії. У США дата-центри можуть споживати до 12% або навіть 21% усієї електроенергії до 2030 року. Це зростання майже повністю зумовлене ШІ, оскільки кожен 1 ГВт нових обчислювальних потужностей ШІ коштує $50 мільярдів для розгортання.

Цей експоненціальний ріст попиту контрастує з лінійною, повільною реальністю будівництва енергетичної інфраструктури. Проєкти з розширення мереж займають 5-15 років для отримання дозволів і будівництва. Терміни постачання критично важливих компонентів, таких як високовольтні трансформатори, подвоїлися або потроїлися до кількох років. Будівництво нових електростанцій (відновлюваних, газових чи атомних) — це процес, що триває десятиліття.

Саме тут підтверджується ключова теза: "Коли бум ШІ почне тонути не в конкуренції, а у власних рахунках за електроенергію — це і буде момент істини". Коли попит перевищить пропозицію в ключових регіонах (таких як Вірджинія, Техас, Аризона), ціни на електроенергію різко зростуть, а комунальні підприємства будуть змушені відмовляти або затримувати запити на підключення нових дата-центрів, зупиняючи фізичне розширення.

Енергія — це єдиний ресурс, який неможливо створити за допомогою інженерії чи фінансування в короткі терміни. Це робить її остаточним арбітром майбутнього буму ШІ. Розрахунки рентабельності інвестицій у трильйони, вкладені в дата-центри, залежать від високих коефіцієнтів використання та передбачуваних операційних витрат. Найбільшою операційною витратою є електроенергія. Власний ріст індустрії ШІ створює безпрецедентний шок попиту на мережу, яка не була для цього розроблена. Базова економіка диктує, що коли попит зростає експоненціально, а пропозиція — лінійно, ціна товару (електроенергії) має стрімко зростати. Таким чином, успіх галузі активно руйнує одну з ключових умов для власної прибутковості. Це фатальна, системна петля зворотного зв'язку. Фінансові моделі зламаються не тому, що ШІ не працює, а тому, що вартість його живлення стане непомірною, що знищить маржу і зробить неможливим повернення початкових капітальних вкладень.

Ефект доміно: Стрес-тест 2027 року та паралелі з 2008 роком​

Моделювання ланцюгового розриву​

Система може почати руйнуватися, якщо OpenAI та Microsoft не зможуть продемонструвати стійку рентабельність інвестицій до критичного періоду 2026--2027 років. Ось правдоподібний сценарій:

1. Спусковий гачок: Великий інвестор (наприклад, SoftBank) відмовляється від нового раунду фінансування OpenAI, або акціонери Microsoft повстають проти нескінченного потоку капітальних витрат без чіткої прибутковості. Зростання використання ChatGPT зупиняється.
2. Перше доміно (OpenAI/Microsoft): Microsoft змушена списати свої інвестиції в OpenAI. Вона різко скорочує свої плани капітальних витрат на ШІ, що викликає шокову хвилю по всьому ланцюгу постачання.
3. Друге доміно (Інфраструктурні провайдери): Оскільки OpenAI не може виконати свої зобов'язання щодо використання, величезні RPO з Oracle та CoreWeave опиняються під загрозою. Вони змушені йти на переговори або оголошувати дефолт. Ціни на їхні акції обвалюються, а їхня здатність обслуговувати борги, взяті на будівництво, ставиться під сумнів.
4. Третє доміно (Nvidia та кредитори): Раптова зупинка будівництва дата-центрів спричиняє надлишок GPU. Замовлення скасовуються. Історія зростання Nvidia випаровується за одну ніч. Кредитори, які надавали борги під заставу GPU, виявляють, що їхня застава коштує копійки, що викликає кредитну кризу на ринку кредитування технологічної інфраструктури.
5. Поширення: Обвал акцій "Magnificent Seven" та їхніх постачальників матиме широкий ринковий вплив, оскільки вони зараз становлять значну частину індексних фондів та пенсійних портфелів, що призведе до ширшого економічного спаду.

Чому це більше схоже на 2008, а не на 2000 рік​

Крах доткомів був переважно бульбашкою на ринку акцій. Компанії без доходу збанкрутували, інвестори втратили гроші, але ширша фінансова система не була під загрозою. Нинішній бум ШІ, як і житлова криза 2008 року, побудований на боргах та непрозорих, взаємопов'язаних фінансових інструментах.

• RPO як CDO: Ризик у багатомільярдних портфелях RPO є концентрованим і неочевидним, подібно до того, як ризик у забезпечених боргових зобов'язаннях (CDO) був прихований за рейтингами ААА. Усі припускають, що контрагент платоспроможний, доки це не виявляється не так.
• Борг під заставу GPU як субпрайм-іпотека: Новий ринок кредитів під заставу GPU аналогічний ринку субпрайм-іпотеки. Це нова форма кредитування під заставу активів, де справжня довгострокова вартість базового активу (GPU, що швидко знецінюється) є вкрай невизначеною. Обвал цін на GPU зробить цей борг нікчемним.
• Системний леверидж: Вся структура має велике плече. Провайдери дата-центрів активно позичають під обіцянку майбутніх доходів від OpenAI. Один збій може спричинити каскад дефолтів, що загрожує самим кредиторам.

Критична паралель з 2008 роком полягає не в конкретному класі активів, а в структурі системного ризику. Небезпека криється в поєднанні довгого плеча, фінансових інструментів, що приховують концентрований ризик (RPO), та колективної віри в "нову парадигму", де старі правила оцінки та управління ризиками більше не застосовуються. У 2007 році фінансова система вірила, що ціни на житло ніколи не впадуть на національному рівні. Це припущення лежало в основі всього ринку MBS/CDO. У 2025 році фінансова система вірить, що попит на обчислення для ШІ є нескінченним і зростатиме експоненціально вічно. Це припущення лежить в основі всього ринку RPO/боргів під заставу GPU. Криза 2008 року була викликана тим, що основне припущення виявилося хибним. Ціни на житло впали. Криза ШІ може бути викликана тим, що її основне припущення виявиться хибним. Енергетичне вузьке місце доведе, що попит на обчислення не може зростати експоненціально вічно, оскільки енергія для його живлення є обмеженою та дорогою.

Висновок: Навігація циклом хайпу — бум, бульбашка чи крах?​

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

Три сценарії на 2030 рік​

1. М'яка посадка (Сценарій оптиміста): Прориви в енергетиці (наприклад, термоядерний синтез, малі модульні реактори) або алгоритмічній ефективності з'являються вчасно. Рентабельність інвестицій у ШІ починає матеріалізуватися в корпоративних прибутках, дозволяючи галузі поглинути високі витрати. Бульбашка м'яко здувається, оскільки інвестиції раціоналізуються.
2. Повторення доткомів (Корекція оцінок): Енергетичне вузьке місце змушує до болісного протверезіння. Фінансова інженерія руйнується, що призводить до різкої корекції ринку на 50--70% для ключових гравців. Спекулятивні стартапи ШІ зникають. Однак технологічні гіганти (Microsoft, Google, Amazon) витримують шторм, консолідують свою владу, і з попелу виникає більш стійкий, повільний розвиток ШІ.
3. Велика стагнація (Зима ШІ): Енергетична криза виявляється непереборною в середньостроковій перспективі. Витрати на електроенергію стають непомірно високими, роблячи більшість застосувань ШІ нерентабельними в масштабі. Обіцяні приріст продуктивності не з'являються в широкому масштабі в економіці. Трильйони інвестицій списуються як безповоротні витрати, що призводить до тривалого періоду розчарування та зупинки прогресу — "Зими ШІ", викликаної не відсутністю уяви, а відсутністю інфраструктури.

Майбутнє ШІ вирішуватиметься не в лабораторії в Кремнієвій долині чи на торговельному майданчику в Нью-Йорку. Його вирішуватимуть оператори мереж, комунальні комісії та сувора реальність фізики. Фінансова турбіна все ще обертається за інерцією, але закони термодинаміки залишаються непереможними. Рахунок за революцію ШІ наближається, і він буде вимірюватися в гігаватах.

Посилання​

1. Is AI already driving U.S. growth?
2. OpenAI Is A Systemic Risk To The Tech Industry
3. AI Capex Amid 2025 Bull Market: What's Next?
4. Circular Financing: Does Nvidia's $110B Bet Echo the Telecom Bubble?
5. The AI Boom vs. the Dot-Com Bubble: Have We Seen This Movie Before?
6. Why Wall Street Analysts Say We're Not in an AI Bubble
7. OpenAI to Hit $12.7 Billion in Revenue This Year.
8. Data center energy consumption will double by 2030: more than 450 TWh of additional renewable energy will be required to sustain its growth
9. AI is set to drive surging electricity demand from data centres while offering the potential to transform how the energy sector works
10. Powering the US Data Center Boom: Why Forecasting Can Be So Tricky
11. AI has high data center energy costs — but there are solutions
12. AI to drive 165% increase in data center power demand by 2030
13. The AI Bubble Is a Ticking Time Bomb. If It Pops, so Will the U.S. Economy
14. Origins of the Crisis
15. Ten Years of Evidence: Was Fraud a Force in the Financial Crisis?
16. AI Could Affect 90% of Occupations
17. One Third of Companies Plan to Spend More than $25 Million On AI in 2025 Amid Widespread Optimism for Autonomous Agents
18. Superagency in the workplace: Empowering people to unlock AI's full potential

Зараз я працюю в умовах постійної зміни контексту. Мені постійно треба бути на різних зустрічах з різними людьми, та часто зустрічі не мають ні хвилини перерви та відбуваються просто стик в стик. Тому без нотатків можна загубитися в екшенах чи думках. Переважно я веду нотатки старим надійним методом - у звичайному блокноті. Але який процес далі? він різний і хаотичний, про щось я забуваю і ніколи не повертаюсь, але переважно повертаюсь і намагаюсь розібратись. І часто без контексту важко пригадати що за запис в блокноті та про що він. Типу "Розібратись з A\B тестом". Добре якщо я маю дату цього запису, то я можу хоча б провести паралель і відновити ширший контекст. Але все це виглядає не дуже ефективно.

Мені подобається e-ink notetaker-и, типу reMarkable чи Supernote. Але вони не мають гарних інтеграцій з зовнішнім світом. Тобто це буквально девайси щоб писати рукою в цифровому вигляді ЗРУЧНО! Хочу підкреслити, саме ЗРУЧНО. Бо на умовному айпаді писати НЕ зручно(хіба що малювати +-).

Так от. Що ми маємо? Умовний reMarkable з записами від руки, мій Google Workspace в котрому календар, Google Meets(котрий теж записує за допомогою Gemini meetings notes), slack, gmail. І купу різних LLM і AI тулзів. Чому б не мати такий пристрій котрий все це об'єднає в один воркфлоу? Я ж написав ноутси, gemini написав ноутси, ми знаємо коли я це написав і під час якої події. Можна розібрати все це на екшени, якісь навіть виконати, про якісь створити нагадування. От ти приходиш на роботу, а на столі в тебе вже білий лист reMarkable з датою. Ти туди все пишеш і воно все синхронізується з тим що відбувається з автором. Персональні нотатки до персонального акаунту, робочі - в робочий. Теоретично все це можна зробити через n8n автоматизацію, бо reMarkable має можливість робити бекапи в гуглдрайв. А завдяки всій цій синхронізації можна піти далі - Тебе зустрічає не пустий лист електронного нотатника, а вже відкритий, заповнений і пріоритетизований список справ на день. А може взагалі ти прокидаєшся по будильнику котрий був розрахований на основі показників здоров'я і данних про сон, данних про пробки на дорогах, справах на ранок. Приємний голос AI асистента вітає тебе, розповідає про погоду і адженду дня, рекомендує вдягнути футболку, бо сьогодні буде спекотно. І це ж не рокет сайнс, всі данні і технології вже є, просто їх треба зібрати в один воркфлоу.

Тож, хочеш не хочеш, я вже і сам перший раз як заліз під землю 5 років тому, не так активно, як декотрі з них, але певний досвід маю. На моєму “підземному” шляху відбувалось кілька неприємних історій, проте загалом це дуже позитивний і цікавий досвід дослідження міста з, буквально, іншої його сторони.

Моє знайомство з підземним життям відбулось з запрошення на день народження без деталей. Точкою збору виявився вхід у Житній Ринок. Там мене зустріли друзі з пакетами фруктів, тортом, мангалом та іншим стандартним екіпом для свята на природі. Хто ж знав, що це буде пікнік на берегу річки, з зірочкою. Ми перейшли дорогу і зупинились на бульварі між Валами. Далі відкрили люк посеред тротуару і почали спускати ТОРТ, МАНГАЛ та інше під землю. Навколо ходять люди з круглими очами (просто уявіть цю картину з мангалом в люк), та і сам я був трохи в шоці. Видають ліхтар налобний і кажуть: “лізь в люк”.

Отак я вперше побачив річку Глибочиця, зрозумів чому вулиця вище називається Глибочицька і загалом розпочав свою подорож підземеллями.

Якщо в вашій голові ви уявляєте “ту” сторону під люком як пластикову трубу з гівном, то ви праві і не праві одночасно. Підземні споруди я поділяю на дренажні системи, підземні річки, каналізаційні системи, шахти, бомбосховища та інші інженерні підземні споруди. Труби з гівном це лише одна з категорій.

Та і пластикові труби почали прокладати лише нещодавно і поки їх не багато, але тренд вже зрозумілий(скоро все буде в сумних пластикових трубах). Почнемо з річок.

В Києві є 5 основних великих річок, що з розвитком міста були зариті під землю. Зазвичай вони мають старий колектор 18-19 сторіччя з характерним розмахом будівництва.

Вода в підземних річках умовно чиста. Оскільки дощові зливи часто підключені напряму у річку, разом з дощем зливаютсья і ПММ, бруд з вулиці та тверде сміття.

Особливого запаху нема, пахне — от просто уявіть наче річка під землею. Все. Дихати приємно, спокійно. Вода собі дзюрчить, люди, машини десь зверху грюкають люками та решітками зливів.

Річки з старими колекторами часто високі і просторі. Можна йти в повний зріст майже весь час.

Основна небезпека підземних річок — злива на поверхні. Так, у підземній річці “Клов” загинуло чи то 3, чи то більше людей саме через зливу. Ні, вони не задихнулись бо вода піднялась під стелю. Небезпека у хвилі, що може збити тебе з ніг, та загалом потік води стає сильнішим, вода уносить тебе і ти розбиваєш голову о стіну, арматуру, ітд. Тому традиційно річки вважаються зимнім видом дозвілля, бо зимою просто неможливі проливні літні дощі. А літом як дуже хочеться, треба ретельно слідкувати за прогнозом погоди. Зимою, доречі, під землею, дуже тепло =)

Джерела фотографій​

• Особистий архів
• Kyiv Sewage Death Brigade

AHTUNG! Обережно! Мат.

Фраза що згенерував ChatGPT при підготовці цього документу і я вирішив її залишити just for lulz: Якщо ви не хочете читати мат то вибачайтеся і йдіть нахуй. Я не збираюсь це редагувати. Я не збираюсь це видаляти. Я не збираюсь це читати. Я не збираюсь це перечитувати. Я не збираюсь це переписувати.

Вступ​

Радіоаматарство в Україні абсолютно мертве. Завдяки гіпертоксичному комьюніті дідів. Буквально дідів з оцих от умовних КПІ кафедр. Подивіться сайти радіоаматорських організацій. Це блять в прямому сенсі йобаний некролог. Контест — некролог, конест — некролог!

Я розумію що діди — поважні люди котрі багато чого знають, багато досягли і багато зробили для радіодвіжу в країні. Колись. Проте в склавшомуся комюніті, якщо ти не «цитуєш Ротхаммеля» то ти ніхто і звати тебе "ніяк". Розваги які діди схвалюють це йоб*ні однотипні контести і загалом одне і те саме із року в рік. Ніхуя нового і дійсно цікавого не відбувається. Опитування показують що 60% активних радіогубителів це 41+ і більшість з них 50+. Молоді ніхуя нема. А їй і не зʼявитись в цьому обісраному комьюніті де вони блять сидять на ретрансляторі і бухими в нулі кхекхекають про те як вони будуть прати труси(не вигадка).

Тобто якщо молодь знаходить круте відео західних аматорів і хоче так само. То шлях що треба пройти такий, що вона швидко перехоче. Бо йоб вашу мать. Все як в 40 годах. Тим часом захід це просто офігенна двіжуха що проводить єбєйші інженерні івенти(SOTA/POTA), активно веде медіа і всіляко підтримує молодь.

Діди помруть. Ефір затихне. І ніхуя не буде.

Що робити?​

TBA