Я уже несколько раз писал про то, что считаю, что на #semver полагаться нельзя.
И, будучи последовательным сумасшедшим, я исповедую следующую практику версионирования:
* стабильные снепшоты кода нужно помечать автоинкрементным счетчиком.
Я лично предпочитаю v1, v2, etc.
Так же имеет право на существование схема vyyyymmdd, и подобные. Они несколько удобнее для ориентации от версии к версии. #calver
Для багфикс релизов можно делать что-то типа vN.M, где М может быть чем угодно. Я нумерую любимыми сериями из Футурамы. На самом деле, я бы тут мог написать все, что угодно, потому что багов не сажаю, и багфикс релизы не завожу.
В связи с этой нумерацией могу вспомнить очень давнюю историю, как я чуть было не подрался с начальником качества всего поиска, потому что забраковал отведенную(вроде шестую?) версию, и, ничтоже сумняшеся, завел N + 1, а он не хотел дырок в нумерации.
———
Вторая холиварная тема на сегодня - source based distro.
У меня есть две противоположные точки зрения на эту тему.
1) source based distro победят.
* Вычислительная мощность растет все еще экспоненциально. Сложность программ хер его знает, как растет, но, органолептически, как-то немножко медленнее. Давайте я поспекулирую, и скажу, что как квадрат. 30 лет назад на сборку gcc можно было потратить 2 суток. 15 лет назад это занимало час, а сейчас - 5 минут. Через 10 лет это будет еще относительно быстрее.
* Мы проверям md5 перед запуском бинарников из интернетов
* Самый лучший способ провалидировать, что бинарник собран правильным образом - это собрать его из исходников
Исходя из всего этого, предсобрать программы перед использованием это будет как зубы перед сном почистить. 2 минуты на инсталляцию.
2) сохранится status quo
* На самом деле, всем похер, и никто не заморочен на том, чтобы не запустить какую-нить хрень.
И, будучи последовательным сумасшедшим, я исповедую следующую практику версионирования:
* стабильные снепшоты кода нужно помечать автоинкрементным счетчиком.
Я лично предпочитаю v1, v2, etc.
Так же имеет право на существование схема vyyyymmdd, и подобные. Они несколько удобнее для ориентации от версии к версии. #calver
Для багфикс релизов можно делать что-то типа vN.M, где М может быть чем угодно. Я нумерую любимыми сериями из Футурамы. На самом деле, я бы тут мог написать все, что угодно, потому что багов не сажаю, и багфикс релизы не завожу.
В связи с этой нумерацией могу вспомнить очень давнюю историю, как я чуть было не подрался с начальником качества всего поиска, потому что забраковал отведенную(вроде шестую?) версию, и, ничтоже сумняшеся, завел N + 1, а он не хотел дырок в нумерации.
———
Вторая холиварная тема на сегодня - source based distro.
У меня есть две противоположные точки зрения на эту тему.
1) source based distro победят.
* Вычислительная мощность растет все еще экспоненциально. Сложность программ хер его знает, как растет, но, органолептически, как-то немножко медленнее. Давайте я поспекулирую, и скажу, что как квадрат. 30 лет назад на сборку gcc можно было потратить 2 суток. 15 лет назад это занимало час, а сейчас - 5 минут. Через 10 лет это будет еще относительно быстрее.
* Мы проверям md5 перед запуском бинарников из интернетов
* Самый лучший способ провалидировать, что бинарник собран правильным образом - это собрать его из исходников
Исходя из всего этого, предсобрать программы перед использованием это будет как зубы перед сном почистить. 2 минуты на инсталляцию.
2) сохранится status quo
* На самом деле, всем похер, и никто не заморочен на том, чтобы не запустить какую-нить хрень.
😁8👏2
Закончил эпопею с телегой.
"Закончил" - значит, наконец-то, собрал telegram desktop. До этого я сначала пользовался:
* Веб версией. Там есть две версии - K https://web.telegram.org/k, и Z(совпадение?) https://web.telegram.org/z. Пишут, что это две соревнующиеся команды. Дурову за это респект, если на конечную задачу бесконечно много денег, очень хороший способ. https://www.reddit.com/r/Telegram/comments/mzicwm/what_is_the_difference_between_webktelegramorg/
* Потом я обернул web версию в webview.
webview я взял на основе webkitgtk. https://github.com/webview/webview Автор какой-то упырь, принципиально не прикручивает систему сборки, типа, "один файл, чо вам еще надо". При использовании этого webview столкнулся со странным - если загрузить сайт в webview, то у него некорректно работают размеры контролов и прочего гуи. С проблемой столкнулся не только я - https://github.com/luakit/luakit/issues/279, люди рекомендуют руками выставить zoom.
Мне было понятно, что это workaround для какого-то бага, я решил разобраться.
TL;DR - передаю привет любителям int, sentinel == -1, и, как результат, DPI в -1/1024.0
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/gtk/PlatformScreenGtk.cpp#L115
int - зло, sentinel - убивал бы за такое, в том числе, за ZTS.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/webview/unwrap/mix.sh#L25 - починил, соорудил себе бинарь webview, гонял телегу в нем.
Все же, как бы ни был хорош JS telegram, хотелось нативочки.
* Сегодня дособирал себе настоящую телегу.
Что хотел бы сказать по этому поводу?
* Не понимаю, чего там дистрибутивы жалуются на разрабов телеги, они делают все, что в их ограниченных силах для де-вендоринга. Даже страницу с инструкциями накидали - https://github.com/telegramdesktop/tdesktop/wiki/The-Packaged-Building-Mode
* Пишут телегу олимпиадники. Код норм, не рыхлый, читать приятно. Слишком сильно увлекаются последними стандартами. Поэтому clang у меня этот код отказался компилировать, а gcc падал на некоторых файлах:
Казалось бы, все пропало?
Но ваш покорный слуга не растерялся, и соорудил cadavercc:
Исходники пришлось подпатчить.
Пришлось очень долго возиться с cmake. Коллеги накостыляли сборку subproject, а cmake не передает в глубину все нужные аргументы, пришлось делать над ним враппер, который бы верно обрабатывал рекурсию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/telegram/desktop/mix.sh#L83
* был приятно удивлен сборкой QT. Все собралось как-то быстро и без проблем, так же, в QT есть штатный механизм статической сборки с плагинами, устроен примерно так же, как у меня подмена dlfcn, только уровнем повыше.
* самая мякотка - полез чинить сборку с clang. https://github.com/telegramdesktop/tdesktop/issues/24385 Как обычно, не сдержался, влез. Как ни странно, полностью на стороне дуровцев - делают все, что могут, в ограниченных условиях, не больше, но и не меньше.
"Закончил" - значит, наконец-то, собрал telegram desktop. До этого я сначала пользовался:
* Веб версией. Там есть две версии - K https://web.telegram.org/k, и Z(совпадение?) https://web.telegram.org/z. Пишут, что это две соревнующиеся команды. Дурову за это респект, если на конечную задачу бесконечно много денег, очень хороший способ. https://www.reddit.com/r/Telegram/comments/mzicwm/what_is_the_difference_between_webktelegramorg/
* Потом я обернул web версию в webview.
webview я взял на основе webkitgtk. https://github.com/webview/webview Автор какой-то упырь, принципиально не прикручивает систему сборки, типа, "один файл, чо вам еще надо". При использовании этого webview столкнулся со странным - если загрузить сайт в webview, то у него некорректно работают размеры контролов и прочего гуи. С проблемой столкнулся не только я - https://github.com/luakit/luakit/issues/279, люди рекомендуют руками выставить zoom.
Мне было понятно, что это workaround для какого-то бага, я решил разобраться.
TL;DR - передаю привет любителям int, sentinel == -1, и, как результат, DPI в -1/1024.0
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/platform/gtk/PlatformScreenGtk.cpp#L115
int - зло, sentinel - убивал бы за такое, в том числе, за ZTS.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/webview/unwrap/mix.sh#L25 - починил, соорудил себе бинарь webview, гонял телегу в нем.
Все же, как бы ни был хорош JS telegram, хотелось нативочки.
* Сегодня дособирал себе настоящую телегу.
Что хотел бы сказать по этому поводу?
* Не понимаю, чего там дистрибутивы жалуются на разрабов телеги, они делают все, что в их ограниченных силах для де-вендоринга. Даже страницу с инструкциями накидали - https://github.com/telegramdesktop/tdesktop/wiki/The-Packaged-Building-Mode
* Пишут телегу олимпиадники. Код норм, не рыхлый, читать приятно. Слишком сильно увлекаются последними стандартами. Поэтому clang у меня этот код отказался компилировать, а gcc падал на некоторых файлах:
ceFiles/main/session/send_as_peers.cpp.o.d(gcc как был всратым говном, так и остался. Компиляет он, по ощущениям, раза в 2 - 3 медленнее, чем clang)
-o Telegram/CMakeFiles/Telegram.dir/
SourceFiles/main/session/
send_as_peers.cpp.o
-c /mix/build/coPWMHWqHpBGFNTA/src/
Telegram/SourceFiles/main/session/
send_as_peers.cpp
x86_64-pc-linuxg++: internal compiler error:
Segmentation fault signal
terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
Казалось бы, все пропало?
Но ваш покорный слуга не растерялся, и соорудил cadavercc:
cat << EOF > clang++cadavercc, на удивление, прожевал кодовую базу, и выдал рабочий результат.
#!/bin/sh
/path/to/clang++ "\${@}" || g++ "\${@}"
EOF
Исходники пришлось подпатчить.
Пришлось очень долго возиться с cmake. Коллеги накостыляли сборку subproject, а cmake не передает в глубину все нужные аргументы, пришлось делать над ним враппер, который бы верно обрабатывал рекурсию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/telegram/desktop/mix.sh#L83
* был приятно удивлен сборкой QT. Все собралось как-то быстро и без проблем, так же, в QT есть штатный механизм статической сборки с плагинами, устроен примерно так же, как у меня подмена dlfcn, только уровнем повыше.
* самая мякотка - полез чинить сборку с clang. https://github.com/telegramdesktop/tdesktop/issues/24385 Как обычно, не сдержался, влез. Как ни странно, полностью на стороне дуровцев - делают все, что могут, в ограниченных условиях, не больше, но и не меньше.
web.telegram.org
Telegram Web
Telegram is a cloud-based mobile and desktop messaging app with a focus on security and speed.
👍17😁6🔥5
#tcmalloc #mimalloc #allocator
Обнаружил, что у меня стали иногда падать сборки webkit, по нехватке памяти.
Я как-то уже писал, что включил себе zswap на несколько гигабайт, ровно по этой же причине - в моменте там есть пара файлов, на которых у меня система упирается в лимит по памяти.
Странно, что оно начало случаться снова.
В барабашек я не верю, полез разбираться.
Таки да, нативная телега жрала довольно дофига памяти(в этом посте я обойдусь без абсолютных цифр, они у вас могут отличаться, да и не важно это).
Дуровцы собирают телегу с jmalloc, я собираю весь дистрибутив с mimalloc.
Тут будет небольшое лирическое отступление.
Я фанат mimalloc. Мне он очень нравится идейно, я даже статью прочел. Хорошо знаю его кодовую базу.
Но, если честно, собирать целый дистрибутив на mimalloc - это, во многом, эмоциональное решение.
Потому что в качестве аллокатора по умолчанию я всем рекомендую tcmalloc, из gperftools.
Почему?
* жОпыт. Мой говорит, что tcmalloc - наиболее предсказуемый из всех известных мне аллокаторов. Да, он почти во всех сценариях уступает локальному лидеру, но, зато, никогда не приходит хуже, чем вторым. Предсказуемость - это очень важно.
* Известно довольно много случаев, когда в Я переходили на tcmalloc там, где важны latency spike.
* Я очень верю в hard work :) tcmalloc - это прямо очень hard work, туда вбуханы, не знаю, сотня человеко-лет. За это время инженеры гугла успели идентифицировать и починить кучу corner case, от которых страдают те или иные аллокаторы. Красивой идеей можно обогнать hard work в некоторых случаях, но не в среднем.
Поэтому, если есть время на тесты, я советую взять mimalloc, tcmalloc, и hualloc, и прогнать их на реальной нагрузке, а если нет - то tcmalloc как аллокатор по умолчанию.
Я решил посмотреть, как ведет себя сборка tdesktop с разными аллокаторами.
setup у меня примерно такой - собираю испытуемую программу с нужным аллокатором, запускаю ее, и начинаю серфить. В соседней консоли - top, по нему я в realtime слежу за RSS. CPU и прочее не смотрю, не интересно.
Графиков я не строил, все же, не новую конфигурацию железа для ДЦ выбираю.
Победил tcmalloc:
* В steady режиме процентов на 15 меньше RSS.
* В пиках потребления он лучше конкурентов в 1.5 раза.
Из интересного:
* tcmalloc потрясающе бережно относится к вирутальной памяти - он распределяет где-то 80% от аллоцированного адресного пространства. jemalloc - 50%(это довольно примерные цифры, скачет же все), mimalloc - 15%. В целом, кажется(я пока себя не до конца в этом убедил), это должно в лучшую сторону влиять на спайки, потому что чаще выдаем уже прогретую память.
* jemalloc - какая-то непредсказуемая хрень, то у нее потребление памяти скакануло высоко, то вообще все, досуха, вернули в систему.
* mimalloc, jemalloc примерно одинаково жрут памяти в среднем, и в пиках.
* mimalloc почему-то очень много выделяет адресного пространства.
Обнаружил, что у меня стали иногда падать сборки webkit, по нехватке памяти.
Я как-то уже писал, что включил себе zswap на несколько гигабайт, ровно по этой же причине - в моменте там есть пара файлов, на которых у меня система упирается в лимит по памяти.
Странно, что оно начало случаться снова.
В барабашек я не верю, полез разбираться.
Таки да, нативная телега жрала довольно дофига памяти(в этом посте я обойдусь без абсолютных цифр, они у вас могут отличаться, да и не важно это).
Дуровцы собирают телегу с jmalloc, я собираю весь дистрибутив с mimalloc.
Тут будет небольшое лирическое отступление.
Я фанат mimalloc. Мне он очень нравится идейно, я даже статью прочел. Хорошо знаю его кодовую базу.
Но, если честно, собирать целый дистрибутив на mimalloc - это, во многом, эмоциональное решение.
Потому что в качестве аллокатора по умолчанию я всем рекомендую tcmalloc, из gperftools.
Почему?
* жОпыт. Мой говорит, что tcmalloc - наиболее предсказуемый из всех известных мне аллокаторов. Да, он почти во всех сценариях уступает локальному лидеру, но, зато, никогда не приходит хуже, чем вторым. Предсказуемость - это очень важно.
* Известно довольно много случаев, когда в Я переходили на tcmalloc там, где важны latency spike.
* Я очень верю в hard work :) tcmalloc - это прямо очень hard work, туда вбуханы, не знаю, сотня человеко-лет. За это время инженеры гугла успели идентифицировать и починить кучу corner case, от которых страдают те или иные аллокаторы. Красивой идеей можно обогнать hard work в некоторых случаях, но не в среднем.
Поэтому, если есть время на тесты, я советую взять mimalloc, tcmalloc, и hualloc, и прогнать их на реальной нагрузке, а если нет - то tcmalloc как аллокатор по умолчанию.
Я решил посмотреть, как ведет себя сборка tdesktop с разными аллокаторами.
setup у меня примерно такой - собираю испытуемую программу с нужным аллокатором, запускаю ее, и начинаю серфить. В соседней консоли - top, по нему я в realtime слежу за RSS. CPU и прочее не смотрю, не интересно.
Графиков я не строил, все же, не новую конфигурацию железа для ДЦ выбираю.
Победил tcmalloc:
* В steady режиме процентов на 15 меньше RSS.
* В пиках потребления он лучше конкурентов в 1.5 раза.
Из интересного:
* tcmalloc потрясающе бережно относится к вирутальной памяти - он распределяет где-то 80% от аллоцированного адресного пространства. jemalloc - 50%(это довольно примерные цифры, скачет же все), mimalloc - 15%. В целом, кажется(я пока себя не до конца в этом убедил), это должно в лучшую сторону влиять на спайки, потому что чаще выдаем уже прогретую память.
* jemalloc - какая-то непредсказуемая хрень, то у нее потребление памяти скакануло высоко, то вообще все, досуха, вернули в систему.
* mimalloc, jemalloc примерно одинаково жрут памяти в среднем, и в пиках.
* mimalloc почему-то очень много выделяет адресного пространства.
🔥12👍7
Хорошие измерения - сложно.
В комментариях к моему вчерашнему посту мне объяснили, что коллеги выбрали jemalloc после тестов на особо всратом канале, где зашкаливало потребление памяти. Канал можно подсмотреть в дискуссии.
Мне стало интересно, как это починить для #tcmalloc, и я решил запустить background thread, который бы постепенно возвращал память в систему.
Вот мой код. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/trim/mix.sh
(тут хочу отдельно отметить, какая у меня крутая система сборки - кодогенерация исходников на С++, с настройками от потребителя через флажки - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/telegram/desktop/unwrap/mix.sh#L38 - тут написано, что мы используем такую библиотеку, которая бы освобождала по 10 мегабайт в секунду. Мне, признаться, даже немного стремно выпускать такую описательную мощь наружу)
Все работало очень хорошо, при выбранных мной параметрах телега возвращалась в steady режим за пару минут, этот режим был лучше того, что показывал jemalloc.
И я уже предвкушал момент, когда я напишу что-нить типа "ну, вот так-то и так-то, а если надо еще, то пусть коллеги приходят за небольшой прайс за консультацией".
Но не тут-то было, и в комментариях мне рассказали, что телега, в случае сборки по феншую, каноничными скриптами, активирует похожий режим, только для jemalloc. https://github.com/desktop-app/cmake_helpers/blob/87d46d81111d9ebfff560e1be3d52306c7475fe7/linux_jemalloc_helper/linux_jemalloc_helper.cpp
Починил, провел новые измерения, и имею сказать:
* В пике RSS у tcmalloc и jemalloc при просмотре этого канала примерно одинаковый - 4 гига.
* После возвращения в steady режим жрут они по 450 - 500 мегабайт, тоже одинаково.
* В steady режим jemalloc возвращается быстрее, но это мой личный выбор, потому что вернуть много памяти сразу - это долго, и может быть заметно в виде latency spike.
* Для mimalloc я такого режима не нашел, для него результатов не будет.
Короче, jemalloc для телеги тоже норм, но я доверюсь своему личному жОпыту.
Хочу попробовать воткнуть такое в другие программы, которые в пиках могут жрать много памяти - в worker браузера, etc.
Так же мне стало интересно, как дела обстоят с телегами, которые собирают дистрибутивы - все ли там хорошо, или нет.
* Alpine linux - https://git.alpinelinux.org/aports/tree/community/telegram-desktop/disable-jemalloc.patch они явно отключают jemalloc в пользу системного. Скорее всего, там все плохо, и телега жрет памяти, как не в себя.
* Arch linux - https://archlinux.org/packages/community/x86_64/telegram-desktop/ https://github.com/archlinux/svntogit-community/blob/packages/telegram-desktop/trunk/PKGBUILD - все сложно. Есть зависимость от системного jemalloc, но забандленый явно не выключен. Поэтому все зависит от того, как работает configure/cmake(выключит он или нет забандленый код, если найдет системный), а дальше - от порядка линковки и фичей системного jemalloc. Пара вариантов:
1. Все работает just as planned, используется забандленный, линкер просто выкидывает зависимость от системного.
2. Все работает наперекосяк. Самыми разными способами. Например, символы аллокатора берутся из системного, заголовки - из забандленного, код по активации вызывается или нет, ну и в системном может просто не быть поддержки этого вызова.
Нужно брать и проверять наживую, фанатам того или иного дистра рекомендую проверить телегу в нем - поставить gdb на mallctl, и потрейсить готовые бинари.
В комментариях к моему вчерашнему посту мне объяснили, что коллеги выбрали jemalloc после тестов на особо всратом канале, где зашкаливало потребление памяти. Канал можно подсмотреть в дискуссии.
Мне стало интересно, как это починить для #tcmalloc, и я решил запустить background thread, который бы постепенно возвращал память в систему.
Вот мой код. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/trim/mix.sh
(тут хочу отдельно отметить, какая у меня крутая система сборки - кодогенерация исходников на С++, с настройками от потребителя через флажки - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/telegram/desktop/unwrap/mix.sh#L38 - тут написано, что мы используем такую библиотеку, которая бы освобождала по 10 мегабайт в секунду. Мне, признаться, даже немного стремно выпускать такую описательную мощь наружу)
Все работало очень хорошо, при выбранных мной параметрах телега возвращалась в steady режим за пару минут, этот режим был лучше того, что показывал jemalloc.
И я уже предвкушал момент, когда я напишу что-нить типа "ну, вот так-то и так-то, а если надо еще, то пусть коллеги приходят за небольшой прайс за консультацией".
Но не тут-то было, и в комментариях мне рассказали, что телега, в случае сборки по феншую, каноничными скриптами, активирует похожий режим, только для jemalloc. https://github.com/desktop-app/cmake_helpers/blob/87d46d81111d9ebfff560e1be3d52306c7475fe7/linux_jemalloc_helper/linux_jemalloc_helper.cpp
Починил, провел новые измерения, и имею сказать:
* В пике RSS у tcmalloc и jemalloc при просмотре этого канала примерно одинаковый - 4 гига.
* После возвращения в steady режим жрут они по 450 - 500 мегабайт, тоже одинаково.
* В steady режим jemalloc возвращается быстрее, но это мой личный выбор, потому что вернуть много памяти сразу - это долго, и может быть заметно в виде latency spike.
* Для mimalloc я такого режима не нашел, для него результатов не будет.
Короче, jemalloc для телеги тоже норм, но я доверюсь своему личному жОпыту.
Хочу попробовать воткнуть такое в другие программы, которые в пиках могут жрать много памяти - в worker браузера, etc.
Так же мне стало интересно, как дела обстоят с телегами, которые собирают дистрибутивы - все ли там хорошо, или нет.
* Alpine linux - https://git.alpinelinux.org/aports/tree/community/telegram-desktop/disable-jemalloc.patch они явно отключают jemalloc в пользу системного. Скорее всего, там все плохо, и телега жрет памяти, как не в себя.
* Arch linux - https://archlinux.org/packages/community/x86_64/telegram-desktop/ https://github.com/archlinux/svntogit-community/blob/packages/telegram-desktop/trunk/PKGBUILD - все сложно. Есть зависимость от системного jemalloc, но забандленый явно не выключен. Поэтому все зависит от того, как работает configure/cmake(выключит он или нет забандленый код, если найдет системный), а дальше - от порядка линковки и фичей системного jemalloc. Пара вариантов:
1. Все работает just as planned, используется забандленный, линкер просто выкидывает зависимость от системного.
2. Все работает наперекосяк. Самыми разными способами. Например, символы аллокатора берутся из системного, заголовки - из забандленного, код по активации вызывается или нет, ну и в системном может просто не быть поддержки этого вызова.
Нужно брать и проверять наживую, фанатам того или иного дистра рекомендую проверить телегу в нем - поставить gdb на mallctl, и потрейсить готовые бинари.
🔥9👍1😁1
https://lwn.net/Articles/892334/
"Тихо и незаметно" вышел M1-ready OpenBSD. 3D там, очевидно, нет, и быть не может.
———
https://www.opennet.ru/opennews/art.shtml?num=57067
https://gitflic.ru/project/erthink/libmdbx
github беснуется.
Вроде, обещали, что банить без причин и возможности оправдаться не будут, но нет.
С libmdbx вообще какая-то странная ситуация, я не понимаю, за что их.
———
Я тут захотел себе kinetic scrolling везде.
Хотел было даже запилить в libinput, но вовремя остановился, поискал, почему еще нет.
https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#kinetic-scrolling-does-not-work
Удивительно, но совершенно корректная причина - если сделать по рабоче-крестьянски(как я и хотел), то ошметки могут попасть в другое приложение.
Дальше моя мысль пошла по 2 направлениями:
* А что с kinetic в qt, или, на худой конец, прямо в телеге?
https://github.com/telegramdesktop/tdesktop/issues/6746
Читаем, ходим по ссылочкам.
TL;DR - оно подвисло где-то в QT, видимо, они не заинтересованы. И, наверное, их можно понять, потому что, если я их верно понимаю, у них деньги не от десктопа. Десктоп - всего лишь витрина.
* Запилить прямо в sway. Композитор может послать шлейф kinetic эвентов в нужное окно. Понятно, что в upstream такое не примут, читаю код, можно ли это сделать малой кровью, чтобы потом было несложно мержить.
———
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.18-x86-WERROR
В Linux 5.18 хотят включить werror дляx 86_64. Шансов на это нет, потому что, имея на руках нетестируемое декартово произведение всех возможных настроек, средняя сборка не будет иметь шансов сойтись.
К счастью, я имею возможность override идиотских решений разработчиков, у меня враппер для компилятора, куда я добавлю -w принудительно.
"Тихо и незаметно" вышел M1-ready OpenBSD. 3D там, очевидно, нет, и быть не может.
———
https://www.opennet.ru/opennews/art.shtml?num=57067
https://gitflic.ru/project/erthink/libmdbx
github беснуется.
Вроде, обещали, что банить без причин и возможности оправдаться не будут, но нет.
С libmdbx вообще какая-то странная ситуация, я не понимаю, за что их.
———
Я тут захотел себе kinetic scrolling везде.
Хотел было даже запилить в libinput, но вовремя остановился, поискал, почему еще нет.
https://wayland.freedesktop.org/libinput/doc/latest/faqs.html#kinetic-scrolling-does-not-work
Удивительно, но совершенно корректная причина - если сделать по рабоче-крестьянски(как я и хотел), то ошметки могут попасть в другое приложение.
Дальше моя мысль пошла по 2 направлениями:
* А что с kinetic в qt, или, на худой конец, прямо в телеге?
https://github.com/telegramdesktop/tdesktop/issues/6746
Читаем, ходим по ссылочкам.
TL;DR - оно подвисло где-то в QT, видимо, они не заинтересованы. И, наверное, их можно понять, потому что, если я их верно понимаю, у них деньги не от десктопа. Десктоп - всего лишь витрина.
* Запилить прямо в sway. Композитор может послать шлейф kinetic эвентов в нужное окно. Понятно, что в upstream такое не примут, читаю код, можно ли это сделать малой кровью, чтобы потом было несложно мержить.
———
https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.18-x86-WERROR
В Linux 5.18 хотят включить werror дляx 86_64. Шансов на это нет, потому что, имея на руках нетестируемое декартово произведение всех возможных настроек, средняя сборка не будет иметь шансов сойтись.
К счастью, я имею возможность override идиотских решений разработчиков, у меня враппер для компилятора, куда я добавлю -w принудительно.
lwn.net
OpenBSD 7.1 released
OpenBSD 7.1 has been released. The list of changes and new features is
long, as usual; see the full text, below, for all the details.
long, as usual; see the full text, below, for all the details.
👍5
Наши телерадиослушатели коммитят исправление сборки с clang в телегу, не могу не поделиться!
https://github.com/telegramdesktop/tdesktop/pull/24435
———
Задачка на unix shell - переместить все файлы из директории в какую-то другую, не являющуюся потомком исходной.
Нельзя пользоваться C/Perl/Python, etc
Я делал подход к снаряду несколько раз, и всегда у меня находились дыры :)) Однострочником так и не получилось, пришлось в циклы и вот это вот все.
https://superuser.com/questions/62141/how-to-move-all-files-from-current-directory-to-upper-directory
Тред с обсуждением решений. Во всех решениях, которые там есть(не читерские), есть дыры, попробуйте их поискать.
———
https://gitlab.freedesktop.org/libinput/libinput/-/commit/a423d7d3269dc32a87384f79e29bb5ac021c83d1
Фикс бага в libinput.
"Ядро" фикса, конечно, доставляет - https://gitlab.freedesktop.org/libinput/libinput/-/commit/a423d7d3269dc32a87384f79e29bb5ac021c83d1#29a46532ba391d88b6cc8668e181e65c1e43a7d7_401_409
———
https://spacedoutandsmiling.com/blog/2021-12-27-nerdy-aws-graviton-vs-m1-vs-m1-pro-nodejsr-benchmarks
Старая ссылка, почему-то забыл про нее написать. По косвенным данным можно сделать вывод, насколько одно ядро M1 круче, чем одно ядро от graviton.
https://github.com/telegramdesktop/tdesktop/pull/24435
———
Задачка на unix shell - переместить все файлы из директории в какую-то другую, не являющуюся потомком исходной.
Нельзя пользоваться C/Perl/Python, etc
Я делал подход к снаряду несколько раз, и всегда у меня находились дыры :)) Однострочником так и не получилось, пришлось в циклы и вот это вот все.
https://superuser.com/questions/62141/how-to-move-all-files-from-current-directory-to-upper-directory
Тред с обсуждением решений. Во всех решениях, которые там есть(не читерские), есть дыры, попробуйте их поискать.
———
https://gitlab.freedesktop.org/libinput/libinput/-/commit/a423d7d3269dc32a87384f79e29bb5ac021c83d1
Фикс бага в libinput.
"Ядро" фикса, конечно, доставляет - https://gitlab.freedesktop.org/libinput/libinput/-/commit/a423d7d3269dc32a87384f79e29bb5ac021c83d1#29a46532ba391d88b6cc8668e181e65c1e43a7d7_401_409
———
https://spacedoutandsmiling.com/blog/2021-12-27-nerdy-aws-graviton-vs-m1-vs-m1-pro-nodejsr-benchmarks
Старая ссылка, почему-то забыл про нее написать. По косвенным данным можно сделать вывод, насколько одно ядро M1 круче, чем одно ядро от graviton.
GitHub
Explicitly specify QVector element type to fix build with clang13+qt6 by noiseless · Pull Request #24435 · telegramdesktop/tdesktop
More info:
#24385
fixes #24014
ericniebler/range-v3#1691
#24385
fixes #24014
ericniebler/range-v3#1691
👍6
У меня сегодня 2 истории, несколько технические, но, КМК, интересные.
В #tcmalloc нет реализации reallocarray(). В принципе, они в своем праве, потому что никому ничего не должны.
Проблема в том, что в musl reallocarray реализован.
Почему это проблема? Потому что у нас получается интересная ситуация - в stdlib.h есть сигнатура для reallocarray(), а в libmusl.a + libtcmalloc.a такого символа нет.
Дальше получается следующее:
1) Если configure проекта определяет наличие символа через компиляцию, то он получит, что reallocarray есть в наличии, и не включит у себя флажок, по которому бы код подставил свою реализацию. И в момент линковки будет ошибка.
2) Если configure определяет это через линковку, то он получит, что reallocarray нет, и включит флажок, по которому код включит у себя fallback на свою реализацию. Казалось бы, все хорошо? Нет, потому что эта рализация может не скомпилироваться, потому что в stdlib.h есть сигнатура от musl, и они могут, в деталях, не совпадать(например, throw()/noexept/etc).
Засада.
После ряда попыток это workaround в разных местах, я решил, что проще всего добавить реализацию в tcmalloc:
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/mix.sh#L25
Кстати, в реализации, в которой я на это наткнулся, ошибка - https://git.sr.ht/~emersion/basu/tree/master/item/src/basic/alloc-util.h#L76 (впрочем, AFAIK стандарта на это еще нет, поэтому все в своем праве)
———
Решил я себе собрать #dosbox.
А он, зараза, зависит от SDL1, которая давно не обновляется, и собирать ее с wayland мне особо не хотелось.
Есть реализация api sdl1 через sdl2. https://github.com/libsdl-org/sdl12-compat/blob/main/src/SDL12_compat.c (в одном файле, да)
От автора sdl, судя по всему, он ее делал за деньги(потому что такое говно, как по этой ссылке, можно пилить только за деньги, и очень большие), работает хорошо.
Проблема в том, что у sdl1 и sdl2 один и тот же namespace, и функции пересекаются по именам. Поэтому коллега, ничтоже сумняшеся, загружает .so с SDL2 в RTLD_LOCAL режиме, и достает оттуда символы почем зря.
Мне пришлось соорудить интересную шутку - собрать библиотеку SDL2, и переложить все символы в другой namespace(по сути, добавить префикс V2_ ко всем экспортируемым именам). Я назвал библиотеку "SDL2 chimera". https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/sdl/chimera/mix.sh#L12 После чего "загрузка" такой .a библиотеки дело техники - нужно всего лишь составить список вида [("SDL2", "SDL_xxx", &V2_SDL_xxx)] для моего загрузчика .so. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/sdl/chimera/dl/mix.sh#L14 Пересечений с SDL1 в общем пространстве имен бинарника не будет.
dosbox, сликованный в один бинарь с SDL2 - никто не умеет, а я умею :)
Отмечу, что вот это решение - оно вполне себе норм, то есть, это не хак, который будет разваливаться от каждого чиха. Переименование символов - хорошо определенная операция на объектных файлах, без странных side effect. Ну а добавить "V2_" - это очень разумная эмуляция для RTLD_LOCAL, найдите 5 отличий, что называется.
В #tcmalloc нет реализации reallocarray(). В принципе, они в своем праве, потому что никому ничего не должны.
Проблема в том, что в musl reallocarray реализован.
Почему это проблема? Потому что у нас получается интересная ситуация - в stdlib.h есть сигнатура для reallocarray(), а в libmusl.a + libtcmalloc.a такого символа нет.
Дальше получается следующее:
1) Если configure проекта определяет наличие символа через компиляцию, то он получит, что reallocarray есть в наличии, и не включит у себя флажок, по которому бы код подставил свою реализацию. И в момент линковки будет ошибка.
2) Если configure определяет это через линковку, то он получит, что reallocarray нет, и включит флажок, по которому код включит у себя fallback на свою реализацию. Казалось бы, все хорошо? Нет, потому что эта рализация может не скомпилироваться, потому что в stdlib.h есть сигнатура от musl, и они могут, в деталях, не совпадать(например, throw()/noexept/etc).
Засада.
После ряда попыток это workaround в разных местах, я решил, что проще всего добавить реализацию в tcmalloc:
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/tcmalloc/mix.sh#L25
Кстати, в реализации, в которой я на это наткнулся, ошибка - https://git.sr.ht/~emersion/basu/tree/master/item/src/basic/alloc-util.h#L76 (впрочем, AFAIK стандарта на это еще нет, поэтому все в своем праве)
———
Решил я себе собрать #dosbox.
А он, зараза, зависит от SDL1, которая давно не обновляется, и собирать ее с wayland мне особо не хотелось.
Есть реализация api sdl1 через sdl2. https://github.com/libsdl-org/sdl12-compat/blob/main/src/SDL12_compat.c (в одном файле, да)
От автора sdl, судя по всему, он ее делал за деньги(потому что такое говно, как по этой ссылке, можно пилить только за деньги, и очень большие), работает хорошо.
Проблема в том, что у sdl1 и sdl2 один и тот же namespace, и функции пересекаются по именам. Поэтому коллега, ничтоже сумняшеся, загружает .so с SDL2 в RTLD_LOCAL режиме, и достает оттуда символы почем зря.
Мне пришлось соорудить интересную шутку - собрать библиотеку SDL2, и переложить все символы в другой namespace(по сути, добавить префикс V2_ ко всем экспортируемым именам). Я назвал библиотеку "SDL2 chimera". https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/sdl/chimera/mix.sh#L12 После чего "загрузка" такой .a библиотеки дело техники - нужно всего лишь составить список вида [("SDL2", "SDL_xxx", &V2_SDL_xxx)] для моего загрузчика .so. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/sdl/chimera/dl/mix.sh#L14 Пересечений с SDL1 в общем пространстве имен бинарника не будет.
dosbox, сликованный в один бинарь с SDL2 - никто не умеет, а я умею :)
Отмечу, что вот это решение - оно вполне себе норм, то есть, это не хак, который будет разваливаться от каждого чиха. Переименование символов - хорошо определенная операция на объектных файлах, без странных side effect. Ну а добавить "V2_" - это очень разумная эмуляция для RTLD_LOCAL, найдите 5 отличий, что называется.
👍10🔥5
Хочу out of band спросить уважаемую публику - а вы понимаете экономику вот таких вот штук? https://www.opennet.ru/opennews/art.shtml?num=57098
По моим представлениям, у этой хтони 1000 пользователей, и никто из них не готов дать денег на развитие.
А релизы и gui кто-то клепает... GUI в моей картине мира люди делают только за деньги, потому что это очень скучно.
По моим представлениям, у этой хтони 1000 пользователей, и никто из них не готов дать денег на развитие.
А релизы и gui кто-то клепает... GUI в моей картине мира люди делают только за деньги, потому что это очень скучно.
www.opennet.ru
Доступна мобильная платформа KDE Plasma Mobile 22.04
Опубликован выпуск мобильной платформы KDE Plasma Mobile 22.04, основанной на мобильной редакции рабочего стола Plasma 5, библиотеках KDE Frameworks 5, телефонном стеке ModemManager и коммуникационном фреймворке Telepathy. Для вывода графики в Plasma Mobile…
👍3
#gold #ix #bootstrap
У меня есть обширная тема про пересборку одного и того же набора исходников в разных контекстах.
Сегодня я поговорю про "хорошую", полезную пересборку, которая, так уж получилась, теперь составляет большой кусок модели моей пакетной базы.
А завтра поговорю про "плохую" пересборку. Да, про rust, и про go.
Пересборка одного и того же набора исходников в разных контекстах у меня происходит в следующих случаях:
* Самый простой случай - собрать один и тот же код с разным набором библиотек и опций.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/curl/t/mix.sh - вот библиотеки для обычного libcurl, https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/curl/lite/mix.sh - а вот для лайтовой версии.
Лайтовая версия используется в cmake, который используется в процессе сборки самого дистрибутива. Меньше зависимостей - меньше глубина дерева, проще bootstrap.
* Немного более сложный случай. Я уже пару раз рассказывал, что для эмуляции динамической линковки я завожу конструктор статического объекта, который заставляет влинковаться в программу нужные символы.
Проблема в том, что эти символы будут влинковываться всегда, у линкера не будет возможности выкинуть их.
А теперь представьте, что в поставке sway идет 2 программы - композитор, и cli для управления им. В моей модели получится, что, если не хачить систему сборки, драйвера и реализация opengl будут влинкованы в обе программы, хотя нужны только в одной.
Я решаю это так - собираю sway 2 раза, 1 раз с драйверами, и оставляю только бинарник композитора. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/compositor/mix.sh А заодно заменяю там аллокатор, да, и добавляю тред, который бы возвращал память в систему. И без драйверов, и со стандартным аллокатором - все остальное https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/tools/mix.sh
Финальный пакет со sway - это набор из нескольких пакетов. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/mix.sh
Таких примеров довольно много. Ну, вот, Xpdf - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/xpdf/mix.sh Примерно по тем же соображениям.
* Еще более интересный случай.
Я уже как-то рассказывал, что у меня каждый пакет может быть собран в нескольких контекстах.
Для простоты скажу, что есть bin контекст - это когда от сборки пакета мы оставляем только бинари, и lib контекст - когда оставляем только библиотеки. Это прямо жестко и формально сделано - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/std/postinstall.sh#L29
Поэтому у меня есть гарантия, что от host тулзы во время сборки не приползет host же библиотека, или от target библиотеки не приползет левая target тулза, которая даже не запустится.
Оказалось, что делать немножко разную сборку для lib контекста и для bin контекста - очень удобно.
Это позволяет уменьшить высоту графа, и ускорить сборку(хотя суммарно работы будет сделано и больше).
Как?
Ну вот возьмем в качестве примера библиотеки компрессоров. У них у всех есть очень интересное свойство - все библиотеки зависят только от libc, а вот бинари зависят от всех остальных компрессоров, потому что все претендуюут на всеобъемлимость, и хотят быть точкой входа в компрессию.
Поэтому разделение на bin и на lib дает понятное уплощение графа. И убирает некоторые кольцевые ссылки, да. Код, который зависит от того или иного кодека имеет шансы начать собираться раньше, потому что зависимость lib/c -> lib/z -> some/bin, а не lib/c -> lib/lz4 -> lib/z -> some/bin https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/brotli/mix.sh - надстройка над либой для сборки brotli tools.
Все то же самое для кодеков для изображений, и для видео.
* Еще один пример, я про него уже рассказывал - mesa я собираю как реализацию opengl, и как драйвера для этой реализации. Набор флагов от бинаря опускается только для драйверов, и мы не имеем комбинаторного взрыва числа сборок гуишных библиотек от числа доступных драйверов в mesa.
Короче, мой поинт в том, что из штуки, которую я считал временной, пересборка в разных контекстах стала одной из основ моей пакетной базы.
У меня есть обширная тема про пересборку одного и того же набора исходников в разных контекстах.
Сегодня я поговорю про "хорошую", полезную пересборку, которая, так уж получилась, теперь составляет большой кусок модели моей пакетной базы.
А завтра поговорю про "плохую" пересборку. Да, про rust, и про go.
Пересборка одного и того же набора исходников в разных контекстах у меня происходит в следующих случаях:
* Самый простой случай - собрать один и тот же код с разным набором библиотек и опций.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/curl/t/mix.sh - вот библиотеки для обычного libcurl, https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/curl/lite/mix.sh - а вот для лайтовой версии.
Лайтовая версия используется в cmake, который используется в процессе сборки самого дистрибутива. Меньше зависимостей - меньше глубина дерева, проще bootstrap.
* Немного более сложный случай. Я уже пару раз рассказывал, что для эмуляции динамической линковки я завожу конструктор статического объекта, который заставляет влинковаться в программу нужные символы.
Проблема в том, что эти символы будут влинковываться всегда, у линкера не будет возможности выкинуть их.
А теперь представьте, что в поставке sway идет 2 программы - композитор, и cli для управления им. В моей модели получится, что, если не хачить систему сборки, драйвера и реализация opengl будут влинкованы в обе программы, хотя нужны только в одной.
Я решаю это так - собираю sway 2 раза, 1 раз с драйверами, и оставляю только бинарник композитора. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/compositor/mix.sh А заодно заменяю там аллокатор, да, и добавляю тред, который бы возвращал память в систему. И без драйверов, и со стандартным аллокатором - все остальное https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/tools/mix.sh
Финальный пакет со sway - это набор из нескольких пакетов. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/sway/mix.sh
Таких примеров довольно много. Ну, вот, Xpdf - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/xpdf/mix.sh Примерно по тем же соображениям.
* Еще более интересный случай.
Я уже как-то рассказывал, что у меня каждый пакет может быть собран в нескольких контекстах.
Для простоты скажу, что есть bin контекст - это когда от сборки пакета мы оставляем только бинари, и lib контекст - когда оставляем только библиотеки. Это прямо жестко и формально сделано - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/std/postinstall.sh#L29
Поэтому у меня есть гарантия, что от host тулзы во время сборки не приползет host же библиотека, или от target библиотеки не приползет левая target тулза, которая даже не запустится.
Оказалось, что делать немножко разную сборку для lib контекста и для bin контекста - очень удобно.
Это позволяет уменьшить высоту графа, и ускорить сборку(хотя суммарно работы будет сделано и больше).
Как?
Ну вот возьмем в качестве примера библиотеки компрессоров. У них у всех есть очень интересное свойство - все библиотеки зависят только от libc, а вот бинари зависят от всех остальных компрессоров, потому что все претендуюут на всеобъемлимость, и хотят быть точкой входа в компрессию.
Поэтому разделение на bin и на lib дает понятное уплощение графа. И убирает некоторые кольцевые ссылки, да. Код, который зависит от того или иного кодека имеет шансы начать собираться раньше, потому что зависимость lib/c -> lib/z -> some/bin, а не lib/c -> lib/lz4 -> lib/z -> some/bin https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/brotli/mix.sh - надстройка над либой для сборки brotli tools.
Все то же самое для кодеков для изображений, и для видео.
* Еще один пример, я про него уже рассказывал - mesa я собираю как реализацию opengl, и как драйвера для этой реализации. Набор флагов от бинаря опускается только для драйверов, и мы не имеем комбинаторного взрыва числа сборок гуишных библиотек от числа доступных драйверов в mesa.
Короче, мой поинт в том, что из штуки, которую я считал временной, пересборка в разных контекстах стала одной из основ моей пакетной базы.
🔥11👍1
Без этого свойства пакетная база была бы сильно другой, и существенно сложнее(потому что нужно было бы как-то делать, чтобы один и тот же артефакт годился в разных контекстах).
Некоторые исходники у меня пересобираются по 5 раз, а сколько раз пересобирается musl - я сбился со счету. И, да, по рассчетам, это стоит мне +10-20% gross CPU, потому что основные потребители(clang) собираются по 1 разу. Ну, то есть, совсем немного, а концептуальное упрощение прямо сильно заметно.
Почему я считаю эту тему важной и основополагающей?
Потому что эта штука реально определяет, как выглядят конечные пакеты для пользователя, и их внутреннее устройство. Потом поменять уже будет невозможно, это одно из тех решений, которые всерьез и надолго.
Некоторые исходники у меня пересобираются по 5 раз, а сколько раз пересобирается musl - я сбился со счету. И, да, по рассчетам, это стоит мне +10-20% gross CPU, потому что основные потребители(clang) собираются по 1 разу. Ну, то есть, совсем немного, а концептуальное упрощение прямо сильно заметно.
Почему я считаю эту тему важной и основополагающей?
Потому что эта штука реально определяет, как выглядят конечные пакеты для пользователя, и их внутреннее устройство. Потом поменять уже будет невозможно, это одно из тех решений, которые всерьез и надолго.
Давно не обращался к слушателям с просьбой поделиться ссылкой на канал где-нибудь, если нравится. Вот, обращаюсь!
"Не для славы, для забавы, я пишу" (с)
Кстати(сейчас уже трудно точно вспомнить, репу я без сохранения истории раза 2 менял), КМК, #Mix исполняется год на днях, я его начал то ли в прошлые майские, то ли немного раньше.
Надо бы собраться, и уже написать эту печальную историю про мои первые 2 попытки запилить свой дистрибутив. Да, #mix это уже третья попытка.
"Не для славы, для забавы, я пишу" (с)
Кстати(сейчас уже трудно точно вспомнить, репу я без сохранения истории раза 2 менял), КМК, #Mix исполняется год на днях, я его начал то ли в прошлые майские, то ли немного раньше.
Надо бы собраться, и уже написать эту печальную историю про мои первые 2 попытки запилить свой дистрибутив. Да, #mix это уже третья попытка.
👍16
Обещал написать про "плохую", негодную пересборку.
Речь, конечно, пойдет про Rust и про Go с точки зрения дистростроителя.
С точки зрения разработчика в Rust все устроено более-менее норм:
- повторные сборки кешируются
- по сути, нет никаких configure скриптов, поэтому граф выполнения очень "плотно" забивает многоядерную машину.
Короче, можно было бы и лучше, но и так неплохо.
С точки зрения мейнтейнера CI в дитсрибутиве, Rust - это тихий ужас:
* любой вменяемый CI отключит cargo cache. Потому что искать мигалки в сборке, особенно в чужом кеше - так себе идея.
* Проекты на Rust делают lock совершенно без оглядки друг на друга. Поэтому пересечение у двух случайно взятых проектов по подходящим артефактам будет нулевое.
* Даже если бы этих проблем и не было, то есть и такая проблема - cargo очень unfriendly к внешним системам. Вычленить из cargo сборки что-то подходящее для того или иного дистрибутива(либо сборку, либо скачку промежуточных результатов в виде урлов и команд для сборки) - работает плохо. Максимум, что у меня пока получилось - это составить список урлов на закачку, и подготовить из них папочку vendor. Про кеширование промежуточных результатов я уже и не говорю.
Поэтому получается, что в CI средний растопроект собирается довольно долго.
Но и это самое главное. Самое главное, что сборка среднего проекта в CI для Rust примерно в 100 раз дороже, чем сборка проекта, устроеного более конвенциональным образом. Почему в 100? Ну потому что известные мне растопроекты содержат > 100 зависимостей каждый.
А еще Rust любит LTO, да.
Поэтому получается так, что дистростроители прямо очень сильно не любят Rust:
* Дорого в CI. Прямо реально очень дорого!
* subtle problem - если линковать все нужное в 1 .so(как делает rsvg), то будет существенное дублирование кода между этими .so, что в dynlink мире не очень любят.
* Rust спустя рукава относится к своему bootstrap, а запускать произвольный код от васяна владельцы CI не любят.
Я для себя это решил так(ну, понятно, что пока до этого дело не дошло, но когда-нибудь дойдет):
* буду иметь сборочные таргеты для Rust в репозитории
* буду иметь bitcoin кошелек, куда фанбои могут сдавать донаты
Есть донаты - есть CI, нет - нет. TANSTAAFL!
Сразу будет давление, чтобы разработчики cargo уже повернулись лицом к дистростроителям.
А если этого не будет - ну так и останется cargo build для избранных, без возможности установки через репозиторий. Возможно, кто-то скажет "ну и ОК", но распространенным способом это явно не станет.
Я почти ничего не сказал про Go, потому что там ровно все то же самое. За одним исключением, что код на Go собирается очень быстро. Поэтому Go вызывает не такое сильное неприятие, а что-то вроде "meh".
Речь, конечно, пойдет про Rust и про Go с точки зрения дистростроителя.
С точки зрения разработчика в Rust все устроено более-менее норм:
- повторные сборки кешируются
- по сути, нет никаких configure скриптов, поэтому граф выполнения очень "плотно" забивает многоядерную машину.
Короче, можно было бы и лучше, но и так неплохо.
С точки зрения мейнтейнера CI в дитсрибутиве, Rust - это тихий ужас:
* любой вменяемый CI отключит cargo cache. Потому что искать мигалки в сборке, особенно в чужом кеше - так себе идея.
* Проекты на Rust делают lock совершенно без оглядки друг на друга. Поэтому пересечение у двух случайно взятых проектов по подходящим артефактам будет нулевое.
* Даже если бы этих проблем и не было, то есть и такая проблема - cargo очень unfriendly к внешним системам. Вычленить из cargo сборки что-то подходящее для того или иного дистрибутива(либо сборку, либо скачку промежуточных результатов в виде урлов и команд для сборки) - работает плохо. Максимум, что у меня пока получилось - это составить список урлов на закачку, и подготовить из них папочку vendor. Про кеширование промежуточных результатов я уже и не говорю.
Поэтому получается, что в CI средний растопроект собирается довольно долго.
Но и это самое главное. Самое главное, что сборка среднего проекта в CI для Rust примерно в 100 раз дороже, чем сборка проекта, устроеного более конвенциональным образом. Почему в 100? Ну потому что известные мне растопроекты содержат > 100 зависимостей каждый.
А еще Rust любит LTO, да.
Поэтому получается так, что дистростроители прямо очень сильно не любят Rust:
* Дорого в CI. Прямо реально очень дорого!
* subtle problem - если линковать все нужное в 1 .so(как делает rsvg), то будет существенное дублирование кода между этими .so, что в dynlink мире не очень любят.
* Rust спустя рукава относится к своему bootstrap, а запускать произвольный код от васяна владельцы CI не любят.
Я для себя это решил так(ну, понятно, что пока до этого дело не дошло, но когда-нибудь дойдет):
* буду иметь сборочные таргеты для Rust в репозитории
* буду иметь bitcoin кошелек, куда фанбои могут сдавать донаты
Есть донаты - есть CI, нет - нет. TANSTAAFL!
Сразу будет давление, чтобы разработчики cargo уже повернулись лицом к дистростроителям.
А если этого не будет - ну так и останется cargo build для избранных, без возможности установки через репозиторий. Возможно, кто-то скажет "ну и ОК", но распространенным способом это явно не станет.
Я почти ничего не сказал про Go, потому что там ровно все то же самое. За одним исключением, что код на Go собирается очень быстро. Поэтому Go вызывает не такое сильное неприятие, а что-то вроде "meh".
🔥11🤔3❤1
Красивое, без комментариев:
https://lenta.ru/news/2022/04/30/yandex/
https://www.opennet.ru/opennews/art.shtml?num=57111
———
https://www.ctrl.blog/entry/selinux-unmanageable.html
Я, как-то, писал текст про то, что чем дальше модель безопасности от рекурсивного разделения на "все можно" и "все нельзя", тем сложнее ей воспользоваться правильно, и очень высока вероятность багов.
Мне кажется, ссылка достаточно в тему. #sec_model
———
https://www.opennet.ru/opennews/art.shtml?num=57095
Paragon с декабря забила на поддержку NTFS в Linux. Интересно, это имеет отношение к происходящим сейчас событиям, или просто так совпало?
———
В моем уютном бложике вчера состоялась оживленная дискуссия(ажно о 300 комментариев) про подходы к распространению софта, почитайте, интересно.
———
украдено с lwn.net - https://lwn.net/Articles/892611/. sorry за копипасту, но текст за pay wall, а ситуация настолько прекрасна, что я не могу не поделиться:
Как обычно это бывает в большой монорепе, кто-то заимплементил что-то, что уже было(в похожем виде) в этой монорепе.
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
https://git.kernel.org/linus/3a161d99c43c
Дальше, конечно, драма, кто тут папа, и чей код, в итоге, должен победить, а чей надо переписать поверх старого.
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
"The conversations continued over a few different thread branches, and got somewhat adversarial in a few of them. #Kent Overstreet made it clear, with references to "not-invented-here syndrome" and such, that he was not pleased with the reception given to his code. It began to look like one of those threads that leads to the developer involved walking away from the kernel community altogether."
https://lenta.ru/news/2022/04/30/yandex/
https://www.opennet.ru/opennews/art.shtml?num=57111
———
https://www.ctrl.blog/entry/selinux-unmanageable.html
Я, как-то, писал текст про то, что чем дальше модель безопасности от рекурсивного разделения на "все можно" и "все нельзя", тем сложнее ей воспользоваться правильно, и очень высока вероятность багов.
Мне кажется, ссылка достаточно в тему. #sec_model
———
https://www.opennet.ru/opennews/art.shtml?num=57095
Paragon с декабря забила на поддержку NTFS в Linux. Интересно, это имеет отношение к происходящим сейчас событиям, или просто так совпало?
———
В моем уютном бложике вчера состоялась оживленная дискуссия(ажно о 300 комментариев) про подходы к распространению софта, почитайте, интересно.
———
украдено с lwn.net - https://lwn.net/Articles/892611/. sorry за копипасту, но текст за pay wall, а ситуация настолько прекрасна, что я не могу не поделиться:
Как обычно это бывает в большой монорепе, кто-то заимплементил что-то, что уже было(в похожем виде) в этой монорепе.
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
https://git.kernel.org/linus/3a161d99c43c
Дальше, конечно, драма, кто тут папа, и чей код, в итоге, должен победить, а чей надо переписать поверх старого.
https://lwn.net/ml/linux-kernel/[email protected]/
https://lwn.net/ml/linux-kernel/[email protected]/
"The conversations continued over a few different thread branches, and got somewhat adversarial in a few of them. #Kent Overstreet made it clear, with references to "not-invented-here syndrome" and such, that he was not pleased with the reception given to his code. It began to look like one of those threads that leads to the developer involved walking away from the kernel community altogether."
Lenta.RU
Дата-центр «Яндекса» в Финляндии отключили от электропитания
Дата-центр «Яндекса» в финском городе Мянтсяля был вынужден запустить резервные дизельные генераторы после отключения электропитания. Об этом сообщает РИА Новости со ссылкой на представителей самой компании. По его словам, даже несмотря на это, дата-центр…
👍4😁1
Недавно писал, что начал добавлять memory reclaim thread в user facing программы.
Столкнулся с красивым, внезапно упал sway, в месте, в котором падать несколько неожиданно:
Вот такой вот интересный side effect.
Еще у меня упала телега, где-то в глубинах видеодрайвера, но я не связываю это с реклеймером, а с криворукими разрабами #mesa. Блин, у меня при смене минорной версии с 22.0.1 на 22.0.2 наблюдаются баги рендеринга в некоторых приложениях.
Отмечу, что дебажить статически слинкованные приложения - это сказка. Вот написало тебе ядро в dmesg, что приложение упало по такому-то ip, то можно взять бинарь, и без секса с установкой правильных версий библиотек можно посмотреть, что лежит по этому ip. Так же очень доставляет отсутствие в коде plt, got, и прочей нечести - ассемблер начинает читаться, ну как С, ей-богу. Полустатически слинкованные приложения(все свое ношу с собой, кроме libc) таким свойством не обладают, к сожалению.
Раз заговорил про gdb, вот вам еще такой fun fact. Мои развлечения с objcopy не прошли совсем без последствий. Например, мне пришлось отключить деманглер в gdb. Ну вот потому, что, когда я добавляю "V2_" к символу "_Z..."(к любому C++ символу), ему становится плохо, и gdb падает. А иногда я по именам регулярочкой прохожусь, да...
Ну, и, раз у нас сегодня день стектрейсов и gdb, то вот вам в ленту корочка от qbittorrent, прямо на старте, падает в бустовом реакторе:
Качество opensource софта, конечно, вымораживает. Если за софтиной нет корпорации - пиши пропало.
Столкнулся с красивым, внезапно упал sway, в месте, в котором падать несколько неожиданно:
gdb) disassemble 0x0000000001e71b07Мое предположение, что sway содержит в себе use after free, и после добавления реклеймера он начал падать при обращении в эту область памяти(так как ее вернули в систему), вместо того, чтобы читать оттуда треш.
Dump of assembler code for function wl_list_remove:
0x0000000001e71b00 <+0>: mov (%rdi),%rax
0x0000000001e71b03 <+3>: mov 0x8(%rdi),%rcx
0x0000000001e71b07 <+7>: mov %rcx,0x8(%rax)
0x0000000001e71b0b <+11>: mov 0x8(%rdi),%rcx
0x0000000001e71b0f <+15>: mov %rax,(%rcx)
0x0000000001e71b12 <+18>: xorps %xmm0,%xmm0
0x0000000001e71b15 <+21>: movups %xmm0,(%rdi)
0x0000000001e71b18 <+24>: ret
End of assembler dump.
(gdb)
Вот такой вот интересный side effect.
Еще у меня упала телега, где-то в глубинах видеодрайвера, но я не связываю это с реклеймером, а с криворукими разрабами #mesa. Блин, у меня при смене минорной версии с 22.0.1 на 22.0.2 наблюдаются баги рендеринга в некоторых приложениях.
Отмечу, что дебажить статически слинкованные приложения - это сказка. Вот написало тебе ядро в dmesg, что приложение упало по такому-то ip, то можно взять бинарь, и без секса с установкой правильных версий библиотек можно посмотреть, что лежит по этому ip. Так же очень доставляет отсутствие в коде plt, got, и прочей нечести - ассемблер начинает читаться, ну как С, ей-богу. Полустатически слинкованные приложения(все свое ношу с собой, кроме libc) таким свойством не обладают, к сожалению.
Раз заговорил про gdb, вот вам еще такой fun fact. Мои развлечения с objcopy не прошли совсем без последствий. Например, мне пришлось отключить деманглер в gdb. Ну вот потому, что, когда я добавляю "V2_" к символу "_Z..."(к любому C++ символу), ему становится плохо, и gdb падает. А иногда я по именам регулярочкой прохожусь, да...
Ну, и, раз у нас сегодня день стектрейсов и gdb, то вот вам в ленту корочка от qbittorrent, прямо на старте, падает в бустовом реакторе:
Thread 5 "Network" hit Breakpoint 1, 0x0000000004176989 in abort ()какой-то free(0x1)
(gdb) bt
#0 0x0000000004176989 in abort ()
#1 0x000000000411fd75 in _ZN8tcmalloc3LogENS_7LogModeEPKciNS_7LogItemES3_S3_S3_ ()
#2 0x0000000004118613 in _ZN12_GLOBAL__N_111InvalidFreeEPv ()
#3 0x0000000004119a65 in _ZN12_GLOBAL__N_120free_null_or_invalidEPvPFvS0_E ()
#4 0x000000000419b2a5 in tc_free ()
#5 0x00000000026e21a7 in _ZN5boost4asio6detail11executor_opINS1_7binder0IZNK10libtorrent14session_handle10async_callIMNS4_3aux12session_implEFvNSt3__110shared_ptrINS4_9ip_filterEEEEJSC_EEEvT_DpOT0_EUlvE_EENS9_9allocatorIvEENS1_19scheduler_operationEE3ptr5resetEv ()
Качество opensource софта, конечно, вымораживает. Если за софтиной нет корпорации - пиши пропало.
👍7👎2
Я сегодня решил рассказать про свои любимые 5 минут перед сном.
Нет, это не то что ты подумал, извращуга, речь идет про обновление версий пакетов.
(а про то, про что вы все подумали, имею сказать, что xvideos не банят пользователей из России, это важно. Хотя, конечно, контент там не такой хороший, как на pornhub, чего уж тут)
Общался с владельцем repology, полнял, что пока не могу к нему встать, по техническим причинам.
repology предполагает, что мейнтейнеры проектов сами нормализуют название пакета и версию.
Я-то думал, что достаточно будет сгрузить используемые урлы, а нормализованных версий и названий у меня нет.
Если подумать, то вокруг этого есть понятная экономика - мейнтейнеры заинтересованы в том, чтобы их труд был заметен на github, а владельцы кода заинтересованы в том, чтобы быть как в можно большем числе дистрибутивов. Поэтому оно работает и так, но мне не очень подходит.
Договорился с владельцем, что он мне запилит API, которая будет возвращать все апдейты за сутки, а я уже буду их просматривать, и апдейтить версии по необходимости.
Апдейтов OSS софта за день происходит 500 - 700, интересных мне - 5.
Я решил, что, раз работаю в поисковой компании, мне не западло решить эту задачу самому.
Вот мой скрипт - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo
Что он делает?
* Парсит все тексты описаний сборок на предмет урлов к исходникам
* Парсит пути к описаниям сборок(в путях часто тоже лежит кусок названия пакета)
* Строит по этому барахлу n-граммы
* После чего для каждого входа типа "freetype 2.11.1", он строит n-граммы, котоыре ищет в списке всех n-грамм.
* Если пересечение достаточно большое, то надо показать этот пакет, он есть у меня в базе.
Интересное, конечно, в деталях
* n == 4. Почему? А я почем знаю, дает наилучший для меня результат
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo#L58 - общий 4-граммный индекс содержит только уникальные граммы. Возьмем, например, название "linux-headers". Понятно, что все, что про linux, и про headers по отдельности - оно будет дублироваться 100 раз, и совершенно бесполезно. А вот 'x-hea' встретится 1 раз, и это полезная информация.
* помимо названия пакета, в индекс и в текст для поиска полезно добавлять еще и версию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo#L88
Почему? Потому что версия чаще всего изменяется не очень сильно, и в текстах 'freetype2110', 'freetype2111' 4-граммы вида 'pe21'(и прочие) дают много информации.
Список того, что надо обновить за сегодня, отфильтровано из нескольких сот записей:
Если честно, сегодня просто особенно хорошо, алгоритм требует еще докруток и доработок, но и сейчас уже полезен.
(за скобками остался exact match, который тоже полезен, можно найти его в коде скрипта)
Нет, это не то что ты подумал, извращуга, речь идет про обновление версий пакетов.
(а про то, про что вы все подумали, имею сказать, что xvideos не банят пользователей из России, это важно. Хотя, конечно, контент там не такой хороший, как на pornhub, чего уж тут)
Общался с владельцем repology, полнял, что пока не могу к нему встать, по техническим причинам.
repology предполагает, что мейнтейнеры проектов сами нормализуют название пакета и версию.
Я-то думал, что достаточно будет сгрузить используемые урлы, а нормализованных версий и названий у меня нет.
Если подумать, то вокруг этого есть понятная экономика - мейнтейнеры заинтересованы в том, чтобы их труд был заметен на github, а владельцы кода заинтересованы в том, чтобы быть как в можно большем числе дистрибутивов. Поэтому оно работает и так, но мне не очень подходит.
Договорился с владельцем, что он мне запилит API, которая будет возвращать все апдейты за сутки, а я уже буду их просматривать, и апдейтить версии по необходимости.
Апдейтов OSS софта за день происходит 500 - 700, интересных мне - 5.
Я решил, что, раз работаю в поисковой компании, мне не западло решить эту задачу самому.
Вот мой скрипт - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo
Что он делает?
* Парсит все тексты описаний сборок на предмет урлов к исходникам
* Парсит пути к описаниям сборок(в путях часто тоже лежит кусок названия пакета)
* Строит по этому барахлу n-граммы
* После чего для каждого входа типа "freetype 2.11.1", он строит n-граммы, котоыре ищет в списке всех n-грамм.
* Если пересечение достаточно большое, то надо показать этот пакет, он есть у меня в базе.
Интересное, конечно, в деталях
* n == 4. Почему? А я почем знаю, дает наилучший для меня результат
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo#L58 - общий 4-граммный индекс содержит только уникальные граммы. Возьмем, например, название "linux-headers". Понятно, что все, что про linux, и про headers по отдельности - оно будет дублироваться 100 раз, и совершенно бесполезно. А вот 'x-hea' встретится 1 раз, и это полезная информация.
* помимо названия пакета, в индекс и в текст для поиска полезно добавлять еще и версию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/scripts/repo#L88
Почему? Потому что версия чаще всего изменяется не очень сильно, и в текстах 'freetype2110', 'freetype2111' 4-граммы вида 'pe21'(и прочие) дают много информации.
Список того, что надо обновить за сегодня, отфильтровано из нескольких сот записей:
libxml2 2.9.14Что называется, в яблочко, папа еще умеет в данные!
fuse 3.11.0
htop 3.2.0
vim 8.2.4854
gdb 12.1
fcft 3.1.1
Если честно, сегодня просто особенно хорошо, алгоритм требует еще докруток и доработок, но и сейчас уже полезен.
(за скобками остался exact match, который тоже полезен, можно найти его в коде скрипта)
🔥8😁4👍2
Я тут решил, что мне нужно собрать какой-нить медиаплеер. Не то чтобы я очень много чего с компа смотрю, но так, на всякий случай.
Конечно, я решил начать с https://mplayerhq.hu/design7/news.html, сайт я набрал по памяти, без поиска.
Mplayer - это знаковая программа в истории Linux:
* Первое время ее развитие было неразрывно связано с ffmpeg
* Это была одна из немногих программ, про которые я мог однозначно сказать "оно работает лучше, чем любая альтернатива в Windows". Интересно, в виндах все еще такой же секс с кодеками?
Для меня так же важным было то, что Mplayer легко бутстрапается. Я тогда использовал LFS(со своим пакетным менеджером, да), и раз в какое-то время мне нужно было провести пару дней за полной пересборкой софта, смотря в черный linux framebuffer, а Mplayer работал даже в нем.
Какое-то время назад я перестал следить за судьбой проекта, в том числе, потому что перешел на macOS, вот, сейчас восстановил для себя картинку.
Mplayer, судя по всему, загнулся, хотя какие-то релизы все еще бывают. Например, запустить воспроизведение без цепочки с X11 у меня получилось только через opengl context = (sdl1 -> sdl2 -> waylang -> egl), если вы понимаете, о чем я.
После чего от него отщепился mplayer2, а от него уже современный mpv, который просто божественен.
Mpv, конечно, очень современный, вовсю использует vulkan/opengl/шейдеры.
(кстати, пока не забыл, давно хотел поинтересоваться - а почему нет generic декодеров на шейдерах, зачем каждый вендор клепает свои расширения для этого?)
В процессе его сборки узнал много интересного, спешу поделиться:
* Разработчик mpv имеет мысли про весь open source AV stack, и не боится это мнение записывать. Это мне, конечно, очень импонирует. https://github.com/mpv-player/mpv/wiki/FAQ Мне особенно зашли пассажи про качество софта у Apple, качество дрйверов от Intel, и про Nvidia.
* Самая мякотка - чтобы, во время просмотра, экран не чернел, есть специальный протокол в Wayland. https://github.com/mpv-player/mpv/wiki/FAQ#i-use-gnome-wayland-and-i-have-xyz-problem
Там я разжился ссылкой на очередной эпичный тред "GNOME против всех":
https://gitlab.gnome.org/GNOME/mutter/-/issues/20
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/111
#GNOME, как обычно, в своем репертуаре - 3 года мурыжат разработчиков, только в данном случае не отказывают явно. Ну прост не мержат PR, бывает.
* mpv умеет расширяться через mujs. Я сам предпочитаю lua, но, как говорится, все для любимых пользователей. Но тут случилась какая-то засада - я добавил зависимость от lib/mu/js, а waf скрипт от mpv никак не мог найти нужную зависимость.
TL;DR - сборка mujs писала в mujs.pc "Version: src" вместо "Version: 1.2.0", и mpv думал, что версия неподходящая.
Я не стал разбираться, почему у меня так вышло, если со всем таким разбираться, поседеть можно. Пофиксил по рабоче-крестьянски - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mu/js/mix.sh#L26
Такие мелкие фиксы, кстати, частое дело. Вот, например, readline считает, что всегда собирается с termcap, даже когда его собрать с terminfo/curses, а потом autoconf скрипты его не находят, потому что ошибка линковки - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/readline/mix.sh#L28
Конечно, я решил начать с https://mplayerhq.hu/design7/news.html, сайт я набрал по памяти, без поиска.
Mplayer - это знаковая программа в истории Linux:
* Первое время ее развитие было неразрывно связано с ffmpeg
* Это была одна из немногих программ, про которые я мог однозначно сказать "оно работает лучше, чем любая альтернатива в Windows". Интересно, в виндах все еще такой же секс с кодеками?
Для меня так же важным было то, что Mplayer легко бутстрапается. Я тогда использовал LFS(со своим пакетным менеджером, да), и раз в какое-то время мне нужно было провести пару дней за полной пересборкой софта, смотря в черный linux framebuffer, а Mplayer работал даже в нем.
Какое-то время назад я перестал следить за судьбой проекта, в том числе, потому что перешел на macOS, вот, сейчас восстановил для себя картинку.
Mplayer, судя по всему, загнулся, хотя какие-то релизы все еще бывают. Например, запустить воспроизведение без цепочки с X11 у меня получилось только через opengl context = (sdl1 -> sdl2 -> waylang -> egl), если вы понимаете, о чем я.
После чего от него отщепился mplayer2, а от него уже современный mpv, который просто божественен.
Mpv, конечно, очень современный, вовсю использует vulkan/opengl/шейдеры.
(кстати, пока не забыл, давно хотел поинтересоваться - а почему нет generic декодеров на шейдерах, зачем каждый вендор клепает свои расширения для этого?)
В процессе его сборки узнал много интересного, спешу поделиться:
* Разработчик mpv имеет мысли про весь open source AV stack, и не боится это мнение записывать. Это мне, конечно, очень импонирует. https://github.com/mpv-player/mpv/wiki/FAQ Мне особенно зашли пассажи про качество софта у Apple, качество дрйверов от Intel, и про Nvidia.
* Самая мякотка - чтобы, во время просмотра, экран не чернел, есть специальный протокол в Wayland. https://github.com/mpv-player/mpv/wiki/FAQ#i-use-gnome-wayland-and-i-have-xyz-problem
Там я разжился ссылкой на очередной эпичный тред "GNOME против всех":
https://gitlab.gnome.org/GNOME/mutter/-/issues/20
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/111
#GNOME, как обычно, в своем репертуаре - 3 года мурыжат разработчиков, только в данном случае не отказывают явно. Ну прост не мержат PR, бывает.
* mpv умеет расширяться через mujs. Я сам предпочитаю lua, но, как говорится, все для любимых пользователей. Но тут случилась какая-то засада - я добавил зависимость от lib/mu/js, а waf скрипт от mpv никак не мог найти нужную зависимость.
TL;DR - сборка mujs писала в mujs.pc "Version: src" вместо "Version: 1.2.0", и mpv думал, что версия неподходящая.
Я не стал разбираться, почему у меня так вышло, если со всем таким разбираться, поседеть можно. Пофиксил по рабоче-крестьянски - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mu/js/mix.sh#L26
Такие мелкие фиксы, кстати, частое дело. Вот, например, readline считает, что всегда собирается с termcap, даже когда его собрать с terminfo/curses, а потом autoconf скрипты его не находят, потому что ошибка линковки - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/readline/mix.sh#L28
GitHub
FAQ
🎥 Command line video player. Contribute to mpv-player/mpv development by creating an account on GitHub.
👍10
Про подход к performance.
Perf - это состояние души :) Это не то, что ты делаешь иногда, время от времени, это штука, которая стоит рядом с тобой, когда ты пишешь каждую строчку кода, или продумываешь каждое архитектурное решение.
Удаление большого числа файлов - достаточно медленная операция. Причем в сборке ее нужно выполнять довольно часто - удалять старые артефакты, удалять тысячи временных файлов и исходников.
Более конкретно, я возьму mix gc, эта операция удаляет все ранее собранные артефакты, если они более не достижимы от корня. Фактически, это всякое старье, более не нужное в системе. Если вспомнить, что в mix/nix/guix content addressable storage, и сравнить это с git, станет примерно понятно, о чем идет речь.
За месяц таких артефактов может накопиться много, особенно если заниматься разработкой пакетного менеджера. Речь идет про десятки(может, даже сотни) миллионов файлов и каталогов.
Скажем, время mix gc под macOS у меня легко могло достигать часа, потому что на маках ну очень уж неповоротливая FS. Под Linux скажу аккуратно - минуты и десятки минут.
А так как perf - это состояние души, эта тема мне не давала покоя. В конце-концов, сумрачный гений родил следующее решение:
* Операции, которые раньше делали rm -rf /some/folder, теперь просто делают mv /some/folder /mix/trash/$RANDOM
* В системе есть cron job, который регулярно и асинхронно очищает /mix/trash/*, в щадящем режиме.
Время mix gc сократилось до секунд, ну и сама сборка тоже ускорилась, ввиду https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/sh.sh#L21 , аккуратно расставленного в нужных местах.
———
Совсем короткая тема, wayland, ненависть.
Разработчики wayland - сумасшедшие. Они решили, что, если приложение выходит, то все записи от него в clipboard надо стереть.
Я не смотрел, как это реализовано технически, как минимум, можно предположить два способа:
* после закрытия окна композитор может инициировать очистку clipboard для id этого окна.
* clipboard физически может храниться распределенно, в памяти приложений, а в общее место приложения публикуют только id элемента.
(если знаете, как, расскажите, интересно)
Если об этом факте не знать, и если ты не работаешь в DE, которая это все за тебя настроила, это, конечно, очень доставляет.
Perf - это состояние души :) Это не то, что ты делаешь иногда, время от времени, это штука, которая стоит рядом с тобой, когда ты пишешь каждую строчку кода, или продумываешь каждое архитектурное решение.
Удаление большого числа файлов - достаточно медленная операция. Причем в сборке ее нужно выполнять довольно часто - удалять старые артефакты, удалять тысячи временных файлов и исходников.
Более конкретно, я возьму mix gc, эта операция удаляет все ранее собранные артефакты, если они более не достижимы от корня. Фактически, это всякое старье, более не нужное в системе. Если вспомнить, что в mix/nix/guix content addressable storage, и сравнить это с git, станет примерно понятно, о чем идет речь.
За месяц таких артефактов может накопиться много, особенно если заниматься разработкой пакетного менеджера. Речь идет про десятки(может, даже сотни) миллионов файлов и каталогов.
Скажем, время mix gc под macOS у меня легко могло достигать часа, потому что на маках ну очень уж неповоротливая FS. Под Linux скажу аккуратно - минуты и десятки минут.
А так как perf - это состояние души, эта тема мне не давала покоя. В конце-концов, сумрачный гений родил следующее решение:
* Операции, которые раньше делали rm -rf /some/folder, теперь просто делают mv /some/folder /mix/trash/$RANDOM
* В системе есть cron job, который регулярно и асинхронно очищает /mix/trash/*, в щадящем режиме.
Время mix gc сократилось до секунд, ну и сама сборка тоже ускорилась, ввиду https://git.sr.ht/~pg/mix/tree/main/item/pkgs/mix/sh.sh#L21 , аккуратно расставленного в нужных местах.
———
Совсем короткая тема, wayland, ненависть.
Разработчики wayland - сумасшедшие. Они решили, что, если приложение выходит, то все записи от него в clipboard надо стереть.
Я не смотрел, как это реализовано технически, как минимум, можно предположить два способа:
* после закрытия окна композитор может инициировать очистку clipboard для id этого окна.
* clipboard физически может храниться распределенно, в памяти приложений, а в общее место приложения публикуют только id элемента.
(если знаете, как, расскажите, интересно)
Если об этом факте не знать, и если ты не работаешь в DE, которая это все за тебя настроила, это, конечно, очень доставляет.
👍11
https://www.opennet.ru/opennews/art.shtml?num=57131 #cve
Уязвимость и уязвимость, но подход коллег к уязвимостям доставляет:
"В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества."
Я, как ни странно, считаю, что это очень разумный подход. Денег не платите - DIY.
———
Две новости про Rust:
https://www.opennet.ru/opennews/art.shtml?num=57133 - кусок clamav переписали на subj.
https://www.phoronix.com/scan.php?page=news_item&px=System76-Scheduler-1.1 - насколько я понимаю, это деятельность одного из авторов redox, какие-то патчи для шедулера Linux, тоже на Rust. Патчи для меня интересные, потому что про desktop responsivenress.
https://github.com/pop-os/system76-scheduler
Я, честно, пока не нашел там ядерного кода, пока я там вижу только более красивую версию своего shell скрипта по настройке приоритетов для известных типов процессов, через d-bus.
Короче, школота беснуется, фанбои довольны.
———
Продолжая вчерашнюю тему про wayland clipboard.
Есть такой проект, https://github.com/bugaevc/wl-clipboard, с двумя cli тулзами:
wl-paste, она позволяет или напечатать содержимое clipboard на stdin, или запустить обработчик на поступления новых сообщений в буфер обмена. Скажем, wl-paste -w cat просто печатает новые сообщения на экран.
wl-copy копирует stdin в clipboard. (На самом деле, технически, запускает фоновый процесс, который держит это сообщение, пока оно нужно)
Удобно?
Казалось бы, запусти себе wl-paste -w wl-copy, и ты получишь персистентный clipboard в wayland?
Какое там, команда приводит к 100% потреблению CPU, потому что wl-copy не проверяет, что в clipboard лежит то же самое, что мы хотим положить, и мы получаем бесконечный цикл.
Уверен, что такую команду составляет каждый первый пользователь этого пакета, и, странно, что она не работает.
Наверняка какое-нить очередное ЧСВ у автора, я пока не разбирался.
Так же доставляет тот факт, что тулза пытается делать временные файлы прямо в /tmp.
TMPDIR? XDG_RUNTIME_DIR? Не, не слышали.
Уязвимость и уязвимость, но подход коллег к уязвимостям доставляет:
"В марте была попытка отдельно связаться с сопровождающим проект uClibc-ng, но он ответил, что не в состоянии исправить уязвимость самостоятельно и рекомендовал публично раскрыть информацию о проблеме, рассчитывая получить помощь в разработке исправления от сообщества."
Я, как ни странно, считаю, что это очень разумный подход. Денег не платите - DIY.
———
Две новости про Rust:
https://www.opennet.ru/opennews/art.shtml?num=57133 - кусок clamav переписали на subj.
https://www.phoronix.com/scan.php?page=news_item&px=System76-Scheduler-1.1 - насколько я понимаю, это деятельность одного из авторов redox, какие-то патчи для шедулера Linux, тоже на Rust. Патчи для меня интересные, потому что про desktop responsivenress.
https://github.com/pop-os/system76-scheduler
Я, честно, пока не нашел там ядерного кода, пока я там вижу только более красивую версию своего shell скрипта по настройке приоритетов для известных типов процессов, через d-bus.
Короче, школота беснуется, фанбои довольны.
———
Продолжая вчерашнюю тему про wayland clipboard.
Есть такой проект, https://github.com/bugaevc/wl-clipboard, с двумя cli тулзами:
wl-paste, она позволяет или напечатать содержимое clipboard на stdin, или запустить обработчик на поступления новых сообщений в буфер обмена. Скажем, wl-paste -w cat просто печатает новые сообщения на экран.
wl-copy копирует stdin в clipboard. (На самом деле, технически, запускает фоновый процесс, который держит это сообщение, пока оно нужно)
Удобно?
Казалось бы, запусти себе wl-paste -w wl-copy, и ты получишь персистентный clipboard в wayland?
Какое там, команда приводит к 100% потреблению CPU, потому что wl-copy не проверяет, что в clipboard лежит то же самое, что мы хотим положить, и мы получаем бесконечный цикл.
Уверен, что такую команду составляет каждый первый пользователь этого пакета, и, странно, что она не работает.
Наверняка какое-нить очередное ЧСВ у автора, я пока не разбирался.
Так же доставляет тот факт, что тулза пытается делать временные файлы прямо в /tmp.
TMPDIR? XDG_RUNTIME_DIR? Не, не слышали.
www.opennet.ru
Уязвимость в uClibc и uClibc-ng, позволяющая подменить данные в кэше DNS
В стандартных Си-библиотеках uClibc и uClibc-ng, применяемых во многих встраиваемых и портативных устройствах, выявлена уязвимость (CVE не присвоен), позволяющая подставить фиктивные данные в кэш DNS, что можно использовать для подмены в кэше IP-адреса произвольного…
👍6
Q: Антон, почему тебе так не нравится Rust? #школота
A: Мне Rust очень нравится, у меня даже в планах написать на нем пару программ для Mix, не очень сложных, как раз для того, чтобы въехать:
* process supervisor, для выставления nice, ionice, приоритетов, rt scheduler, блокировок, subreaper, управления логами, и так далее. Сейчас это все сделано разными тулзами, поэтому в системе неоптимальное число процессов(subreaper отдельно, flock отдельно).
* graph executor, для пакетного менеджера. Сейчас это питонячка, не очень красиво.
Мешает мне только то, что Rust не работает в статическом окружении, и я раз в пару недель трачу вечер выходного дня, чтобы это как-то починить:
* mrustc. К сожалению, ничего, кроме Rust он собрать не может.
* docker образ с компилятором и glibc. На крайний вариант, сложно, пока не делал.
* запилить сборку glibc + patchelf на бинари с Rust.
Меня в Rust бесит:
* community. Школота и фанбои. Настолько бесит, что лезть туда не хочется.
* Хайп вокруг. Знаете, каждый язык, наверное, должен пройти статию "гля, еба, мы написали ядро на X". С это прошел когда, в 72-73 году? С++ в 80-ых? Читать об этом интересно, находиться в моменте - как получается, не очень.
Хайп бесит потому, что мешает отделять зерна от плевел. Каждую новость про Rust или очереднуюперемогу перписывание чего-то на Rust надо пропускать через сито, как вот с шедулером PopOS.
———
Больше всего на свете я люблю, когда пакет содержит в себе 2 или больше систем сборок.
Казалось бы, авторы подумали вообще обо всем, даже об этом?
Какое там:
* А чем собирается проект в своей CI? Какая из систем сборок наиболее поддерживаема?
* Часто результат не совпадает! Бывает, что cmake сборка не ставит .pc файлы, а #autohell/Makefile ставят. Или вот сегодняшний пример, от чего меня и взбугуртнуло-то - nlohmann-json при сборке через meson не ставит ${out}/lib/cmake/* файлы, и потом cmake проекты не могут его автоматически подхватить.
Короче, не делайте несколько систем сборок, сделайте одну, нормально, и поддерживаемо.
Отдельно, конечно, хочется сказать большое человеческое "спасибо"(нет) авторам cmake, за изобретение lib/cmake/*.cmake для автоконфигурации, это на порядок хуже простых .pc файлов, и ломается на каждый чих.
A: Мне Rust очень нравится, у меня даже в планах написать на нем пару программ для Mix, не очень сложных, как раз для того, чтобы въехать:
* process supervisor, для выставления nice, ionice, приоритетов, rt scheduler, блокировок, subreaper, управления логами, и так далее. Сейчас это все сделано разными тулзами, поэтому в системе неоптимальное число процессов(subreaper отдельно, flock отдельно).
* graph executor, для пакетного менеджера. Сейчас это питонячка, не очень красиво.
Мешает мне только то, что Rust не работает в статическом окружении, и я раз в пару недель трачу вечер выходного дня, чтобы это как-то починить:
* mrustc. К сожалению, ничего, кроме Rust он собрать не может.
* docker образ с компилятором и glibc. На крайний вариант, сложно, пока не делал.
* запилить сборку glibc + patchelf на бинари с Rust.
Меня в Rust бесит:
* community. Школота и фанбои. Настолько бесит, что лезть туда не хочется.
* Хайп вокруг. Знаете, каждый язык, наверное, должен пройти статию "гля, еба, мы написали ядро на X". С это прошел когда, в 72-73 году? С++ в 80-ых? Читать об этом интересно, находиться в моменте - как получается, не очень.
Хайп бесит потому, что мешает отделять зерна от плевел. Каждую новость про Rust или очередную
———
Больше всего на свете я люблю, когда пакет содержит в себе 2 или больше систем сборок.
Казалось бы, авторы подумали вообще обо всем, даже об этом?
Какое там:
* А чем собирается проект в своей CI? Какая из систем сборок наиболее поддерживаема?
* Часто результат не совпадает! Бывает, что cmake сборка не ставит .pc файлы, а #autohell/Makefile ставят. Или вот сегодняшний пример, от чего меня и взбугуртнуло-то - nlohmann-json при сборке через meson не ставит ${out}/lib/cmake/* файлы, и потом cmake проекты не могут его автоматически подхватить.
Короче, не делайте несколько систем сборок, сделайте одну, нормально, и поддерживаемо.
Отдельно, конечно, хочется сказать большое человеческое "спасибо"(нет) авторам cmake, за изобретение lib/cmake/*.cmake для автоконфигурации, это на порядок хуже простых .pc файлов, и ломается на каждый чих.
🔥9👍4👎2🤔1
История одного бутстрапа.
Знаете, есть такие программы, собираешь их, и думаешь - "кто-то наверняка берет деньги за их сборку", потому что нафига так все усложнять?
Собирал я себе transmission-gtk, потому что Netflix все, приходится молодость вспоминать. Из новых зависимостей, которые приехали с ним:
* libdht, https://github.com/jech/dht/blob/master/Makefile - нет таргета сборки библиотеки, только вспомогательная программа. Библиотеку, типа, собирай сам.
* libutp - https://github.com/bittorrent/libutp У библиотеки нет ни релизов, ни стабильных тегов. Очень, очень надежный код, бери любой снепшот, используй.
* libminiupnpc - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mini/upnpc/mix.sh#L6 Сломан Makefile, патч я взял у arch linux.
* libnatpmp - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/natpmp/mix.sh#L18 Какая-то срань вместо общеупотребимого PREFIX, промахнулся мимо директории, если вы понимаете, о чем я(кстати, все же знают, какой сегодня день?)
Мораль? Понятия не имею, наверное, просто не повезло.
———
Обновил gcc на 12.1 - https://www.opennet.ru/opennews/art.shtml?num=57145
Немного опасался за ядро Linux, потому что
"При использовании уровня оптимизации "-O2" по умолчанию включено применение векторизации (включены режимы -ftree-vectorize и -fvect-cost-model=very-cheap). Модель "very-cheap" допускает векторизацию только если векторный код может полностью заменить векторизируемый скалярный код."
Но все обошлось.
Так же пересобрал телегу с ним, потому что cadaverсс это весело, но не очень промышленно.
g++ код телеги прожевал, а вот код libc++ отказался, потому что у них несовпадение во взглядах на стандарт, g++ теперь считает, что нельзя анонимную структуру наследовать.
Полез в trunk llvm, чтобы показать, а там уже починили - https://github.com/llvm/llvm-project/blob/main/libcxx/include/string#L692
Было
https://git.sr.ht/~pg/mix/commit/230cc30d5dce6cfd94e66acbff9db84c52b213df
Особенно классный хак был про precompiled headers, чтобы один и тот же Makefile работал и для clang, и для gcc, я по нему проходился sed'ом.
Знаете, есть такие программы, собираешь их, и думаешь - "кто-то наверняка берет деньги за их сборку", потому что нафига так все усложнять?
Собирал я себе transmission-gtk, потому что Netflix все, приходится молодость вспоминать. Из новых зависимостей, которые приехали с ним:
* libdht, https://github.com/jech/dht/blob/master/Makefile - нет таргета сборки библиотеки, только вспомогательная программа. Библиотеку, типа, собирай сам.
* libutp - https://github.com/bittorrent/libutp У библиотеки нет ни релизов, ни стабильных тегов. Очень, очень надежный код, бери любой снепшот, используй.
make: *** No rule to make target 'install'. Stop- нет install таргета.
* libminiupnpc - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/mini/upnpc/mix.sh#L6 Сломан Makefile, патч я взял у arch linux.
* libnatpmp - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/natpmp/mix.sh#L18 Какая-то срань вместо общеупотребимого PREFIX, промахнулся мимо директории, если вы понимаете, о чем я(кстати, все же знают, какой сегодня день?)
Мораль? Понятия не имею, наверное, просто не повезло.
———
Обновил gcc на 12.1 - https://www.opennet.ru/opennews/art.shtml?num=57145
Немного опасался за ядро Linux, потому что
"При использовании уровня оптимизации "-O2" по умолчанию включено применение векторизации (включены режимы -ftree-vectorize и -fvect-cost-model=very-cheap). Модель "very-cheap" допускает векторизацию только если векторный код может полностью заменить векторизируемый скалярный код."
Но все обошлось.
Так же пересобрал телегу с ним, потому что cadaverсс это весело, но не очень промышленно.
g++ код телеги прожевал, а вот код libc++ отказался, потому что у них несовпадение во взглядах на стандарт, g++ теперь считает, что нельзя анонимную структуру наследовать.
Полез в trunk llvm, чтобы показать, а там уже починили - https://github.com/llvm/llvm-project/blob/main/libcxx/include/string#L692
Было
struct: __padding<value_type> {
unsigned char __size_;
};
Я отменил alternative layout для std::string, телега собралась, убрал кучу хаков.https://git.sr.ht/~pg/mix/commit/230cc30d5dce6cfd94e66acbff9db84c52b213df
Особенно классный хак был про precompiled headers, чтобы один и тот же Makefile работал и для clang, и для gcc, я по нему проходился sed'ом.
GitHub
dht/Makefile at master · jech/dht
BitTorrent DHT library. Contribute to jech/dht development by creating an account on GitHub.
🔥5👍1😁1
Так, надо же рассказывать не только все хорошее, но и все плохое?
Известный факт, что люди не любят рассказывать про неудачи, но, IMHO, это тоже полезно и интересно.
У меня тут случился FAIL эпических масштабов.
Я уже рассказывал, что у меня каждый пакет может быть собран в двух контекстах - в lib, и в bin, и что во время шаблонизации сборочного файла текущий контекст можно узнавать как "if lib", "if bin".
Это не очень удобно, замусоривает логику сборки, поэтому я завел себе несколько новых видов блоков. Для примера:
env, кстати, содержит в себе указания вида
Все было бы хорошо, но у меня остался 1 шаблон, в котором я оставил только "block env", и не разделил его на "block env_lib", "block env_bin".
Это привело к тому, что некоторые цели перестали экспортировать флаги компилятора на свои зависимости, потому что "block env_lib" был no-op в этом шаблоне.
И, конкретно, это привело к тому, что у меня весь код какое-то время собирался с дефолтными флагами оптимизатора.
Потому что набор оптимизаций - это просто подключаемые цели, которые экспортируют определенный env:
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/build/opt
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/build/opt/mix.sh
К счастью, это означало, что код собирался в -O2, без -g, и без -DNDEBUG(главное отличие), то есть, с ассертами.
Ну и по мелочи, типа, отключилась сборка промышленного компилятора с LTO.
Это, конечно, неприятно, но, к сожалению, не настолько фатально, чтобы было заметно невооруженному взгляду.
Как нашел? Собрал программулю для дебага с флагами —opt=O0 —buildtype=debug, а там не было отладочной информации.
fun fact - за время жизни с такими флагами у меня появилась библиотека, сломанная с "-O2 -DNDEBUG" - конкретно, openssl 1 и 3. Бисектом сейчас такое ловить уже сложно, я виню в этом обновление clang. Пока я в openssl просто поставил более слабую оптимизацию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/openssl/t/mix.sh#L25
Такие дела.
Известный факт, что люди не любят рассказывать про неудачи, но, IMHO, это тоже полезно и интересно.
У меня тут случился FAIL эпических масштабов.
Я уже рассказывал, что у меня каждый пакет может быть собран в двух контекстах - в lib, и в bin, и что во время шаблонизации сборочного файла текущий контекст можно узнавать как "if lib", "if bin".
Это не очень удобно, замусоривает логику сборки, поэтому я завел себе несколько новых видов блоков. Для примера:
{% block env_lib %}...
эквивалентен(не буду вдаваться в технические подробности){% if lib %}
{% block env %}...
Я взял, и во всем поддереве lib/ заменил sed'ом "block env" на "block env_lib", с простой целью - чтобы, когда этот таргет собирается в bin контексте, этот env не выставлялся.env, кстати, содержит в себе указания вида
export CPPFLAGS="-I${out}/include \${CPPFLAGS}"
или, например:export CFLAGS="-O2 -g \${CFLAGS}"
Понятно, зачем такое нужно в библиотеке, и почему это не нужно при сборки библиотеки в bin контексте?Все было бы хорошо, но у меня остался 1 шаблон, в котором я оставил только "block env", и не разделил его на "block env_lib", "block env_bin".
Это привело к тому, что некоторые цели перестали экспортировать флаги компилятора на свои зависимости, потому что "block env_lib" был no-op в этом шаблоне.
И, конкретно, это привело к тому, что у меня весь код какое-то время собирался с дефолтными флагами оптимизатора.
Потому что набор оптимизаций - это просто подключаемые цели, которые экспортируют определенный env:
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/build/opt
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/build/opt/mix.sh
К счастью, это означало, что код собирался в -O2, без -g, и без -DNDEBUG(главное отличие), то есть, с ассертами.
Ну и по мелочи, типа, отключилась сборка промышленного компилятора с LTO.
Это, конечно, неприятно, но, к сожалению, не настолько фатально, чтобы было заметно невооруженному взгляду.
Как нашел? Собрал программулю для дебага с флагами —opt=O0 —buildtype=debug, а там не было отладочной информации.
fun fact - за время жизни с такими флагами у меня появилась библиотека, сломанная с "-O2 -DNDEBUG" - конкретно, openssl 1 и 3. Бисектом сейчас такое ловить уже сложно, я виню в этом обновление clang. Пока я в openssl просто поставил более слабую оптимизацию. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/openssl/t/mix.sh#L25
Такие дела.
🔥5👍3