llvmweekly

https://discourse.llvm.org/t/rfc-lifetime-annotations-for-c/61377

lifetimes для C++. Кажется, на этот раз все серьезно. Не очень только понимаю, как это работает без изменения ABI, по идее, lifetimes же должны манглиться вместе с остальными свойствами типов.

Надеюсь, предложение пройдет, и, надеюсь, это даст толчок для развития С++ 2.0, на базе clang, и без старперов из комитета.

https://nullprogram.com/blog/2018/05/27/

Сказ про то, почему динамически слинковаться с библиотекой может быть дороже, чем позвать функцию через dlopen. Для тех, кто не знает, что такое got и plt, может быть интересно.

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

Будни #bootstrap

Я как-то писал про процедуру generic #bootstrap, когда мы пересобираем весь мешок инструментов предыдущей версией. Как я тогда отмечал, эта процедура довольно fragile к изменениям входных данных. Но я таки сумел ее заиспользовать, и упростить всю цепочку.

У меня, как и раньше, цепочка сборки первого инструментария описана руками, жесткими зависимостями, потому что fragile.

Но вот инструменты второго поколения я пересобираю с помощью такой автоматически построенной цепочки. Напомню, что у меня нотация a/b(c=d) означает зависимость от пакета a/b, собранного с флагами c == d. И есть особо выделенный флаг std_box - это ссылка на пакет инструментов, с помощью которого нужно собирать искомое. Флаги наследуются на все поддерево библиотек, поэтому с помощью std_box= пересоберется все поддерево.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/make/mix.sh#L4 - собираем make "второго поколения", указав std_box, и сказав, что в этом make не нужна поддержка i18n от gnu. Давно хотел это сделать, но раньше это было сложно, потому что один и тот же сборочный файл использовался и для сборки инструмента, и как user-facing пакет. А теперь это бесплатно.

Кстати, intl_ver работает очень просто - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/intl/mix.sh#L4 - это dispatch по имени флажка в конкретную реализацию. Так же я умею собирать пакеты с разными openssl, curses, whatever. В любой комбинации флажков.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bld/mold/mix.sh#L4 - или вот более интересный пример. Собираем mold "второго поколения", и заодно указываем, что в качестве openssl для mold взять мою велосипедную реализацию - https://git.sr.ht/~pg/mix/tree/main/item/pkgs/lib/openssl/md/mix.sh, которая оборачивает libmd в openssl-совместимый интерфейс. Сделано это для того, чтобы не тащить в это поддерево openssl, и perl, соответственно.

А user-facing пакеты собираются уже с помощью "второго поколения" инструментов.

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

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

Кажется, у меня вырисовываются интересные перспективы :D

https://github.com/NVIDIA/libglvnd

Узнал о существовании вот такой библиотеки. Это такой loader для opengl реализаций, чтобы их можно было свитчить на лету, видимо, чтобы разные приложения можно было запускать на разных карточках(встроенной и дискретной, например).

Масла в огонь подливает факт, что по аргументам некоторых функций из glx(привязка контекста opengl к X11) невозможно узнать, в какой драйвер делать реальный вызов.

Поэтому там есть пертредная map, отображающуя созданные контексты на загруженную .so с драйвером.

А еще есть libepoxy, https://github.com/anholt/libepoxy, которая, видимо, загружает libglvnd тоже через dlopen, и наводит свой лоск и хаки уже поверх нее.

Как это все работает, я думаю, не понимает никто.

Судя по форумам, работает оно через раз, и херово.

Я, конечно, буду предлагать пользователям собирать свои приложения с нужными дровами статически! Хочешь quake на nvidia гонять, а gui на встройке - да пожалуйста!

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

Nevertheless, мне надоело постоянно вводить

echo 255 > $(find /sys | grep backl 
    | grep amd | grep /brigh)

в консоли, и я решил сделать все по красоте.

Выбор пал на https://github.com/haikarainen/light. Все шло хорошо, до того момента, когда я запустил это инженерное чудо в первый раз.

Программа просто вышла, не реагируя ни на -h, ни на -v.

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

Чтение исходников показало, что автор совершил детскую ошибку - писал в log, не установив loglevel во что-то разумное.

https://github.com/haikarainen/light/blob/master/src/light.c#L494 - зацените, сколько полезной работы мы уже сделали до того момента, как решили распарсить command line.

Ладно, это место я починил, но не тут-то было.

Программа начала выходить с какой-то очень странной ошибкой, что не смогла создать каталог в папочке ~/.config. Причем под strace программа прекрасно выполнялась, я такое в первый раз в жизни видел.

Короче, эта шняга выставляла set group id on exec, https://github.com/haikarainen/light/blob/master/src/Makefile.am#L8, и чо это значит, я не знаю, и знать не хочу. Подозреваю, что gid/egid этого процесса был не очень подходящий, чтобы писать в мою папочку.

Некоторые запчасти Unix, конечно, лучше не знать.

Я строю #system0 без systemd, но я считаю, что для десктопа нужна общая шина.

Соображения мои такие:

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

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

Поэтому я считаю, что dbus и polkit - здравые, по своей сути, идеи.

Но, как обычно, реализация у них всратая.

Я даже молчу, что у dbus настройки через xml, и ни с чем не совместимый и уникальный wire формат. Хотя и считаю правильным, чтобы там был \n-delimited json, чтобы сервисы можно было делать в виде скриптов на любом языке, и на любой чих(*). Для dbus запилить сервис это то еще удовольствие.

Я про то, что, хотя dbus и определяет wire format, но он не определяет стандартные интерфейсы.

Поэтому что ConnMann, что iwd, что NetworkManager - они не реализуют стандартный интерфейс по настройке сети, они реализуют свои, уникальные, интерфейсы.

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

Есть такой набор стандартов от XDG, классная штука. Но они, например, предлагают использовать https://linux.die.net/man/1/xdg-open для того, чтобы открывать файлы и урлы на простмотр.

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

Интересно, GNOME и KDE сумели договориться про общие интерфейсы в этом месте? А про global menu? :)

Кстати, тот факт, что каждый sway пишет себе свой swaymsg, вместо того, чтобы использовать общую шину, это тоже камешек в огород десктопному Linux.

Настраивать каждое сочетание compositor + нотификацию + пользовательские программы приходится своим, особенным, образом, вместо того, чтобы 1 раз и навсегда написать набор шелл-скриптов, которые бы дергала сессионная шина по тем или иным запросам приложений.

*: Именно поэтому протокол должен быть простой, чтобы скрипт мог его реализовать через pipe + jq.

Кстати, рабочим названием mix всегда было pizdOS, или pizDOS, кому как больше нравится :D

https://www.phoronix.com/scan.php?page=news_item&px=Mesa-Kopper-Merged

"Zink with Kopper now provides native Vulkan windowing system integration (WSI), proper Vulkan swapchain handling"

"This moves Zink closer to being able to run with a Wayland compositor and other features previously only dreamed about for this generic but performant OpenGL implementation for running on Vulkan drivers. Mike Blumenkrantz continues working on Zink/Mesa thanks to employment from Valve" (Все #хорошее в графическом стеке Linux делают корпорации!) #zink #mesa

Интересно, а как у меня так получается уже гонять весь opengl stack через связку wayland + zink + vulkan? В том числе, и композитор.

Ну и непонятно, зачем этот самый WSI нужен. EGL вполне справляется с настройкой контекста, и, кроме слова GL, там от opengl нет ничего особо.

Тут вот пишут, что профессия художника уже закончилась. Интересно, когда придут за IT? 5 лет? 10?

Мысли ниже:

Я тут собирал #kitty под Linux, прост потому что мне не нравится, когда в репозитории есть сломанные таргеты. Так-то я использую #foot

И у меня случилось всяких разрозненных мыслей по этому поводу.

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

* Мое любимое занятие(на самом деле нет) - делать так, чтобы эмуляторы терминала выглядели одинаково. Для этого при размере шрифта в foot 12pt мне пришлось выставить в kitty 11.8pt(на тот же шрифт). Не могу доказать, но чую, что автор kitty где-то что-то умножил на константу или сложил, потому что у него там границы символов не сходились, ну или просто так больше нравилось. Да, это prejustice prejudice.

* В kitty какое-то безумное чило настроек. Такое ощущение, что автор бездумно вместо терма X везде писал (X + X1) * X2, ну чтобы можно было настроить что угодно и как угодно, иначе я все эти бессмысленные настройки объяснить не могу.

* Я решил проверить kitty и foot на performance. Для этого я, конечно(MAD SKILZ detected), сделал cat some_big.pdf прямо в терминал. Kitty тупо завис(не, прямо реально завис), foot отработал неважно с какой скоростью. Лог kitty перед смертью:

[097 21:55:06.343874] [PARSE ERROR] 
Unknown char after ESC: 0x24
[097 21:55:06.343883] [PARSE ERROR] 
Unknown char after ESC: 0x65
[097 21:55:06.347035] [PARSE ERROR] 
Unrecognized APC code: 0x1a

* После этого я вывел 20 мегабайт случайного текста.

foot:

real 0m0.642s
user 0m0.000s
sys 0m0.198s
pg->

kitty:

real 0m0.644s
user 0m0.000s
sys 0m0.207s
pg->

Казалось бы, одинаковая скорость, что у GPU-accel kitty, что у CPU foot? Какое там, это только потребление CPU! Kitty еще съел невозбранно дофига GPU, которое я не умею измерять!

* Kitty весит 51MB, foot - 8. Помним, что у меня статическая линковка. Чем меньше кода, тем меньше багов.

* Вишенка на торте - размер https://github.com/kovidgoyal/kitty/blob/master/setup.py в Kitty 50KB. Чувак там реально запилил сборку .c и .py кода(херовую, конечно). Размер всего ядра MIX - 45KB. А я уже собрал 550 пакетов, у меня супер крутая сборка с декартовым произведением флагов и кросс-компиляцией.

* Еще хочу похвастаться, как у меня круто устроено наследование шаблонов и диспатч между таргетами. Для тех, кто не знает шаблоны ruby/jinja2/etc, {{super()}} - это "взять текст базового блока и подставить в это место".

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/t/mix.sh - базовый шаблон
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/linux/mix.sh - надстройка для linux
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/darwin/mix.sh - для darwin
https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/kitty/mix.sh - диспатч между ними

Я все мог бы сделать в одном файле через if darwin, if linux, но так намного читаемее.

TL:DR; - не ведитесь, когда вам продают GPU accelerated что-то, чаще всего это хайп ни о чем.

https://github.com/libarchive/libarchive/releases/tag/v3.6.1

Вышла минорная версия libarchive.

Меня заинтересовала строчка в changelog:

ZIP reader: fix possible out 
of bounds read (OSS-Fuzz 38766 #1672)

https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=38764&q=libarchive (там несколько однотипных ссылок, которые нашел фаззер, я даю только одну из них)

TL;DR - 16 сентября нашли багу, 16 декабря открыли ее публично(grace period в 3 месяца). В марте оунеры проекта зашевелились, и таки починили.

OSS такой OSS

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

"Из других изменений отмечается прекращение установки утилиты zless на системы без утилиты less"

https://www.youtube.com/watch?v=CF166bieJ-k

У меня, после очередного обновления, стал падать браузер, а, точнее, его WebKitWebProcess, вот с таким вот стектрейсом:

#0  0x000000000852cfb0 in strcmp ()
#1  0x0000000004a937b9 in 
_ZNK3PAL12Text...CUConverterEv ()
#2  0x0000000004a938b4 in 
_ZN3PAL12TextCodecICU6decodeEPKcmbbRb ()
#3  0x00000000040fc431 in 
_ZN7WebCore19T...er6decodeEPKcm ()
#4  0x00000000040fd227 in 
_ZN7WebCore19T...ushEPKcm ()
#5  0x00000000041413ee in 
_ZN7WebCore12CachedScript6scriptEv ()

Падает вот тут:
https://github.com/WebKit/WebKit/blob/main/Source/WebCore/PAL/pal/text/TextCodecICU.cpp#L181

Предыдущий вызов из ICU стал возвращать nullptr.

https://github.com/unicode-org/icu/releases/ - тут написано, что был минорный релиз, ничо не меняли, "мамой клянусь".

semver такой #semver. Верить нельзя никому, только своим тестам.

https://github.com/kovidgoyal/kitty/issues/606

Зато из комментариев стало понятно, зачем этот господин форкнул glfw. Он не осилил сделать нормальный ввод для своей аццкой программы, и ему понадобилось одновременно получать информацию про scancode, и про текст.

Это ПИЗДЕЦ как странно, от OS нужно получать либо сканкоды, и самому превращать их в юникодные символы для программы внутри терминала, либо получать готовый текст(и иметь те проблемы, которые он имеет в kitty с настройкой шорткатов).

https://github.com/microsoft/msquic

Портабельная реализация QUIC, от MS.

Альтернативная реализация от Google обладает каким-то странным свойством, что для ее работоспособности надо написать 100К привязок к платформе. In the wild оно есть только в Chromium, с привязкой к его кодовой базе. И, по слухам, в envoy, но про там я ничего не знаю.

UPD: вспомнил, еще есть quiche от Cloudflare, на Rust. Бардачная ситуация, потому что разобраться где quiche от Google, а где от cloudflare, решительно невозможно.

Признаться, я в восторге!

Новости одной строкой: #mrustc https://github.com/thepowersgang/mrustc умеет в rust 1.54.0.

Надо бы им попробовать собрать не rustc, а что-то полезное. В отличие от mainstream rustc, оно умеет в процедурные макросы без загрузки .so в адресное пространство rustc.

https://xanmod.org/ - скажите, а кто-нибудь пробовал? Какие результаты?
Ну и, пользуясь случаем - кого бы мне подергать про ручки шедулера Linux? Хочу понять, как уменьшить цену миграции процесса с одного ядра на другое.

Пробую собирать #mrustc, https://github.com/thepowersgang/mrustc

Автор этого проекта, очевидно, разбирается в компиляторах, но совершенно не разбирается в системах сборки.

Его система сборки - это 4 Makefile, котрые рекурсивно вызывают друг друга, модифицируя аргументы и переменные среды.

https://github.com/thepowersgang/mrustc/blob/master/build-1.54.0.sh - главный драйвер сборки, вызывает make 7 раз, с разными Makefile, и аргументами(и каждый из этих вызовов еще рекурсивно дергает make!)

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

Пока получилось:

* собрать компилятор
* собрать minicargo
* с их помощью собрать cargo(1) из mainstream исходников

Дальше цепочка bootstrap предполагает:

* mrustc + minicargo -> rustc(1)
* minicargo + rustc(1) -> std(2)
* std(2) + cargo(1) + rustc(1) -> rustc(2), cargo(2)

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

То есть, получить rustc(1), cargo(1) я могу, а вот дальше с ними сделать ничего не выйдет.

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

Что я могу заметить по процессу?

Разработчики rust, конечно, пионеры, с завышенным ЧСВ. Иначе я никак не могу объяснить вот это вот говно - https://github.com/rust-lang/libc/tree/master/src/unix/linux_like/linux

Поштырьте по исходникам, и оцените, как изящно эти долбоебы обертывают libc. Фактически, они хардкодят оффсеты и размеры структур.

Нормальный человек нагенерил бы кучу setter/getter для структур, типа:

int struct_stat_get_inode(struct stat* s) {
    return s->st_ino;
}

И скомпилял бы это С-компилятором, чтобы вообще не думать о layout этого С-шного хлама.

Но это же не по пацански, и вообще, у нас комплексы лапки, и нужно сделать вид, что C тут и рядом не стояло, поэтому мы построим все на Rust: https://github.com/rust-lang/libc/blob/master/src/unix/linux_like/linux/musl/b64/aarch64/mod.rs#L10 Копипаста под все платформы и возможность разъехаться - не, не слышали.

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

True story, я искал, в качестве фикса mrustc у меня принудительно собирает под musl, потому что куда это в нем передать, я не нашел.https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/mrustc/mix.sh#L41

Ну и вендоринг C/C++ исходников(openssl, git2, curl, etc) - я про это уже писал, и повторю еще раз. Код эти пионеры вендорят, данные - нет. Потому что вендорить корневые сертификаты - это сложна, одной системой сборки не обойтись. Поэтому, конечно, найти в системе корневые сертификаты свежеиспеченный cargo не умеет.