https://devblogs.microsoft.com/commandline/systemd-support-is-now-available-in-wsl/

Не могу не поделиться этой прекрасной новостью - systemd теперь работает под Винду!

У меня для вас сегодня лингвистическое исследование, благодаря одному из наших дорогих радиослушателей!

Коллега решил выяснить, как будет фраза "хуяк-хуяк, и в production" звучать на английском.

Выяснилось, что самое близкое, что можно придумать - это фраза "ping clang", фактически, калька с "дзынь-дзынь", звук, который издают молоточки в кузнице. https://www.merriam-webster.com/thesaurus/clang

Соответственно:

* Фраза целиком - "ping clang and to production", пользуйтесь

* clang вполне можно перевести как "хуяк"

Живите тепрь с этим знанием :D

Флеймообразующая (надеюсь) тема сегодня.

Вам не кажется, что ООП, по крайней мере в формулировке "инкапсуляция, наследование, полиморфизм" - в современном мире скорее мертво, чем живо?

* самое общее - все эти 3 кита можно рассматривать как оптимизации некоторых частных случаев замыканий и lambda. Я не хочу глубоко влезать в эту тему, но для понимания вполне достаточно вспомнить, как устроены объектные модели lua, javascript, lisp(?), и про хак dict["xxx"] == dict.xxx

* в целом, люди предпочитают мономорфизацию и интерфейсы, нежели полиморфизм в стиле C++. Интерфейсы, как нас учит Go, это не полиморфизм(хотя технически может быть сделано и через него).

* наследование не от интерфейса - довольно странная сама по себе вещь, единственное полезное известное мне применение - CRTP/mixin, но, опять же, это довольно нишевая техника.

3 вечера, 50 убитых коннекторов, и пара метров убитого кабеля.

Кажется, я прошелся вообще по всем граблям, пока учился обжимать витую пару.

Понятно, что с первой попытки ничего не заработало, и я начал исключать одну проблему за другой:

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

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

* Понял, что херовая обжималка, за 200 рублей-то - у нее не совсем верно были раположены два пенька для обжатия, и она либо не защелкивала, либо не обжимала. Впрочем, у обжималки первым делом отвалилось лезвие для зачистки, поэтому ожидаемо.

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

В какой-то момент сеть заработала, но максимум выдавала 100 мегабит. Я изучил, чем отличается кабель на 100 мегабит и кабель на гигабит, и понял, что у меня не идет ток по соответствующим проводам. А по другим шел.

Тут меня торкнуло, что кабель из стены у меня торчит не совсем такой, как я привык.

Добрый интернет мне рассказал, что такое cat5, cat6, чем отличаются кабели и коннекторы.

cat6, судя по всему, обжать cat5 коннектором можно, но это вероятностная процедура - оплетка у проводков более жесткая, и не факт, что контакты смогут прорезать все 8.

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

В итоге, конечно, все заработало, но пару раз за весь процесс я уже начинал сомневаться в собственной адекватности - "у всех получается, а ты что?"

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