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

Градус безумия зашкаливает.

Некто Эрик Реймонд форкнул "ntp classic", для повышения безопасности, и удаления неиспользуемого кода.

При этом:

* "Восстановлена поддержка протокола NTPv1 и проведена чистка его реализации"

* "В системе сборки восстановлена поддержка Python 2.6"

https://withinboredom.info/blog/2022/12/29/golang-is-evil-on-shitty-networks/

#rant по поводу того, что, как выяснилось, в гошечке сокеты по умолчанию не используют nagle.

Обсуждение на HN, https://news.ycombinator.com/item?id=34179426

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

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

Вот, и Расс Кокс пишет:

"I do remember why, though. At the time, I was working on a variety of RPC-based systems that ran over TCP, and I couldn't understand why they were so incredibly slow. The answer turned out to be TCP_NODELAY not being set"

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

Когда-то, очень давно, TFileInput был небуферизованным, и, чтобы получить буферизацию, нужно было использовать вот такую вот конструкцию:

TFileInput fileInput("path");
TBufferedInput input(&fileInput);

Люди, конечно, часто забывали посмотреть на комментарии к этому классу, и считали, что TFileInput буферизован по умолчанию.

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

Сообщество победило, и TFileInput стал буферизованным.

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

КМК, правильно - не делать этот выбор (поведение по умолчанию) вовсе, и иметь TUnbufferedFileInput + TBufferedFileInput(ну или Socket), а решение уже за конечным пользователем.

Трактат "об одной особенности сборки grub".

При попытке собрать grub, без шаманства, получаю вот такую ошибку:

grub_script.tab.c:1123:9: error: variable
    'grub_script_yynerrs' set but not used
    [-Werror,-Wunused-but-set-variable]
    int yynerrs;

Понятно, что господа включили -Werror (чего нельзя делать по умолчанию, как я уже несколько раз писал).

При попытке добавить -w в CFLAGS начинает валиться configure скрипт, забавным образом:

checking for options to get soft-float... no
configure: error: could not force soft-float

Если заменить -w на -Wno-error, валится точно так же:

checking for options to get soft-float... no
configure: error: could not force soft-float

Получается, они там реально накостылили какой-то тест, который зависит от того, что какой-то конкретный конпелятор должен выдавать warning(который превращается в ошибку с помощью -Werror) на какой-то код!

В их configure есть опция --disable-werror, но с ней валится точно так же(потому что эта опция приводит к добавлению -Wno-error к CFLAGS в недрах configure)!

checking for options to get soft-float... no
configure: error: could not force soft-float

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

Занимался рутинным обновлением софта. #pkgconfig

Контур CI - это очень круто и удобно, потому что как я еще бы заметил, что, с новым libpcap, начала падать сборка wireshark?

Падать оно начало с очень странным сообщением об ошибке:

"ninja: Entering directory `/ix/build/mcpe98eHnOfPdF2O/obj'
ninja: error: '/ix/store/iDo8RMwHvMz5h6hQ-lib-pcap/lib/libpcap.a;/ix/store/3KBy5KQKrWQR6EuF-lib-nl/lib/libnl-genl-3.a;/ix/store/3KBy5KQKrWQR6EuF-lib-nl/lib/libnl-3.a', needed by 'run/tshark', missing and no known rule to make it"

Тут реально написано, что cmake сгенерил некорретный ninja файл - там где-то, в список зависимостей какой-то цели попала вот такая странная строка - 3 статических библиотеки, объединенных через ";"

На самом деле, тут довольно понятно, что cmake просто пишет туда какую-то строку, которую он получил из pkg-config, и там оказалось что-то неожиданное.

Вот diff в libpcap.pc двух разных версий библиотек:

Name: libpcap
 Description: Platform-independent network 
    traffic capture library
+Version: 1.10.2
+Requires.private: libnl-genl-3.0 
+Libs: -L${libdir} -Wl,-rpath,${libdir} -lpcap
-Version: 1.10.1
-Libs: -L${libdir} -lpcap

Подозрение, конечно, вызвало поле Requires.private.

https://people.freedesktop.org/~dbn/pkg-config-guide.html

"Requires.private: A list of private packages required by this package but not exposed to applications. The version specific rules from the Requires field also apply here"

Максимально запутанное объяснение, которое IMHO ничего не объясняет.

Я это понимаю как зачатки package management в pkg-config - набор библиотек, которые должны быть в системе (потому что они нужны по зависимостям каким-то .so в пакете)

В случае статических библиотек получаем вот такую вот странную шляпу, из всех абсолютных путей, объединенных через ;

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

Поэтому я просто снес ее к херам из всех .pc - https://github.com/pg83/ix/commit/bac7f907bc4d8841e4eff9aba93c2a0bd765fc96

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

Вот, например, фикс, который нужно применять ко всем файлам meson.build - https://github.com/pg83/ix/blob/main/pkgs/die/c/meson.sh#L107-L109

К сожалению, в meson (и в cmake, но не в autoconf!) автор сборочных скриптов может сказать "а вот это собери как .so, даже если пользователь пакета попросил собраться статически", без возможности override.

Как говорится, факир был пьян, фокус не удался!

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

Не буду вдаваться в подробности, но там очень замороченная сборка, которая использует разный набор путей поиска заголовков, потому что часть кода они собирают с нативным EGL, а часть кода - со своим враппером, #ANGLE, и это нетривиальным образом ломается от комбинации "мой враппер" + "принудительная починка .pc файлов".

Видимо, вместо "сделать все за один раз" придется откусывать слона по частям.

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) из одной организации.

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