https://observablehq.com/@vsapsai/effect-of-clang-modules-on-compilation-time

Пишут о том, что модули в clang ускоряют clean build в полтора раза, а вот инкрементальную пересборку замедляют, причем иногда в разы.

TIL что pthread_create под нагрузкой может вернуть EAGAIN. https://github.com/oneapi-src/oneTBB/pull/824

От автора #mold, пишет, что в Go тоже есть retry.

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

Я лично с таким никогда не сталкивался, хотя запуск pthread_create на большом нагруженном кластере наблюдал регулярно.

#bootstrap

https://niconiconi.neocities.org/posts/ken-thompson-really-did-launch-his-trusting-trust-trojan-attack-in-real-life/

Оказывается, атака Томпсона - это не теоретическое построение, а то, что он реально сделал.

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

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

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

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