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

Есть хорошие новости:

"Удалён сеанс X11 для KDE, оставлена только поддержка Wayland"

А есть и плохие:

"Вместо загрузчика gummiboot задействован systemd-efistub (только данный компонент, а не весь systemd)"

Был дистрибутив, да сплыл. Как думаете, это начало конца?

#sat #Z3

https://lemire.me/blog/2025/06/01/easy-vectorized-classification-with-z3/

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

TL;DR - никто не умеет пользоваться гитом, даже его создатели.

Как выяснилось, Миша с фороникса просто плохо прочитал release notes:

https://www.phoronix.com/forums/forum/software/distributions/1550203-alpine-linux-3-22-replaces-gummiboot-with-systemd-efistub

"It is so difficult to write release notes.

One package (that happened to be a bootloader) was renamed, and we wanted to give upgraders a heads up in case they happened to use this bootloader. So we mentioned it in release notes.

And thanks to Phoronix.com the entire world now believe that you get systemd(-boot) if you install Alpine Linux from the release ISO. You don't. You get syslinux or grub (or uboot, or raspberrypi-bootloader) depending on the hardware.

Oh well..."

https://blog.pkgforge.dev/https-via-http

TIL, что bash реализует псевдо-mount /dev/tcp, с помощью которого можно ходить по сети!

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

Представлены результаты тестирования свежих выпусков СУБД Redis 8.0 и Valkey 8.1, в которых были заявлены значительные оптимизации производительности. Во всех проведённых тестах развиваемый сообществом форк обогнал оригинальный проект, в основном благодаря внедрению в Valkey нового механизма для многопоточной обработки ввода/вывода в асинхронном режиме, переданного проекту компанией Amazon.

#perf #fork

https://localmess.github.io/

"We disclose a novel tracking method by Meta and Yandex potentially affecting billions of Android users. We found that native Android apps—including Facebook, Instagram, and several Yandex apps including Maps and Browser—silently listen on fixed local ports for tracking purposes."

https://www.securitylab.ru/news/560030.php
https://github.com/tpde2/tpde
https://arxiv.org/abs/2505.22610
https://discourse.llvm.org/t/tpde-llvm-10-20x-faster-llvm-o0-back-end/86664

"Исследователи из Технического университета Мюнхена (TUM) представили TPDE — инструмент для быстрой компиляции кода, который способен ускорить сборку для архитектур x86_64 и AArch64 в 10–20 раз по сравнению с LLVM Clang на базовом уровне оптимизации -O0. Новый backend-компилятор ориентирован на задачи с минимальной задержкой — например, для JIT-сборки или быстрой отладки без оптимизаций. Исходный код проекта уже доступен на GitHub , а описание архитектуры опубликовано в научной статье на arXiv"

https://www.phoronix.com/news/Redox-OS-Implementing-X11

"Rust-written Redox OS has begun rolling out X11 support within its Orbital display server"

"Another big milestone for Redox OS during the month of May is seeing an initial GTK3 toolkit port"

Это они вовремя подсуетились, конечно.

Чувствую, что опять упускаю бизнес-возможность...

https://www.phoronix.com/news/Linux-PCACHE-RFC-v2

Судя по сводной табличке, нам скоро придется ждать "pcachefs", ага.

В копилочку того, почему не надо держать свою #infra, и #gitlab, в частности.

Но, на этот раз, история касается меня непосредственно.

https://github.com/pg83/ix/pull/22

Вот, пришли коллеги из torproject, и сказали, что я приложил их #gitlab.

А я чо? Я ничо, я вообще сделал все возможное, чтобы не прикладывать, за оригинальным урлом хожу, только если 5 кешеров недоступны.

Урл я поправил, но вот даже сам коллега признает, что:

"to be fair, gitlab shouldn't just fall over if you crawl /archive/ endpoints like this"

Наткнулся на забавную штуку.

Есть большой класс — кусок query execution, в некотором смысле state machine. Соответственно, в нём есть мембер переменная enum State : int, по которой делают switch и в которую делают store в этом же switch.

А ещё код был примерно такой, и я заметил, что _unused не используется — и удалил:

void* ...;  
int _unused;  
State _state;  
void* ...;  

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

И тут, собственно, причина, почему я пишу: я заметил, что тесты стали проходить медленнее — процентов на 5-10 от обычного времени (42 vs 46 минут). Ну, подумал, может, совпадение, но решил запустить ещё раз с/без патча. Результаты повторились (к сожалению, это было не единственное изменение в PR).

Пошёл смотреть, какие именно тесты стали медленнее, и заметил, что в половине из них разница в пределах погрешности, но многие тесты кверинга стали заметно медленее.
В общем, методом пристального взгляда я нашёл это место и позапускал с _unused и без. И действительно оказалось, что на ryzen 4 (по крайней мере, 7950X) код с чтением и записью 4 байт по адресу с alignment 4 работает лучше, чем с alignment 8.

Есть у кого идеи, почему?
Возможно, это какой-то затуп store-to-load forwarding-a, но как-то неочевидно, почему это происходит именно в таком сетапе.

Если что, store-to-load forwarding — это оптимизация в процессорах, когда ты пишешь в память x (<= 16?) байт, а потом читаешь <= x байт из того же места — можно не ждать завершения записи.
Неудивительно, что, как и многие другие оптимизации процессора, она работает не всегда. Например, чтение меньшего числа байт (по крайне мере с ненулевого оффсета) обычно работает медленнее.

Но в данном случае, казалось бы, разницы быть не должно: пишут и читают одинаковое число байт, по одинаковому оффсету.

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

Теперь у желающих продолжить развитие X11 появилась подходящая площадка для этого.

Текст по ссылке прекрасен, я даже не буду из него дергать цитаты, просто прочтите.

https://github.com/X11Libre/xserver

Together we'll make X great again!