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.

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

На этот раз хорошенько прилегла инфра #GNOME #gitlab #раньшевсех

https://gist.github.com/pg83/81e6a6bb478225d5bd449757dabd8272

Хорошо лежит, капитально так.

Довольно очевидная мысль, но я раньше ее нигде не слышал.

#panic

* Наличие в языке runtime с hidden control flow усложняет сопряжение этого языка с компонентами на других языках. Читай c++ dynamic exceptions, go/java gc, etc. Понятно, почему? Потому что это hidden control flow может протекать между границами модулей, с понятными косяками.

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

Отсюда следует довольно простая мысль - что поляна кросс-языковых инфраструктурных библиотек будет попилена между языками, в которых нет такого runtime - zig, rust, C, #hare, и так далее. Просто потому, что их можно невозбранно звать друг из друга и передавать коллбеки, не боясь, что это взорвется к херам при раскрутке исключений или вызове финалайзеров в gc. И никого не будет волновать, что tls сделан на Rust, а парсер json - на zig, пока есть четкая граница между модулями.

А до кросс-вызовов они как-нибудь договорятся, на самом деле, уже договорились, через platform abi FFI.

С++, к сожалению, там не будет места. А могло бы и быть, если бы случились https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0709r0.pdf

Но старперы из комитета по С++ предпочитают ныть, что их труды посылают к херам, да (https://www.opennet.ru/opennews/art.shtml?num=58527), вместо того, чтобы осознать и начать решать проблему.

Я как-то писал про свой способ поиска ошибок в configure скриптах, с помощью парсинга config.log, и последующим поиском мест, в которых на один и тот же вопрос о системе мы даем разные ответы. Это особенно важно в рамках кросс-сборки.

Вот, я постепенно пополняю список того, что configure скрипты имеют тенденцию отвечать неверно:

https://github.com/pg83/ix/blob/main/pkgs/die/c/autohell.sh#L18

Ну и вот неполный, но оч забавный список ошибок:

gl_cv_func_realpath_works=[nearly, yes]

Что тут написано? Что часть configure скриптов считает, что realpath() работает, а часть - что "почти работает". Что значит "почти" - науке не известно!

lt_cv_sys_max_cmd_len=[512, 32768, ...]

Скрипты не сходятся во мнении, какой же длины может быть command line.

gl_cv_have_weak=[yes, maybe, no]

Есть ли поддержка weak функций в компиляторе. Убил ответ maybe.

ac_cv_header_stdbool_h=[yes, no]
ac_cv_c_compiler_gnu=[yes, no]
...

Вишенка на торте:

ac_cv_c_bigendian=[yes, no, universal, unknown]

Большие затейники авторы этих скриптов, скажу я вам!

https://go.dev/doc/go1.20 #bootstrap

Вышла новая гошечка.

Я, конечно, сразу захотел ее собрать, и был очень удивлен.

До версии 1.19 включительно, новая go требовала для своей сборки go не ниже 1.4. А 1.4, напомню, последняя версия, написанная на C.

И я это считал одним из незаметных чудес, явленных нам компанией Google.

Почему? Потому что я себе представляю давление на авторов компилятора go, с постоянными требованиями иметь возможность писать код самого компилятора на современном go, а не версии 1.4. А это, напомню, 2014 год, если я ничего не путаю.

Лед тронулся, go 1.20 для своей сборки требует go 1.17, но это не самое плохое, это увеличивает длину цепочки bootstrap всего на одну сборку компилятора go, который собирается довольно быстро.

Самое плохое - они решили перейти на модель разработки Rust, и теперь всегда будут требовать версию не старше года. сhttps://go.dev/doc/go1.20#bootstrap

Это, само собой, будет регулярно увеличивать число сборок go, требуемых для сборки последней версии.

В копилочку красивых историй про то, что случается с CI, когда едут хеши релизных пакетов.

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