https://github.com/rui314/mold/releases/tag/v1.8.0

Вышла новая версия #mold. #money

Removed features:
* The experimental macOS/iOS support has been removed from mold. If you want to use it, please use our #sold linker instead.

В целом, дальше IMHO можно не читать, да и следить за проектом тоже - автор попал в классическую (блин, как летит время, она уже успела ей стать!) ловушку open core, когда фичи перемещают из бесплатной версии в платную.

Наверное, можно отметить, что коллеге подкинули денег от "Uber Open Source" - https://github.com/orgs/uber/sponsoring

Nevertheless, пожелаем этому господину удачи, потому что таких безумцев нашему миру явно не хватает!

#gold #rant про безопасность. Дисклеймер - это личное мнение автора этого блога, не имеющее никакого отношения к компании, в которой он работает.

Есть как бы "общепринятая" точка зрения, что "Security through obscurity" - плохо. Это уже стало мемом, catch phrase, и так далее.

Спросите безопасника, можно ли использовать этот механизм для защиты, и:

* Плохой безопасник рассмеется вам в лицо.

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

Как вспомогательный механизм, security by obscurity - норм, и википедия, кстати, со мной согласна - https://en.wikipedia.org/wiki/Security_through_obscurity - читайте внимательно, не проглатывайте слова "main", "alone", и похожие.

Если смотреть на эту проблему шире, то безопасность - это не про "безопасно" vs. "небезопасно", а про вероятность.

Почему-то безопасники склонны подходить к проблеме иначе - они ищут параметры в системе, при которых систему можно обмануть, находят, вешают ярлык "not secure", и считают, что хорошо сделали свое дело. Это интересно, но имеет мало смысла, потому что в любой реальной физической системе есть дыра.

Это, конечно, в корне неверно. Нужно считать вероятности исходов, умножать их на возможные потери от исходов, и минимизировать сумму (например).

Почему второй подход не очень принят?

У меня есть два предположения на этот счет:

* Потому что коллеги не очень понимают, что это правильно.

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

(Есть и третий вариант: все все понимают, но обосновать бюджет гораздо проще лозунгами "у нас тут 100500 малозначащих дыр, давайте их пофиксим, и станет 'безопасно'", чем скучными цифрами про вероятность. Его я решительно отвергаю, как маловероятный)

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

Я, между прочим, запилил первую версию CI - https://github.com/pg83/ix/blob/main/pkgs/die/scripts/ci

Нет, я не упоролся, это вот такой вот CI - 75% пользы за 1% вложений.

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

Могу сделать ssh на сборочный сервер, и сделать там tail на лог.

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

Ладно, на самом деле, основная работа в этой задаче была связана не с этим скриптом, а вот с этим вот списком - https://github.com/pg83/ix/blob/main/pkgs/set/ci/unwrap/ix.sh, и починкой всех пакетов, которые должны собираться.

Кстати, проект принимает посильную помощь, и, если у вас есть свободные 8cpu/16gb(еще лучше - 16cpu/32gb), и желание повозиться с CI, github actions, и всем таким прочим - пишите.

https://emiruz.com/post/2022-12-28-composable-sql/

Коллега генерит SQL запросы, используя M4. Это тот самый M4, на котором написаны autoconf макросы, и который отвечает за генерацию configure из них. Наверное, один из самых старых макропроцессоров.

Вспоминается анекдот:

Один пацан писал все на JavaScript, и клиент, и сервер, говорил что нравится, удобно, читабельно. Потом его в дурку забрали, конечно.

https://github.com/lite-xl/lite-xl

Классный текстовый редактор, и весьма грамотно сделан.

* Очень небольшая поверхность взаимодействия с системой - буквально, пара десятков довольно простых функций, типа, "отобразить текст", "нарисовать прямоугольник" (кстати, довольно эффективно - https://github.com/lite-xl/lite-xl/blob/master/src/rencache.c#L21) - https://github.com/lite-xl/lite-xl/blob/master/src/api/renderer.c#L354, и поверх этих абстракций стройтся весьма приятный GUI.

* Отрисовкой (скорее даже настройкой контекста) занимается SDL. Это очень правильно, потому что SDL гораздо легче монструозных библиотек, типа QT/GTK, особенно если от GUI нужен всего лишь framebuffer. Есть ощущение, что SDL не любят за пределами gamedev, и зря.

* Вся логика написана на Lua, и потому весьма хакабельна.

https://www.phoronix.com/news/systemd-Git-Stats-2022

Количество коммитов в systemd по годам, или "а ты точно не хочешь использовать systemd?"

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 скрипта пока не проводил, гештальт закрыт.