Теорминимум по #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.

https://news.ycombinator.com/item?id=30410457

Я тут подумал, что, по сути, тема #bootstrap интересует меня с глубокого детства - как сделать что-то из ничего? Мои любимые приключенческие романы:

* Робинзонада
* Жюль Верн - каждое второе произведение про то, как люди оказываются в ситуации, когда у них ничего нет, и надо сделать что-то(чтобы далеко не ходить - "Таинственный остров")
* Майн Рид - скажем, "Морской волчонок".

Конечно, это все про bootstrap в чистом виде.

Clean room bootstrap второй личности - кажется, очень интересная тема. Тоже низачем, тоже в качестве хобби.

———
Хочу развить тему кражи заимствований из других пакетных баз.

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

Недавно я придумал, как мне существенно сократить время на version update.

Мне нужно распарсить репозитории arch и nix, вытащить оттуда url'ы, и, если для какого-то моего урла у меня есть префикс в этой украденной базе, но суффикс не совпадает, то это значит, что у меня появилась новая версия.

Это позволит мне(на первых порах, конечно!) не заниматься скриптами парсинга страниц от вендоров на предмет наличия новых версий, и в несколько раз сократит время на занятие такой поддержкой. Предположительно, минут 5 в день на 1000 пакетов.

———
В продолжение предыдущей темы - про размеры пакетной базы.

Arch и Nix впечатляют своими размерами, но надо понимать, что это "ни о чем".

БОльшая часть этих пакетов - это автоматически сгенеренные описания из хорошо формализованных источников типа pypi, cargo, cabal, etc.

Ну вот у меня тоже такое есть для pypi - https://github.com/pg83/mix/blob/main/pkgs/pip/pypi.json (оно пока неполное, потому что надобности в полном pypi пока нет).

<—Кстати, заодно похвастаю своим механизмом VFS - произвольные части дерева пакетов могут быть построены программным образом. Например:

* https://github.com/pg83/mix/blob/main/pkgs/pip/mount.py - вот такая генерилкя для этого pypi.json. То есть, пакетная система на лету строит описания пакетов для экспорта из pypi.

* Оверлеи в пакетной системе для произвольного локального переопределения произвольного поддерева сборочных пакетов.

Протокол очень простой - если в поддереве есть mount.py, то позвать его метод serve() на суффикс пакета(за вычетом префикса поддерева) - https://github.com/pg83/mix/blob/main/pkgs/pip/mount.py#L68 Конечно, такой VFS слой может вернуть и код какого-то другого mount.py(даже программносгенеренного) в своем поддереве. Мета-мета-программирование my ass!—>

Короче, если выкинуть все такое формализованное, и посмотреть на ручную работу, то у меня 250 библиотек в lib/, а у Nix - 1700 в development/libraries/. Разница есть, но даже не на порядок.

Ну, зато я теперь могу задуматься про импортозамещение Nix && GUIX!

#sway Simon Ser наконец-то очнулся. Видимо, с такой скоростью разгребания входящего потока сообщений наша переписка займет 2 - 4 месяца.

Ну я не удержался, конечно, от того, чтобы поучить его жизни - https://github.com/swaywm/sway/issues/6828#issuecomment-1047656334

А чо, пусть коллега изучит используемые им API, наконец-то. Конец, наверное, тоже немного предсказуем.

Системы по загрузке плагинов делятся на: #plugins

* "Нормальные"

Точка входа в XXX.so имеет вид OBJECT* init_XXX(CTX*). Так устроен, например, python. Версионирование, без излишних вызовов dlsym(), без модификации глобального состояния. В общем, приемлемо, ну, насколько это вообще может быть приемлемо. Статически линкуются только в путь.

* "Ну такое"

Все, то же самое, но точка входа имеет вид init(), без _XXX. Это норм, когда система плагинов не подразумевает никакой возможности статической линковки. В случае статической линковки приходится ходить sed'ом по коду, и сводить все к первому случаю. Ну, например, vulkan loader.

* Всратые

Всратость бывает, конечно, разная. Например, плагины для gio подсистемы из glib:

https://github.com/GNOME/glib-networking/blob/master/tls/gnutls/gtlsbackend-gnutls.c#L278

Казалось бы, первый тип? Нет, 2 строчками ниже опциональная регистрация в каком-то глобальном объекте, если в конструктор не передали место, куда регистрироваться. Опциональная с точки зрения runtime, но не линкера.

Ну, от GNU и #GNOME особо никто ничего и не ждал.

* Всратейшие.

Тут кто во что горазд. Например, FAR Manager - 20 точек входа, 10 из которых - это глобальные объекты в плагине. Все это добро может быть, а может и не быть. Плагин имеет произвольный доступ к состоянию программы, к ее глобальным объектам. Ссылок не дам - это все размазано по всему коду. Ощущение такое, что кто-то порезал монолитную программу на .so произвольным образом, но, вместо того, чтобы динамически с ними слинковаться, сделал из этого плагины.

* Леденящий душу пиздец

Например, загрузка плагинов для загрузки разных форматов изображений в gdk-pixbuf. https://github.com/GNOME/gdk-pixbuf/blob/master/gdk-pixbuf/gdk-pixbuf-io.c

Что бы я тут особо подчеркнул:

- 2 разных системы загрузки плагинов - для встроенных, и для внешних

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

- Самое встратое - вместо того, чтобы полистить содержимое директории с плагинами, это говно ожидает, что установщик очередного плагина добавит метаданные этого плагина в какой-то очень встратый файлик. Повторить это я не смог, и притворился, что svg - это встроенный плагин, но загружаемый через dlopen() https://github.com/pg83/mix/blob/main/pkgs/lib/gdk/pixbuf/00.diff

- Конечно, всё это говно только ради одного единственного настоящего плагина in the wild - загрузчика svg

Точек входа у каждого плагина там 2, это важно. Имена у всех них одинаковые, статическая сборка не предусмотрена.

Отдельной строкой хотел бы упомняуть лоадер из opengl(). Там, конечно, есть GetProcAddr(const char*), чтобы можно было одни драйвера делать послойно над другими, но, несмотря на это, каждый драйвер должен проэкспортировать все 300 функций из opengl() явно. Благо, это просто - все 300 функций описаны в удобном XML файле. Отсюда десятки проектов типа https://github.com/anholt/libepoxy, которые генерят мегабайты кода в виде .so, только чтобы подменить пару функций. Я думаю, программистам на C это очень заходит - мегабайты кода без единой аллокации и возможных проездов.

Я, кстати, прикидывал - средний вызов в opengl/vulkan проходит 3 - 5 уровней косвенности. Так и живем.

Я не люблю проекты GNU и #GNOME за их левацкую, SJW-шную показушность, очковтирательство, и нечестность.

https://www.phoronix.com/scan.php?page=news_item&px=GNOME-42-Beta

GNOME 4X - это сплошная ложь.

Я не уверен, что на старте у них вообще были приложения, портированные на GTK4, сейчас таких приложений около половины, и ни одного, в которых вы проводите бОльшую часть времени. Epiphany(WEB браузер), Evince(просмотр документов), terminal - все еще на GTK3. inkscape(хотя и не часть GNOME) вообще только недавно перешел с GTK2 на GTK3). Просмотрщик шрифтов на GTK4 - это, конечно, круто(нет, это херня). Я не думаю, что вы проводите много времени в control center и просмотре шрифтов.

Благо, отличить на внешний вид приложение на GTK4 от приложения на GTK3 невозможно. С одной стороны, это может быть и хорошо в виде преемственности, а с другой - зачем тогда вообще бампать версию тулкита, если там только рефакторинг интерфейсов?

Бампать мажорную версию DE, с таким трудом обновлять в репах, чтобы что? Чтобы видеть те же приложения в том же интерфейсе и с теми же фичами?

Кстати, вчера каналу исполнилось полгода, принимаю поздравления и фидбек. Напомню, что лучшее, что вы можете сделать - поделиться ссылкой на канал где-нибудь(разве что, вот тут не надо - https://bdsmpeople.club/).

В одном там рабочем чате с коллегами зашла речь, кто как смотрит порно. Мне пришлось признаться, что я для этого использую рабочий macbook, потому что в моем браузере все еще не работает поддержка видео. Собственно, у меня там 3 заметных проблемы:

1) Поддержка видео. Как починю, обязательно напишу про эту эпичную историю.
2) Про кривые иконки из-за старой librsvg я уже писал, надо или как-то затащить Rust, или научить это оффлоадить в inkscape. Я склоняюсь ко второму пути.
3) И сегодняшняя история - поддержка PDF!

Epiphany, как и многие, поддерживает PDF через PDF.JS. Но оно почему-то не работает. Конечно, как обычно, дело в динамическом связывании - код, которому нужен код читалки, не может его найти в runtime. И в данном случае дело не в статической линковке, а в чем-то еще(что-то с ресурсной системой glib, я не разобрался пока).

Чинить это займет время, а pdf-ки читать надо уже сейчас.

Я решил вечерочком собрать себе читалку - Evince. Думал, плевое дело, простая программа, все зависимости уже в репе, 5 минут, не больше. Ага, конечно.

* В программе есть плагины. Читатели у меня уже прошаренные, поэтому я просто скажу, что загрузка плагинов там по второму типу #plugins Плагины много времени не заняли, все же, это основная фишка дистрибутива.

* После загрузки программы я увидел надпись "unsupported mime type application/octet-stream", и тут я понял, что это надолго.

Не буду утомлять скучными подробностями #debug, но:

* glib неявно зависит от базы данных для определения mime types. Неявно - значит, все делает вид, что работает, до поры до времени, примерно как TLS в той же #glib.

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

* Самое страшное - сборка этих данных зависит от docbook xml, а это моя дикая боль. Я напишу об этом отдельно, но надо понимать, что там очень сложная динамическая линковка данных поверх XML, все это сдобрено perl, с легким налетом GNU. Я это затащить могу, но очень не хочу, и пока просто обходил стороной. А тут жесткая зависимость сборки.

Короче, я решил, что вместо всей этой херни я вкорячу старую-добрую libmagic, из пакета file http://www.darwinsys.com/file/. Хороший, древний, проверенный код, без изъебов.

revision 1.1
date: 1987/08/23 19:51:05;  author: ian;  state: Exp;
Initial revision

Код чуть младше меня.

Замечания по ходу процесса:

* Пришлось сделать thread-safe обертку над api libmagic: https://github.com/pg83/mix/blob/main/pkgs/lib/mimetype/mix.sh

* Как оно используется: https://github.com/pg83/mix/blob/main/pkgs/lib/glib/01.diff (блин, а код без аллокаций на C писать вполне норм!) Я бы хотел тут остановиться, и сказать, что оно заработало like a charm, но нет

* glib сначала пытается определить тип по расширению, в #libmagic этого нет. Я это обошел тем, что всегда определяю по данным. NVMe все стерпит.

* Без нужных ему данных glib определяет длину буфера для autodetect в 0. Ну, починил.

* Названия mime types в библиотеках немного расходятся. К счастью, авторы Evince это предусмотрели, и добавить нужный mime type было несложно.

Короче, все заработало, а бонусом я выяснил, что в диалоге открытия файлов в GTK не работали иконки, потому что им нужен mimetype. А я и не замечал.

Почему freedesktop не взяли эту либу за основу, я не понимаю. Ведь в OSS так много свободных рук.