https://nullprogram.com/blog/2023/01/18/ #pkgconfig

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

Хотел кинуть и на предыдущую его заметку про SDL - https://nullprogram.com/blog/2023/01/08/, но мне, почти про каждый пункт из нее хотелось сказать "не делайте так!", поэтому не кинул.

В новом тексте коллега рассказывает про сложности с pkg-config (это такой способ для поиска зависимостей и их настроек в unix), и, конечно, решает написать свою реализацию, которая бы была #bootstrap`able, и работала под винду.

Ну и написал.

Штука довольно интересная, так как специально создана для того, чтобы разорвать зависимость сборки pkg-config -> pkg-config, то есть, может мне довольно сильно упростить жизнь на ранних стадиях bootstrap.

Использовать ее как полноценную замену pkg-config, конечно, не выйдет, потому что "дьявол в деталях"! В pkg-config довольно много странных и неочевидных правил подстановки переменных, которые реализовать все - ну такое. Собственно, я тоже пытался частично запилить эту логику подстановки, писал про это в https://xn--r1a.website/itpgchannel/845, и "малой кровью" у меня это не получилось,

Меня в комментариях попросили показать размер .text.

Показываю!

На этот раз, для curl, собранного в режиме "полный фарш":

pg-> llvm-objdump --headers ./curl.x86_64 | grep text
  5 .text             003211f0 0000000000509dc0 TEXT
pg-> llvm-objdump --headers ./curl.aarch64 | grep text
  5 .text             002fae94 0000000000505e30 TEXT
pg-> llvm-objdump --headers ./curl.riscv64 | grep text
  5 .text             0026bcfc 000000000026512c TEXT

Тенденция та же - riscv64 у меня занимает меньше всего(размеры в hex, если что).

В продолжении темы #reboot #stal/ix

https://www.phoronix.com/news/Fedora-38-Shutdown-Timer-45

"Last month a change proposal was filed for aiming to yield faster reboots and shutdowns of Fedora Linux by shortening the time window that services can block the shutdown process"

У меня, конечно, shutdown - моментальный процесс, даже процессы не убиваю.

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

Знаете, такой подход дает результаты. Например, я так нашел отсутствующий вызов sync в пакетном менеджере - иногда, после reboot, система просыпалась со старым system #realm, потому что переключение симлинки откатывалось файловой системой. А не нашел бы - был бы странный https://en.wikipedia.org/wiki/Heisenbug

https://verdagon.dev/blog/when-to-use-memory-safe-part-2

Закончил читать, это прямо фундаментальный текст, который я себе добавлю в копилку. #asan

Я довольно часто повторяю простую мысль, что современная разработка на С++ почти так же безопасна, как и использование memory safe languages, но, при этом, существенно более проста(потому что не нужно укладывать архитектуру приложения в прокрустово ложе borrow checker).

"Google Earth proved that this strategy can work well. In an average Google Earth quarter, only 3-5% of bug reports were traceable to memory safety problems, and Address Sanitizer made them trivial to reproduce in development mode"

Вот что тут еще добавить? Продукт использует современные методы разработки, и в нем мало memory safety ошибок. Настолько мало, что, я, например, считаю, что тот же Rust сделал бы разработку суммарно дороже, чем С++. Потому что, напомню, за memory safety мы платим скоростью разработки.

Про тесты. #ix, #stal/ix

Есть выбор - запускать тесты от upstream в процессе сборки софта, или не запускать.

Я пока решил "не запускать", потому что чужая душа - потемки, и разбираться со свалившимися тестами у меня нет никакой возможности - musl это, clang, или просто мейнтейнер - долбоеб, и не следит за своими же тестами.

Водораздел лично для меня проходит по сборке - я гарантирую, что моя пакетная база собирается, что я корректно сделал де-#vendor, и де-плагинизировал(собрал в монобинарь) все, до чего дотянулся.

С остальными проблемами - пока в upstream.

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

Какие это тесты?

Это тесты на то, что я пофиксил что-то в upstream, что мешало корректно собрать код, и я хочу, чтобы и дальше это не ломалось!

Вот пример, с пылу, с жару!

https://github.com/pg83/ix/commit/a3c94806ec344a3f87e147bac8edf9fe1e613be0

Один там автор русского апача, так же известный своим срачиком с Экслером, решил, что c++ библиотека - это всегда libstdc++, и записал это знание в libraw.pc, то есть, все клиенты этой библиотеки у меня перестали бы собираться, с ошибкой, что нет такой библиотеки.

Я это починил, и сразу же написал тест, что в этой конкретной либе libstdc++ не проедет, если, вдруг, мой фикс сломается!

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf #cplpl_doomed
https://www.opennet.ru/opennews/art.shtml?num=58527

А теперь вот и Страуструп решил высказать свое "фи" по поводу безопасных языков программирования.

И, несмотря на то, что наша аргументация во многом совпадает (а было бы странно иначе, потому что она лежит на поверхности), все равно - Бьерн - старый гондон из группы стандартизации, и этот текст он, наверняка, написал с плохой мотивацией - ему, простите, жалко терять такую классную позицию (автор языка, используемого в mission critical сложных системах!).

А все, а раньше надо было, заниматься развитием языка, а не замораживанием его на месте, по сути, занимаясь, в основном, перделками и свистелками.

Сегодня анекдот на тему #bootstrap.

Занялся де-#vendor библиотеки freeimage.

Для этого:

* понадобилось собрать библиотеку, которую когда-то запили в MS, а теперь не дают скачать! https://archive.codeplex.com/?p=jxrlib

* но есть несколько прикопанных вариантов на github. Я не нашел каноничный, взял тот же самый, что и в arch - https://github.com/glencoesoftware/jxrlib

* но сам по себе этот код не собирается, поэтому коллегии arch накостыляли свой сборочный файл для этой библиотеки! https://github.com/archlinux/svntogit-community/tree/packages/jxrlib/trunk

* де-#vendor библиотеки довольно сложно, поэтому коллеги из arch потырили патч из федоры - https://github.com/archlinux/svntogit-community/blob/packages/freeimage/trunk/PKGBUILD#L29 https://github.com/archlinux/svntogit-community/blob/packages/freeimage/trunk/freeimage-unbundle.patch

* но этот процесс они не завершили до конца, потому что в freeimage осталась копипаста из libtiff - https://github.com/pg83/ix/blob/main/pkgs/lib/freeimage/ix.sh#L37 Они, об этом, наверняка, не знают, потому что скрывают эти символы!

В чем мораль?

* Мы все стоим на плечах великих!
* Блеск и нищета opensource - вместо того, чтобы интегрировать все это добро в канонические репы этих двух заброшенных проектов, люди таскают патчи из дистрибутива в дистрибутив! (и я тоже, нуачотакова)

Я вот, например, взял все патчи из arch, а они уже включают в себя федорины! https://github.com/pg83/ix/blob/main/pkgs/lib/freeimage/ix.sh#L6

Продолжаем тему кросс-компиляции. #cross #ix_run #dev_shell

Я теперь умею, например, так:

pg-> ./ix run \
    bin/qemu --for_target=aarch64-linux-user \
    bin/convert --target=linux-aarch64 \
    -- qemu-aarch64 '$(command -v convert)'

Что тут написано?

Тут написано: "собери мне realm, в котором есть host qemu, умеющий запускать arm бинарники, собери мне image magick convert под aarch64, и запусти в этом realm программу convert"

Что эта команда выводит на экран:

READY /ix/store/uFlUrE6DQMb3SC2l-rlm-ephemeral/touch
Version: ImageMagick 7.1.0-58 Q16-HDRI aarch64  
    https://imagemagick.org
Copyright: (C) 1999 ImageMagick Studio LLC
License: https://imagemagick.org/script/license.php
Features: Cipher DPC HDRI 
Delegates (built-in): bzlib fontconfig 
    freetype heic jng jp2 jpeg jxl lcms 
    openexr pangocairo png raw tiff 
    webp zlib
Compiler: gcc (4.2)
Usage: convert [options ...] 
    file [ [options ...] 
    file ...] [options ...] file

Обратите внимание, что запускается именно aarch64 бинарник convert!

Фактически, я умею в одном сборочном графе манипулировать артефактами, собранными под разные target platform.

Что нам это дает?

* https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh - дешевая автосборка и CI под другие платформы. Реально, добавить aarch64 в автосборку заняло 2 строчки в сборочных файлах. https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/linux/aarch64/ix.sh - список того, что я регулярно собираю под aarch64. Там есть и gdb, и даже графические программы!

* Новые возможности для #bootstrap. Например, go сейчас не является воспроизводимым с точки зрения классических способов (пакетных менеджеров и систем сборки), потому что последняя версия go, собираемая С-компилятором, не умеет строить код под M1, и не собирается под ним. Я теперь могу подступиться к этой проблеме, написав в сборочном файле для go что-то вроде:

{% block bld_tool %}
bin/qemu(for_target=linux-x86_64)
bin/kernel(target=linux-x86_64)
bin/busybox(target=linux-x86_64)
bin/go/1.4/(target=linux-x86_64)
{% endblock %}

Поднять в этом сборочном узле qemu (который сам себе и собрал), linux kernel, go1.4, и там провести цепочку #bootstrap. И это будет работать, в том числе, под host == darwin.

Мне сейчас кажется, что я достиг чего-то, чего ранее никто не делал в open source. Все автосборочные кросс-компилирующие решения, известные мне, основаны на том, что кто-то руками прикопал заранее собранные инструменты, поэтому они имеют довольно маленький scope.

Наливал тут себе #stal/ix на новый ноутбук, столкнулся с прекрасным.

После первоначальной наливки IX с fedora live cd я ребутнулся в установленную OS, и начал процесс полной пересборки мира (когда уже под боком нет файла от fedora, и сборка будет еще более лучше).

В этот момент отработал ntp клиент, и установил правильное время. А, надо сказать, что в live cd от федоры оно было неправильное. Не знаю, я там забыл какую-то галку нажать, или оно по wifi его не получило, не суть.

И у меня, в какой-то момент, зависла сборка harfbuzz, довольно необычным образом:

* Она бежала до конца, без ошибок
* В самом конце писала на экран "clock skew detected"
* Начинала все собирать снова

И так до бесконечности.

В общем:

* meson генерирует ninja-файлы, в которых есть зависимость артефактов проекта от внешних сущностей. Ну, вот, реально, если нода запускает /bin/sh, то там будет прописана /bin/sh в качестве зависимости.

* /bin/sh, вдруг, резко, стал родом из будущего.

Такие дела.

Давно хотел выставлять нулевой ts всем собранным артефактам, но руки не доходили. Вот, дошли - https://github.com/pg83/ix/blob/main/pkgs/die/sh.sh#L71

А можно как-то красивее это сделать?

У Пети было 32 байта в буфере. 24 он отдал Маше, а оставшиеся 128 — Ване.

https://arstechnica.com/gadgets/2023/01/big-layoffs-at-googles-fuchsia-os-call-the-projects-future-into-question/

Тут вот пишут, что Гугл сократил 16% разработчиков Фуксии. Что больше, чем средние 6% по компании.

Тут, конечно, интересны абсолютные цифры - получается, что у Гугла над Фуксией работало 2500 человек.

Не знаю, что про это думать, кроме как "гора родила мышь", и что Гугл безумно неэффективен.

UPD: в комментариях сказали, что на opennet неверный перевод, и уволили 16% от 400 человек. То есть, Гугл не безумно неэффективен, а просто неэффективен!

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

Мне, понятное дело, нельзя это комментировать, но сказать "остановитесь, злые люди, и не называйте это git репозиторием" я вполне могу :D

UPD: https://habr.com/ru/news/t/712888/ https://news.ycombinator.com/item?id=34526253 - BTW, 2 из 3 первых самых забавных названий - мои!

Тут вот github подогнал сразу 2 текста про #carbon:

* Конечно же, уже привычный transparency report! https://github.com/carbon-language/carbon-lang/discussions/2556

* Текст про то, что не то чтобы кодить не начали, но еще и сам язык продумать не успели! https://github.com/carbon-language/carbon-lang/blob/trunk/proposals/p2551.md#retrospective-on-2022

Вместе эти два текста смотрятся особенно хорошо, да.

Видимо, одновременно работу работать и права защищать - не получается!

https://lwn.net/SubscriberLink/920158/313ec4305df220bb/

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

Ядрописатели решили запилить свою libc, для "small, low-level" приложений.

По первой ссылке жалкая попытка обосновать этот проект. Жалкая, потому что автор решил сравниться с какими-то калеками, типа diet libc, uclibc, которые не развиваются много лет.

С #musl сравнения, очевидно, нет, потому что если бы оно было, то было бы очевидно, что #nolibc не нужна.

Оч. странный продукт, ни одного .c файла, все заинлайнено в .h файлах - https://elixir.bootlin.com/linux/v6.2-rc4/source/tools/include/nolibc

Зачем так делать, если есть ориентация на минимальный размер получающегося кода?

https://elixir.bootlin.com/linux/v6.2-rc4/source/tools/include/nolibc/stdio.h#L32 - а вот так вот сделаны stdin, stdout, stderr. Rust, как тебе такое?

Nevertheless, это поделие может быть мне полезно, на самой первой стадии, когда надо собрать musl "из ничего", даже без стандартных unix tools, типа cp, mv, и так далее.

Думаю, вполне можно собрать простые версии unix tools с этой libc, и дальше, пользуясь ими, по человечески собрать #musl.

https://habr.com/en/post/713402/

Странный текст про наши утекшие исходники.

С одной стороны, оч. приятно за ""Взрослые" компании получили отличный пример, как надо делать. Инфраструктура, логика и реализация у Яндекса всегда была чем-то "волшебным". Сейчас мы все можем убедиться в том, что это были не сказки, так оно и есть. Всё структурировано, документация к каждому проекту, кодстайл к каждому проекту, почти в каждой документации отдельный пункт: "если чего-то непонятно -- не стесняйтесь, спрашивайте". Внутренние CRM, аркадия, вики, сообщества и чаты. Отличный повод посмотреть на то, как делаешь бизнес "лично ты". Есть на кого ровняться"

С другой, коллега думает, что может невозбранно использовать украденные исходники, потому что в шапке нет копирайта - "Много внутренних проектов Яндекса в своих сурсах "по дефолту" имеют лицензию MIT, это явно прописано в метафайлах. Другие исходники никак не подписаны, что так же позволяет их копировать, использовать в коммерческих целях, видоизменять итп"

У меня, конечно, для коллеги плохие новости, это работает немношк не так.

https://github.com/ninja-build/ninja/issues/1459

Скинули в комменатриях, забавный тикетос про поддержку пересборки по изменению md5, вместо timestamp.

В тикете есть люди с такими же симптомами, как у меня - у людей в цикле запускается ninja, которая запускает meson для регенерации ninja файлов, после чего сборка запускается снова.

Понятно, что никто никакую пересборку по md5 вместо timestamp в ninja никогда не запихнет, потому что и так уже "уважаемый проект, собирающий половину open source софта, а вы в жопу идите чего добился ты?".

Ну вот не любят устоявшиеся OSS проекты перемен, не любят.

Я несколько раз писал, что в #cmake нет кросс-компиляции.

До недавнего времени я знал одно исключение из этого правила - это сборочные файлы #qt, они там, по сути, написали на cmake самопальный слой кросс-компиляции, благо cmake turing complete, и грубой силой там можно написать все, что угодно.

Вот, коллеги показали второе исключение из этого правила - https://github.com/ClickHouse/ClickHouse/blob/master/contrib/protobuf-cmake/CMakeLists.txt#L252

Тут "очень изящно" вызывается рекурсивный cmake + make на прикопанную папочку с protoc во время configure этапа. И, к моменту поиска protoc в системе, он уже готов.

У меня, конечно, двойственное к этому отношение.

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

С другой, понятно, что дистростроители с такого вешаются, когда нужно сделать де-#vendor.

С точки зрения upstream, конечно, сборки от дистрибутивов, после ручного де-#vendor, не являются воспроизводимыми, и, наверняка, их не поддерживают (по вполне понятным причинам).

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

* Не поможет в будущем, потому что точка расширения не понадобится.

* Просто вредно, потому что это не отношение "A является B" (LSP, да), а просто так получилось, что AST похожи.

Вот вам совет от "ведущих собаководов" - прежде чем обобщать, скопируйте.

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

Часто оказывается, что общего-то и не было, с самого начала, а если бы вы его ввели, то потом пришлось бы это "общее" курочить самым диким образом под новые требования, или отказываться реализовывать новые фичи, потому что они не подходят под архитектуру.

(Кстати, copy-paste - очень хороший способ переиспользования кода, на много порядков более лучший, чем код не реюзать вовсе)

Будни #bootstrap.

После очередной порции обновлений стала сыпаться сборка kimageformats - это пакет с дополнительными загрузчиками картинок для QT.

С довольно странной ошибкой:

-- Configuring done
CMake Error in CMakeLists.txt:
    Imported target "PkgConfig::LibHeif"
    includes non-existent 
    path "@CMAKE_INSTALL_PREFIX@/include"

Натурально, написано, что, при попытке поискать библиотеку через #pkg-config, мы получили какую-то строку, которая не является корректным путем в FS.

Причем, как видно, строка содержит макроподстановку, которая, кажется, должна делаться силами cmake.

(казалось бы, где cmake, а где pkg-config)

Причем, что самое интересное, сломался pc файл не от libheif, а от libde265, то есть, косвенной зависимости.

Сломался он вот этим коммитом - https://github.com/strukturag/libde265/commit/388b61459c2abe2b949114ab54e83fb4dbfa8ba0

Причем сломался очень интересно!

Видимо, проект поменя основную систему сборки с autohell на cmake, и начали обрабатывать pc.in файл не autohell макросами, а с помощью cmake.

Соответственно, у меня сломалась сборка с autohell, и я решил ее переключить на cmake.

Но и cmake построил неверный pc файл, с поломкой уже вот тут - https://github.com/strukturag/libde265/blob/388b61459c2abe2b949114ab54e83fb4dbfa8ba0/libde265.pc.in#L11

Теперь уже cmake подставил не те подстановки, заменив их на пустую строку:

Name: libde265
Description: H.265/HEVC video decoder.
URL: https://github.com/strukturag/libde265
Version: 
Requires: 
Libs: -lde265 -L

Понятно, что линкеру такое не понравилось!

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

На это уже успел наткнуться arch - https://github.com/archlinux/svntogit-packages/commit/b871cc1222248707d6389f7c80842e6e1561b61c

Ну и разрабы тоже заметили свою оплошность - https://github.com/strukturag/libde265/commits/master, 10 минут назад вкоммитили fix.

Никто ничего не тестирует. Вот вообще ничего - очевидно же, что результат работы исходного патча никто не отсмотрел глазами, потому что он ломал обе системы сборки!

Я тут разжился таки новым монитором, он же LG OLED 42 чего-то там.

OLED, быстрый отклик (120HZ), хороший телевизор, с кучей настроек, которые нужно было последовательно найти, и выключить, чтобы перестали применяться всякие улучшаторы картинки. Для телевизора они, может быть и нужны, но совсем не нужны для монитора.

Вот, 2 неполных списка того, что надо сделать:

https://www.reddit.com/r/OLED_Gaming/comments/mbpiwy/lg_oled_gamingpc_monitor_recommended_settings/
http://webos-forums.ru/post138951.html

Но запустить его в режиме 4K@120hz у меня пока не вышло!

В целом, похожая история написана вот тут - https://habr.com/ru/post/656479/ Все очень похоже, но у меня так и не заработало.

По спекам, мой ноут должен уметь выдавать DP 1.4 на два type c порта, дальше стоит хороший кабель с hdmi адаптером, который должен преобразовывать DP в HDMI, и отдавать в телевизор.

Кстати, DP неожиданно - довольно условно цифровой протокол, потому что я сумел увидеть на экране наведенку от соседнего кабеля.

При попытке выставить 4K@120hz, телевизор рисует картинку "нет сигнала", sway считает, что телевизор inactive:

Output DP-1 'LG Electronics LG TV 
    SSCR2 0x00000101' (inactive)
  Available modes:
    3840x2160 @ 120.000 Hz
    3840x2160 @ 119.880 Hz
    3840x2160 @ 100.000 Hz

В логах ядра какая-то дрисня:

https://gist.github.com/pg83/7e5b763089ae0f1f1c59d84207443b9a

Особенно радуют строки вида

[drm] Mode Validation Warning: 
    Validation OK failed validation.

И не работает. Есть идеи, что мне еще потыкать?