Странный сегодня день, я отделаюсь шуткой

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

"Google отложил на 2024 год прекращение поддержки второй версии манифеста Chrome"

У меня тут 2 соображения:

1) Они что-то знают про 2023
2) Они думают, что 2024 наступит!

https://www.opennet.ru/opennews/art.shtml?num=57847 #ball_lick

Тут вот пишут, что вышла новая версия #qt, и я хочу сказать, что сборка QT, после ее перехода на cmake - это леденящий душу пиздец.

Связано это с:

* #cmake сам по себе говно, в нем нет кросс-компиляции. А в QT есть, поэтому им пришлось написать соответствующий слой поверх cmake самим. #cross

* QT решили задачу по переходу, в том числе, оттранслировав большое число проектных файлов автоматом. Для этого им пришлось наговнякать большой runtime поверх макросов cmake, который имплементировал нужную им модель, в которую они и погрузили свои сборочные файлы. https://github.com/qt/qtwayland/blob/dev/src/qtwaylandscanner/CMakeLists.txt#L4

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

К чему этот rant?

https://github.com/pg83/ix/blob/main/pkgs/die/c/qt.sh#L16 - мне пришлось добавить пятый флажок в набор флажков, отвечающих за то, что нужно собрать тулзы, и, желательно, только их.

Реально, там полный набор - от "ну пожалуйста", до "мамой клянусь, они мне точно нужны".

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

Это вообще какая-то дичь, которую я для себя никак не могу объяснить:

* Их сборка начала ломаться, если этот флаг разный у разных пакетов. Схера ли? build tools могут быть собраны в режиме host == target, а либы - уже в режиме кросс-компиляции, это вполне валидный сценарий.

* А как же воспроизводимость? Пакет должен быть идентичный, неважно, в каком окружении он собран. А тут налицо факт, что пакеты, собранные кросс-компиляцией, будут отличаться.

Будни #bootstrap, #bootstrap_science

Вчера я рассказал про сборку #qt, конкретно, про:

* набор (неортогональных) флагов, которые чуть по разному решают в qt задачу принудительной сборки бинарников в host-target режиме

* про то, что они написали поверх #cmake свой слой кросс-компиляции

* про то, что их система сборки сравнима с "Войной и Миром" Толстого(как по актуальному размеру, так и по уровню графомании)

Сегодня про то, как оно сломалось при обновлении до qt 6.4, и как я "ловко" и "изящно" это обошел.

Есть такой проект - https://github.com/qt/qtdeclarative, и он жестко отказался собираться после обновления. С ошибками конфигурации где-то в недрах своих cmake хелперов, без внятной диагностики(это, кстати, отдельная боль в cmake).

Выглядело это так, как будто сломались вот эти самые механизмы, про которые я писал ранее - аццкая кросс-компиляция + комбинация флагов для сборки. Неудивительно, потому что вряд ли их тестировали в таком сочетании.

С симптомом круговой зависимости, что, мол, какой-то файл зависит от цели, которой нужен какой-то собранный бинарник(с говорящим названием qmltoolregistrar), который зависит от этого же файла. Скажем, вот тут - https://github.com/qt/qtdeclarative/blob/dev/src/qml/Qt6QmlMacros.cmake#L2494

Я копался в этом часа 3, но починить так и не смог, из-за размеров этой махины.

В итоге дорожку к результату я "протоптал" так - если там нет актуальной круговой зависимости, и она только в шизанутой системе сборки от qt, то давайте ее "разорвем" - соберем проект по частям.

Как это было сделано?

* Удаляем из сборочных файлов круговую зависимость. https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L13 После этого получается битый makefile, но его достаточно, чтобы осуществить первые этапы сборки.

* https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L4 - собираем все, что собирается этим битым makefile, и устанавливаем в качестве сборочного результата

* Повторяем эти шаги, постепенно увеличивая число собирающихся таргетов, и используя предыдущие результаты как host тулзы - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/2/ix.sh#L14

Мне понадобилось 2 шага - https://github.com/pg83/ix/tree/main/pkgs/bld/qt/6/tools/qml, результат второго шага вполне достаточен, чтобы им собрать полноценный пакет - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/ix.sh#L12.

Я не рассказал про всякие мелочи, типа ручного релоцирования из build в output директории получившихся cmake файлов, чтобы дальнейшие шаги сборки могли их подхватить - https://github.com/pg83/ix/blob/main/pkgs/bld/qt/6/tools/qml/1/ix.sh#L21

Звучит это все довольно страшно, но сборку эти 2 дополнительные стадии почти не замедлили, потому что в них собирается процентов 5 от всего набора исходников этого пакета.

https://www.opennet.ru/opennews/art.shtml?num=57853 - уязвимость в ffmpeg. Сама уязвимость не очень интересная IMHO, а вот то, как ее пофиксили - конечно, огонь:

https://github.com/FFmpeg/FFmpeg/commit/c953baa084607dd1d84c3bfcce3cf6a87c3e6e05#diff-68a4481d8e32579fae275ffb17e58ec71b79f854b65515e13d0b3fa316e48fafR4009

Натурально,

return AVERROR_PATCHWELCOME;

Что-то в стиле "throw NotImplemented()", да.

"Вот вы нам сколько заплатили, мы так код и пишем"

https://randomascii.wordpress.com/2022/09/29/why-modern-software-is-slow-windows-voice-recorder/

Занятный case тормозов какой-то программы.

На мой вкус, коллега не раcкрывает основную причину того, что софт тормозит.

Софт тормозит, потому что никто не готов платить за ускорение этого софта, и любой rant на эту тему заканчивается тем, что люди считают, что софт надо оптимизировать "на сдачу", и вообще, надо писать софт прямыми руками.

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

Так же могу предложить провести мысленный эксперимент - в вашем любимом сторе выходит новая версия вашей любимой платной программы, в ней в changelog одна строка - "мы стали быстрее на 15%", и просят заплатить полную стоимость этой программы за эту новую версию.

Заплатите?

Я - нет.

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

Какая боль, какая боль, последний Linux без Rust'а - 6.0

(kinda) #GNU hate speech

https://catgirl.ai/log/elegy-gnu/

Небольшой текст, дополняющий мою большую нелюбовь к проекту GNU. Конкретно, с претензией к RMS, что он, мол, плохой руководитель.

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

(Кстати, я давно хочу написать текст про то, почему раньше софт был очень плохой, все никак не соберусь.

Мои основные соображения:

* Не был накоплен "опыт", "культурный слой", "инженерные практики", "инструменты", как хотите. Кстати, fun fact(ну, ладно, серьезный фактчекинг я ему не устраивал) - у наших предков мозг был больше, поэтому, вполне возможно, они были умнее, но умели при этом меньше, потому что опыт не был накоплен. http://trv-science.ru/2021/09/glupeet-li-chelovechestvo/ Поэтому, например, мне в обертке над libmagic пришлось вставить блокировку - https://github.com/pg83/ix/blob/main/pkgs/lib/mimetype/mt.cpp#L37 Ну потому что автору кода 40 лет назад не был известен простой факт, что read only данные стоит отделять от модифицируемого состояния.

* Потому что программированием занимались не профессионалы, а те, кому "очень надо" - математики, физики, химики, и так далее. Ну и софт мы имели соответствующий.

* Сейчас на несколько порядков больше программистов. Чем больше глаз, тем очевиднее и лучше решаются проблемы. Интересно, сколько сейчас в мире есть программистов, и сколько было, когда я только пришел в Яндекс?

Уф, написал)

Счастье, между прочим, все ближе.

Ну, снова за аниматоров, операторов, актрис, моделей, селебритис.
Моделеров, риггеров, маттепайнтеров, концептеров.
И вот за это вот бессмысленное софтпорно.
Не чокаясь ИИ в городе. Waifudiffusion.

Прогресс просто космический.

Stable Diffusion вырвался на свободу этим летом, а на его базе народ уже творит форменные безобразия.

Да, есть артефакты и любители ловить блох щас будут заглядывать в зубки дареному ИИ. И в глазки.

Но дайте ещё подучиться двухмесячному младенцу. Он покажет зубки.

Меня тут (опять) спрашивают, почему я не люблю проект #GNU. #gold

Расскажу сегодня другую часть этой истории.

Все из-за очень большого разочарования! От любви до ненависти, как известно, не очень далеко.

Я пришел в Linux и в OSS примерно в 2000 году, еще будучи студентом. Знаете, довольно сообразительным, но не очень опытным, знающим. В целом, могу сказать про тогдашнего себя - легко велся на красивые идеи.

Проект GNU, конечно, тогда мне показался чем-то очень волшебным - могучие мейнтейнеры, великий провидец Столлман, Линус, гениальный kernel hacker, вот это вот все.

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

Я, помнится, тогда напридумывал себе много очень правдоподобных идей, почему OSS будет рулить миром, например: "в отличие от корпораций, которые склонны переизобретать все снова и снова, чтобы заработать деньги на одной и той же идее, в OSS проекты аддитивны - то есть, ты не пилишь новый Office, а дописываешь кусочек в общее здание".

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

И что, наоборот, коммерческие компании заинтересованы в том, чтобы было меньше бардака, и что новые xml(тогда еще)-парсеры плодятся в open source, а не в компаниях.

И что если ты придешь в какое-то такое "общее здание", то, за очень небольшим числом исключений, тебя пошлют из-за какой-то ЧСВ-шной херни того или иного мейнтейнера(тут можно вспомнить историю того же gcc и его ast).

В этот момент я понял, что OSS (ну вот даже лично мне) полезен довольно в ограниченном наборе софта*, и что RMS воюет не за что-то общеполезное, а потому что его в детстве обидели, не дав исходники от его любимой lisp машины.

Собственно, GNU я не люблю потому, что они до сих пор вербуют программистов на эту бессмысленную войну, и, тем самым, сегментируют OSS софт на пустом месте.

*: в основном, инфраструктурный софт, протоколы взаимодействия(не только TCP, а еще документооборот, например), и так далее.

https://lkml.org/lkml/2022/9/19/840

Очень controversial переписка между Линусом и фанатами Rust.

Суть довольно простая - товарищи из Rust хотят притащить к себе знание, в каком контексте вызвал аллокатор, чтобы не корячить интерфейс аллокатора заради "странных" хотелок ядра, а Линус совершенно корректно объясняет им, что так делать нельзя:

"And that is FUNDAMENTALLY BROKEN.

If you want to allocate memory, and you don't want to care about what context you are in, or whether you are holding spinlocks etc, then you damn well shouldn't be doing kernel programming. Not in C, and not in Rust"

Потому что пул аллокаций, который можно распределить так, очень мал:

"But it needs to be explicit, because that GFP_ATOMIC pool of allocations really is very limited, and you as the allocator need to make it *explicit* that yeah, now you're not just doing a random allocation, you are doing one of these *special* allocations that will eat into that very limited global pool of allocations."

Я тут испытываю очень противоречивые эмоции.

С одной стороны, ядро сейчас написанно именно так, как рассказывает Линус, и, очевидно, аллокатор надо звать так, как нужно в этом ядре.

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

По классике, можно, например, так - https://stackoverflow.com/questions/45095735/top-halves-and-bottom-halves-concept-clarification (попрошу отметить, что в Linux так можно) - в interrupt handler просто сериализуешь данные в область памяти, и кидаешь ее в пул тредов на обработку. Конечно, бывают ситуации, когда надо "ответить" прямо здесь и сейчас, но их можно пересчитать по пальцам одной руки(ладно, я просто больше не вспомнил).

Если посмотреть на какое-нить современное ядро, типа Zircon, то там вообще хрен найдешь это место, которое выполняется асинхронно.

https://www.business-gazeta.ru/article/566137

У меня впервые в жизни ощущение, что профильный министр "за тебя", и "делает все возможное". В ситуации, когда в стране Министерство Войны входит везде с пинка в дверь, это, конечно, очень круто, что у Шадаева вообще что-то получается сделать, и получается хорошо.

https://discourse.llvm.org/t/clang-16-notice-of-potentially-breaking-changes/65562

llvm начали заранее публиковать о грядущих изменениях, которые что-то ломают.

"The community is trying out a new way to alert interested parties about potentially disruptive changes in pre-release versions of our tools, and this post is the first such attempt at that. We expect to post these announcements to this channel and mark the posts with potentially-breaking so people can more easily be alerted without having to track development progress as closely. We’ve also added a potentially breaking changes section to our release notes to highlight concerns"

"нутром чую, что литра, но доказать не могу"

Я нутром чую, что это как-то связано с жопой при релизе clang15, про которые я пару раз писал, но доказательств этому найти не сумел.

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

Совсем забыл написать про фееричный баг от Intel:

"Ошибка в ядре Linux 5.19.12, потенциально способная повредить экраны на ноутбуках с GPU Intel"

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc6aff984b1c63d6b9e54f5eff9cc5ac5840bc8c

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

https://www.kommersant.ru/doc/5605730

"Вооруженные силы Украины заявили, что в работе спутниковой сети Starlink наблюдаются перебои, сообщает Financial Times со ссылкой на украинских чиновников. По их словам, проблемы со связью особенно усилились на территориях, которые присоединены к России — в ДНР, ЛНР, а также в Херсонской и Запорожской областях. Основатель SpaceX Илон Маск написал в Twitter, что не может комментировать ситуацию на поле боя"

https://3dnews.ru/1012993/komanda-spacex-starlink-soznalas-chto-otpravila-na-orbitu-30-tisyach-kompyuterov-na-linux

А все потому, что нехрен дырявое решето отправлять на орбиту.

Писал, пишу, и буду писать, что security by obscurity, как один из компонентов обеспечения безопасности - хорошо!

А так - пошел на чёрный рынок, купил пару дыр задорого, и вперед.

https://www.ixbt.com/news/2022/10/08/intel-horse-creek-risc-v-intel-4.html

Интересная тема, Intel дает возможность делать чужие процы на своих мощностях, причем, насколько я понял, этот техпроцесс сама Intel еще не использует в своих решениях. Такая отладка "на кошках".

https://www.phoronix.com/news/Zink-Evolve-OpenGL-API

Я уже примерно год рассказываю про то, что #zink + vulkan - это будещее графических API под Linux, но вот тут товарищи заходят даже несколько дальше - пишут, "берите vulkan, zink над ним, и дотачивайте его под свои нужды, как более простое графическое API".

В каком-то смысле это смещает восприятие opengl как "еще один (игровой?) движок поверх vulkan", наравне с тем же unity, unreal, etc.

https://www.phoronix.com/news/Wayland-Protocols-1.27

"The content type hint notification is used for enabling clients to provide hints to the Wayland compositor around the type of visual content provided by the app. In turn the content type hint notifications can be used for the compositor to adapt its behavior. This content-type-v1 protocol was originally written last year and initially supported "content types" are photo, video, or game content. If hinted to be game content, the compositor may optimize for reduced latency, if video it may be optimized for reduced stuttering and better scaling, or photo type for minimal extra processing by the compositor. With this content-type protocol still being in staging, it's possible other content types will still be added but ultimately is left up to the compositor if/what to optimize based upon the various content types"

У нас тут очередной #wayland moment, если вы понимаете, о чем я.

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

(это упрощенная схема, как оно устроено "на самом деле" я представляю, но для объяснения сойдет)

Аппаратная начинка вашего монитора и видеокарты должна выдавать какой-то фиксированный RPS. Давайте для простоты вычислений скажем "20 RPS".

То есть, каждые 50ms композитор должен выдавать буфер, откуда аппаратная начинка нарисует нам следующий кадр. Если этот буфер будет меняться в момент отрисовки(например, кто-то продолжит в него писать уже после того, как отдали буфер на отрисовку, или кто-то будет генерить новый буфер быстрее, чем надо), то у нас случится тиринг, BTW.

Как это можно сделать?

(здесь и далее я намеренно не рассказываю, как это все взаимодействует с вводом, потому что это усложнит все в 10 раз)

Самый простой вариант - раз в 50ms делать gather от всех клиентов композитора, блендить их в результирующий буфер, сделать usleep(50 - X), где X - время выполнения gather + blend, и отдать готовый буффер.

С этим решением есть следующая проблема - картинка на мониторе будет отставать от логики приложения на сколько-то времени. Потому что после того, как сделан gather, логика приложения продолжает "тикать".

Это будет ощущаться как постоянный лаг(курсора мышки, нажатия на элементы интерфейса, a/v desync, лаги в играх).

Самый простой способ "пофиксить" это - это сделать usleep() на какую-то константу перед началом всей этой процедуры, так, чтобы и рыбку съесть и окна успели отрисовать себя, но и так, чтобы мы не вывалились за deadline на рисование этого кадра.

(кстати, теперь вы знаете, что делает опция max_render_time в sway, как ее тюнить, и почему она плохо работает)

Одно из правильных решений этой задачи - отдать ее на откуп приложению. Например, делать gather с самого начала кванта в 50ms, и передавать в приложение deadline(скажем, если blend занимает 10ms, то можно передать в качестве deadline now() + 40ms).

Тогда приложение, зная, сколько оно будет рисовать кадр, сможет предпринять нужные действия(например, межкадровую интерполяцию для видеоплеера, или usleep в игре).

Конец рассказа про compositor internals.

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

И, к гадалке не ходи, GNOME media player будет знать, как работает GNOME compositor(какая там логика), и в GNOME shell оно будет работать прилично, и лагать под другими композиторами.