https://www.fsf.org/blogs/community/googles-decision-to-deprecate-jpeg-xl-emphasizes-the-need-for-browser-choice-and-free-formats

#fsf высказались по теме выключения поддержки #jpeg_xl в Chromium.

Слушайте, я не смог прочесть этот текст.

У меня опять сработала регулярка на тему "проклятых sjw", на фразе "... issue in the history of the Chromium project, the nominally free basis for the Google Chrome browser"

Мерзотные, левацкие sjw, вот кто такие эти fsf.

Ну вот реально, вот как им еще сказать "вы, конечно, выполняете все правила free software, и мы, конечно, по нашим же правилам, так и должны вас назвать, но вы нам не нравитесь, поэтому вот вам плашка nominally".

Всем же понятно, что есть free software, а есть какое надо free software, и не надо их смешивать!

Или, может, с Mozilla Foundation проще договориться, чем с google? (хер там)

#abi #dwarf #elf #unwind #gold

Я как-то кидал ссылку на реализацию базовых функций Itanium ABI, для раскрутки стека и исключений. Вот, в каком-то смысле, продолжение - а что же там такое делает компилятор с линкером на пару, чтобы поддержать itanium runtime?

https://lesenechal.fr/en/linux/unwinding-the-stack-the-hard-way

Текст - огонь. Он явно войдет в мою золотую коллекцию ссылок про низкоуровневое устройство современных runtime.

По многим темам в интернетах не хватает ссылок уровня upper intermediate - это когда ты еще не прочел 10 стандартов по 1000 страниц каждый, но, после прочтения подходящего текста, ты уже можешь взять в руки какой-то инструментарий, и сделать что-то содержательное.

Есть куча зумерских восторгов вида "гля я заменил __cxa_throw, у меня программа теперь падает новым интересным образом", есть спецификации на ELF/DWARF, которые ни один нормальный человек читать не захочет (если он не на зарплате, конечно), а вот текстов "посредине" - очень и очень мало.

В тексте очень сжато расписано, как устроены разные секции, нужные для обработки исключений, начиная от ELF формата выполняемых файлов, и кончая описанием байткода DWARF, нужного для вычисления значения регистров в разные моменты выполнения программы (в том числе, base pointer), по текущему контексту.

Прямо очень, очень хорошо.

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

#unbound #musl #dns #dnsmasq

Перешел с unbound на dnsmasq, по советам коллег.

(да, я понимаю, что это продукты несколько разных масштабов, потому что unbound - настоящий рекурсивный dns resolver, а dnsmasq - "просто" кеширующая прокся (+dhcp +говна самовар), я их использовал для одного и того же)

pg# ls -la /ix/.../bin/unbound 
... 5683992 unbound
pg# ls -al /ix/.../bin/dnsmasq
... 2948464 dnsmasq

dnsmasq (вроде) не виснет, и весит меньше.

Заодно сделал использование локального кешера обязательным, потому что musl без этого так себе работает - https://wiki.musl-libc.org/functional-differences-from-glibc.html#Name-Resolver/DNS, а люди потом жалуются на alpine - https://martinheinz.dev/blog/92

Коллеги посоветовали посмотреть в сторону #systemd-resolvd, но, КМК, они так шутят, потому что, будучи статически слинкованным, он будет под сотню мегабайт весить, наверное.

https://www.phoronix.com/news/Fedora-38-Released

Пишут, что вышла свежая Fedora. Пишут, что собрана она gcc 13, который еще не вышел. https://gcc.gnu.org/

Мне кажется, или собирать дистрибутив для людей до-релизным компилятором - это такое?

#stal/ix #security #ROP

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

Возьмем, например, https://en.wikipedia.org/wiki/Return-oriented_programming

Это такая конструкция, которая позволяет составить вредоносный код, исполняющийся в адресном пространстве процесса, из запчастей самой программы.

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

func1:
...
A
B
ret

func2:
...
C
D
ret

Вот, можно так аугментировать call stack, что будет выполнено:

A
B
ret
C
D
ret
...

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

Количество реюзабельных кусочков пропорционально общему объему кода программы.

Поэтому, как ни странно, статическая линковка, за счет того, что линкер выкидывает неиспользуемые функции, дает меньше строительных материалов для атаки, нежели когда ты в себя влинковал кучу мертвого кода из кучи .so (суммарный объем всех .so для почти любой программы, конечно, больше, чем та же программа, но слинкованная статически).

А, значит, "более безопасна"!

Как-то один умный человек мне сказал, что на Земле живет всего 100 (или 500?) настоящих живых людей, а все остальные - NPC (да, он из геймдева).

Ничего не могу сказать про это, но вот мир, конечно, очень маленький, по крайней мере, в узкой области профессиональных интересов (или хобби).

Поэтому, когда мне в тележеньку пришла отбивка от бота про то, что на lobste.rs появилась новая статья с заголовком "Functional exception-less error handling with C++23's optional and expected", я уже знал, кто ее написал, про что она будет, и даже знал, какие ссылки будут в конце этой статьи.

Почему?

Потому что на днях мне прилетело обновление библиотеки tl-expected (fun fact - используется только в тележеньке), https://github.com/pg83/ix/blob/main/pkgs/lib/expected/ix.sh#L4, и я нашел 5 минут поштырить, что же это такое.

Спойлер - мне совершенно не близок такой способ обработки ошибок, все эти .or_else(), .and_then() (а заодно псевдоумные рассуждения про монады и теорию категорий) - это от бедности, потому что не договорились про https://habr.com/ru/articles/430690/ (несколько раз кидал ссылку на proposal, пусть сегодня будет на habr)

Тест на программиста⁠⁠

Programmer memes

Senior: "в среднем, осталось 0.95 яблока, берите float"

Наш (тут я, конечно, про проект #stal/ix) PR отдел рекомендовал мне завести блог на medium, потому что ссылки оттуда на там же HN/lobste.rs будут выглядеть солиднее, чем c какого-то там личного github.

С моей небольшой помощью наши совершенно потрясающие волонтеры запилили мне страничку с info - https://medium.com/@anton_samokhvalov/about (перебор? Не знаю, мне кажется, любое внимание не повредит), ну и, для затравки, один пост - https://medium.com/@anton_samokhvalov/about-bootstrapping-5eab2a0dba24

Мне кажется, это очень круто!

#rant

Я тут ускоряю локальный #dns #resolver #dnsmasq, раз уж у меня дошли до него руки.

В процессе мне понадобилась тулза dig.

Ну и, конечно, при первом запуске оно сегфолтнуло, вот с таким вот стеком:

Program received signal SIGSEGV, Segmentation fault.
0x0000000000b568b0 in isc.trampoline_get ()
(gdb) bt
#0  0x0000000000b568b0 in isc.trampoline_get ()
#1  0x0000000000b4fb04 in isc_thread_create ()
#2  0x0000000000b25280 in isc.netmgr_create ()
#3  0x0000000000b44a84 in isc_managers_create ()
#4  0x0000000000b1d9d6 in setup_libs ()
#5  0x0000000000b1545a in dig_setup ()
#6  0x0000000000b1a54d in main ()

Слушайте, я сел, и заплакал.

Ну вот какая в жопу точка в имени функции в C? Как это грепать в исходниках-то?

Так-то я тоже так умею, но я же не хвастаюсь этим направо-налево, и, тем более, не качу такое в прод:

Reading symbols from ./a.out...
(No debugging symbols found in ./a.out)
(gdb) b жопа#кеды%гладиолус 
Breakpoint 1 at 0x201244
(gdb) r
Starting program: /home/pg/a.out 

Breakpoint 1, 0x0000000000201244 in жопа#кеды%гладиолус ()
(gdb)

Разбираться я не стал, обновил версию bind до более свежей, оно как-то прошло "само".

Девочка Антон продолжает познавать #git.

Внезапно обнаружил, что, с моим CI, мне удобнее вести green trunk через merge flow, а не через rebase flow.

Вот, у меня есть своя ветка https://github.com/pg83/ix, я туда пушу обновления почем зря, потом, когда появляется время, начинаю смотреть в свой #CI, и пушить фиксы сборки и тестов. Эта ветка, конечно, использует rebase flow, и мой любимый стиль "better".

В какой-то момент моя ветка становится зеленой, и ее надо интегрировать в green trunk.

Раньше я делал это тоже через rebase, но мне всегда казалось неудобным, что я теряю информацию про предыдущие зеленые состояния. trunk-то зеленый, но как получить предыдущий зеленый транк?

По идее, можно было бы как-то помечать ссылки на зеленые коммиты, но вот мне показалось удобным помечать их как "merge commit".

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

Конечно, я хотел бы что-то типа монорепного зеленого транка, но, кажется, это не будет хорошо работать в ситуации, когда ты, в среднем, не доверяешь контрибутору (а у меня, например, CI не изолирован, поэтому перед тем, как отправить PR в CI, я хочу его отсмотреть).

В мой любимый тикет про #harfbuzz пришел ncopa, https://github.com/harfbuzz/harfbuzz/issues/2524#issuecomment-1514618751, пишет, что:

"As a distro maintainer for Alpine Linux, ABI breaks are trivial to handle compared to circular dependencies. And we handle ABI breaks all the time. Circular dependencies on the other hand always end up with some hackish and fragile solution"

Вот полностью с ним согласен, хотя, конечно, кому как.

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

Кстати, пишу так "ncopa", как будто все должны знать, кто это такой. Это создатель Alpine Linux. А я, по роду деятельности, пересекаюсь с ним во всякой своей ticket work чуть ли не еженедельно.

Меня тут спрашивают, как проще всего получить такой стектрейс.

Самый простой - вот так, и потом заменить 'xxx' в результате на 'жопа%кеды$гладиолус':

pg# cat qw.c 
int xxx() {
    return 0;
}

int main() {
    return xxx();
}
pg# ~/ix/ix run bld/compiler 
    bin/clang/env bld/sh 
    lib/musl/pure -- 
    cc -O0 -g qw.c
pg# gdb ./a.out 
GNU gdb (GDB) 13.1
Reading symbols from ./a.out...
(gdb) b xxx
Breakpoint 1 at 0x201244: file qw.c, line 2.
(gdb) r
Starting program: a.out 

Breakpoint 1, xxx () at qw.c:2
2     return 0;
(gdb)

Какой вопрос - такой и ответ.

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

Но, в данном случае, я совершенно точно знал, что символ может содержать любой utf8, а вот будет ли с ним корректно работать gdb - я не знал, поэтому сделал более сложно, чтобы результат таки можно было проверить в gdb:

pg# ~/ix/ix run bld/compiler 
    bin/clang/env bld/sh 
    lib/musl/pure -- 
    cc -O0 -g -c qw.c
pg# llvm-objcopy \
    --redefine-sym=xxx='жопа@кеды$гладиолус' qw.o
pg# ~/ix/ix run bld/compiler 
    bin/clang/env bld/sh 
    lib/musl/pure -- cc qw.o

Как вы знаете, я хочу стать следующим Курцвейлом. #future

Пока у меня в активе есть только прозорливое (== я об этом стал писать раньше других комментаторов) понимание, что #zink вытеснит все остальные реализации #opengl, не только в #mesa, а вообще.

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

Казалось бы - написал 1 раз, и дотачивай потом себе perf.

Я так понимаю, что все реализации vulkan по разному понимают, что такое vulkan, потому что технология еще не очень устоялась, поэтому нужны хаки там и тут.

https://www.phoronix.com/news/Zink-Intel-Arc-Graphics-Doom

Вот, пишут, что zink + anv (vulkan от Intel) в некоторых играх в пару раз быстрее, чем iris (opengl от Intel)

Продолжаю историю про #libbsd (это такой набор функций из мира bsd для всех остальных).

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

Позволю себе просто процитировать комментарий из libbsd к реализации функции, в которой у меня было падение:

https://gitlab.freedesktop.org/libbsd/libbsd/-/blob/main/include/bsd/vis.h#L92

/*
 * NetBSD added an strnvis and unfortunately made it incompatible with the
 * existing one in OpenBSD and Freedesktop's libbsd (the former having existed
 * for over ten years). Despite this incompatibility being reported during
 * development (see http://gnats.netbsd.org/44977) they still shipped it.
 * Even more unfortunately FreeBSD and later MacOS picked up this incompatible
 * implementation.
 *
 * Provide both implementations and default for now on the historical one to
 * avoid breakage, we will switch to the NetBSD one in libbsd 0.10.0 or so.
 * Define LIBBSD_NETBSD_VIS to switch to the NetBSD one now.
 * Define LIBBSD_OPENBSD_VIS to keep using the OpenBSD one.
 */

Божечки, из этого комментария просто сочится кровь и боль - libbsd скопировали функцию из openbsd, потом в netbsd ее запилили иначе (с другим прототипом), потом во всякие freebsd и macos просочился код из netbsd.

Авторы libbsd поступили мудро - добавили директиву препроцессора для клиентов (которую мне и надо было выставить), которую нужно переопределять в зависимости от того, откуда нужна реализация.

Мораль? Не используйте языки без манглинга имен!

https://www.phoronix.com/news/Red-Hat-Layoffs

Пишут, что в RH сокращения.

Мне сразу пришел в голову вопрос, что будет, если у RH кончатся деньги на развитие #systemd - что будет? Реально, community не потянет развивать это УГ, хватит ли сил у организации?

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1384350-red-hat-begins-cutting-hundreds-of-jobs?p=1384370#post1384370 - забавно, но один из первых комментариев на форониксе ровно про то же самое.

Да и на opennet тоже - https://www.opennet.ru/openforum/vsluhforumID3/130300.html#2