https://www.phoronix.com/news/Linux-DRM-Process-Start-With-X

Опять кто-то возбухает про хак про определение имени процесса, и выключении какой-то функциональности в ядре, если есть совпадение.

Так-то это нормальная практика, я несколько раз писал, что это делает, например, #mesa. Кстати, не помню, рассказывал или нет, но в одной из версий они проапдейтили этот механизм так, что он начал матчить хаки по md5 от бинарника(https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf#L888). В мире Linux это имеет мало смысла, а вот в мире игруль под wine(windows, valve, etc) это, конечно, имеет смысл.

https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/src/util/00-mesa-defaults.conf - вообще, посмотрите, сколько тут всяких интересных хаков для разных программ.

https://www.phoronix.com/news/Mesa-RTX-30-Ampere-OpenGL

Вот, пожалуйста, результат.

Открытые дрова от #mesa для #nvidia - это хорошо, потому что не придется делать хаки вокруг их бинарного libGL.so, который собран с glibc.

Я вам сегодня расскажу, что такое катарсис!

Катарсис, это когда:

* тебе нужно указать зависимость gtk -> набор иконок по умолчанию(скажем, adwaita)
* ты понимаешь, что рендеринг этих иконок у тебя сломан, потому что старая librsvg
* ты хочешь отрендерить эти иконки с помощью inkscape
* и тут появляется кольцевая зависимость, потому что inkscape -> gtk -> adwaita -> inkscape
* ты полгода пилишь свой графовый движок, чтобы он был достаточно хорош, чтобы понять, что data runtime dep не портит uid сборки, и сборка inkscape + gtk + adwaita - это ровно то же самое, что сборка inkscape + gtk + no icons
* и, наконец, разбить этот цикл, сказав, что inkscape для сборки - это inkscape, но с "gtk без иконок" - https://github.com/pg83/ix/commit/95eeebcce8a347873dbbf2b4ec54915265c7b1ff
* самое главное - что получившийся "inkscape без иконок" имеет тот же uid, и команду для сборки, что и "inkscape с иконками", то есть, у нас не случилось extra work!

То вот это вот - катарсис! :D

Oops!…I Did It Again

У меня тут, при переходе на #QT 6.4, каким-то очень странным образом начала коркаться телега, при попытке отобразить какие-то очень специфические картинки:

[Switching to LWP 14132]
0x0000000009f795b7 in QRgba64 const* fetchTransformedBilinear64<(TextureBlendType)4>(QRgba64*, Operator const*, QSpanData const*, int, int, int) ()
(gdb) bt
#0 0x0000000009f795b7 in QRgba64 const* fetchTransformedBilinear64<(TextureBlendType)4>(QRgba64*, Operator const*, QSpanData const*, int, int, int) ()
#1 0x0000000009f87338 in handleSpans<BlendSrcGenericRGB64>(int, QT_FT_Span_ const*, QSpanData const*, Operator const&)::{lambda(int, int)#1}::operator()(int, int) const ()
#2 0x0000000009f87444 in void std::__1::__function::__policy_invoker<void ()>::__call_impl<std::__1::__function::__default_alloc_func<handleSpans<BlendSrcGenericRGB64>(int, QT_FT_Span_ const*, QSpanData const*, Operator const&)::{lambda()#1}, void ()> >(std::__1::__function::__policy_storage const*)
()
#3 0x000000000a4ce3a1 in QThreadPoolThread::run() ()
#4 0x000000000a4cbdb9 in QThreadPrivate::start(void*) ()
#5 0x000000000a746a6c in start ()
#6 0x0000000000000000 in ?? ()

Проблема в том, что в дебажной сборке нихрена не видно - не падает, а как(и куда) нести такое - непонятно.

Поэтому базовую библиотеку qt я(временно!) собираю без оптимизаций - https://github.com/pg83/ix/blob/main/pkgs/lib/qt/6/base/ix.sh#L61, так оно делает вид, что работает.

Это уже вторая такая библиотека, первой была openssl - https://github.com/pg83/ix/blob/main/pkgs/lib/openssl/t/ix.sh#L25

Морали в этом особой нет, просто "и вот такие решения приходится принимать". На поиск таких ошибок можно полжизни положить, было бы желание.

https://hmarr.com/blog/how-stdbuf-works/

А вот более подробный рассказ про stdbuf, если кому-то интересно!

https://www.oilshell.org/release/0.12.9/changelog.html

Я продолжаю (с огромным удовольствием!) следить за развитием проекта oil shell.

На этот раз интересного changelog нет, но я просто посмотрел в список коммитов.

Некто "Andy C" занимается рефакторингом, рантаймом, gc, бенчмарками, фреймворком для бенчмарков, всем, кроме самого shell.

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

Ну, ладно, автора явно прет, а остальные-то чего хотят?

Субботний rant про невменяемые системы сборки.

Нет ни одной OSS системы сборки, которую я бы мог назвать "бескомпромиссно хорошей".

Мало кто из OSS сборок знает, что такое "чистые билды", что такое content addressable storage.

#bazel знает, но написан на java.

#meson не знает, но зато в нем приятные скрипты для описания конфигурации.

Дай, думаю, посмотрю на #premake. https://premake.github.io/

Бугага, в качестве graph execution engine он предлагает gnu makefile, и даже не предлагает ninja.

И, самая мякотка, https://github.com/SpartanJ/efsw/blob/1.3.0/premake5.lua#L121, он позволяет сборочному скрипту контролировать, куда premake положит Makefile.

Вот, реально, сгенеренный Makefile можно положить в любое место, которое придет в голову мейнтейнеру пакета, и переопределить снаружи это невозможно.

Это вообще какое неуважение к тем, кто этот код собирает?

Для запуска Makefile так-то нужно знать, где он лежит.

Набор типовых конфигураций тоже не стандартизован - https://github.com/SpartanJ/efsw/blob/1.3.0/premake5.lua#L123, install таргетов я не нашел, да и вообще, все это выглядит как зумерская поделка.

https://sohl-dickstein.github.io/2022/11/06/strong-Goodhart.html

Интересный текст про ML, он мне напомнил, что я давно хотел написать нижележащий текст(прямо они не связаны).

Я бы хотел поговорить про евгенику.

Мне кажется, что человечество "застревает". Каждый следующий шаг дается труднее, чем предыдущий.

Это видно и локально, и глобально:

* Когда вы оптимизируете программу, в какой-то момент вы получаете плоский профиль, и дальше наших мозгов не хватает, чтобы что-то улучшить радикально. Потому что задача становится слишком сложной. И мы начинаем тратить просто колоссальные усилия, чтобы выедать по 0.5% перфа за год, условно говоря.

* Когда вы оптимизируете какую-то метрику качества. Тут применимы ровно те же слова, что и в предыдущем абзаце.

* Теория относительности и квантовая механика - довольно простые штуки, с ними может разобраться любой выпускник мехмата. Попытка построить теорию, их объединяющую - это какие-то гигантские усилия больших количеств ученых, в течении многих лет, без видимого результата. Да и БАК нам намекает, что за пределами стандартной модели ничего и нет. Или просто мы не видим?

Когда мы пытаемся применить к задачам AI, все становится еще хуже. Мы часто получаем работающее решение, но не можем сказать, как оно это делает.

Вот ровно та же ситуация - человек может написать решатель в 100 if(), и он будет понимать структуру решения, и структуру исходной задачи и данных. Применив AI, для получения следующих 10% метрики, понимания не возникает.

Более того, мое ключевое утверждение - вот эти 10%, добытые таким образом - это не интересно. Профит есть, а интеллектуальное удовольствие от возникшего понимания - не наступает.

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

Кстати, уже кидал ссылку на эту книгу, но IMHO весьма годный текст про потенциальное устройство взаимодействия человеков и strongai - https://www.labirint.ru/books/512769/.

Воодушевления не вызывает.

Мне не нужен результат, мне хочется понимания структуры решения, и самой задачи.

Вот тут и наступает разговор про евгенику. Он будет короткий!

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

Как это сделать? Я не знаю, я не знаю ничего про физическое устройство мозга. Может, надо собачкам начать вживлять по 100000 соединений разных участков мозга, и смотреть, как они будут решать задачи.

Может, после серии таких экспериментов какая-нибудь обезьянка смогла бы с нами поговорить, а, заодно, рассказать про объединение квантов и гравитации. Так, походя :)

К сожалению, эксперименты одного там Адольфа закрыли возможность даже серьезно говорить на эту тему надолго.

(Хотя, nuff said, скрининг на синдром Дауна сейчас все стараются делать)

Кстати, пишут, что range based for loop починили в С++23! Инфа свежак, с пылу с жару с полей комитета!

https://dougallj.wordpress.com/2022/11/09/why-is-rosetta-2-fast/

Закончил читать этот прекрасный текст.

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

Например:

"Rosetta 2 translates the entire text segment of the binary from x86 to ARM up-front.... Each x86 instruction is translated to one or more ARM instructions once within the ahead-of-time binary (with the exception of NOPs, which are ignored). When an indirect jump or call sets the instruction pointer to an arbitrary offset in the text segment, the runtime will look up the corresponding translated instruction, and branch there"

Это же прямо целый новый мир того, как это может быть устроено. Наверняка такая техника известна всем специалистам, а я вот не знал.

TL;DR по теме теста - Apple M1/M2 просто классное железо, поэтому оно может выполнить таким образом оттранслированный код "быстро".

Я бы тут даже поспекулировал, что исполнитель внутри M1 может понимать, что это оттранслированный по таким простым правилам x86 код, восстанавливать его, и выполнять примерно так же как и ARM инструкции, поверх своего внутреннего ядра.

(зачем так сложно? Ну, например, Intel не продает лицензии на архитектуру)

https://github.com/oneapi-src/oneTBB/pull/824

PR, наконец-то, вмержили.

Заняло это с мая месяца этого года.

Я тут как-то писал, как правильно делать code review, вот, почитайте этот тред, чтобы понять, как точно не надо:

* Морозить до первой реакции несколько месяцев.

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

* Попросить написать тест на мигающую проблему. Леденящий душу пиздец, я бы в этот момент послал бы нахуй(конечно, если бы делал это для себя, а не для Я).

* Попросить решить более широкую задачу, вот это самое "а заодно". А заодно сделайте нам graceful degradation, my ass.

Я прекрасно понимаю, что tbb - это OSS проект, но точно так же понимаю, что пишут его люди на зарплате от Intel, и ожидаю, что они будут соблюдать соответствующие стандарты качества. Реально, github надо сделать кнопку "пожаловаться менеджеру в материнской компании проекта".

https://www.phoronix.com/news/Mold-1.7 #money

Оказывается, слона-то в новом релизе #mold я и не заметил!

"I'd like to inform users that I'm seriously considering changing the mold's license from AGPL to a source-available license unless I secure big funding. The new license would be something like individuals can use it for free but corporate users have to pay. mold started as my personal project, and I've been working on this full time for two years so far. I thought that I could earn a comfortable income if mold become popular, but unfortunately, I'm still losing my money."

Забавно, что такой умный человек попал в эту ловушку. В open source нет денег, писал про это и буду писать.

open source, если он от отдельных граждан, а не от больших компаний - это for fun, для души, как #charity, опять же. Но уж точно не деньги.

Он пишет(кстати, очень стандартная тема от таких "жалующихся"):

"It's even a bit ironic that I had been asked by several big-name companies when mold/macOS would become available, since they wanted to use it for their multi-billion-dollar businesses. But none of them gave me financial support"

Я ему могу легко ответить.

#mold не настолько лучше, по сравнению с ближайшим конкурентом(lld), чтобы за него платить деньги.

Это удивительно, и наивно, - "я сделал хороший продукт, подарил его вам, а теперь заплатите мне".

Блин, я вообще посмотрел в сторону mold в том числе, потому, что он открытый И бесплатный, зачем он мне в виде платного софта? Ну, нет, на рынке линкеров большая конкуренция, есть предложения и получше(бесплатный lld, например).

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

"техническая новость", интерес представляет только для энтузиастов графического стека Linux.

"В состав принят код проекта dxvk-native, позволяющего формировать родные сборки DXVK для Linux (не привязанные к Wine), которые можно использовать не для запуска Windows-приложений, а в обычных Linux-приложениях, что может быть полезным для создания портов игр для Linux без изменения кода отрисовки на базе D3D"

Мы тут как-то обсуждали direct x state tracker в #mesa, а вот еще одна независимая реализация той же идеи, только поверх vulkan, умеет теперь нативно собираться под Linux.

Я так понимаю, граф "X поверх Y" скоро станет полным, для X, Y в (DirectX, Vulkan, Metal), и уже будет неважно, под какой API ты решил разрабатываться.

Вышел релиз wayland-protocols, за номером 1.29. 1.28 была, буквально, на днях, я писал про новые ошибки линковки, с ней связанные. #wayland

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

https://lists.freedesktop.org/archives/wayland-devel/2022-November/042499.html

"This release contains a bug fix to the 'content-type' protocol extension, where an incorrect enum name was previously used. See [1] for more information how it eventually can be avoided in the future"

Мусолят-то мусолят, но нихрена не тестируют.

Шапито.

Продолжая тему #wayland, на днях вышли новые wlroots - https://www.phoronix.com/news/wlroots-0.16-Released

Ничего особенно интересного, но у меня наконец-то починились всплывающие окошки в gtk4. gtk4 перешли на аппаратно-ускоренный рендеринг, и что-то там так себе работало, когда композитор(sway) работал через opengl, а gui рендерило в буфер через #zink(ну, то есть, в буфера попадали команды от vulkan, грубо говоря).

Теперь в #sway хорошо заработал рендер на основе vulkan, и артефакты исчезли.

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

Они, видимо, часть общеупотребительных протоколов сразу предоставляют в виде C библиотеки, а всякую шнягу только в виде xml файлов.

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

d.lld: error: duplicate symbol: zwp_linux_dmabuf_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_dmabuf_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:76 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:76)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_dmabuf_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a

ld.lld: error: duplicate symbol: zwp_linux_buffer_params_v1_interface
>>> defined at wayland-linux-dmabuf-unstable-v1-protocol.c
>>> wayland-linux-dmabuf-unstable-v1-protocol.c.o:(zwp_linux_buffer_params_v1_interface) in archive /ix/store/vG3f4y9IuqH0uqOa-lib-qt-6-wayland/./plugins/wayland-graphics-integration-server/libqt-wayland-compositor-linux-dmabuf-unstable-v1.a
>>> defined at linux-dmabuf-unstable-v1-protocol.c:94 (/ix/build/dKHxjGBeXc36a9Nv/obj/src/egl/wayland/wayland-drm/linux-dmabuf-unstable-v1-protocol.c:94)
>>> meson-generated_.._wayland_wayland-drm_linux-dmabuf-unstable-v1-protocol.c.o:(.rodata.zwp_linux_buffer_params_v1_interface+0x0) in archive /ix/store/dKHxjGBeXc36a9Nv-lib-mesa/lib/libEGL.a
clang-15: error: linker command failed with exit code 1 (use -v to see invocation)

Я, честно говоря, подзадолбался ходить по библиотекам, и переименовывать там эти символы - https://github.com/pg83/ix/blob/main/pkgs/lib/wpe/fdo/ix.sh#L18. В .so их, понятное дело, просто скрывают.

https://bluewhalesystems.blogspot.com/2022/11/mold-linker-may-not-switch-to-source.html

Подоспел ответ от Rui.

IANAL, но, КМК, он еще меньше lawyer, чем я, судя по придуманной им схеме.

"That is, we claim that the output from the linker is a derivative work of the linker. That's a bold claim but not entirely nonsense since the linker copies some code from itself to the an output. Therefore, there's room to claim that the linker's output is a derivative work of the linker, and since the linker is AGPL, the license propagates"

1) Ну даже он сумеет показать, что verbatim слинкованный бинарь идет под AGPL, и что? Это же не будет иметь отношения к исходникам.

2) Ну не будут распространять бинари, слинкованные mold. Разрабы, которым приходится линковать chromium, будут это делать, а CI продолжит варить бинари в прод через lld.

Короче, он там чем-то явно упоролся.

#llvmweekly

https://uob-hpc.github.io/rtb/

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

https://discourse.llvm.org/t/rtb-tracking-compile-time-and-compiler-sizes-for-llvm-and-gcc/66461 - анонс.

TL;DR - там давно уже ничего не происходит, ни в gcc, ни в clang.

Илон Маск выдвинул сотрудникам Twitter ультиматум: усердно работать или уволиться — Washington Post