Будни #bootstrap

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

Недавеча увидел в этом списке exim. Это самый популярный MTA, и я подумал, что "нужно"!

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

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

Вот этот сборочный файл из arch - https://github.com/archlinux/svntogit-community/blob/packages/exim/trunk/exim.Makefile

Я попрошу отметить, что это файл из репозитория Arch.

В комментариях дали ссылку на gentoo - https://gitweb.gentoo.org/repo/gentoo.git/tree/mail-mta/exim/exim-4.96-r1.ebuild#n170

КМК, это какое-то лютое пренебрежение к пользователю.

Или я чего-то недопонял, и есть путь проще?

https://habr.com/ru/amp/post/675036/

тут вот пишут, что Blizzard потребовала удалить с гитхаба альтернативный движок для третьего Warcraft.

С одной стороны, конечно, хочется что-нить сказать про жадных капиталистов, но у меня не сходится факт чекинг:

* На lobsters/HN про это ничего нет. Я прошерстил пару раз, не нашел ничего.

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

* Сам движок всратый, ничего не умеет.

* Коллега заявил об этом прямо день в день юбилея игры, зачем такой PR Blizzard'у?

Фейк? Не фейк?

https://www.phoronix.com/scan.php?page=news_item&px=Systemd-Creator-Microsoft

Вчера стало известно, что Леннарт ушел из RH. Ну ушел и ушел, я не стал про это писать.

Но, знаете ли, удержаться от того, чтобы сообщить, что ушел он в Microsoft, я не могу.

Ну, что же, пожелаем им всем удачи. Звука всем виндоводам хорошего, и скорости загрузки!

Утв. 1: время сборки и обновления source-based distro определяется временем сборки используемого браузера. Все остальное - o-малое.

Это, в целом, практический факт, и он довольно понятен:

* Браузер собирается очень долго

* Браузер зависит от кучи всего, поэтому пересобирается на любой чих

Ладно, я чуть-чуть утрирую, на самом деле, в этом списке 2 - 3 самых тяжелых конечных приложения. Чаще всего это браузер, и еще что-нибудь, в моем случае, telegram.

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

Не для того, чтобы они собирались быстрее, а для того, чтобы они собирались сильно реже.

Вот, расскажу про пример такой паразитной цепочки.

Обновлял nettle, это такая криптобиблиотека, и у меня пересобрался телеграм. Казалось бы, где телега, а где nettle,

1) gnutls -> nettle.
2) microhttp(гнутая библиотека для разработки http client-server) -> gnutls
3) elfutils(tool) -> microhttp
4) x264/vpx(кодеки) -> elfutils(tool)
5) -> ffmpeg
6) -> telegram

Все зависимости довольно понятны, и логичны, кроме 3)

В составе elfutils идет debuginfod, которому нужно уметь ходить по http, а всем остальным, нужным мне в сборке, тулзам, из elfutils, http не нужен.

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

Кстати, браузер тоже зависел от gnutls, но эту зависимость я оторвал немного раньше, и заменил ее на openssl.

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

Реклама - наше все!

Сравните заглавную страницу проекта(W): http://www.graphicsmagick.org/

И release notes(R): https://sourceforge.net/projects/graphicsmagick/files/

W: "GraphicsMagick is the swiss army knife of image processing. Comprised of 279K physical lines (according to David A. Wheeler's SLOCCount) of source code in the base package (or 1,275K including 3rd party libraries) it provides a robust and efficient collection of tools and libraries which support reading, writing, and manipulating an image in over 89 major formats including important formats like DPX, GIF, JPEG, JPEG-2000, PNG, PDF, PNM, TIFF, and WebP."

R: "For several years now, the burden has entirely been on me (Bob Friesenhahn). I have been sheparding the project for 20 years already (and contributed to ImageMagick and GraphicsMagick combined for 26 years already). It is not reasonable to expect someone with a full time job (and expecting to retire in a few years) to do all of the work."

W: "GM participates in Google's oss-fuzz project (since February, 2018)." (типа, круто, нас фаззят!)

R: "GraphicsMagick is participating in Google's oss-fuzz project due to the contributions and assistance of Alex Gaynor. Since February 4 2018, ??? issues have been opened by oss-fuzz and ?? issues remain open." (фаззят, а issues не закрывают)

Ну и так далее.

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()???