Давненько не было новостей про #toybox! #busybox

Вышла новая версия, полез посмотреть, каких новых команд они досыпали.

https://github.com/landley/toybox/blob/master/toys/pending/git.c

Пожалуйста, вот вам git client за 600 строк кода!

Никакого продуктового смысла в этом, конечно, нет, но так-то довольно интересно поштырить, чтобы понять, что ядро git - это вот эти вот 600 строк кода, с кучей слоев вокруг.

Есть такой классный torrent клиент transmission.

Мне казалось, что на него, в последние годы, подзабили - последний релиз был почти 3 года назад, а до этого - в 18 году.

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

https://github.com/transmission/transmission/releases/tag/4.0.0-beta.3

Самое IMHO вкусное - это порт на QT6.

Не могу не похвастаться. #cross

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

С самого начала разработки #ix, я закладывал в него такую возможность - учет host/target в графе, возможность указывать библиотеки, нужные для сборки, в разных контекстах (host/target), прокидывание этой информации до cmake/meson/autohell, до каждого запуска clang/lld, и так далее.

И я даже использовал кросс-компиляцию, в узком смысле этого слова, например, для отладочных сборок, для LTO, и так далее.

Понятно же, что, когда тулчейн нужно собрать под host, а библиотеку этим тулчейном уже под host+LTO, это уже тоже кросс-компиляция?

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

И, вот, пожалуйста!

pg-> ./ix build lib/c++/15 --target=linux-aarch64 
READY /ix/store/eS3L7CZ3qS6dEkaX-rlm-ephemeral/touch
pg-> find /ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/
/ix/store/...-rlm-ephemeral/lib/Scrt1.o
/ix/store/...-rlm-ephemeral/lib/crti.o
/ix/store/...-rlm-ephemeral/lib/crtn.o
/ix/store/...-rlm-ephemeral/lib/crt1.o
/ix/store/...-rlm-ephemeral/lib/rcrt1.o
/ix/store/...-rlm-ephemeral/lib/libm.a
/ix/store/...-rlm-ephemeral/lib/librt.a
/ix/store/...-rlm-ephemeral/lib/libpthread.a
/ix/store/...-rlm-ephemeral/lib/libcrypt.a
/ix/store/...-rlm-ephemeral/lib/libutil.a
/ix/store/...-rlm-ephemeral/lib/libxnet.a
/ix/store/...-rlm-ephemeral/lib/libresolv.a
/ix/store/...-rlm-ephemeral/lib/libdl.a
/ix/store/...-rlm-ephemeral/lib/libcrt.a
/ix/store/...-rlm-ephemeral/lib/libc.a
/ix/store/...-rlm-ephemeral/lib/libc++abi.a
/ix/store/...-rlm-ephemeral/lib/libc++.a
/ix/store/...-rlm-ephemeral/lib/libc++unwind.a
pg-> llvm-objdump --disassemble 
    /ix/store/...-rlm-ephemeral/lib/crtn.o

crtn.o:  file format elf64-littleaarch64

Disassembly of section .init:

0000000000000000 <$x.0>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret

Disassembly of section .fini:

0000000000000000 <$x.1>:
       0: a8c17bfd       ldp  x29, x30, [sp], #16
       4: d65f03c0       ret
pg->

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

Забавно, что от "собрать пару либ" до "собрать содержательный пакет" - всего пара строк кода! #cross

pg-> ./ix build bin/sed --target=linux-aarch64
READY /ix/store/...-rlm-ephemeral/touch
pg-> /ix/store/...-bin-sed/bin/sed 
bash: /ix/store/...-bin-sed/bin/sed: 
    cannot execute binary file: 
    Exec format error
pg-> 

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

Битва людей против машин продолжается.

На Stable Diffusion подали в суд. В иске утверждается, что нейросети нарушают авторские права миллионов художников. Заявляется, что права нарушаются уже на стадии обучения нейросетей. Нейросети называют «инструментами для создания коллажей 21 века».

Иск пестрит таким фразами "Скопировав пять миллиардов изображений", "Это паразит, который, если позволить ему размножаться, нанесет непоправимый вред художникам сейчас и в будущем."

По дороге досталось Midjourney и Devian Art.

Истцы требуют возмещение ущерба (сумму предложили определить суду). Stable Diffusion обвиняют в незаконном обогащении. К иску предложили присоединиться художникам, которые недовольны генераторами изображений.
https://stablediffusionlitigation.com/
На реддите приподвскипает:
https://www.reddit.com/r/MachineLearning/comments/10bkjdk/n_classaction_lawsuit_filed_against_stability_ai/

Когда у тебя появляется микроскоп, то им обязательно хочется что-нибудь забить! #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 сложных системах!).

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