Оказывается, я пропустил очередной юбилей канала, и почти дотянул до следующего. А, значит, я уже забыл, что это нужно трекать, и канал стал для меня повседневностью.

Привычка - это хорошо.

Поэтому объявляю аттракцион невиданной щедрости!

1000-ному подписчику я лично* приеду и устанвлю Mix на ноутбук!

* - выезд в пределах ТТК.

Кому что, а голому вшивому - баня. Я снова про #fontconfig

Периодически я запускаю strace на свои процессы, и смотрю, какие файлы открывают программы, чтобы:

* Они не лезли по системным путям, типа /usr

* Чтобы они не лезли в папки с установленными статическими библиотеками(если лезут, значит, я где-то забыл выделить общие данные из кода библиотек, и после gc цикла программы перестанут работать)

Почти все графические программы лезут в /usr/share/fonts, и я, наконец, решил это побороть.

Нашел пути в устанавливаемом конфиге, https://github.com/freedesktop/fontconfig/blob/master/fonts.conf.in#L28, убрал, пересобрал, проверил. Программы все равно лезут в /usr, за шрифтами.

Нашел добавление этих путей в исходниках. https://github.com/freedesktop/fontconfig/blob/master/src/fccfg.c#L2670 Ну так, на всякий случай - вдруг кто-то удалит из конфига, и не получит нужных шрифтов. Вспомнил недобрым словом Кейта Пакарда, удалил, пересобрал, проверил - все равно лезут.

Запустил греп еще раз. На этот раз увидел, что отличилась система сборки - https://github.com/freedesktop/fontconfig/blob/master/meson.build#L213 Вспомнил недобрым словом Кейта, его маму, папу, и прочих коллег по цеху X.org.

Короче, на этот раз все сработало. Больше программы в /usr не лезут.

Очень, очень надежная система.

PS: мое творчество:
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/data/mix.sh
https://github.com/pg83/mix/blob/main/pkgs/lib/fontconfig/t/mix.sh#L26

Обещал про динамическую линковку в OSS. #GNOME

Есть такая библиотека - #glib. И в ней типа есть возможность использовать tls. Ну, была раньше. Потом поддержку tls вынесли в отдельную либу - https://gitlab.gnome.org/GNOME/glib-networking, видимо, по лицензионным соображениям(раньше же openssl и GPL были несовместимы), но это же OSS, поэтому glib продолжает делать вид, что умеет в tls.

При попытке использования tls glib пытается загрузить glib networking, и сыпется, если это невозможно. Отделили, да.

Поэтому всякий там код, который хочет использовать tls, проверяет наличие этого загружаемого модуля во время компиляции:

Checking if "GIO has real TLS support" with
 dependencies glib-2.0, gmodule-2.0,
 gobject-2.0, gio-2.0 runs: NO (1)

Реально, вдумайтесь в происходящий цирк.

Конечно, тут же и кольцевая зависимость образовалась(потому что этот плагин продолжает зависеть от glib, а как же иначе).

К счастью, libc от проекта gnu очень хорошо умеет жить с кольцевыми зависимостями(UPD: а до последнего времени был пиздец о n^3 - https://habr.com/ru/post/451208):

"В системе динамического связывания реализован новый алгоритм сортировки DSO, использующий метод поиска в глубину (DFS) для решения проблем с производительностью при обработке зацикленных зависимостей."

https://www.opennet.ru/opennews/art.shtml?num=56631

Выскажу такую мысль - примерно треть проблем, которые можно увидеть на разных форумах про Linux(ладно, я на LOR смотрел) - это проблемы разбиения приложения на плагины. Неработающий звук - 100% посреди цепочки какой-нить pipewire не может найти плагин с alsa. Неработающее ускорение видео в браузере - 100% Mesa не может найти плагин для какого-нить vdpau. И так далее.

Обычно причины этому следующие:

* Пути не стандартизованы. Драйвер от nvidia может положить интерфейс для ускорения декодирования не туда, где его ожидает увидеть mesa.

* Не прописана зависимость, плагина просто нет на FS

* Плагин сломан(не хватает каких-то символов), не загружается.

Тестов на это все нет, и не будет.

Поэтому, конечно, мой подход приятнее - если приложение слинковалось, и список драйверов указан верный, то все заработает.

https://www.youtube.com/watch?v=u9R4RoaLSIM #abi
https://habr.com/ru/company/yandex/blog/649497/

Я всегда спрашиваю, "а чо там с range-based for loop", и мне не отвечают. Комитет С++ уже много-много лет ищет пуговицу, потому что его взяли в заложники IBM(и другие компании, которым важно поддержание ABI) и несколько старых дедов(которым важно поддержать свое слабеющее влияние), и не дают решать насущные проблемы.

Пуговицу искать, конечно, очень увлекательно, но перспективы С++ сейчас, конечно, очень туманны. #cppcom

https://www.opennet.ru/opennews/art.shtml?num=56675

Я, конечно, все понял, только я не понял, на какие исходники, принадлежащие РФ, мне дадут позырить.

Сегодня я выступаю в роли https://ru.wikipedia.org/wiki/%D0%90%D1%80%D0%BC%D1%8F%D0%BD%D1%81%D0%BA%D0%BE%D0%B5_%D1%80%D0%B0%D0%B4%D0%B8%D0%BE

Нас спрашивают, мы отвечаем!

Q: Антон, вот ты, в который раз, пишешь, что в С++ все плохо, а что делать-то?
A:

В рамках текущей организационной структуры С++ комитета ничего сделано быть не может.

Посмотрите, сколько там голосов у американских компаний, и сколько у российских, например(спойлер - у российских 0, Антон туда ездит не как представитель Яндекса, а как представитель всей России(если я верно все понимаю)). Поэтому небольшое число голосов компаний, которым важна обратная совместимость, могут превалировать над всеми разработчиками С++ всего мира, которым ABI нафиг не всралось, они все равно и так все пересобирают, так же, как в Rust.

Ну и текущая структура комитета настроена на воспроизведение самое себя, впрочем, как и любая другая структура. Люди, которым там что-то не нравится, и они публично об этом заявляют, каким-то образом оказываются вне этой структуры, я периодически на такие coming out кидал ссылки.

Мне кажется, у MANGA(основные потребители С++) могло бы хватить сил, чтобы переломить эту ситуацию. Например, сказать, что они делают С++v2, и что clang будет его поддерживать. Если бы они сказали, что сделают в С++v2 нормальные lifetimes, и правильную обработку ошибок, я бы пошел двигать переход на их стек, думаю, как и многие другие.

Может ли кто-то, кроме MANGA? Сомневаюсь. Да нет, не сомневаюсь, не может.

А они сделают? Думаю, нет, думаю, им ОК новая волна в виде Rust. Зачем чинить С++ - это сложно, муторно, долго, и немодно, когда можно просто воспользоваться новым хайпом? Если бы не Rust, то стимул починить С++, конечно, был бы существенно выше, я был бы оптимистичнее про судьбу С++.

Я думаю, выбор между "душнилы, которые заставляют в говно мамонта" и "светочи прогресса, которые за стильно, модно, молодежно" очевиден(хотя старые пердуны, которые принимают решения внутри, прекрасно понимают, что с инженерной точки зрения особой разницы нет).

Я, конечно, пытаюсь свои патчи отправлять в upstream, но чаще всего оказывается, что оунеры кода - те еще негодяи.

Вот, отправил свой патч про отказ от double fork. -20 строк кода, сплошное упрощение и улучшение. Как думаете, какие шансы у патча? Я вангую, что околонулевые.

https://github.com/swaywm/sway/issues/6828

Теорминимум по #bootstrap

Разные команды вкладывают в это понятие очень разные смыслы.

Кто-то - что в процессе сборки не должны участвовать бинарные блобы(за исключением возможного минимума). Понятие "бинарный" часто не конкретизируется. Java VM, python pickle - чаще всего "бинарные блобы". По мне, так программы для "раннебутстрапного" forth от бинарных блобов не отличимы, но это никого не останавливает.

Кто-то идет еще дальше, и считает, что автосгенеренные исходники использовать тоже нельзя. Эти люди занимаются бутстрапом flex/bison/ragel/etc. К сожалению, на этом пути лежит пропасть и бездна - configure скрипты. Уважаемым коллегам или приходится переписывать систему сборки части кода, или бутстрепать код в бездну веков. Это, например, GUIX.

Кто-то больше всего печется о "чистоте" результата. Ну, чтобы рандомный Васян мог воспроизвести md5-equal result. Используется ли при этом бинарный seed, или нет, коллег особо не волнует. Это, например, Nix.

Я тут стараюсь придерживаться прагматичной стороны - я не перестраиваю configure на ранних этапах bootstrap, но когда у меня готов perl, начинаю перестраивать. Типа, получить 95% результата за 5% денег. Если у меня 1000 пакетов, и в 995 из них я убираю сгенеренные файлы, поверхность для атаки я уменьшаю многократно, и вполне достаточно для практических целей. Бинарный seed я, фактически, использовать не могу, потому что чаще всего он рассчитывает на наличие glibc.

Еще интересная дихотомия - какой язык использовать в качестве "изначального". Чаще всего это компилятор С, потому что достаточно высокороуровнево(не надо мудохаться с ассемблером и гипервизором в кольце 0), можно дотащить цепочку, куда угодно, большинство системного кода написано на С.

Я тяну цепочку с С++, потому что поддерживаю Darwin, а там единственный компилятор, который умеет рожать Mach-O - это clang. Есть проекты, которые тащут tcc/scc под Mach-O, я с удовольствием за ними слежу(потому что С++, это, конечно, многовато).

Наверняка есть попытки затащить эту цепочку с Rust, но я о чем-то таком успешном пока не слышал. В принципе, все для этого есть - uutils, наверняка есть простой компилятор С на Rust, шелл точно есть. Если тащить с Rust, то, конечно, с собой нельзя брать Cargo. Весь смысл теряется, если добавить cargo в seed, да и не спортивно это. Как #mrustc тянет cargo через свой minicargo - это же песня.

Про патч в #sway у меня, конечно, плохие предчувствия. Судя по активности в репе, разработчики как забухали в начале января, так в строй и не вернулись - ревью не отревьюены, и все такое.

Завершил большой и важный рефакторинг, один из 2 оставшихся, после выполнения которых я бы считал свою пакетную систему завершенной.

Я перенес построение realm/environment из пакетного менеджера в граф построения пакетов. Звучит странно, и непонятно, зачем это нужно?

#realm - definition ***

realm/environment - это материализованное в FS множество пакетов. Если говорить просто - папочка, которая содержит кучу симлинков на файлы из других папочек(пакетов). Куча симлинков образует некоторую сущность(realm, env), которая самодостаточна для выполнения какой-то задачи.

Чтобы совсем просто:

* realm из пакета-бинаря и пакетов-шаренных библиотек является достаточной сущностью для запуска этого бинаря.

* realm из пакетов busybox + runit + kernel достаточен для запуска компьютера.

Раньше у меня было сделано так - я строил граф, описывающий построение всех папок с пакетами, выполнял его, потом кодом сверху делал еще одну папку, которая содержала в себе симлинки на файлы из пакетов.

Теперь построение папки с симлинками погружено в тот же граф, что строит пакеты. Фактически, с точки зрения системы realm стал таким "пакетом с пакетами", если вы понимаете, о чем я.

Почему это вообще важно? Теперь вторая часть моего сегодняшнего рассказа!

Когда я писал, что переехал на mix на своем ноутбуке, конечно, это был многоступенчатый процесс.

* Сначала у меня в системе был только root, все пакеты строились от него, все было в едином namespace. Я так отлаживал пригодность модели "куча папок с симлинками" для управления файлами системы вообще.

* Потом я завел пользователя mix. На этом этапе построение пакетов и realm/env выполнялось от пользователя mix, я сам был залогинен в mix, но сервисы уже работали от root. Я так отлаживал свою модель эскалации привилегий и модель "пакеты не от root". Это уже почти норм, кроме того факта, что неловким движением можно снести всю пакетную базу.

* С пятницы я живу в модели "пакетный менеджер - это демон, который крутится от пользователя mix, принимает команды на управление пакетной базой, и выполняет в соответствие со своей моделью безопасности". Важно отметить, что примитивная команда - это не "установи в систему bin/bash", а ПОЛНОЕ описание(граф с зависимостями) того, как построить бинарник bash, и установить его в систему. Я эту модель опишу в следующих сериях.

Я думаю, тут важность моего рефакторинга стала очевидной. Одно дело, когда поверхность взаимодействия в точке эскалации привилегий - это хорошо формализованный граф, который можно провалидировать вдоль и поперек перед выполнением(ну, вот, как ядро валидирует eBPF программы), другое дело - "хорошо формализованный граф" + "говна самовар" вида "а вот тут, сбоку, сделай еще папочку с кучей симлинков и дерни там чего-нить" ** .

Короче, модель вполне жизнеспособна, пакетный менеджер я отселил в socket activation daemon*, с точки зрения модели безопасности мне все очень нравится.

* забавно, как можно продать одно и то же говно, но разными словами. Мой socket activation daemon - это "mix gen-graph —json | ssh mix@localhost /bin/mix execute —stdin" (напомню, что мои su/sudo - это suidless программы, которые делают ssh на localhost)

** как вы уже, наверное, поняли, прямо сейчас я ничего не валидирую. Я знаю, что это возможно, я сделаю это позже, но слона надо есть по частям. #sec_model

*** я намеренно выбрал странное слово realm, а не всем знакомое env, потому что, конечно, мой realm похож там на env из Nix, но не настолько, чтобы считать их одним и тем же. Чтобы в голове не было путаницы, я выбрал похожее, но другое, слово. IMHO получилось хорошо, удобно, и однозначно(меньше путаницы в голове это уж точно)

https://tjournal.ru/news/533398-rukovoditeli-ibm-vo-vnutrenney-perepiske-nazyvali-rabotnikov-starshe-40-let-dinozavrami-kotorye-dolzhny-vymeret

Новость, конечно, позитивная, потому что это сразу решит проблемы с дедами в Комитете С++, мешающими этот стандарт двигать вперед. Or not? #cppcom

https://www.opennet.ru/opennews/art.shtml?num=56691 #lust

У меня пара свежих мыслей на тему:

* За пределами big tech мало кто понимает, что ядро на голой сишечке - это леденящий душу пиздец. Intel-у, например, вполне OK.

* За последние несколько месяцев я прочел довольно много кода драйверов(kernel, mesa), чтобы понять, что средний драйвер - это очень тупая штука, которая берет набор за-OR-енных generic флагов, превращает их в набор за-OR-енных device specific флагов, и пишет это число в порт. Управления памятью в среднем драйвере или нет, или очень мало.

* Желание читать мануалы про за-OR-енные device flags чаще всего антикореллирует с желанием прогать на высокоуровневом языке.

Поэтому мое IMHO - в текущем виде это проект для себя и узкого круга компаний, типа Facebook, которые "понимают". Я считаю, что текущее целеполагание проекта - странное. Ну перепишут Гугл драйвера для своих TPU, а дальше что? Intel и средний "kernel hacker" это не купят.

IMHO правильным целеполаганием было бы "переписать tcpip stack"(потому что новые алгоритмы для congestion control, конечно, проще на Rust/C++), или "переписать шедулер". Впрочем, возможно, истинное целеполагание именно такое, просто оно не озвучивается. Это, конечно, было бы хорошо. Мне не нравится Rust, но вот писать на С я в ядро точно не полезу, а на Rust полезу.

https://codeberg.org/dnkl/foot/src/tag/1.11.0/README.md#user-content-xtgettcap #terminfo

Хорошая же тема, да, чтобы эмулятор терминала сразу отдавал свои capabilities, без всяких terminfo database, да?

Как бы это сделал вменяемый разработчик? Например, чтобы эта функция терминала отдавала TERMINFO запись as is, чтобы ее можно было там передать в curses, и использовать сразу? В крайнем случае, машинно-понимаемой трансляцией в json/xml/yaml.

Но, очевидно, Том #Хуйкин(разработчик xterm), индус #Ковид(разработчик Kitty), и неизвестный мне разработчик #foot(ссылку на опус которого про поддержку sync updates я тоже кидал), к такому решению, конечно, прийти не могли - это ж всего 3 строчки кода, и победную реляцию не напишешь!

Поэтому, конечно, все это сериализуется в промежуточный непонятный формат(с потерей в процессе), а клиенты потом должны восстанавливать. Зато можно будет написать еще 10 победных реляций про очередную перемогу в стиле "а мы поддержали еще 5 полей из terminfo"(несовместимым, конечно, образом).

———
https://www.opennet.ru/opennews/art.shtml?num=56703
https://www.opennet.ru/opennews/art.shtml?num=56704
https://www.opennet.ru/opennews/art.shtml?num=56700
https://www.opennet.ru/opennews/art.shtml?num=56699

Слушайте, вот вы понимаете, зачем люди клепают эти производные Debian с нескучными обоями? Меня, как автора настоящего, интересного, дистрибутива, это все, конечно, напрягает.

———
https://lobste.rs/s/adr60v/single_binary_executable_packages

Очередной срачик static vs. dynamic. Автор, конечно, говорит дельную вещь - а давайте, типа, сразу все приложения готовить в виде одного исполняемого файла, но он, наверное, сам так не пробовал, и не понимает, в чем проблема такого подхода.

Кстати, совсем забыл. Если вы такой же фанат машграфа, как и я - обязательно подпишитесь на https://www.facebook.com/sergey.tsyptsyn/

Вернусь к вчерашней ссылке про static vs. dynamic.

https://lobste.rs/s/adr60v/single_binary_executable_packages#c_xoxpbs

1) Там подняли интересные темы про статическую линковку в Rust и Go.

2) СЯУ, что в Rust нет кросс-компиляции. Ну, точнее, есть, по модели CMake(#cross #cmake на сайте написано, что есть, а cargo таки оперирует одним графом). Я это еще заприметил, когда только начал им пользоваться, но у меня не хватало уверенности, чтобы об этом сказать.

———
https://codeberg.org/dnkl/fuzzel/pulls/53

Автор #foot классный. Я как-то писал про проблему первого кадра в sway, так вот, коллега тоже обратил на нее внимание, и даже предложил решение.

———
https://rtpg.co/2022/02/13/your-own-sudo.html

Товарищи, если кто-то в вашей окружности решит написать sudo на python, пристрелите его.

* питон загружает много модулей
* авторам so-шек обычно нет выхода, кроме как заполучать параметры для себя через env
* man secure_getenv, и связанные с загрузкой so #suid-ными бинарями CVE.

———
https://gankra.github.io/blah/text-hates-you/
http://rastertragedy.com/RTRCh0.htm

Классные тексты про text rendering и text shaping.

Вообще, хочу сказать, что то, что эмодзи решили погрузить в шрифты - это, конечно, леденящий душу пиздец и layer violation, который до сих пор аукается. Почитайте, как разные люди решают задачу рендеринга эмодзи, это прекрасно.

Кстати, про шрифты - связка Inter + IBM Plex мне нравится даже больше, чем набор шрифтов в macOS.

https://github.com/skarnet/execline/issues/9

Успел посраться с автором s6, по поводу утилиты #execline. По очкам я, конечно, победил, но мое предложение он, конечно, отверг.

———
Будни бутстрапа.

Как-то писал про то, что система зависает, если убить sway неправильно. Оказалось, что она не зависает, а просто прекращает как-то реагировать на ввод. Фикс, что характерно, я подсмотрел в трекере sway. https://github.com/pg83/mix/blob/main/pkgs/bin/fixtty/main.c https://github.com/swaywm/sway/issues/4540

Фикс этот, конечно, не может войти в sway, и его вряд ли примут mainstream дистрибутивы. Я не гордый, я дергаю программулю перед каждым новым логином:

https://github.com/pg83/mix/blob/main/pkgs/bin/mingetty/runit/mix.sh#L16

У меня лучший дистрибутив для работы со sway!

Заодно выпилил хаки, и прибиваю stale процессы почем зря.

Отдельно скажу, что вот эти tty - это, конечно, кошмар. Про них Линус и так говорил, что не понимает, как они работают, но после того, как к ним привязали KMS/DRM, стало вообще худо. https://lwn.net/Articles/343828/

Еще интересный факт - у меня, когда я еще использовал Fedora, регулярно не просыпался ноутбук после сна. Теперь я смог это раздебажить. Оказывается, драйвер amdgpu начинал сыпать стектрейсами, sway падал в кору, и система приходила в волшебное состояние, которое я описал выше. Теперь же она из него замечательно выходит сама, и я увидел все корки в dmesg.

Простота - это хорошо. В федоре у меня не было никакой возможности увидеть эти трейсы. Чинить баги, а не документировать их в wiki, как делают Arch/Gentoo - тоже.

Кстати, amdgpu не сыпет этими стектрейсами в 5.17, ждем релиза.

https://mobile.twitter.com/marcan42/status/1494213855387734019 #asahi

У меня чет знатно долбануло от заявления этого долбоеба разработчика Asahi Linux Гектора Мартина:

"Well, this is unfortunate. It turns out Apple's custom NVMe drives are amazingly fast - if you don't care about data integrity."

Давайте я вам расскажу, что там происходит.

Гектор жалуется, что macos "читит" - некорректно реализует семантику fsync(а я, кстати, позволю себе напомнить, что macos - сертифицированный Unix, в отличие от), и, за счет этого, обгоняет его драгоценный Ляликс на бенчмарках NVMe. И отмечает, что, если в Apple ткнуть паяльником, то после ребута она потеряет данные.

Коллега просто не понимает, что такое "делать хорошо" и "полагаться на хорошо спроектированный и реализованный нижележащий слой".

Вы в macos теряли данные после ребута? Я не терял.

Если инженеры Apple:

* Хорошо отладили свою ОС, настолько, что ГАРАНТИРОВАТЬ, что OS сбросит буфера FS и контроллера на диск при нажатии на кнопку Reset.

* На всякий случай добавили туда батарейку, и написали код, который по исчерпании батарейки сбросит буфер и выключит комп.

То им просто не надо реализовывать ту семантику fsync, о которой говорит Гектор, чтобы обеспечить целостность данных.

Я напомню, что вот та семантика fsync, о которой пишет Гектор, нужна, когда твою OS пишут красноглазые пионеры без тестов. Потому что заставить весь зоопарк FS флашить данные пофайлово - невозможно. Заставить FS флашить данные корректно - невозможно https://danluu.com/file-consistency/ https://www.deconstructconf.com/2019/dan-luu-files Убедиться, что весь зоопарк контроллеров флашит данные корректно - невозможно.

Единственное, на что можно(а на самом деле и нельзя) полагаться - что fsync сделает большой мега-барьер по всему стеку, и скинет данные на диск насколько это возможно надежно, в такой ситуации.

Короче, Кисо обиделось, что кто-то хорошо проделал свою работу, и может на это полагаться, и срезать пару острых углов на этом, и хорошо смотреться на бенчмарках. И что не рассчитывает на паяльник. А его красноглазое поделие такой роскошью не обладает. И что это поделие не способно эффективно работать в той модели sync, на которую рассчитывает macos.

Ну чо, норм, но не надо говорить, что macos "читит", это вводит людей в заблуждение. "if you don't care about data integrity" - Гектор просто не понимает, насколько, а самое главное, КАК, Apple заботится о integrity.

И, кстати, еще такая мысль - подобные штуки поясняют, почему Apple против Хакинтошей, и почему Хакинтоши - так себе мысль. macOS работает на железе, которое сделано по несколько другой философии, это нужно учитывать

Давно обещал написать про Фуксию, и, думаю, пора. #gold

WARNING: я лично очень хочу, чтобы то, что я напишу ниже, произошло, поэтому этот текст во многом - wishful thinking.

Для начала - исторический экскурс.

Индустрии в начале 90-ых нужна была нормальная стандартная OS, потому что под тот зоопарк, что был, писать софт(серверный и для рабочих станций) было решительно невозможно.

Фактически, у индустрии было 2 пути:

* MINIX. К сожалению, Таненбаум уперся рогом, и отказался выпустить эту OS под нормальной лицензией.

* BSD. К сожалению, в тот момент AT/T && Bell Labs сошли с ума, закрыли код Unix, и начали вовсю судиться за его наследие. Поэтому судьба BSD ответвления была неясна, а корпорации не любят, когда правила игры не известны, и не лезут в это. Конечно, появился проект по переписыванию спорных частей BSD, мы его теперь знаем как FreeBSD. Но он немного опоздал.

(открытие кодовой базы Solaris, я, например, не рассмариваю, потому что она была ответвлением той же "проблемной" BSD)

В этот момент появился Linux. Нормальный(для того времени) код, более-менее приличная лицензия. Энтузиасты подхватили, корпорации пошли вслед за ними. Да, я считаю, что залог успеха Linux - это не качество его кода и не личность Торвальдса, а, в основном, что это было good enough решение, появившееся just in time.

Война коммерческих юниксов и Linux отгремела в 95 - 2000, я пришел в Unix в 2000, уже на исходе войны. На тот момент было интересно - с одной стороны, уже все было предрешено, в Linux двинулись большие корпорации, с другой - Linux еще не настолько оторвался от конкурентов, чтобы занять настолько монопольную позицию, как сейчас.

Я, например, на тот момент перепробовал и Linux, и все семейство BSD, и я не могу сказать, что кто-то из них был явно лучше. Более того, я могу совершенно уверенно заявить, что на момент 2010 года core Linux и FreeBSD по качеству отличались не сильно. Perf поисковых программ на Linux и на FreeBSD были вровень вплоть до самого перехода.

Корпорации привнесли в Linux современные FS и драйвера под серверное железо, и за счет этого Linux стал смотреться лучше, чем конкуренты.

Теперь я хочу сформулировать некоторый ключевой для текста поинт.

Мой поинт - core Linux прогрессировал не шибко сильно, по крайней мере, конкуренты в лице FreeBSD все еще смотрятся неплохо на его фоне(драйвера оставляем за скобками). Ссылок давать не буду, perf тесты на всяких phoronix легко доступны. То есть, не надо думать, что там запилили кучу крутых алгоритмов, которые делают что-то умное - кодовая база это не позволяет.

Linux обогнал конкурентов в виртуализации(не очень далеко, на самом деле), и поддержка серверного и телефонного железа у него лучше, по понятным причинам.

Еще одно ключевое утверждение - современное железо становится все больше и больше черным ящиком с какой-то mini-OS внутри, работающим по фиксированному протоколу. Поясню, что я имею в виду - в Linux 50 драйверов для SATA устройств, потому что эти драйвера напрямую программируют соответствующий контроллер. А вот NVMe - это, простите, 1 generic driver на всех. USB HID - 4(джойстик, мышь, клавиатура, и 1 я забыл) generic driver на всех.

(Из этих 2 утверждений следует все остальное)

Что я хочу этим сказать? А то, что важность Linux как коллекции драйверов будет неизбежно падать, и конкурировать с другими OS он снова будет шедулером, VM, и прочими generic штуками. И, как я уже показал выше, другие OS не то чтобы сильно отстали в этом направлении(потому что, повторюсь, в core Linux нет магии, это очень обычное ядро из 90-ых).

#gold

Еще один важный факт - современные OS, которые пишут на нормальных языках, разрабатывать в 10 раз проще, чем кодовую базу Linux.

Например, код Фуксии я понимаю влет, и смогу включиться в разработку в любой момент времени. Шедулер OS - это, на самом деле, очень простая вещь. Это надо прочесть 10 академических статей, попробовать 100 вариантов на симуляторе, и выбрать наилучший. Проблема в том, что в кодовой базе Linux это невозможно. А в Фуксии - возможно, и это будет сделано.

Виртуализацию, которую пилили 15 лет, можно будет нагнать за 2 - 3 года, имея современную кодовую базу и язык.

Исходя из всего написанного, и из того, что разработчики Linux не поменяют свою тактику, вот вам мой прогноз:

Важность Linux будет падать. Его роль в качестве гипервизора займут современные системы, написанные на современных безопасных языках. По мере того, как устройства будут упрощаться с точки зрения OS, Linux потеряет важность и как коллекция драйверов. Потом он уйдет под управление гипервизором как неплохой POSIX слой, но и там он потеряет свою важность, потому что:

* FreeBSD тоже норм POSIX слой, а корпорации таки не любят GPL.
* Я ожидаю, что свободные OS на безопасных языках подтянутся и в этом месте, и станут неплохой POSIX-пускалкой внутри гипервизора. Если там не нужна коллекция драйверов, то какая разница, кто для приложения обеспечивает POSIX fs?

(кстати, macOS тоже можно рассматривать по этой модели - non-POSIX OS снаружи, POSIX layer внутри)

Короче, в перспективе 20 лет, если кернелхакеры не поменяют свое отношение к разработке, я не вижу Linux нигде.

Будет ли там гипервизором фуксия, а POSIX слоем redox - я не берусь гадать. Фуксия лично мне нравится, но Google ее точит под IoT, и что там выйдет на больших машинах - я ХЗ. (redox мне не нравится, и вряд ли он там будет)

Почему я лично хочу, чтобы это случилось?

* Я хочу, чтобы на компе у меня стояла OS, в которой можно ковыряться

* Я хочу, чтобы у меня не тормозил браузер во время компиляции браузера

Я готов и сам экспериментировать с шедулером, но не в кодовой базе Linux. Это контрпродуктивно.

Поэтому, конечно, я хочу, чтобы была свободная OS, с дровами, и чтобы в шедулер к ней можно было залезть, не боясь взорвать мир.

У меня для вас сегодня парочка анекдотов. Про сборку, конечно.

* https://github.com/pg83/mix/blob/main/pkgs/bin/net/tools/mix.sh#L18

Авторы net-tools настолько упоролись, что решили, что их сборка может быть запущена только руками, и ответы на вопросы надо вводить в терминале. К счастью, в Unix есть утилита yes, видимо, как раз для таких случаев. expect не понадобился. Чо делать, если, вдруг, на какой-то вопрос надо будет ответить N, и порядок плохо определен, я не представляю. Рецепт я подсмотрел то ли в arch, то ли в nix. Я часто обращаюсь к ним за помощью - у меня всего 1 человек на 500 пакетов, а с них не убудет.

* https://github.com/johnsonjh/OpenVi/blob/master/GNUmakefile#L402

Автор openvi при инсталляции готовит для себя какой-то бекдор(ладно, на самом деле, нет, просто так выглядит). Без всякого PREFIX, DESTDIR, в систему по живому. А временные файлы он хочет хранить в /tmp, и больше нигде.

* https://github.com/pg83/mix/blob/main/pkgs/bin/yambar/00.diff

Автор yambar настолько упоролся по плагинам, что вынес в плагин часть core, и ему приходится принудительно рассчитывать на этот плагин. Мой патч просто заменяет dlsym() на прямой extern символ, потому что ему пришлось оставить этот символ в бинарнике. Плагины такие плагины.

* Для сборки ядра нужна тулза bc. Тулза bc от проекта GNU требует для сборки программу ed. Но если собирать bc от GNU с ed от GNU, то ed зависает на входе. При этом, замечательно срабатывает ed из проекта heirloom, но на получившемся bc виснет сборка самого ядра(я смотрел на выхлоп heirloom ed, и почти готов дать зуб, что он таки правильный). На этом замечательном результате я остановился, и взял bc из проекта busybox.