https://www.opennet.ru/opennews/art.shtml?num=58392

К прошлогоднему тексту про opennet добавить нечего, он остается лучшим источником текстов на почитать.

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

#harfbuzz

На этот раз в тикет пришел великий и ужасный Матиас Класен (я правильно транслитерировал?) - это тот человек, который виноват во всем плохом, что случается в #gtk и #gnome, и снова рассказал, что "ничего нельзя сделать", но я так просто их не отпущу :))

https://www.schneier.com/blog/archives/2023/01/breaking-rsa-with-a-quantum-computer.html

Гля чо пишут - сломали 2048 bit RSA на современных нам квантовых компухтерах, без миллионов кубит!

Мое внимание снова привлек этот самый hyprland, потому что в ленту на github прилетела их новая репа - https://github.com/hyprland-community/awesome-hyprland

Реально, проект не успел починить ошибки сборки, а уже завеле себе *awesome!

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

В целом, все довольно прозрачно, потому что такая пионерия часто соседствует с желанием использовать последние фичи стандарта на полную программу - https://github.com/pg83/ix/blob/main/pkgs/bin/hypr/picker/ix.sh#L30

Возвращаясь к их awesome списку - доставляет цветовая дифференциация языков.

Я ее расшифровываю так:

* C++ - жжет!
* Rust тоже жжет, но чуть менее.
* С - унылое серое говно.
* Zig - meh, чуть лучше, чем С, но все равно что-то желтоватое.

Остальные языки я не берусь классифицировать.

Вот, неделю назад вышла следующая версия gtk3, в ней странное поведение сборочной системы "починили" - откатили изменения в курсорах, и спилили к херам autoconf:

- Revert cursor changes from 3.24.35
- Drop the autotools build

"Что это было", видимо, останется нам неизвестным.

Ворчать - так ворчать!

Ошибки у них реально школьные!

ConfigManager.cpp:24:98: 
    error: cannot pass object of non-trivial type 
    'std::string' (aka 'basic_string<char,
     char_traits<char>, allocator<char>>') 
    through variadic function; 
    call will abort at runtime [-Wnon-pod-varargs]
            Debug::log(CRIT, "No config file provided.
            Specified file %s couldn't be opened.",
            configPath);

И, кстати, встроенный редактор в github - классная штука, вот хрен бы я без него отправил эти патчи в проект!

https://github.com/hyprwm/hyprpaper/pull/30

#rant

Я тут разбирался, почему у меня перестал собираться транковый #epiphany, выяснил, что они совершенно не стесняются заносить обратно-несовместимые изменения в нестабильную ветку gtk, и собираться с ней.

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

Но мой сегодняшний текст про другое.

Пока я грепал интернеты на предмет политики изменения epiphany и gtk, наткнулся на вот этот замечательный пост, https://blog.gtk.org/2022/12/15/a-grid-for-the-file-chooser/

(Кстати, пост написан небезызвестным нам господином Класеном)

Пост про то, как какой-то там рефакторинг в #gtk дал возможность запилить фичу, которую пользователи хотели последние 18 лет!

https://bugzilla.gnome.org/show_bug.cgi?id=141154

Теперь, после рефакторинга, это стало "easily possible now".

Прочел я это, сел, и задумался - очень мне интересно, что творилось в голове у человека, который 18 лет не давал запилить эту фичу(потому что #errogant разработчикам #gnome/gtk казалось, что оно будет сделано криво), и, наконец, написал в своем бложике "Judging from the number of likes on the merge request, this is a popular feature. We hope you enjoy it", и "It only took us 18 years"!

Реально, я это читаю как "мы 18 лет не делали популярную/нужную фичу, потому что нам казалась некрасивой/неправильной возможная реализация".

(да, я читал тред в багзилле, и я прекрасно понимаю, что, на самом деле, люди имеют в виду, когда пишут в такой ситуации "ну вы запилите патч, а мы на него посмотрим")

Иногда мне кажется, что разработка некоторых open source проектов totally broken.

Не могу удержаться и не воткнуть шпильку в адрес другого столпа DE в Linux!

https://blog.vladzahorodnii.com/2023/01/03/how-cursor-is-rendered/

TL;DR - чувак рассказывает, как он модифицировал kwin, чтобы поддержать отличные от статической картинки курсоры.

Подпись к картинке с демонстрацией достигнутого результата:

https://vladzzag.files.wordpress.com/2023/01/img_20221222_165045.jpg?w=2048

"Red square is the cursor surface, the green square is its subsurface. No idea why you would want to do this, but kwin should handle this fine now"

KDE, конечно, кидается немного в другую крайность :D

Я, кстати, тогда не рассказал, что попросил господ из Химеры запилить busybox-style binary из bsdutils, раз уж они занялись его перехреначиванием под meson, но господа тогда отказались, мотивируя это тем, что "не нужно". Не нужно - так не нужно, я эту тему отложил.

Но, вот, на январских решил этот гештальт закрыть.

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

В целом, мой процесс описан тут - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L10, я немного прокомментирую:

* В пакете достаточно регулярная структура исходников - по папке на каждую тулзу. Я прохожу по всем папкам верхнего уровня, и готовлю libfunc.a из всех *.o, соответствующих эой тулзе. https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L15 Важно - в каждом таком .a есть функция main()!

* После чего я добавляю префикс вида "${tool_name}_" ко всем символам в этой libfunc.a - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L16 (это уже мой инструментарий для бинарного патчинга). Важно - main() в, скажем, sed, начинает называться int sed_main(). После этого все эти .a файлы можно слинковать в один бинарь.

* После чего я генерирую настоящий int main(), который устроен примерно так:

...
if (strcmp(argv[0], "sed") == 0) {
    return sed_main(argc, argv);
}
...

(вот, кстати, тут сишечка "сияет", потому что используется ровно для того, для чего ее придумали!)

Наверное, тут стоит отметить, что мое решение не до конца аккуратно, потому что вызываемый sed_main() может иметь сигнатуру не int sed_main(), а void sed_main(), и/или не принимать все argc/argv/envp, но:

- Я глазами убедился, что в коде void не бывает, а если бы был, нужно было бы еще занулить RAX перед вызовом sed_main() (попробуйте себя в этом убедить!)

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

* Линкуем всю конструкцию в монобинарь - https://github.com/pg83/ix/blob/main/pkgs/bin/bsdutils/box/ix.sh#L57

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

Получившийся бинарник работает just as planned, из интересного - он чутка меньше, чем такой же монобинарь для coreutils.

bsdbox - 2M, coreutils - 2.4M

Тесты на perf какого-нибудь развесистого configure скрипта пока не проводил, гештальт закрыт.

Запустил таки configure с bsdutils, вместо coreutils.

Результата не дождался, потому что словил oom в sed!

[837157.716471] oom-kill:
    constraint=CONSTRAINT_NONE,
    nodemask=(null),
    cpuset=/,mems_allowed=0,
    global_oom,task_memcg=/,
    task=sed,pid=7540,uid=1000
[837157.716492] Out of memory: 
    Killed process 7540 (sed) 
    total-vm:6018196kB, anon-rss:5584024kB, 
    file-rss:0kB, shmem-rss:0kB, 
    UID:1000 pgtables:11820kB 
    oom_score_adj:0

В целом, неудивительно, учитывая changelog!

https://github.com/dcantrell/bsdutils/releases/tag/v13.1

"Freshly imported from FreeBSD 13.1 and patched. Also add the sed(1) command. Enjoy"

У телеги очень интересно разные changelog в приложении, и на github:

"Telegram Desktop was updated to version 4.5.3

— Bug fixes and other minor improvements

Full version history is available here:
https://desktop.telegram.org/changelog"

https://github.com/telegramdesktop/tdesktop/releases/tag/v4.5.3

"Attempt to fix incoming video in calls from mobile apps"

В github всегда интереснее!

https://lobste.rs/s/pza2fr/sqld_is_server_mode_for_libsql

Анонс sqld, сервера баз данных, построенных поверх libsql(которая сама по себе довольно забавный форк sqlite, вызванный тем, что всех подзаебало, как оунеры sqlite ее развивают(а, точнее, не принимают внешний код от слова совсем)).

В анонсе ничего интересного нет, кроме того, что я из-за него вспомнил, что хотел написать следующее:

Никогда, никогда не используйте встраиваемые базы данных (*)! Вот вообще никогда!

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

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

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

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

Как правильно?

Ну вот так и правильно - запускать вместе с приложением вот такой вот sqld, и ходить к нему через сокет.

*: "на самом деле" (tm), есть один случай, когда встроенный sql - OK. Это случай, когда вы решили использовать sql как структурированный формат для save/load. Не как базу данных, к которой в процессе работы идут постоянные запросы, а при старте приложения прочитали файл в память, поработали с ним, в конце записали целиком заново.

Увожаемые, а дайте совет про лучшие практики CI на github?

Сейчас у меня есть процесс, который на каждый коммит умеет сказать OK/FAIL.

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

А как вообще принято?

https://sourcehut.org/blog/2023-01-09-gomodulemirror/

Продолжение истории про ddos от Google.

Решение Дрю, конечно, спорное, потому что принципы - принципами, но вот go-шные проекты у него хостить будет сложнее.

https://quick-lint-js.com/blog/cpp-vs-rust-build-times/

Текст про сравнение скорости сборки Rust vs. C++.

От кучи подобных текстов отличает монументальность подхода - коллега переписал 17 тыщ строк с С++ на Rust, для корректности сравнения.

Измеряется вообще ВСЕ - инкрементальные vs полные сборки, различные трюки для ускорения сборки как С++, так и для Rust, в том числе, (за это отдельный респект и уважуха) - попытка собрать тулчейны с #BOLT.

Короче, автор явно одержим скоростью, почитайте.

Выводы? Все сложно!

Коллеги принесли красивое.

Обсуждали внутренний патч во flakes8, вида

-VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,3}$", re.ASCII)
+VALID_CODE_PREFIX = re.compile(
    "^[A-Z]{1,3}[0-9]
    {0,4}$", re.ASCII)

Ну, типа, не хватает ширины какого-то поля, давайте, мол, увеличим на 1.

Конечно, возник вопрос - почему так в upstream, и можно ли это будет смержить в него.

https://github.com/PyCQA/flake8/pull/1782#issuecomment-1377346615
https://github.com/PyCQA/flake8/issues/1777

TL;DR - начнем с того, что ты пиздоглазое мудило "what part of "this is not changing" do you not understand?"

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

А, ну и вишенка на торте - договориться не могут проекты(pylint и flake8) из одной организации.

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

https://seclists.org/oss-sec/2023/q1/13

Просто оставлю это здесь.

На самом деле, из текста я не понял, где именно не случается нужная проверка. Я вот, например, при скачке исходников тоже не проверяю сертификаты, потому что важнО несовпадение чексуммы(SHA), которая получена по надежному каналу.

Если при скачке репозитория версий и зависимостей - то это, конечно, хорошо.

Вчера разбирались с коллегой, почему у него странно работает ssh на машину с установленным #stal/ix.

Если совсем коротко, то это выглядело так:

# ssh host env
...
A=B
...
# ssh host
> env
...
A=C
...

Ну, то есть, натурально, сильно разный environment при запуске команды в batch режиме ssh, и такой же команды в интерактивном режиме.

Дело свелось вот к этой функции - https://github.com/mkj/dropbear/blob/master/dbutil.c#L371

Совсем коротко - для интерактивного режима оно запукает shell в login mode, и тогда shell читает содержимое /etc/profile, и далее все, как положено, а для запуска batch команды запускает шел в неинтерактивном режиме, через -c. Ну и этот shell, конечно, наследует env от parent process, и не зачитывает на старте /etc/profile.

Я тут не очень понимаю, как правильно (и кто это "правильно" вообще определяет).

Мне лично кажется, что и во втором случае нужно запускать login shell, но не в интерактивном режиме!

Я это у себя зачинил так - https://github.com/pg83/ix/blob/main/pkgs/bin/dropbear/ix.sh#L7 https://github.com/mkj/dropbear/blob/master/dbutil.c#L388 - вот тут заменяем -c на -cl, указывая, что надо зачитать env из /etc/profile.

Вот теперь думаю, надо ли с этим стучаться в dropbear upstream, или меня там сразу нахер пошлют?

Мне кажется, надо бы апнуть этот замечательный пост, в котором я объяснял, зачем я затеял свой дистрибутив Linux.

Если коротко - то меня бесят многие вещи, сделанные в Unix/Linux, и самый простой способ их починить - это иметь контроль над всем окружением!

Вот, если говорить про предыдущий пост, где я написал про "странность" поведения ssh daemon в интерактивном vs. batch режиме.

На самом деле, эта странность очень просто объясняется - она вызвана путаницей между login shell, и interactive shell!

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

Но это в корне неверно!

Login shell, это, если очень грубо, первый shell в цепочке для вашего пользователя. Обычно его стартует какой-нибудь display manager, типа mingetty, agetty, emptty, greetd, sddm, да тысячи их. ssh, putty, telnet, mosh, и так далее - это тоже штука, которая spawn первую shell в цепочке!

Interactive shell - это то, куда вы вбиваете команды с клавиатуры.

Это, конечно, довольно разные штуки.

(Кстати, немного в сторону - если у вас бывают случаи, когда в PATH повторяются одни и те же элементы - это значит, что вы не понимаете разницу между этими сущностями, и у вас иногда два раза срабатывает конструкция добавления чего-то к PATH, потому что лежит не в том файле)

Проблема тут еще усугубляется тем, что разные shell читают разные startup файлы, в зависимости от режима.

Например, bash читает /etc/profile как и в interactive, так и в login mode. А большинство других shell так не делают!

Короче, тут явно видны треш, угар, и содомия, наслоение привычек, непонимания, и так далее. Оцените, например, только /etc/environment - https://superuser.com/questions/664169/what-is-the-difference-between-etc-environment-and-etc-profile - это упячка, родившаяся из того, что иногда надо сделать "login", но без "shell", а переменные откуда-то надо взять!

Поэтому, конечно, я тут намерен сделать все "правильно" (*), а не воспроизвести хак, к которому все привыкли!

Почему?

Потому что, если бы меня устраивал этот хак, я бы поставил Fedora! А мне нужно better!

(*) Правильно - конечно, ssh и прочие должны запускать первый shell в login mode. Еще лучше - для каждого shell пользователь должен разобраться, в какие файлы ему класть interactive настройки (типа completion), а куда - login.

https://xn--r1a.website/PAAMAYIM_NEKUDOTAYIM/30

Не могу не утащить из комментариев!

Продолжается замечательная история про #gil в Питоне.

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

https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional/22606

Я настроен довольно пессимистично, потому что люди прекрасно понимают, что это сильно фрагментирует экосистему. Условно говоря, будешь ты приходить к автору third party модуля с просьбой починить в нем баг в многопотоке(или починить регрессию в однопотоке), а он будет посылать нахер, с "не использовали многопоток, и неча начинать". В итоге, все разделится по признаку "можно в многопоток/нельзя", и это не очень.