https://hi-tech.mail.ru/news/57350-pervyy-noutbuk-na-baykal-m-raskryta-cena/

Ноутбуки, которые мы заслужили.

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

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

Мне так только кажется?

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

https://lobste.rs/s/wxqcul/project_with_single_11_000_line_code_file

Тут вот собирают список проектов, написанных в 1 файле, большого размера. Рассказать им про bsconfig, чтоли? :D

———
#mesa

В продоложение темы разных personalities для opengl.

Вся эта конструкция, которую я описал в прошлом посте про mesa, на самом деле, выглядит и ведет себя очень странно. In the wild довольно много кода, который линкуется с glesv2, но в runtime ищет libGL.so, и экспортирует из нее к себе символы, и даже вызывает это.

Фактически, это приводит к тому, что программа видит символ с одним и тем же именем, но с разной семантикой.

Что это значит, и как работает, я пока не понял.

———
Парочка анекдотов про сборку.

Пара вводных: lib_deps: [X, Y] - список библиотек, от которых зависит данный таргет, и они ведут себя транзитивно. bld_libs: [X, Y] - список библиотек, которые нужны только для сборки данного таргета, то есть, ведут себя нетранзитивно.

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

Поэтому, когда, однажды я сделал вот такую замену: lib_deps: [A, B] + bld_libs: [C] -> lib_deps [A] + bld_libs [B, C], и у меня ничего не пересобралось, я занервничал.

А потом понял, что так и должно было быть, потому что актулаьный набор библиотек для сборки таргета [A, B, C] не изменился.

И второй.

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

Например, факт, что cmake зависит от libcurl, меня совсем не радует.

На днях тут обнаружил красивое - #libvte (это библиотека-виджет эмулятора терминала) зависит от gnutls - https://github.com/GNOME/vte/blob/master/meson.build#L588

Причем, если собрать ее без gnutls, то gnome-console/vte начинает на старте предупреждать, что все соединения от ее имени будут идти через несекурный канал.

Я, конечно, выпал в осадок, разбираться пока не стал.

https://developers.google.com/open-source/gsoc/faq#are_participants_from_ukraine_russia_or_belarus_allowed_to_participate_in_gsoc_2022

А действительно, зачем проводить GSoC на территории стран, в которые нельзя заплатить?

———
#quake

Я тут, для проверки работоспособности opengl и vulkan решил собрать себе quake2. Все шло очень хорошо, пока не пошло совсем наперекосяк.

Очень грубо, клиент quake загружает в себя 2 .so(на самом деле, больше, но для понимания сути рассказа это неважно), каждая из которых устроена примерно так:

client.so = 1.o + 2.o
game.so = 2.o + 3.o

При этом, fun fact - 1.o и 3.o содержат в себе некоторую функцию, с одинаковым именем, которая реально зовется в 2.o, и должна иметь разную семантику в client.so, и в game.so

Ну, для примера, пусть это будет функция printf(), только в одном случае она пишет на экран, а в другом - отправляет сообщение по сети на сервер. Влинковать две функции printf с разной семантикой в одну программу не представляется возможным.

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

В конце-концов, я нашел решение, симулировав поведение hidden symbols с помощью objcopy. Конкретно - добавляем к каждому экспортируему символу уникальный для архива префикс - скажем, client_ для client.a, и game_ для game.a, после чего их можно безопасно влинковать в одну и ту же программу.

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/quake/2/yamagi/mix.sh#L34

+ немного магии в моем псевдо-динамеческом загрузчике по переадресации вызовов:

https://git.sr.ht/~pg/mix/tree/main/item/pkgs/bin/quake/2/yamagi/mix.sh#L36

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

Думаю, до меня статический бинарник для quake2 не изготовлял никто, потому что это гениальное решение можно проследить еще в исходниках от id software.

Кстати, раз уж начал про quake.

Я редко играю в игрухи, но раз в 2 - 3 года на меня находит желание погонять в первый или второй quake. Вообще, я вам так скажу - софтверный рендер второго quake - это самый красивый графоний в играх, без дурацкого блюра и прочих наворотов. Прекрасные, четкие, квадратные пиксели, сделанные с душой.

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

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, решительно невозможно.

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