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

(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, а еще документооборот, например), и так далее.