https://github.com/Novum/vkQuake/releases/tag/1.20.3

#vkquake

"Fixed multiple parallelism bugs"

Вот жопа, хоть бы спасибо сказал.

У меня есть (короткий) список из нескольких задач, которые надо закрыть, прежде чем можно показать #stal/ix широкой общественности. #libmagic

Это задачи не про перфекционизм, а конкретные вещи, без которых "ничего работать не будет".

Как пример - дать возможность пользователю выбрать 3d драйвер из mesa. Пока у меня все заточено под мой setup из zink + radv, но там надо поддержать и более классическую схему с radeonsi, и intel, и software stack. Nouveau пока трогать не буду, подожду, пока они впилят наработки от open source nvidia.

На днях закрыл две задачи из списка - про размер курсора в gtk приложениях(он у меня был прибит гвоздями, а теперь может быть установлен через XCURSOR_SIZE), и про xdg-open.

Про xdg-open расскажу сегодня.

У вменяемого приложения под Linux есть два способа открыть какой-то внешний по отношению к себе файл:

* позвать портал через dbus.

* позвать command line тулзу xdg-open, передав ей путь к файлу или url.

Предполагается, что каждое DE будет предоставлять свой портал, или свой скрипт xdg-open(я тут немного упрощаю, для простоты объяснения).

К сожалению, in the wild я нашел только реализацию от freedesktop, и она настолько всратая, что у меня, при попытке это описать, остаются только матерные слова.

https://www.freedesktop.org/wiki/Software/xdg-utils/

(кстати, у невменяемых приложений есть и другие пути, например, KDE-шники любят долбиться в KParts, убил бы их за это, но это в следующей серии)

У меня какое-то время была заглушка для xdg-open, которая просто все открывала в браузере - https://github.com/pg83/ix/blob/99291c90267d7b690bc39fca7224c0a20b76334c/pkgs/bin/xdg/open/ix.sh#L8

Браузер умеет открывать почти все, и это решало 90% моих задач.

Но, кажется, людям такое отдавать несколько стыдно, но и насилолвать свой мозг через xdg-open от freedesktop мне не хотелось.

Поэтому я решил воспользоваться знанием того, какие у меня бинарники вообще бывают в дистрибутиве, и написал вот такой вот скрипт - https://github.com/pg83/ix/blob/main/pkgs/bin/xdg/open/scripts/xdg-open

Он определяет mime type переданного файла, и пытается для каждого известного типа выбрать наиболее подходящую программу из PATH. Ну и проваливается в браузер, если ничего не найдено(тут есть "мелкая" проблемка - а что, если xdg-open позвал браузер?).

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

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

На мой взгляд, план этот потерпел фиаско. #fast_python

https://github.com/faster-cpython/ideas/blob/main/main-vs-310.rst

(Кстати, fellow kids, учитесь составлять презы - невнимательный читатель может подумать, что ускорили в 1.5 - 2 раза, а geometric mean - всего +25%)

Ускорили на четверть, хотя, по плану из https://github.com/markshannon/faster-cpython/blob/master/plan.md, каждый следующий релиз должен давать +50%, отложили релиз 3.11 еще на несколько месяцев, потому что он ведет себя нестабильно - https://www.spinics.net/lists/fedora-devel/msg302880.html

https://news.ycombinator.com/item?id=32002057

А что с удалением GIL? ХЗ, я не заметил какой-то активности про внедрение https://github.com/colesbury/nogil #nogil

Гвидо - на мыло, я так думаю.

Например, набор классных еженедельных дайджестов на разные темы: https://discu.eu/weekly/

Если лень читать HN/Lobsters/Reddit, то все сливки за неделю - там.

https://github.com/jaor/xmobar#were-using-github-under-protest

Тем временем, наткнулся на первого мамкиного съезжатора с github. #sfc #gnu #gpl #charity

Кстати, я сам, лично, выкладывал что-то под GPL, только когда был literallly голодным студентом. Ну, посудите сами, мне тут жрать нечего, а кто-то, НА ХАЛЯВУ, воспользуется моим бесценным кодом.

После того, как:

* Заработал первые деньги

* На собственной шкуре убедился, что copyleft делит весь софт на 2 плохо связанные части(я тут намеренно не указал OSS, потому что корпорации довольно охотно отдают код под permissive license, да и сами используют тоже). Произошло это примерно так - я, вдруг, понял, что я, Антон, могу использовать кусок GPL2 библиотеки base64 во внешнем проекте, но я, Антон, не могу же использовать ее внутри Я, а, значит, Столлман не за меня, а против корпораций. И это не моя война, так как я хочу иметь возможность использовать OSS софт в любом контексте. Сумасшедшие фанатики тут делают вывод, что все должно быть под GPL, я же сделал вывод, что надо делиться, и не требовать ничего взамен, чтобы не создавать проблем какому-нибудь другому Anton, где-нить совершенно в другом месте.

, я ни строчки не отдавал под copyleft лицензиями.

copyleft - это лицензия очень жадных(и голодных, а оттого жадных) людей, которые готовы делать добро, только если им пообещают, что на это ответят добром.

Простите за моралофажество, но это не по-христиански.

Замахнулся на святое - на ImGui.

https://github.com/ocornut/imgui

Давно хотел попробовать собрать себе что-то интересное с использованием этой библиотеки:

* пощупать вживую immediate mode gui.

* для галочки, что, вот, "и это у меня работает".

* мне кажется, что ее концепция упраления окнами весьма хорошо ложится на sway.

* продолжаю искать графическую библиотеку, на которой я мог бы быстро для себя клепать те или иные инструменты.

ImGui мне пока кажется весьма странным зверем - у нее какое-то бешеное количество звезд на github, в 10 раз больше, чем, скажем, у wxWidgets.

Но при этом, пользовательских приложений на ней практически не сыскать, по крайней мере, в репозиториях.

Но при этом, в changelog к новому релизу imgui - с десяток скриншотов https://github.com/ocornut/imgui/releases/tag/v1.88 новых приложений, которые ее используют.

Короче, какая-то совершенно непонятная мне экономика.

Еще про imgui у меня есть завиральная идея - а что, если взять wlroots, и сделать его одним из поставщиков графического контекста для imgui, как, скажем, sdl, или egl? И в цикле рисования gui просто завести по одному окну на каждое wayland-окно, и отрисовать в нем буфер приложения?

Кажется, если не считать io, то, строк за 200 можно соорудить весьма неплохой композитор.

Да, да, я, в фоне, продолжаю думать на эту тему, никак она меня не отпускает. #cardboard

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

Вот так:

https://github.com/paperwm/PaperWM
https://github.com/cardboardwm/cardboard

Первый тормозит, и под gnome shelll, второй - заброшен.

Короче, из release notes я себе нашел приложение для тренировки - https://github.com/sgiurgiu/reddit_desktop

TL;DR - я его собрал, это потребовало довольно много времени, и, конечно, как у меня бывает, не обошлось без приключений.

Но об этом в следующей серии.

https://www.phoronix.com/scan.php?page=article&item=linux-kernel-o3&num=9 #O3

У меня тут, в закромах, завалялась ссылка про тестирование Мишей сборки ядра с -O3.

Видимо, как ответ на возникушую в lkml дискуссию про сборку ядра с -O3, которую Линус быстренько прекратил https://lore.kernel.org/lkml/CA+55aFz2sNBbZyg-_i8_Ldr2e8o9dfvdSfHHuRzVtP2VMAUWPg@mail.gmail.com/

В целом, я про -O3 думаю так:

* Погромировать никто не умеет, поэтому код надо собирать так, как его чаще всего собирают. С -O2, так с -O2. По крайней мере, пока компиляторы спекулируют на UB.

* Сумасшедших, которые собирают ядро с -O3, или там с LTO, я вообще не понимаю. В нормальной нагрузке ядро занимает 3-5%(если, конечно, вы не пишете DPI для Путина). Ну сделаете вы это быстрее на 10%, и чо? Чтобы что?

* Позиция Линуса мне не нравится. Из-за того, что он отказывается писать на нормальном С, компиляторостроителям приходится поддерживать разного рода хаки, да и не каждая версия компилятора подходит для сборки ядра. Сейчас реже, а раньше в каждом дистре была бережно прикопанная версия gcc для этой задачи.

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

Я, давеча, писал, что приложение в Linux может рассчитывать на наличие 4 шрифтов - sans, serif, #monospace, и system-ui(для отрисовки GUI).

Но, как выяснилось, не все приложения уважают эти настройки.

Например, авторы QT, почему-то, решили, что шрифт для отрисовки GUI - это "Sans Serif"(он матчится в просто "serif"), вместо "system-ui". https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp#L67

Так же доставляет вот эта настройка - https://github.com/qt/qtbase/blob/dev/src/gui/platform/unix/qgenericunixthemes.cpp#L69

Насколько я понял, она не меняется для hidpi систем. Вот так, просто, "девятый размер шрифта хватит всем".

"// Default system font, corresponding to the value returned by 4.8 for
// XRender/FontConfig which we can now assume as default."

https://imgs.xkcd.com/comics/random_number.png

На самом деле, не все так плохо, прежде чем провалиться в этот код, QT проверяет, под каким DE мы запущены, и пытается прочесть настройки этих DE.

(отдельная интересная тема - что чтение настроек KDE есть как в QT, так и в KDE, как они этот код меняют?)

А что же делать пользователям Sway? Я так понимаю, сосать писос, что же еще!

У себя я это, конечно, починил - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/qt/6/base/ix.sh#L56

https://reviews.llvm.org/rGde4a57cb21a19179d7be830967e642b868a05a91

У libc++ из llvm всегда была проблема с излишним включением заголовков, типа <string> мог включать в себя <vector>, и кучу всего прочего - https://reviews.llvm.org/rGde4a57cb21a19179d7be830967e642b868a05a91#change-fOsgWP3mrbAP.

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

А теперь запиливают обратно, готовясь к релизу llvm15, потому что, видимо, сломали много пользовательского кода.

Ну, такое.

https://lwn.net/ml/gcc/CAGWvnym7--36T6L6XhhVhQmafR-w3g1NE1Zh9qTbjcC325Us1Q@mail.gmail.com/

В gcc собираются включить наработки #gccrs, то есть, добавят реализацию Rust.

Это будет уже третья реализация, помимо основной, и #mrustc(https://github.com/thepowersgang/mrustc).

Я надеюсь, они таки сделают процедурные макросы не с помощью загрузки .so(а, например, использовав miri, или что-то подобное), и у меня появится нормальный компилятор Rust.

Ну и факт того, что он написан на С++, не может не радовать, это всегда хорошо для #bootstrap

Будни #bootstrap, обещаный текст про сборку reddit desktop, #imgui

* оно требует libmpv, для просмотра видосиков. Почему не ffmpeg напрямую - загадка. Все бы ничего, но сборка libmpv(или это свойство waf вообще) страдает обычным для OSS багом - "а давайте не будем устаналивать в систему артефакты для статически слинкованных библиотек, только для динамических". Пришлось применять тяжелую машинерию, в виде враппера над компилятором.

* оно требует vcpkg, причем хочет, чтобы vcpkg использовался и под Linux. А это жестейшая жесть, потому что vcpkg предполагает сборку под Windows, единственная OSS система сборки, которая там как-то работает - это cmake, и поэтому vcpkg сам для всех своих пакетов готовит файлы для cmake discovery - https://github.com/microsoft/vcpkg/tree/master/ports/bzip2, и сборку под cmake переделывает. Это привело к тому, что discovery в этом проекте без vcpkg не работает, пришлось патчить.

* по ходу сборки обнаружилось, что сломан boost - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/boost/ix.sh#L35 А чо, он же header-only, при его сборки компилябельность заголовков не проверяется.

* после того, как прошел configure, обнаружилось, что у коллеги забыты многие include. Возможно, это как раз связано с вчерашней темой про llvm14/15.

* самая мякотка - я не знаю, чо там наворотил автор в своем коде, но единичный файл у него компиляется дольше, чем в одном вам всем известном проекте в Я на букву М, и больше 4 потоков мой ноут не выдерживал - уходил в ядерные стектрейсы по памяти.

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

Кажется, я так процедурно(патчи регулярками над всем кодом) не издевался ни над одним пакетом - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/reddit/desktop/ix.sh#L50

Оно после этого собралось, слинковалось, но не заработало.

С сообщением, что не может загрузить в рантайме вот эту функцию - https://github.com/ocornut/imgui/blob/master/backends/imgui_impl_opengl3_loader.h#L656

Тут я подумал, что попал, потому что, как выяснилось, реализация imgui на opengl завязана на динамический загрузчик функций из glx(это привязка X11 к opengl).

А X11 у меня нет.

Я тут уже, было, решил сдаться, но потом почитал код, и понял, что, кроме самого загрузчика, далее код использует конвенциональный opengl, без glx.

Ну и я реализовал эту фабрику по загрузке функций сам - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/mesa/gl/dl/glx/ix.sh#L15, благо, сама фабрика по загрузке opengl у меня уже была реализована, для эмуляции dlopen. Тут тонкое, но забавное, место - эта фабрика для opengl идет в мою фабрику по динамической загрузке символов, реализованной внутри моей реализации dlopen.

Короче, оно собралось, и показало работающий imgui gui. Думаю, я тут опять первопроходец, так как, повторю, на базе чистого wayland стоковый код работать не может.

Победа?

Какое там, картинка была заблюреной, видно, что hidpi в imgui не работал, хотя и заявлен.

Рассказ про это - в следующей серии!

https://discourse.llvm.org/t/board-meeting-minutes-may-2022/63628

Расшифровка встречи "совета директоров LLVM", не знаю, как лучше перевести.

Ничего особенно интересного, но вот, кажется, в тему #copilot:

"Relicensing next steps - assuming small patches are not covered by copyright

“Small” patches are widely considered to be non-copyrightable.
Doing an analysis to look at what value of “how many lines” impacts the number of companies and contributors.
Some projects that use CLA assume that patches with <= 10 don’t need an assignment.
LLVM Foundation license lawyer has suggested <=10 lines of code.
This is only counting lines of code added and modified, not deleted.
Kristof has built a spreadsheet that outlines every not-covered patch.
VOTE: Should we consider patches that are <= 10 lines of code to be non-copyrightable?
Approved: Chris, Kristof, Kit, Hal, Anton, Tanya, Cyndy, Tom."

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

Совокупное мнение, согласованное с их юристами, - что до 10 строк кода - non-copyrightable work.

То есть, copyleft-атака на copylot как бы пролетает мимо.

https://lwn.net/Articles/900917/ #cve
https://comsec.ethz.ch/research/microarch/retbleed/

Еще пачка spectre-like уязвимостей, ничего интересного, кроме того, сколько стоит их исправление:

"Our performance evaluation shows that mitigating Retbleed has unfortunately turned out to be expensive: we have measured between 14% and 39% overhead with the AMD and Intel patches respectively."

Очень жду от облачных провайдеров разделение на независимые кластера, с mitigations=off, и mitigations=on, потому что зачем мне платить "за того парня с паранойей"?

https://blog.rust-lang.org/2022/07/12/changes-in-the-core-team.html

"Ashley Williams will be stepping down from the Core Team and other roles. "

https://github.com/libsixel/libsixel

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

Как выяснилось, я мастер предсказывать уже произошедшие события.

По ссылке:

* SDL в терминале
* qemu в терминале, со всеми вытекающими
* X11 в терминале, со всеми вытекающими

Надо сказать, что sixel output в gnuplot - мегаудобно.

Все же, мне нравится клепать системы сборки.

У меня есть некоторое количество библиотек, которые не имеют смысла за пределом #stal/ix.

Например, https://github.com/pg83/ix/tree/main/pkgs/lib/shim/gnu

Ничего особенного, просто пара функций, которых нет в musl, но которые сторонний софт иногда хочет.

(хотя, например, когда я писал вот это вот - https://github.com/pg83/ix/blob/main/pkgs/lib/shim/gnu/string.h, то я определнно ощущал себя #обмазаться_шоколадом)

Собиралось это предельно тупо - файлы материализовывались на диске, потом я вручную вызывал для них команды компиляции, линковки, и устанавливал в систему - https://github.com/pg83/ix/blob/e50237c6130b4a68fae9b44633af198e8ef816a7/pkgs/lib/shim/gnu/ix.sh

Когда у меня таких библиотечек стало 10 штук, пришло время это дело порефакторить, и я написал дня них общий шаблон - https://github.com/pg83/ix/blob/main/pkgs/die/inline/common.sh

Он, точно так же, материализует файлы на диске, и вызвает команды компиляции, только делает это немного более общО(собирает все подходящие файлы в директории, и копирует все .h файлы в ${out}/include/, библиотеки в ${out}/lib/, программы - в ${out}/bin/).

Конечный сборочный файл выглядит как-то так - https://github.com/pg83/ix/blob/main/pkgs/lib/shim/gnu/ix.sh

Вот почему, что бы я не делал со сборкой, там, все равно, появлются PEERDIR() + SRCS()???

https://github.com/libgit2/libgit2/releases/tag/v1.5.0

Вышла новая версия libgit2.

Коллеги затеяли большое дело - начали разработку внутри libgit2 непосредственно клиента к git.

Пишут, что хотят использовать тесты от git, ну и как пример, но мы-то понимаем!

Дело хорошее, git написан очень плохо, libgit2 - хорошо неплохо.

UPD:

pg-> ...MHVE-bin-git-2/bin/git2_cli 
usage: git2 [--help] [--version] <command> [<args>...]

Забавно, видимо, команду переименовали из git2 в git2_cli, чтобы было поменьше коннотаций про конкуренцию.

#bootstrap #bootstrap_science

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

Сейчас поясню на пальцах.

Допустим, вы, в процедуре bootstrap, собираете clang + coreutils, которые, потом, используются для сборки всего остального. Но для их сборки вам нужны промежуточные инструменты A, B, C.

Вы собрали себе нужный набор пакетов, сделали #ix gc, после чего A, B, C были удалены, так как они никому не нужны для работы.

А теперь, представьте себе, что какой-то конечный, user visible код случайно по сборке стал напрямую зависеть от A(или от B, или от C) Тогда, при попытке собрать этот таргет, нам придется воссоздать A, а значит, пройти всю цепочку bootstrap целиком.

Собственно, моя задача - найти такое множество пакетов, которе, если "заякорить"(то есть, сделать доступными после ya gc), то bootstrap никогда не будет происходить полностью(кроме как случаев, когда меняется сама цепочка bootstrap).

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

До тех пор, пока я не переделал цепочку bootstrap, как в предыдущем посте, на который я ответил.

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

Понятно же, почему это правило порождает необходимый и достаточный набор инструментов?

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

Вот, я перечислил все такие инструменты в 1 таргете - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bld/ix.sh

Это очень удобно, потому что теперь, чтобы прикопать эти инструменты, мне достаточно завести #realm с этим таргетом(realm задает множество корней для gc).

Все, как я люблю - нового механизма не случилось, а его функции исполняются старыми.

А, тем временем, кодовая база #stal/ix:

pg-> (find . -type f -name '*.sh' 
    | while read l; do cat ${l}; done) | wc -l
34391
pg-> (find . -type f -name '*.py' 
    | while read l; do cat ${l}; done) | wc -l
2967
pg-> find . -type f -name '*.sh' | wc -l
1617

35000 строк кода, 1500 пакетов.

Немало.

https://medium.com/@mproberts/a-discussion-about-the-breaking-of-the-internet-3d4d2a83aa4d #npm

Я, например, тогда не следил за всей этой историей, и переписку автора модуля, который "сломал интернет", с оунерами на trademark, не читал.

А правда, что trademark дает такие серьезные права на это слово? То есть, я не могу на github завести репозиторий с названием yandex/google/whatever? А может, например, владелец trademark запретить употреблять это слово вообще, или в каком-то контексте?

Мои пакеты, в каком-то смысле, программно-генерируемые.

Это значит, что в них может прийти набор флагов, и, в зависимости от этих флагов, будет получаться разный сервис, и даже код этого сервиса.

Благодаря использованию этого механизма, некоторые штуки получается сделать существенно проще.

Например, у меня так сделан task scheduling в системе.

Cron? Не, не слышали.

Вот такой программно-генерируемые сервис - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh

Он ожидает на вход параметр delay, и дальше использует его для генерации своего исходника:

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L4 - у сервиса будет уникальная папка для запуска его через runit

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L10 - спим столько, сколько указано в delay

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/scripts/ix.sh#L12 - после чего выполняем все скрипты, лежащие в папке /etc/sched.d/{{delay}}

Что это значит?

Это значит, что любой клиент, который хочет, чтобы какой-то его скрипт выполнялся раз в delay секунд, он:

* Делает зависимость от этого сервиса, с параметром delay= - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/staleprocs/ix.sh#L4

* https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/sched/staleprocs/ix.sh#L8 - в папочку /etc/sche.d/{{delay}} материализует запускаемый скрипт

https://git.sr.ht/~pg/ix/tree/main/item/pkgs/set/system/0/unwrap/ix.sh#L17 - дльше мы просто устанавливаем в систему пакеты с указанием этого самого конкретного delay, и дело сделано.

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

Почему не cron? Посекундно сложно, конфигурационный файл плохо composable из запчастей.

Собственно, у меня на таком "кроне" работает, например, очистка системной /ix/trash/(про нее я рассказывал отдельно), и убиение stale процессов. И вместо постоянно висящего ntpd - регулярное хождение в ntp https://git.sr.ht/~pg/ix/tree/main/item/pkgs/set/system/0/unwrap/ix.sh#L23.