Красивое, без комментариев:
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
https://www.phoronix.com/scan.php?page=news_item&px=Apple-M1-Gallium3D-glmark2
baby steps для Mesa на Apple M1. Удивительно, но что-то уже начинает работать.
———
https://www.phoronix.com/forums/forum/software/desktop-linux/1322382-system76-releases-v1-1-scheduler-for-optimizing-linux-desktop-laptop-responsiveness #ananicy
Наткнулся на красивое, пока читал про new rust popos scheduler.
Конерктено - на https://gitlab.com/ananicy-cpp/ananicy-cpp.
Это с++ вариант моего скриптеца, который выставляет приоритеты и тип шедулера для процессов системы.
С++, event-driven(то есть, не пересканирует каждый раз дерево процессов, красота).
Конечно, я решил выкинуть свой скрипт нахер, и заменить его на эту программулю.
Программуля - простая, как 5 копеек. Загружает 100 json, в которых для определенных названий процесса есть настройки nice, ionice, scheduler, etc.
Но намучался я с ней, что пиздец.
* Автор настаивает, что его код надо всегда собирать с -fsanitize=undefined. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L46 Товарищи, вот в тот момент, когда я написал workaround для фикса этого "ценного мнения", я уже понял, что мне предстоит интересный вечер. Очень редко когда у коллеги есть ценное мнение по одному такому поводу, и нет ценного мнения на любой другой вопрос.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L49 - автор расставил nodiscard почем зря, а вот проверить, что оно работает хотя бы в clang - нет, не проверил.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L75 - очень вольно обходимся с включением заголовков. Настолько вольно, что я не стал патчить исходники, и, наконец-то, разобрался, как в clang включить какой-нибудь заголовок везде, принудительно.
* Коллега считает, что очень хорошо знает С++(нет), поэтому везде использует самые последние фичи. Но он, типа, позаботился о тех, у кого компилятор не позволяет последние фичи, и написал пару библиотек-оберток.
https://gitlab.com/ananicy-cpp/stl-polyfills
Если stl-format просто прокcирует std::format -> fmt::format, то с stl-jthread я намучался.
В какой-то момент я понял, что коллега просто не осилил написать работающий код, и забил на это дело. https://gitlab.com/ananicy-cpp/stl-polyfills/std-jthread/-/blob/master/src/stop_source.cpp#L24 - вот тут неустранимый segfault.
Но я не отчаялся, и просто заменил std::jthread на "new std::thread". Ну, да, утечет 2 треда, не столь важно для демона.
(#reboot Минутка мудрости от старого меня - не пытайтесь написать корректный graceful shutdown, просто пишите exit(0) по месту. Все равно оно никогда верно работать не будет, только замучаетесь чинить)
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L58
* на musl это никто никогда не собирал, в Alpine пакетов нет https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L79
Оно скомпилировалось, и даже заработало - выставило правильный nice процессам.
А вот выставить тип шедулера у нее не получилось, с ошибкой ENOSYS.
Знаете, я, когда гуглил вот это вот - https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 уже знал, что столкнусь с особым ценным мнением Ричарда Фелкера(автора musl). И, конечно, я не ошибся.
Он пишет, что Linux не может posixly correct выполнить эту задачу, поэтому мы вернем ENOSYS.
На этом я уже взвыл, место начало казаться таки проклятым.
Но решил не сдаваться.
Сначала я попробовал собрать связку uclibc-ng + libc++, так как в uclibc эта функция реализована ожидаемым способом. Но так не вышло, потому что в uclibc какая-то не такая поддержка локалей.
В итоге, реализовал syscall сам - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/gnushim/sched.c, и, кстати, нашел ошибку в коммите от Фелкера, https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getschedparam.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2 , там лишний & у param. Пппц, коммитят, вообще не проверяя свой говнокод.
Оно завелось, работает, 2 треда утекают, ну и хрен с ними. Отдельный вопрос, зачем в этой программе вообще треды.
baby steps для Mesa на Apple M1. Удивительно, но что-то уже начинает работать.
———
https://www.phoronix.com/forums/forum/software/desktop-linux/1322382-system76-releases-v1-1-scheduler-for-optimizing-linux-desktop-laptop-responsiveness #ananicy
Наткнулся на красивое, пока читал про new rust popos scheduler.
Конерктено - на https://gitlab.com/ananicy-cpp/ananicy-cpp.
Это с++ вариант моего скриптеца, который выставляет приоритеты и тип шедулера для процессов системы.
С++, event-driven(то есть, не пересканирует каждый раз дерево процессов, красота).
Конечно, я решил выкинуть свой скрипт нахер, и заменить его на эту программулю.
Программуля - простая, как 5 копеек. Загружает 100 json, в которых для определенных названий процесса есть настройки nice, ionice, scheduler, etc.
Но намучался я с ней, что пиздец.
* Автор настаивает, что его код надо всегда собирать с -fsanitize=undefined. https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L46 Товарищи, вот в тот момент, когда я написал workaround для фикса этого "ценного мнения", я уже понял, что мне предстоит интересный вечер. Очень редко когда у коллеги есть ценное мнение по одному такому поводу, и нет ценного мнения на любой другой вопрос.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L49 - автор расставил nodiscard почем зря, а вот проверить, что оно работает хотя бы в clang - нет, не проверил.
* https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L75 - очень вольно обходимся с включением заголовков. Настолько вольно, что я не стал патчить исходники, и, наконец-то, разобрался, как в clang включить какой-нибудь заголовок везде, принудительно.
* Коллега считает, что очень хорошо знает С++(нет), поэтому везде использует самые последние фичи. Но он, типа, позаботился о тех, у кого компилятор не позволяет последние фичи, и написал пару библиотек-оберток.
https://gitlab.com/ananicy-cpp/stl-polyfills
Если stl-format просто прокcирует std::format -> fmt::format, то с stl-jthread я намучался.
В какой-то момент я понял, что коллега просто не осилил написать работающий код, и забил на это дело. https://gitlab.com/ananicy-cpp/stl-polyfills/std-jthread/-/blob/master/src/stop_source.cpp#L24 - вот тут неустранимый segfault.
Но я не отчаялся, и просто заменил std::jthread на "new std::thread". Ну, да, утечет 2 треда, не столь важно для демона.
(#reboot Минутка мудрости от старого меня - не пытайтесь написать корректный graceful shutdown, просто пишите exit(0) по месту. Все равно оно никогда верно работать не будет, только замучаетесь чинить)
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L58
* на musl это никто никогда не собирал, в Alpine пакетов нет https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/ananicy/cpp/mix.sh#L79
Оно скомпилировалось, и даже заработало - выставило правильный nice процессам.
А вот выставить тип шедулера у нее не получилось, с ошибкой ENOSYS.
Знаете, я, когда гуглил вот это вот - https://git.musl-libc.org/cgit/musl/commit/?id=1e21e78bf7a5 уже знал, что столкнусь с особым ценным мнением Ричарда Фелкера(автора musl). И, конечно, я не ошибся.
Он пишет, что Linux не может posixly correct выполнить эту задачу, поэтому мы вернем ENOSYS.
На этом я уже взвыл, место начало казаться таки проклятым.
Но решил не сдаваться.
Сначала я попробовал собрать связку uclibc-ng + libc++, так как в uclibc эта функция реализована ожидаемым способом. Но так не вышло, потому что в uclibc какая-то не такая поддержка локалей.
В итоге, реализовал syscall сам - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/gnushim/sched.c, и, кстати, нашел ошибку в коммите от Фелкера, https://git.musl-libc.org/cgit/musl/tree/src/thread/pthread_getschedparam.c?id=1e21e78bf7a5c24c217446d8760be7b7188711c2 , там лишний & у param. Пппц, коммитят, вообще не проверяя свой говнокод.
Оно завелось, работает, 2 треда утекают, ну и хрен с ними. Отдельный вопрос, зачем в этой программе вообще треды.
Phoronix
Apple M1 Mesa Code Begins To Run glmark2
While the Apple M1 Linux support is off to a great start and using Asahi Linux is offering good CPU performance and most functionality working to at least some degree, the biggest blocker remaining is getting the Apple M1 3D graphics working
🔥19👍2
До последнего времени у меня не было weak зависимостей, потому что я нутром чую, что вот эти вот "provides xyz" - это одна из упячнейших упячек пакетных менеджеров.
Я долго думал, как эту фичу сделать так, чтобы оно было относительно привычным людям, но не казалось мне всратым по сути своей.
У меня есть механизм для "рихтовки напильником" получающихся #realm. Каждый пакет может положить в папочку ${out}/fix/ какой-нибудь sh-скрипт, который система дернет при построении realm, содержащего этот пакет. Для чего это нужно:
* Некоторые пути мы знаем только в момент формирования #realm - например, путь к WebProcess для webkit браузеров.
* xdg пути. Это набор путей для широкого круга задач - для поиска шрифтов, иконок, тем курсоров, и так далее. Они не известны на момент построения пакета, который будет использовать эти assets.
* glib xml schemas. Не спрашивайте.
В итоге, я пока сделал, что weak-зависимость - это тест на наличие того или иного файла в получающимся realm.
Ну вот, реально, кладем в fix/ файлик check-xdg-open.sh, в котором написано
Если при сборке нового realm такой пакет не будет указан, будет понятная ошибка сборки, с указанием, как это починить.
Дальше, конечно, Остапа понесло, потому что получился очень "широкий" механизм.
Например, как проверить, что пользователь установил нужный шрифт в realm?
Не нужно выдумывать новую иерархию фиктивных пакетов, достаточно просто дернуть fc-list, или что-то похожее, и посмотреть, есть ли подходящий ответ. В рамках вычислительной ноды, подготоваливающей этот realm.
Идею хуков в fix/ я подглядел в nixos, творчески ее переработав.
Выглядит это примерно так:
* это тест, как я люблю
* этот тест проверяет ровно то свойство, что нужно, не больше, и не меньше
* никаких "мамой клянусь, мой пакет реализует спецификацию xdg-open!"
* нового механизма нет, а нужная функция выполняется. Это особенно ценнО, стараюсь держать свой toolbox небольшим.
Я долго думал, как эту фичу сделать так, чтобы оно было относительно привычным людям, но не казалось мне всратым по сути своей.
У меня есть механизм для "рихтовки напильником" получающихся #realm. Каждый пакет может положить в папочку ${out}/fix/ какой-нибудь sh-скрипт, который система дернет при построении realm, содержащего этот пакет. Для чего это нужно:
* Некоторые пути мы знаем только в момент формирования #realm - например, путь к WebProcess для webkit браузеров.
* xdg пути. Это набор путей для широкого круга задач - для поиска шрифтов, иконок, тем курсоров, и так далее. Они не известны на момент построения пакета, который будет использовать эти assets.
* glib xml schemas. Не спрашивайте.
В итоге, я пока сделал, что weak-зависимость - это тест на наличие того или иного файла в получающимся realm.
Ну вот, реально, кладем в fix/ файлик check-xdg-open.sh, в котором написано
test -f bin/xdg-openА дельше уже задача пользователя выбрать ту или иную реалзиацию xdg-open, подходящую его нуждам.
Если при сборке нового realm такой пакет не будет указан, будет понятная ошибка сборки, с указанием, как это починить.
Дальше, конечно, Остапа понесло, потому что получился очень "широкий" механизм.
Например, как проверить, что пользователь установил нужный шрифт в realm?
Не нужно выдумывать новую иерархию фиктивных пакетов, достаточно просто дернуть fc-list, или что-то похожее, и посмотреть, есть ли подходящий ответ. В рамках вычислительной ноды, подготоваливающей этот realm.
Идею хуков в fix/ я подглядел в nixos, творчески ее переработав.
Выглядит это примерно так:
ENTER /mix/store/NObQBw2XIB4XeIFG-rlm-guiЧем больше я про это думаю, тем больше мне нравится моя реализация:
+ test -d fix
+ read l
+ find fix/ -name *.sh
+ sh fix/wrap-xdg-transmission-gtk.sh
+ read l
+ sh fix/check-bin-xdg-open.sh
can not find bin/xdg-open, install
providing package into realm
* это тест, как я люблю
* этот тест проверяет ровно то свойство, что нужно, не больше, и не меньше
* никаких "мамой клянусь, мой пакет реализует спецификацию xdg-open!"
* нового механизма нет, а нужная функция выполняется. Это особенно ценнО, стараюсь держать свой toolbox небольшим.
🔥10👍2
#vendor
Забыл тогда написать про еще одну важную причину заниматься де-вендорингом.
Завендоренный код, чаще всего, собирается просто не так, так мне(или другому мейнтейнеру) нужно.
Происходит это в силу того, что просто очень сложно прокинуть весь ворох необходимых настроек от корня до проектов второго и ниже уровней. Поэтому они будут собираться "как-то", а именно, как позвал cmake/meson/etc оунер проекта первого уровня.
Ну, вот, например, если оунер проекта предполагает динамические связывание, то он и cmake для завендоренного проекта позовет с настройками для динамического связывания.
Переопределить это поведение на самом верхнем уровне или очень сложно, или совсем невозможно.
Если сделать де-вендоринг, то каждый проект будет собираться в том окружении, которое предполагает мейнтейнер, и всякие такие штуки(например, в моем случае - тип связывания) довольно легко переопределить.
Примеры таких свойств, помимо типа связывания - оконная система(X11/Wayland/both), аудио стек, и так далее.
В той же телеге пришлось патчить значительный объем сборочных файлов, чтобы X11 был не нужен даже для сборки(напомню, у меня wayland only), ну и pipewire было не очень просто выкорчевать.
———
https://www.opennet.ru/opennews/art.shtml?num=57165
Как бы я ее не любил, Fedora - это локомотив развития десктопного Linux, поэтому решения, принятые в рамках ее развития, важны.
* fedora окончательно переходит на wayland, даже с дровами от nvidia. Это хорошо, свистопляски вокруг X11 vs. Wayland порядком надоели. Wayland, конечно, не сахар, но X11 это же вообще тихий ужас.
* #fontconfig писал как-то про выбор дефолтного шрифта для mix(выбор, фактически, у меня был между noto и ibm flex). Fedora переходит на Noto с Dejavu, и это прямо очень, очень хорошо.
* "В исполняемые файлы и библиотеки в формате ELF добавлена информация о том, к какому rpm-пакету принадлежит данный файл" Интересно, как скоро они придут к модели macos, где, по умолчанию, неподписанный external код запускать вообще нельзя.
*Судя по списку пакетов, некоторые из которых literally вышли неделю назад, fedora - это прямо bleeding edge, КМК, они даже перестают притворяться, что туда попадает хоть как-то оттестированный код.
———
https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html #vendor #npm
В crates.io попал вредонос.
crates ничем не лучше в этом отношении, чем pypi или npm, или любой другой per language repo, ничего удивительного в этом нет.
Чтобы там не было вредоносов, нужно, чтобы у оунеров этих проектов был соответствующий KPI, и, очевидно, его у них нет. Ответственности они за это перед пользователями не несут.
Это все всем давно известно, и никому не интересно.
Я предлагаю подумать вот про какую мысль - мейнтейнеры дистрибутивов, это, ко всему прочему, еще и фильтры вот такого вот говна.
Я для каждого пакета, который кладу в дистрибутив, ищу его дубликаты, нахожу обязательно "оригинал". КМК, мимо меня вот такой вредонос не прошел бы.
И вторая мысль - дистрибутив гораздо легче сменить, чем язык, и чем его экосистему, поэтому мейнтейнеры дистрибутивов гораздо более заинтересованы в поддержании своего реноме, чем условный crates.io.
Забыл тогда написать про еще одну важную причину заниматься де-вендорингом.
Завендоренный код, чаще всего, собирается просто не так, так мне(или другому мейнтейнеру) нужно.
Происходит это в силу того, что просто очень сложно прокинуть весь ворох необходимых настроек от корня до проектов второго и ниже уровней. Поэтому они будут собираться "как-то", а именно, как позвал cmake/meson/etc оунер проекта первого уровня.
Ну, вот, например, если оунер проекта предполагает динамические связывание, то он и cmake для завендоренного проекта позовет с настройками для динамического связывания.
Переопределить это поведение на самом верхнем уровне или очень сложно, или совсем невозможно.
Если сделать де-вендоринг, то каждый проект будет собираться в том окружении, которое предполагает мейнтейнер, и всякие такие штуки(например, в моем случае - тип связывания) довольно легко переопределить.
Примеры таких свойств, помимо типа связывания - оконная система(X11/Wayland/both), аудио стек, и так далее.
В той же телеге пришлось патчить значительный объем сборочных файлов, чтобы X11 был не нужен даже для сборки(напомню, у меня wayland only), ну и pipewire было не очень просто выкорчевать.
———
https://www.opennet.ru/opennews/art.shtml?num=57165
Как бы я ее не любил, Fedora - это локомотив развития десктопного Linux, поэтому решения, принятые в рамках ее развития, важны.
* fedora окончательно переходит на wayland, даже с дровами от nvidia. Это хорошо, свистопляски вокруг X11 vs. Wayland порядком надоели. Wayland, конечно, не сахар, но X11 это же вообще тихий ужас.
* #fontconfig писал как-то про выбор дефолтного шрифта для mix(выбор, фактически, у меня был между noto и ibm flex). Fedora переходит на Noto с Dejavu, и это прямо очень, очень хорошо.
* "В исполняемые файлы и библиотеки в формате ELF добавлена информация о том, к какому rpm-пакету принадлежит данный файл" Интересно, как скоро они придут к модели macos, где, по умолчанию, неподписанный external код запускать вообще нельзя.
*Судя по списку пакетов, некоторые из которых literally вышли неделю назад, fedora - это прямо bleeding edge, КМК, они даже перестают притворяться, что туда попадает хоть как-то оттестированный код.
———
https://blog.rust-lang.org/2022/05/10/malicious-crate-rustdecimal.html #vendor #npm
В crates.io попал вредонос.
crates ничем не лучше в этом отношении, чем pypi или npm, или любой другой per language repo, ничего удивительного в этом нет.
Чтобы там не было вредоносов, нужно, чтобы у оунеров этих проектов был соответствующий KPI, и, очевидно, его у них нет. Ответственности они за это перед пользователями не несут.
Это все всем давно известно, и никому не интересно.
Я предлагаю подумать вот про какую мысль - мейнтейнеры дистрибутивов, это, ко всему прочему, еще и фильтры вот такого вот говна.
Я для каждого пакета, который кладу в дистрибутив, ищу его дубликаты, нахожу обязательно "оригинал". КМК, мимо меня вот такой вредонос не прошел бы.
И вторая мысль - дистрибутив гораздо легче сменить, чем язык, и чем его экосистему, поэтому мейнтейнеры дистрибутивов гораздо более заинтересованы в поддержании своего реноме, чем условный crates.io.
www.opennet.ru
Релиз дистрибутива Fedora Linux 36
Представлен релиз дистрибутива Fedora Linux 36. Для загрузки подготовлены продукты Fedora Workstation, Fedora Server, CoreOS, Fedora IoT Edition и Live-сборки, поставляемые в форме спинов c десктоп-окружениями KDE Plasma 5, Xfce, MATE, Cinnamon, LXDE и LXQt.…
👍12
https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1
Я вот только не вижу исходники их opengl, компилятора шейдеров, и так далее.
Прикольно, но мало, систему на этом пока не построить.
Очень интересно, имеет ли к этому отношение давешний хак нвидии.
Я думаю, как минимум, это хорошо продвинет nouveau(напомню, что одна их основных(и нерешаемых ранее) их проблем - power management).
Я вот только не вижу исходники их opengl, компилятора шейдеров, и так далее.
Прикольно, но мало, систему на этом пока не построить.
Очень интересно, имеет ли к этому отношение давешний хак нвидии.
Я думаю, как минимум, это хорошо продвинет nouveau(напомню, что одна их основных(и нерешаемых ранее) их проблем - power management).
Phoronix
NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver
The day has finally come: NVIDIA IS PUBLISHING THEIR LINUX GPU KERNEL MODULES AS OPEN-SOURCE! To much excitement and a sign of the times, the embargo has just expired on this super-exciting milestone that many of us have been hoping to see for many years.
🔥6😁1🤔1
Нашел на просторах интернета красивое.
https://github.com/jasperla/openbsd-wip/issues/86
О судьбе форка firefox Pale Moon в OpenBSD.
TL;DR - коллеги, с точки зрения оунеров Pale Moon, криво портировали браузер, и поэтому не имеют права на официальную символику Pale Moon.
В комментарии пришел, натурально, БОЕВОЙ ДАЛЕК, и сказал, что все должны obey его rules, и obey его license. Exterminate!
Реально, я совсем не утрирую:
"You must comply with the directive or you must disable official branding for your builds."
Тред фееричный, прочитайте обязательно.
———
https://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Забавный текст про историю /bin, /sbin/, /usr/bin, /usr/sbin, /opt, /usr/local в unix.
В #mix есть только /bin, которая symlink на /mix/realm/system/bin, и /usr -> /. Потому что очень много скриптов полагается на наличие /usr/bin/env, и менять это дорого.
Кстати, в этом месте у меня довольно серьезное отличие от nix и guix, если я все верно понял.
nix, guix стараются прописать конкретные пути к выполняемым бинарям(это верно? поправьте, если я неверно понял), а я объединяю наборы пакетов в realm, и замыкаю их PATH на bin/ в этом realm. Получается, можно собрать разные realm, в которых один и тот же пакет взаимодействует с другим внешним окружением.
Cамое простое, можно набор скриптов запустить с coreutils, а можно с busybox. Или с разными версиями интерпретатора python.
Мне кажется, так более composable.
———
Короткое дополнение ко вчерашней теме, #vendor, #npm
То, как устроены per language repo, не помогает мейнтейнерам решать задачу по фильтрации всякого вредного говна.
Схема с мейнтейнерами работает, когда мейнтейнеров мало, они trusted, и дорожат своей репутацией. Если мейнтейнеров много, то они точно так же untrusted, как и оунеры кода, и увеличение числа причастных к процессу людей только увеличивает вероятность факапа.
Если мейнтейнеров мало, то они не могут делать аудит кода, когда каждый проект зависит от своего, уникального, набора версий. Слишком большой объем работы на одного человека.
Нужен какой-то компромисс, чтобы те же crates.io/npm/pypi составляли рекомендуемый набор версий, чтобы его можно было относительно легко аудировать внешними силами.
https://github.com/jasperla/openbsd-wip/issues/86
О судьбе форка firefox Pale Moon в OpenBSD.
TL;DR - коллеги, с точки зрения оунеров Pale Moon, криво портировали браузер, и поэтому не имеют права на официальную символику Pale Moon.
В комментарии пришел, натурально, БОЕВОЙ ДАЛЕК, и сказал, что все должны obey его rules, и obey его license. Exterminate!
Реально, я совсем не утрирую:
"You must comply with the directive or you must disable official branding for your builds."
Тред фееричный, прочитайте обязательно.
———
https://lists.busybox.net/pipermail/busybox/2010-December/074114.html
Забавный текст про историю /bin, /sbin/, /usr/bin, /usr/sbin, /opt, /usr/local в unix.
В #mix есть только /bin, которая symlink на /mix/realm/system/bin, и /usr -> /. Потому что очень много скриптов полагается на наличие /usr/bin/env, и менять это дорого.
Кстати, в этом месте у меня довольно серьезное отличие от nix и guix, если я все верно понял.
nix, guix стараются прописать конкретные пути к выполняемым бинарям(это верно? поправьте, если я неверно понял), а я объединяю наборы пакетов в realm, и замыкаю их PATH на bin/ в этом realm. Получается, можно собрать разные realm, в которых один и тот же пакет взаимодействует с другим внешним окружением.
Cамое простое, можно набор скриптов запустить с coreutils, а можно с busybox. Или с разными версиями интерпретатора python.
Мне кажется, так более composable.
———
Короткое дополнение ко вчерашней теме, #vendor, #npm
То, как устроены per language repo, не помогает мейнтейнерам решать задачу по фильтрации всякого вредного говна.
Схема с мейнтейнерами работает, когда мейнтейнеров мало, они trusted, и дорожат своей репутацией. Если мейнтейнеров много, то они точно так же untrusted, как и оунеры кода, и увеличение числа причастных к процессу людей только увеличивает вероятность факапа.
Если мейнтейнеров мало, то они не могут делать аудит кода, когда каждый проект зависит от своего, уникального, набора версий. Слишком большой объем работы на одного человека.
Нужен какой-то компромисс, чтобы те же crates.io/npm/pypi составляли рекомендуемый набор версий, чтобы его можно было относительно легко аудировать внешними силами.
🔥2👍1
Ненавижу #cmake.
Это самая худшая система сборки ever.
* Она не умеет в кросс-компиляцию, писал об этом неоднократно #cross
* Фактически, cmake - это интерпретируемый язык с смесью синтаксиса qbasic и cobol, на которой можно как-то написать кривую и косую систему сборки, потому что язык turing complete.
Сложность скриптов на cmake ограничивается только всратостью самого языка, и ничем более.
У разработчиков QT, видимо, было очень много времени на то, чтобы разобраться с cmake, и сделать все самым ненатуральным возможным образом.
В cmake есть переменная, которая определяет список путей, по окторым искать библиотеки, заголовки, и так далее.
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, вот она
Ее поведение можно переопределить 10 разными способами, например
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#variable:CMAKE_SYSTEM_PREFIX_PATH
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_IGNORE_PATH.html#variable:CMAKE_SYSTEM_IGNORE_PATH
find_package() в cmake содержит в себе 10 настроек для этих 10 переменных, https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package - искать по "NO_CMAKE_".
Каждая из которых каким-то нетривиально-всратым образом меняет семантику find_package.
Долбоебы из QT решили, что и этого им мало:
* они переопределили поведение по умолчанию, чтобы либы из QT не искались в CMAKE_PREFIX_PATH
* Они завели себе переменную QT_ADDITIONAL_PACKAGES_PREFIX_PATH, на замену CMAKE_PREFIX_PATH
* Они завели себе переменную, выключенную по умолчанию, которая возвращает поведение к "нормальному"(насколько это возможно в cmake вообще) - QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES
Я НЕНАВИЖУ, когда у программистов заканчивается работа, и они начинают маяться хуйтой.
———
Хозяйке на заметку.
Я потихоньку профилирую свой Linux, ищу, что и гдеплохо лежит происходит не так, как мне нравится, и починяю.
Вот, возможно, пригодится.
#foot по умолчанию запускает ncpu threads для параллельного рендеринга.
Но мы-то знаем, что дисперсия времен ответов от большого числа источников(иными словами, барьер на синхронизацию событий "мы все сделали!") штука опасная, и может быть большой. Например, потому что #scheduler в Linux - говно. Тем более, если запускать по 16 render threads. Ну и памяти под стеки они жрут прилично.
TL;DR - если убрать вообще все worker threads, и оставить только main, скорость рендеринга не меняется никак(проверяем с помощью cat на большой файл, с ansi escape codes)
Тащемта, понятно, откуда там взялся многопоток - автор foot, очевидно, испытывает комплекс перед #alacritty, и ему нужно были эти эфемерные 10% ради собственного спокойствия.
А вам я рекомендую ставить workers=0 в конфиге, работает так же, памяти жрет меньше.
Это самая худшая система сборки ever.
* Она не умеет в кросс-компиляцию, писал об этом неоднократно #cross
* Фактически, cmake - это интерпретируемый язык с смесью синтаксиса qbasic и cobol, на которой можно как-то написать кривую и косую систему сборки, потому что язык turing complete.
Сложность скриптов на cmake ограничивается только всратостью самого языка, и ничем более.
У разработчиков QT, видимо, было очень много времени на то, чтобы разобраться с cmake, и сделать все самым ненатуральным возможным образом.
В cmake есть переменная, которая определяет список путей, по окторым искать библиотеки, заголовки, и так далее.
https://cmake.org/cmake/help/latest/variable/CMAKE_PREFIX_PATH.html, вот она
Ее поведение можно переопределить 10 разными способами, например
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_PREFIX_PATH.html#variable:CMAKE_SYSTEM_PREFIX_PATH
https://cmake.org/cmake/help/latest/variable/CMAKE_SYSTEM_IGNORE_PATH.html#variable:CMAKE_SYSTEM_IGNORE_PATH
find_package() в cmake содержит в себе 10 настроек для этих 10 переменных, https://cmake.org/cmake/help/latest/command/find_package.html#command:find_package - искать по "NO_CMAKE_".
Каждая из которых каким-то нетривиально-всратым образом меняет семантику find_package.
Долбоебы из QT решили, что и этого им мало:
* они переопределили поведение по умолчанию, чтобы либы из QT не искались в CMAKE_PREFIX_PATH
* Они завели себе переменную QT_ADDITIONAL_PACKAGES_PREFIX_PATH, на замену CMAKE_PREFIX_PATH
* Они завели себе переменную, выключенную по умолчанию, которая возвращает поведение к "нормальному"(насколько это возможно в cmake вообще) - QT_DISABLE_NO_DEFAULT_PATH_IN_QT_PACKAGES
Я НЕНАВИЖУ, когда у программистов заканчивается работа, и они начинают маяться хуйтой.
———
Хозяйке на заметку.
Я потихоньку профилирую свой Linux, ищу, что и где
Вот, возможно, пригодится.
#foot по умолчанию запускает ncpu threads для параллельного рендеринга.
Но мы-то знаем, что дисперсия времен ответов от большого числа источников(иными словами, барьер на синхронизацию событий "мы все сделали!") штука опасная, и может быть большой. Например, потому что #scheduler в Linux - говно. Тем более, если запускать по 16 render threads. Ну и памяти под стеки они жрут прилично.
TL;DR - если убрать вообще все worker threads, и оставить только main, скорость рендеринга не меняется никак(проверяем с помощью cat на большой файл, с ansi escape codes)
Тащемта, понятно, откуда там взялся многопоток - автор foot, очевидно, испытывает комплекс перед #alacritty, и ему нужно были эти эфемерные 10% ради собственного спокойствия.
А вам я рекомендую ставить workers=0 в конфиге, работает так же, памяти жрет меньше.
🔥10👍3😁2🤔1
Задачка на бутстрап.
———
Как вы все знаете, я очень уважаю процесс регулярного "better".
Поэтому я к своей пакетной базе отношусь не как к упаковке стороннего кода для кого-то, а как к полноценной монорепе.
Поэтому, конечно, ее не избежал процесс "better", и я не стесняюсь исправлять то, что сделано криво, или не работает вовсе.
Вот есть такая библиотека - https://github.com/jtanx/libclipboard.
Кросс-платформенная абстракция над clipboard, с поддержкой Linux, WinAPI, macOS.
К сожалению, в Linux поддерживается только X11, а Wayland - не поддерживается.
Не знаю, может, автору лень, а может, он просто забил.
Библиотека сделана криво.
* Если нет X11, то она просто не собирается
* А можно было бы сделать бекенд в памяти. Ну, чтобы оно собиралось, программы компилировались, и работал бы clipboard в рамках одного приложения, уже немало.
* Для души можно было бы поддержать clipboard от mc - это когда мы просто пишем в текстовый файлик в .config/mc/
А от этой библиотеки зависит https://github.com/magiblot/turbo, и он мне нравится.
Запилил https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/clipboard/fake/clip.cpp
Это не форк, это полная реимплементация существующего API. Пока я сделал в памяти, надо бы запилить в .config, ну и на wayland можно попробовать замахнуться.
"better!"
Мне иногда пеняют, что я не мержу свои изменения в trunk. А как их мержить, если trunk - это странное поделие на C, а, как знают мои читатели, в С не завезли хеш-таблицы(ладно, завезли, но использовать их запрещающе сложно).
Хочет кто-нить попробовать? Почет, слава, полезный код в OSS!
pg-> cat run.shЧто тут за WTF, и почему так?
while read l; do
echo ${l}
done
echo "ЖОПА"
pg->
pg-> cat run.sh | bash
echo "ЖОПА"
pg->
pg-> cat run.sh | sh
ЖОПА
pg->
———
Как вы все знаете, я очень уважаю процесс регулярного "better".
Поэтому я к своей пакетной базе отношусь не как к упаковке стороннего кода для кого-то, а как к полноценной монорепе.
Поэтому, конечно, ее не избежал процесс "better", и я не стесняюсь исправлять то, что сделано криво, или не работает вовсе.
Вот есть такая библиотека - https://github.com/jtanx/libclipboard.
Кросс-платформенная абстракция над clipboard, с поддержкой Linux, WinAPI, macOS.
К сожалению, в Linux поддерживается только X11, а Wayland - не поддерживается.
Не знаю, может, автору лень, а может, он просто забил.
Библиотека сделана криво.
* Если нет X11, то она просто не собирается
* А можно было бы сделать бекенд в памяти. Ну, чтобы оно собиралось, программы компилировались, и работал бы clipboard в рамках одного приложения, уже немало.
* Для души можно было бы поддержать clipboard от mc - это когда мы просто пишем в текстовый файлик в .config/mc/
А от этой библиотеки зависит https://github.com/magiblot/turbo, и он мне нравится.
Запилил https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/clipboard/fake/clip.cpp
Это не форк, это полная реимплементация существующего API. Пока я сделал в памяти, надо бы запилить в .config, ну и на wayland можно попробовать замахнуться.
"better!"
Мне иногда пеняют, что я не мержу свои изменения в trunk. А как их мержить, если trunk - это странное поделие на C, а, как знают мои читатели, в С не завезли хеш-таблицы(ладно, завезли, но использовать их запрещающе сложно).
Хочет кто-нить попробовать? Почет, слава, полезный код в OSS!
GitHub
GitHub - jtanx/libclipboard: Lightweight cross-platform clipboard library
Lightweight cross-platform clipboard library. Contribute to jtanx/libclipboard development by creating an account on GitHub.
🔥2👍1
Будни бутстрапа.
Собирал себе qimgv, посмотреть, что там за чудо-скейлер на opencv(TL;DR - чуда не заметил).
qimgv падал при просмотре любой картинки, где-то в недрах exiv2.
TL;DR - кусок кода из exiv2:
Коллега собирает либу в с++11, там используется std::auto_ptr, а клиенты используют в любом, в котором захотят. И у них часто используется std::unique_ptr.
По сути, reinterpret_cast из одного типа в другой.
Видимо, в каких-то комбинациях libstdc++/g++/etc это даже работает, а у меня вот падало.
Янапихал автору за щеку сделал так, что там всегда auto_ptr, даже когда он недоступен в том режиме сборки, в котором собирается клиент, через "#include <__memory/auto_ptr.h>"
Если кто-то хочет, то это хорошая задачка на запатчить что-нить в OSS, перейдя на std::unique_ptr в коде exiv2.
———
https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmysql_has_just_started/
Не могу не поделиться - в boost едет клиент для mysql.
Впрочем, и хер с ним, кажется, мы(как индустрия) уже пришли к консенсусу, что в новых проектах boost использовать не нужно.
———
Я решил себе собрать gnome Files, оно же nautilus. Сейчас у меня нет gui-шного file manager, а, наверное, нужно.
Список зависимостей базовой библиотеки:
https://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-desktop.html
У меня, конечно, потекла кровь из глаз, когда я увидел "GTK+-3.24.33, GTK-4.6.3"
Знаете, я, наверное, смогу собрать даже и ТАКОЕ, но что-то пока не хочется.
А #gnome пускай продолжает в глаза долбиться.
Собирал себе qimgv, посмотреть, что там за чудо-скейлер на opencv(TL;DR - чуда не заметил).
qimgv падал при просмотре любой картинки, где-то в недрах exiv2.
TL;DR - кусок кода из exiv2:
#if __cplusplus >= 201103LУ вас бывает при чтении чужого кода ощущение "взять, и уебать"? Вот это оно.
#include <memory>
#include <sys/types.h>
#ifndef _MSC_VER
#include <unistd.h>
#endif
template <typename T>
using auto_ptr = std::unique_ptr<T>;
#endif
Коллега собирает либу в с++11, там используется std::auto_ptr, а клиенты используют в любом, в котором захотят. И у них часто используется std::unique_ptr.
По сути, reinterpret_cast из одного типа в другой.
Видимо, в каких-то комбинациях libstdc++/g++/etc это даже работает, а у меня вот падало.
Я
Если кто-то хочет, то это хорошая задачка на запатчить что-нить в OSS, перейдя на std::unique_ptr в коде exiv2.
———
https://www.reddit.com/r/cpp/comments/unik91/acceptance_review_for_boostmysql_has_just_started/
Не могу не поделиться - в boost едет клиент для mysql.
Впрочем, и хер с ним, кажется, мы(как индустрия) уже пришли к консенсусу, что в новых проектах boost использовать не нужно.
———
Я решил себе собрать gnome Files, оно же nautilus. Сейчас у меня нет gui-шного file manager, а, наверное, нужно.
Список зависимостей базовой библиотеки:
https://www.linuxfromscratch.org/blfs/view/svn/gnome/gnome-desktop.html
У меня, конечно, потекла кровь из глаз, когда я увидел "GTK+-3.24.33, GTK-4.6.3"
Знаете, я, наверное, смогу собрать даже и ТАКОЕ, но что-то пока не хочется.
А #gnome пускай продолжает в глаза долбиться.
Reddit
From the cpp community on Reddit
Explore this post and more from the cpp community
😁5👍2
https://www.opennet.ru/opennews/art.shtml?num=57194
Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".
У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo
Вроде, есть какая-то спека, все договорились ее использовать, но все равно, все терминалы ее реализуют немного по разному, кто-то больше, кто-то меньше, и договориться между собой они не могут.
А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH
Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.
Возможно, я тут упустил какую-то интересную часть истории, расскажите.
———
Я решил устроить фичекат в своей пакетной базе. #mix
Как-то писал, что хочу, чтобы из моей пакетной базы можно было собирать как статически слинкованные программы, так и динамически слинкованные.
Сейчас стало понятно, что пакетная база будет выглядеть очень криво, если из нее надо собирать и то, и другое.
Смотрите.
Довольно часто рядом с библиотекой лежат какие-то данные.
В случае динамической линковки очень естественно, когда .so лежит рядом с данными для этой .so. Ну, типа, если уж слинковал это либу, то и данные понадобятся.
В случае .a файлов это совершенно не так. После того, как программа слинкована, мы совершенно точно не хотим видеть рядом с данными и бинарями .a файлы.
Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14
Это будет выглядеть весьма криво в случае сборки .so файлов.
Пакетная база, которая дает красивый результат для обоих "миров" - сама по себе выглядит ужасно, там куча if, и частных случаев.
Короче, я пока решил это дело пофичекатить.
Любли читать такие тексты. Самое интересное, конечно, не что там с wayland с nvidia, а "как оно вообще бывает, и какие задачи люди решают".
У меня выкристаллизировалась такая мысль - wayland сейчас находится примерно рядом с эмуляторами терминала. #foot, #alacritty, #kitty, #wayland #terminfo
Вроде, есть какая-то спека, все договорились ее использовать, но все равно, все терминалы ее реализуют немного по разному, кто-то больше, кто-то меньше, и договориться между собой они не могут.
А сообщение программе про изменение размера терминала до сих пор идет через SIGWINCH(== dbus рядом с wayland, если вы понимаете, о чем я), а не in-band в потоке сообщений. Про проблемы этого подхода я рассказывал. https://ru.wikipedia.org/wiki/SIGWINCH
Удивительный факт - GNOME, такое ощущение, ненавидит wayland, и, была бы их воля, они бы все переделали поверх dbus. Я этого совершенно не понимаю, они стояли у его истоков.
Возможно, я тут упустил какую-то интересную часть истории, расскажите.
———
Я решил устроить фичекат в своей пакетной базе. #mix
Как-то писал, что хочу, чтобы из моей пакетной базы можно было собирать как статически слинкованные программы, так и динамически слинкованные.
Сейчас стало понятно, что пакетная база будет выглядеть очень криво, если из нее надо собирать и то, и другое.
Смотрите.
Довольно часто рядом с библиотекой лежат какие-то данные.
В случае динамической линковки очень естественно, когда .so лежит рядом с данными для этой .so. Ну, типа, если уж слинковал это либу, то и данные понадобятся.
В случае .a файлов это совершенно не так. После того, как программа слинкована, мы совершенно точно не хотим видеть рядом с данными и бинарями .a файлы.
Поэтому я разделяю пакеты не только на bin, lib(помните, рассказывал про bin, lib контексты сборки?), но еще и на aux контекст(там лежит etc/, share/, etc). Программы и библиотеки уже собираются с путями, которые указывают в этот отдельный, третий, таргет. В сборе это выглядит примерно так - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/fontconfig/mix.sh#L14
Это будет выглядеть весьма криво в случае сборки .so файлов.
Пакетная база, которая дает красивый результат для обоих "миров" - сама по себе выглядит ужасно, там куча if, и частных случаев.
Короче, я пока решил это дело пофичекатить.
www.opennet.ru
Состояние поддержки Wayland в драйверах NVIDIA
Аарон Плaттнер (Aaron Plattner), один из ведущих разработчиков проприетарных драйверов NVIDIA, опубликовал сведения о состоянии поддержки протокола Wayland в проходящей тестирование ветке драйверов R515, для которой компания NVIDIA предоставила исходные тексты…
👍2
Мне тут в комментариях посоветовали вместо gnome files собрать https://wiki.lxde.org/ru/PCManFM #pcmanfm
Мне это показалось хорошим вариантом, часть LXDE, ни от чего не зависит(ну, почти), на вид выглядит не очень страшно.
Что характерно, поддержку gtk3 в нем запилило сообщество Arch, а, значит, проект пользуется некоторой популярностью, потому что так-то сообщество - жопа ленивая обычно.
Замечания по ходу процесса:
* libfm для сборки потребовало gtk-doc, причем практически неотключаемым образом.
Про свои муки с #docbook я уже как-то писал, но тут получилось, что просто так обойти эту зависимость не получается.
Небольшое лирическое отступление. Проекты на GNU #autohell требуют для построения configure наличие dev части некоторых зависимых пакетов, даже если ты потом не захочешь использовать этот пакет, и отключишь его через —disable-XXX.
Поэтому зависимость от gtk-doc я пока решил так - у меня корректно собирается и устанавливается часть gtk-doc, нужная для генерации autohell скриптов, а вот потом, если не позвать —disable-gtk-doc в configure, все будет взрываться самым неприятным образом. Я, конечно, нужный —disable- зову.
* libfm потребовала некую libmenu-cache, которая потребовала libfm. Я тут немного прифигел, но таки да:
https://github.com/lxde/menu-cache
"Since version 0.7.0 the Libmenu-cache requires Libfm-extra for the menu-cache-gen menu cache generation binary. Since Libfm depends on Libmenu-cache, there is some hint for bootstrapers how to build those libraries together: you need create Libfm-extra first, you can easily do this by passing '--with-extra-only' option to configure script and installing Libfm-extra."
С моей точки зрения:
* коллега нагадил посреди комнаты
* вместо того, чтобы тихонько прибраться, повесил табличку "я нагадил, обход тут"
"А что подумал по этому поводу Кролик, никто так и не узнал, потому что Кролик был очень воспитанный"
(нет, Кролик был в ахуе, и выпал в осадок так-то)
* К сожалению, посреди процесса сборки уже самого pcmanfm, я обнаружил, что оно таки непосредственно зависит от X11, и я не могу это собрать и использовать.
Сначала я решил, что ну и хер с ним, но потом внимательнее посмотрел на код, и понял, что могу изящно обойти эту зависимость от X, потому что она используется только если запустить этот FM в качестве X Desktop.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/pcmanfm/mix.sh#L34
По сути, мне пришлось заменить один файлик размером 200К на несколько заглушек. Попрошу отметить, как я изящно расставил abort() в некоторых местах, чтобы быть уверенным, что мы не обсчитываем мусор. Все очень надежно!
Короче, оно даже запустилось, и даже заработало, с некоторыми глюками. Не работает прокрутка мышью, я это списываю на то, что никто и никогда этот код с Wayland не запускал, по понятным причинам. На вид чистенько, бедненько, все, как я люблю в софте.
Самое неприятное, конечно, в другом: #libmagic
Я успел прочитать часть кода, связанную с mime info, и с запуском приложений. Код рыхлый, неприятный, видно, что проект затащили грубой силой. Знаете, вот возникает момент, когда надо выделить функцию, а ты все равно в 10 местах вставляешь еще 1 if.
Поэтому за час у меня не получилось переделать всю эту машинерию на запуск xdg-open вместо своей таблицы отображения mime types на команду, а без этого у меня оно пока неюзабельно.
Пока отложил в сторону.
Мне это показалось хорошим вариантом, часть LXDE, ни от чего не зависит(ну, почти), на вид выглядит не очень страшно.
Что характерно, поддержку gtk3 в нем запилило сообщество Arch, а, значит, проект пользуется некоторой популярностью, потому что так-то сообщество - жопа ленивая обычно.
Замечания по ходу процесса:
* libfm для сборки потребовало gtk-doc, причем практически неотключаемым образом.
Про свои муки с #docbook я уже как-то писал, но тут получилось, что просто так обойти эту зависимость не получается.
Небольшое лирическое отступление. Проекты на GNU #autohell требуют для построения configure наличие dev части некоторых зависимых пакетов, даже если ты потом не захочешь использовать этот пакет, и отключишь его через —disable-XXX.
Поэтому зависимость от gtk-doc я пока решил так - у меня корректно собирается и устанавливается часть gtk-doc, нужная для генерации autohell скриптов, а вот потом, если не позвать —disable-gtk-doc в configure, все будет взрываться самым неприятным образом. Я, конечно, нужный —disable- зову.
* libfm потребовала некую libmenu-cache, которая потребовала libfm. Я тут немного прифигел, но таки да:
https://github.com/lxde/menu-cache
"Since version 0.7.0 the Libmenu-cache requires Libfm-extra for the menu-cache-gen menu cache generation binary. Since Libfm depends on Libmenu-cache, there is some hint for bootstrapers how to build those libraries together: you need create Libfm-extra first, you can easily do this by passing '--with-extra-only' option to configure script and installing Libfm-extra."
С моей точки зрения:
* коллега нагадил посреди комнаты
* вместо того, чтобы тихонько прибраться, повесил табличку "я нагадил, обход тут"
"А что подумал по этому поводу Кролик, никто так и не узнал, потому что Кролик был очень воспитанный"
(нет, Кролик был в ахуе, и выпал в осадок так-то)
* К сожалению, посреди процесса сборки уже самого pcmanfm, я обнаружил, что оно таки непосредственно зависит от X11, и я не могу это собрать и использовать.
Сначала я решил, что ну и хер с ним, но потом внимательнее посмотрел на код, и понял, что могу изящно обойти эту зависимость от X, потому что она используется только если запустить этот FM в качестве X Desktop.
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/pcmanfm/mix.sh#L34
По сути, мне пришлось заменить один файлик размером 200К на несколько заглушек. Попрошу отметить, как я изящно расставил abort() в некоторых местах, чтобы быть уверенным, что мы не обсчитываем мусор. Все очень надежно!
Короче, оно даже запустилось, и даже заработало, с некоторыми глюками. Не работает прокрутка мышью, я это списываю на то, что никто и никогда этот код с Wayland не запускал, по понятным причинам. На вид чистенько, бедненько, все, как я люблю в софте.
Самое неприятное, конечно, в другом: #libmagic
Я успел прочитать часть кода, связанную с mime info, и с запуском приложений. Код рыхлый, неприятный, видно, что проект затащили грубой силой. Знаете, вот возникает момент, когда надо выделить функцию, а ты все равно в 10 местах вставляешь еще 1 if.
Поэтому за час у меня не получилось переделать всю эту машинерию на запуск xdg-open вместо своей таблицы отображения mime types на команду, а без этого у меня оно пока неюзабельно.
Пока отложил в сторону.
🔥8👍1
Я вчера написал, что не буду дочинивать #pcmanfm, но я был бы не я, если бы не взялся дочинить. Тревожный зуд что "что-то не работает" - штука такая. #debug
Прорвался сквозь сложносочиненный код для детектирования mime types, и выяснил нечто совершенно феерическое.
Если в одну программу слинковать lib/glib + lib/magic, то magic_buffer() начинает возвращать nullptr, а если без lib/glib - то "application/gzip" на данные для случайного .gz архива.
Это очень всрато, и, по сути, такое возможно только если с glib приезжают символы, которые оверрайдят какие-то weak символы в программе.
В процессе поиска я было отчаялся, но нашел флажок MAGIC_DEBUG, который выводил на экран запчасти от того, как работает #libmagic. Я там, почти случайно, понял, что:
* в libmagic есть правила на регулярках
* она их применяет линейным перебором, что, само по себе, пиздец
* libmagic ломается на первом же правиле с регулярками. Тут у меня, что называется, щелкнуло, и пазл сложился.
Вместе с glib приезжает libpcre, в составе которой есть библиотека libpcreposix.a, которая содержит в себе реализацию posix regex.x - regcomp/regexec/etc.
* (к слову, pcmanfm 4 раза дергает функцию для определения mime type для каждого файла, причем 2 раза из них реально считывает данные с диска)
Получалось так, что код собирался с определениями из musl regex.h, а линкер брал символы из pcre.
Я это починил, mime types заработали.
Ура? Пьем шампанское? Ага, конечно.
После пересборки world сломался браузер(напомню, что я использую epiphany).
Уже примерно понимая, в чем дело, я поставил breakpoint, и снял вот такой трейc:
Потому что, когда в glib была зависимость от pcreposix, ломался разбор конфига в mesa, и поэтому #zink (мой opengl driver) работал just as planned!
А когда я починил регулярки, конфиг начал обрабатываться правильно, и #zink начал глючить c новыми настройками!
Если вы когда-нибудь, зачем-то, хотели увидеть плачущего 40-летнего мужика, вам надо было быть вчера у меня дома.
Что с этим делать, пока непонятно.
Прорвался сквозь сложносочиненный код для детектирования mime types, и выяснил нечто совершенно феерическое.
Если в одну программу слинковать lib/glib + lib/magic, то magic_buffer() начинает возвращать nullptr, а если без lib/glib - то "application/gzip" на данные для случайного .gz архива.
Это очень всрато, и, по сути, такое возможно только если с glib приезжают символы, которые оверрайдят какие-то weak символы в программе.
В процессе поиска я было отчаялся, но нашел флажок MAGIC_DEBUG, который выводил на экран запчасти от того, как работает #libmagic. Я там, почти случайно, понял, что:
* в libmagic есть правила на регулярках
* она их применяет линейным перебором, что, само по себе, пиздец
* libmagic ломается на первом же правиле с регулярками. Тут у меня, что называется, щелкнуло, и пазл сложился.
Вместе с glib приезжает libpcre, в составе которой есть библиотека libpcreposix.a, которая содержит в себе реализацию posix regex.x - regcomp/regexec/etc.
* (к слову, pcmanfm 4 раза дергает функцию для определения mime type для каждого файла, причем 2 раза из них реально считывает данные с диска)
Получалось так, что код собирался с определениями из musl regex.h, а линкер брал символы из pcre.
gdb) b regexecНи к чему хорошему это не приводило, в том числе, ломался и libmagic.
Breakpoint 1 at 0x2bf0cf: file src/pcreposix.c, line 328.
(gdb) b regcomp
Breakpoint 2 at 0x2bef33: file src/pcreposix.c, line 274.
Я это починил, mime types заработали.
Ура? Пьем шампанское? Ага, конечно.
После пересборки world сломался браузер(напомню, что я использую epiphany).
Уже примерно понимая, в чем дело, я поставил breakpoint, и снял вот такой трейc:
#0 0x0000000008650e70 in regexec ()Это, конечно, прекрасное. Это реальный случай про "два бага, которые отменяли друг друга".
#1 0x0000000007dd061b in optConfStartElem ()
#2 0x000000000857acb7 in doContent ()
#3 0x0000000008578394 in contentProcessor ()
#4 0x0000000008573ab6 in XML_ParseBuffer ()
#5 0x0000000007dcf4fb in parseOneConfigFile ()
#6 0x0000000007dcf33b in driParseConfigFiles ()
#7 0x0000000007d117a9 in loader_get_user_preferred_fd ()
#8 0x00000000068d74c9 in dri2_initialize_wayland ()
#9 0x00000000068d266a in dri2_initialize ()
#10 0x00000000068c4d99 in eglInitialize ()
Потому что, когда в glib была зависимость от pcreposix, ломался разбор конфига в mesa, и поэтому #zink (мой opengl driver) работал just as planned!
А когда я починил регулярки, конфиг начал обрабатываться правильно, и #zink начал глючить c новыми настройками!
Если вы когда-нибудь, зачем-то, хотели увидеть плачущего 40-летнего мужика, вам надо было быть вчера у меня дома.
Что с этим делать, пока непонятно.
😁22🤯5🔥4👍2😢1