https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1835439173

#harfbuzz

Вот, кто-то еще заметил, что там цикл уже существенно больше, чем просто hb <-> freetype.

Понятное дело, что ничего там не произойдет, потому что никто, кроме его работодателей, повлиять на разработчика harfbuzz не может. А им, очевидно, похуй, пока он исправно проталкивает нужные изменения в downstream дистрибутивов.

https://github.com/yandex/yatool

#я_просто_оставлю_это_здесь, #what_a_day_to_be_alive, #джва_года_ждал
#yatool

(пересоздал с КДПВ)

https://www.opennet.ru/opennews/art.shtml?num=60206
https://hacks.mozilla.org/2023/11/introducing-llamafile/

Портабельная запускалка моделек (это хайп), один бинарь может работать на нескольких OS/arch (а вот это вот интересная часть)!

Самое первое известное мне невасянское использования cosmopolitan libc от #justine https://justine.lol/cosmopolitan/

Мне идея cosmopolitan не очень нравится, потому что это хак, в плохом смысле этого слова. Индустрии нужно что-то такое, но я бы хотел видеть в этом месте #WASM, или что-то подобное.

Ну и как я когда-то подметил, Justine катится на волне хайпа от ML.

Будни #bootstrap

Вышла новая тележенька, обновился сразу на 4.12.2.

Не знаю, чего там нового, все собралось без новых патчей, но, что интересно, коллеги перешли на scudo - https://github.com/desktop-app/cmake_helpers/tree/92f27add11ae4280939079249d0f9da933ece6ad/external/scudo https://llvm.org/docs/ScudoHardenedAllocator.html

Это такой hardened allocator, раньше развивался в составе Android, потом перешел под крыло LLVM.

Интересно, зачем.

В прошлом тележенька оптимизировала memory pressure, и им было важно, чтобы память, после пиков потребления, быстро возвращалась в систему.

Я, когда подбирал аллокатор для тележеньки, остановился на #tcmalloc, потому что, хоть он и чуть медленнее возвращал память в систему, то общий memory footprint у него был лучше.

Scudo я тоже тестировал, ничем интересным он тогда себя не проявил.

Полагаю, что коллег задолбало искать проезды в проде, и вот, отсюда scudo.

Техдир выдал каждому девопсу по будильнику, который синхронизирован с критическими алертами на продакшене

Programmer memes

Будни #bootstrap, #cross, #rant

Вот, запилил какую-то поддержку Windows, для cross сборок. И сразу добавил в свой CI - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/mingw/w64/ix.sh

С помощью родных sdk пока не стал делать, запилил в https://www.mingw-w64.org/ target.

#MinGW - это очень странная крича, которая одновременно решает следующие задачи:

* Околоавтоматически сгенерить заголовки для всех доступных виндовых API, в виде, понятному gcc/clang

* Долить в стандартную C библиотеку от винды (msvcrt, и да, я знаю про ucrt, но msvcrt есть под любую винду) какое-то количество unix-измов, которое можно добавить без расширения runtime самих Windows (короче, без fork(), но с pthreads)

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

Мое отношение к винде, с точки зрения ее поддержки в своем инструментарии, можно сформулировать так:

* С одной стороны, windows - довольно всратая самобытная платформа, не-Unix, во всем смыслах этого слова.
Поэтому поддержать ее как один из таргетов - интересная техническая задача, которую можно пытаться решить кучей разных способов, что доставляет само по себе. Ну вот вам, например, пара проектов, которые решают запуск MSVC тулчейнов через wine - https://github.com/yandex/yatool/blob/main/build/scripts/run_msvc_wine.py (моего изначального авторства, кстати, особенно доставляет, что туда добавлены ретраи, без этого никак), https://github.com/eruffaldi/wine_vcpp, https://github.com/mstorsjo/msvc-wine. Тысячи их.

* С другой - у меня есть сильное внутреннее нежелание это делать.

Почему?

Потому что Microsoft, в данном случае, негодяи и пидарасы!

Они специально сделали свои OS отличными от Unix там, где это вообще возможно, в рамках своей политики EEE. Очень классно - ты контролируешь значительную часть рынка, и делаешь свои API не совместимыми ни с чем, чтобы софт с твоей OS было запредельно дорого пртировать в другие OS. Это, кстати, довольно разумное бизнес решение так-то.

Но, зато, теперь, когда Windows утрачивает лидирующие позиции, я с удовольствием смотрю, как ей приходится заигрывать с Unix (тот же WSL), чтобы их OS, как среда разработки, продолжала бы иметь какой-то смысл. Без WSL, и без тулинга, который он предоставляет, разработка под винду - тихий ужас.

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

(Еще раз, повторю, что это было правильное в моменте решение, которое позволило MS стать теми, кто они есть, а не еще одним провайдером еще одного Unix, кстати, где они? Но любви и желания пилить что-то "под" это не добавляет).

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

Пилить поддержку винды как host платформы - да боже упаси, ни в жисть.

https://registry.khronos.org/EGL/extensions/ANDROID/EGL_ANDROID_blob_cache.txt

А вот, кстати, кеширование шейдеров здорового человека. Нормальный протокол для регистрации своего key/value хранилища, можно хоть memcached прикрутить.

Вот бы в #mesa его начали использовать консистентно, а я бы прикрутил mamcached, или там redis? С активацией через dbus, чтобы не висело постоянно.

Мечты, мечты...

Я ору, и не могу остановиться. #harfbuzz

Как обычно, решил влезть в дискуссию, и сказал, что так-то есть дофига способов разорвать эту circular dep, было бы желание - https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1837576427

На что я получил кучу ожидаемой чепухи про ABI, https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1839281781

И, самая мякотка:

"That's a more feasible solution IMO. @lemzwerg would you be open to dlopening libharfbuzz? If not, we might consider it on our side"

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

АААА!!!

#llvmweekly

https://discourse.llvm.org/t/if-llvm-is-so-slow-is-anything-being-done-about-it/75389

Какой-то тролль 80lvl пришел в LLVM, и спросил, знают ли они, что downstream проекты имеют планы по отказу от LLVM, потому что он тормозит? Так-то норм подкат, потому что простой "знаете ли вы, что LLVM тормозит" привел бы к "знаем, и чо?".

На что ему ответили, что так-то LLVM стал на 20% быстрее за последние пару лет, и показали классные графики - https://llvm-compile-time-tracker.com/graphs.php?startDate=2021-02-04&interval=100&relative=on

Мало, мало.

Хочется, чтобы как в go, но "While compile times are a concern, runtime performance of compiled programs is still paramount"

Еще интересных цитат: "OK that makes sense. The Free Pascal compiler said LLVM (which they support too) is 10-15% faster (execution) than their own code generator but they pay for it in terms of compile times" + "In my own testing comparing it to the Free Pascal Compiler it appears to be 3x slower (without optimizations). I must say that’s pretty bad considering how FPC is just a hobby project"

На мой взгляд, это очень показательно - 15% перфа в runtime получается за счет в разы более тормозного codegen. Да, да, pascal это вам не С++ с кучей шаблонов, but still.

Будни #bootstrap

Я, как вы знаете, пристально слежу за потоком обновления разных там библиотек и программ, тех, что у меня есть (для upver), и всех остальных - чтобы подсмотреть, есть ли чем еще поживиться в oss мире.

(использую для этого замечательный https://repology.org, всех благ автору и долгих лет, но это сейчас не важно)

Вот, глаз зацепился за https://qtpass.org/

Менеджер паролей поверх pass.

На сайте у них написано:

"Insecure Password Generation prior to 1.2.1

All passwords generated with QtPass' built-in password generator prior to 1.2.1 are possibly predictable and enumerable by hackers.
The generator used libc's random(), seeded with srand(msecs), where msecs is not the msecs since 1970 (not that that'd be secure anyway), but rather the msecs since the last second. This means there are only 1000 different sequences of generated passwords"

С одной стороны, хорошо, что не пытаются приуменьшить масштаб трагедии.

С другой - ну твою-то мать, "This means there are only 1000 different sequences of generated passwords", ну как вообще такое можно использовать?

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

https://youtu.be/_qaKkHuHYE0?si=u0nHEWKgKasWAUyW
Забавный доклад, автор рассказывает про то как не получилось. Кстати спустя какое-то время код совсем удалили: https://github.com/google/tcmalloc/commit/42555acdab2ece45233bcbdade24ad03987a24bb

Что ещё более забавно, после была попытка в не lock-free ring buffer cache, оно какое-то время поюзалось, но в итоге стек всех пережил
https://github.com/google/tcmalloc/commit/26d81c3707283d341966945fba428e1eab287eaa

Вот есть такой проект - mingw32, https://ru.wikipedia.org/wiki/MinGW (а у него вообще остался оф. сайт?)

Есть его spin off, https://www.mingw-w64.org/, который появился, чтобы дозапилить новые (в том числе, 64-битные), API, появившиеся в Windows. Проект MinGW сам по себе загнулся, и, сейчас, когда вы ссылаетесь к MinGW, вы, на самом деле, ссылаетесь на mingw-w64.

Как вы думаете, как выглядит gnu triplet (это указание target и host, в том формате, в котором его хотят gnu-тые тулзы)?

Очень просто!

https://learn.microsoft.com/en-us/vcpkg/users/platforms/mingw

x86_64-w64-mingw32
i686-w64-mingw32
...

В общем, довольно очевидно - "gnu_arch-gnu_vendor-gnu_os" - https://www.gnu.org/software/autoconf/manual/autoconf-2.65/html_node/Specifying-Target-Triplets.html. Вот для поля vendor сократили mingw-w64 до w64, потому что '-' мешала парсировать это поле, ну и потому что а почему бы и нет?

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

А дальше начинается самое интересное!

Многие проекты (и я, в том числе), решили обозвать "x86_64-w64-mingw32" как mingw64, а "i686-w64-mingw32
" - как mingw32.

Логично? Логично!

Удобно? Удобно!

Но зато, теперь, когда указываешь --target=mingw64, то проверка на gnu_os в моих скриптах выглядит вот так:

{% if mingw32 %}
...
{% endif %}

Потому что gnu_os - это именно MinGW32, как отсылка к изначальному проекту.

Мораль? Да нет ее, боже упаси.

Продолжаю рассказ про #MinGW #windows

Пожалуй, самая дичайшая дичь, с которой я столкнулся, это то, что #GNU #autohell позволяет настроить расширение для собранной статической библиотеки.

Настройка эта доступна не тому, кто запускает готовый configure, а запрятана где-то глубоко в настройках libtool/libtoolize (не спрашивайте, всратые гнутые скрипты, призванные облегчить линковку динамических библиотек под разные платформы). И, что самое удивительное, мейнтейнеры этой настройкой активно пользовались - у кого-то это lib, а у кого-то - a.

Поэтому я не могу пойти и параметризировать свои обвязки этим расширением, потому что его надо настраивать per project, а потом переделывать кучу моих скриптов, которые везде (до этого времени), полагали, что работают с .a файлами.

Я сделал несколько подходов к снаряду:

* Попробовал руками запатчить все проекты, чтобы свести все к .a файлам. Быстро задолбался и прекратил.

* Попробовал указать в качестве libtool стороннюю реализацию - https://github.com/midipix-project/slibtool Это работало удивительно хорошо, кроме тех случаев, когда не работало вовсе. Ну, например, у libtool есть режим "перелинковки" программ при их установке (наверное, для систем, в которых нет rpath). Зачем этот режим иногда срабатывал в случае статлинковки - неизвестно. Как отключить - неизвестно. А сторонняя реализация (совершенно справедливо!) это говно мамонта не поддерживает.

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

Комбинация 2) и 3) позволила вообще не патчить исходные сборочные скрипты, и обойтись настройкой того, какой libtool использовать в проекте.