Когда у тебя появляется микроскоп, то им обязательно хочется что-нибудь забить! #cross

Вот, у меня появилась новая игрушка - кросс-компиляция чего угодно откуда угодно, и я, например, решил проверить выводы про плотность кода.

pg-> ./ix build bin/xz --target=linux-aarch64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1897768 Jan 16 21:11

pg-> ./ix build bin/xz --target=linux-riscv64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1724848 Jan 16 21:14

pg-> ./ix build bin/xz --target=linux-x86_64
pg-> ls -laH /ix/.../bin/xz
-r-xr-xr-x    1 ix       1000       1787144 Jan 16 21:15

Мне системно делать это лень, но на примере 2 - 3 бинарников (я смотрел на sed, xz, и curl, в сниппете размеры для xz) я вижу другую закономерность - что у risc-v, наоборот, самый плотный код из всех!

Кстати, я начал постепенно заполнять файлик с описанием того, зачем оно, и как оно (идеально) устроено - https://github.com/pg83/ix/blob/main/docs/STALIX.md

Пока это, скорее, "декларация о намерениях", с выделенными разделами и кучей ссылок на аргументацию, но без "мяса".

Кстати, пользуясь случаем, говорю спасибо нашим уважаемым волонтерам, за помощь с переводом и оформлением документации!

Я тут, на досуге, продолжил возню с #svg.

Не то чтобы меня не устраивало, как работает #lunasvg, но вот этот вот svgren, о котором шла речь в предыдущем посте, он использует AGG https://en.wikipedia.org/wiki/Anti-Grain_Geometry в качестве канвы для отрисовки, а я, знаете ли, испытываю к ней нежные чувства (не спрашивайте). Ну и мне показалось прикольным, если за рендерингом svg у меня будет стоять это произведение искусства!

Вот список зависимостей, которые пришлось подтащить для сборки этой самой svgren - https://github.com/pg83/ix/tree/main/pkgs/lib/svgren Это все - адовые велосипеды от того же автора, что и сам svgren.

Знаете, я долго сдерживал смех, пока клал эти библиотеки, одну за одной, но вот когда мне пришлось написать нечто вот такое в своем коде - https://github.com/cppfw/svgren/blob/master/tests/render/main.cpp#L120-L121, я уже не смог сдерживаться, и пока отложил порт.

Коллеги притащили красивое - https://github.com/tdlib/td/blob/master/td/telegram/NotificationManager.cpp#L2737

Такой, знаете, ad hoc хеш, позволяющий сильно уменьшить количество сравнений строк (в данном конкретном случае это может быть важно, потому что у строк есть общий префикс).

В данном случае это, скорее всего, premature optimization (perf я не смотрел), но, в качестве "как быстро и грязно заменить ragel" вполне сойдет.

Даже уже и opennet написал, а я все еще нет! #glibc #collabora

https://www.collabora.com/news-and-blog/blog/2023/01/17/a-brave-new-world-building-glibc-with-llvm/
https://www.opennet.ru/opennews/art.shtml?num=58500

Какой-то странный текст, glibc можно было собрать и слинковать с clang/llv/lld еще год назад, как следует из предыдущего текста.

Новая статья - она не про сборку с clang/llvm/lld, а про то, как из говна и палок compiler_rt + libunwind соорудить libgcc(который требуется по LSB - https://en.wikipedia.org/wiki/Linux_Standard_Base).

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

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, это явно прописано в метафайлах. Другие исходники никак не подписаны, что так же позволяет их копировать, использовать в коммерческих целях, видоизменять итп"

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