Мне кажется, эти новости хороши вместе:

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

"Работа ведётся совместно с компанией 9elements, специализирующейся на адаптации CoreBoot для различного оборудования"

Напомню, 9elements - это компания, из-за которой ноутбуки от malibal теперь не поставляются в Германию!

Будни #bootstrap.

Собрал себе ядро с PREEMPT_RT, а заодно с #sched_ext (https://www.tgoop.com/itpgchannel/2137)

Надо сказать, что веб страницы стали загружаться быстрее, и скроллинг в браузере на глаз лучше! Вы чо, ебу дали? Эффекты от этого можно будет найти только с лупой пока!

Да, да, -rcX, давно я так не развлекался, лет 20, наверное, не ставил rc ядро.

Это было не совсем тривиально, потому что для sched_ext понадобилось собрать ядро с clang. Раньше я всегда собирал с gcc, хотя вся остальная система собрана у меня с clang.

Наверное, какая-то инерция мышления, и желание собирать тем, чем собирали разработчики.

Но, в целом, факт того, что самая популярная в мире сборка ядра теперь на clang (да, да, ведроид), пошло ему на пользу, и собралось оно без плясок с бубном.

В общем, вроде, работает, не падает, буду экспериментировать с sched_ext дальше.

#sched_ext

Какие-то демонстрационные шедулеры у меня получилось заставить работать (но и результат, ожидаемо, никакой), а вот что-то серьезное уже не работает:

https://github.com/sched-ext/scx/issues/823

Товарищи захотели перехватить static функцию из ядра, которая у меня, например, заинлайнилась.

UPD:

В транке они это починили - https://github.com/sched-ext/scx/blob/fb3f1d0b43d8a1f69cbc434f4a43145dbd983076/rust/scx_rustland_core/assets/bpf/main.bpf.c#L258

Оно даже собралось, но зависло намертво. В том смысле, что машина зафризилась, без какого-то внятного debug.

Будни #bootstrap

Клал я новую версию libunistring (это такое оверинжиниренное говно для работы с unicode, от проекта #GNU), и там что-то сломалось под aarch64.

Что именно, для рассказа неважно, там в тестах заюзали непортабельную хрень, решил я это, как обычно, грубо и эффективно - https://github.com/pg83/ix/blob/main/pkgs/lib/unistring/ix.sh#L26-L27

Пока я с этим разбирался, наткнулся на смешной комментарий в коде:

/* Work around clang bug <https://github.com/llvm/llvm-project/issues/104670> */

"clang bug" от сумасшедших GNU мейнтейнеров - это должно быть очень весело, подумал я!

https://github.com/llvm/llvm-project/issues/104670

Там, действительно, какое-то несоответствие между тем, как работает gcc, и как работает clang (macro expansion в pragma - должно или не должно случаться?)

Мне очень понравилось, как коллега аргументирует, что это именно баг в clang:

"I claim that this is a bug, because

* With "gcc" instead of "clang", it works fine.
* The documentation at https://gcc.gnu.org/onlinedocs/gcc/Weak-Pragmas.html does not mention effects of macro definitions"

Сука, в этот момент я, конечно, взорнул, да.

Правда, там чуть ниже есть настоящая причина, почему это баг (standalone пропроцессор в clang работает не так, как если бы он был встроен):

"* If I preprocess main.c before compiling it, it works fine as well"

Наверное, у коллеги просто такое специфическое чувство юмора.

Еще забавно, что в этот тикет набижал главный мейнтейнер gcc, и рассказал эту печальную историю, откуда пошло такое поведение - https://github.com/llvm/llvm-project/issues/104670#issuecomment-2294994641 (спойлер - все грустно).

Оказалось, что https://github.com/pinskia регулярно набигает в багтрекер llvm, и рассказывает, где clang и gcc не совпадают, очень хорошее дело, я считаю.

А пока я вспоминал, кто же такое pinskia, наткнулся на замечательный срачик Тео Де Раадта с мейнтейнерами gcc, про его скорость - https://gcc.gnu.org/legacy-ml/gcc/2004-03/msg00011.html

https://habr.com/ru/news/851968/

TL;DR - хорошо мотивированный стажер может горы свернуть!

#nix #nixgate

https://determinate.systems/posts/announcing-determinate-nix/

Гля какая красота, в ответ за то, что квадроберы фурри его пидорнули из Nix, чувак взял, и запилил форк.

Причем, насколько я помню историю, форк этот подкреплен понятными ресурсами.

Запасаемся попкорном!

Админ за работой.

https://lore.kernel.org/linuxppc-dev/CAHk-=wiUaWnHGgusaMOodypgm7bVztMVQkB6JUvQ0HoYJqDNYA@mail.gmail.com/

Вот, и Линус тоже считает их "ненастоящими"!

"Honestly, I'm pretty damn fed up with buggy hardware and completely theoretical attacks that have never actually shown themselves to be used in practice.

So I think this time we push back on the hardware people and tell them it's *THEIR* damn problem, and if they can't even be bothered to say yay-or-nay, we just sit tight.

Because dammit, let's put the onus on where the blame lies, and not just take any random shit from bad hardware and say "oh, but it *might* be a problem""

Безопастность такая безопастность.

У меня в сборках ядра mitigations=off на уровне кода, чтобы даже случайно не пролезло - https://github.com/pg83/ix/blob/main/pkgs/bin/kernel/t/2/ix.sh#L21

Меня тут спрашивают, зачем мне realtime (PREEMT_RT) ядро.

Мол, realtime - это не про скорость, все будет медленнее.

Я утверждаю, что нет вообще никакого смыcла (ну, кроме пока не отлаженных багов) не использовать PREEMT_RT, а использовать что-то другое.

Смотрите, Linux имеет несколько "классов" шедулинга. Условно говоря, realtime, "обычные процесы", "фоновые процесы" (я упрощаю специально, для ясности).

И если у вас в системе нет realtime процессов, то (за очень небольшим числом исключений, я про них знаю, но они не меняют сути происходящего) наличие full PREEMT_RT шильдика вообще никак не влияет на вашу нагрузку.

Потому что шедулинг устроен примерно так - ядро шедулит сначала RT процессы, в соответствие с их RT приоритетом, а в "остатки" процессорного времени уже шедулит все оставшиеся процессы. И, если у вас нет RT процессов, то "остаток" всего CPU - это 100% CPU, которое "обычным образом" распределяется между остальными классами процессов и процессами.

Вот какой, в таком случае, смысл не иметь возможности зашедулить RT процесс, если он тебе, вдруг, стал нужен, тем более, это практически ничего не стоит?

Ну и, для полноты картины, приведу пример процессов, которые у меня уже прямо сейчас RT:

* Звуковой демон (мультиплексор). Когда мне нужно проиграть звук, то мне нужно, чтобы он попал в звуковую карту ровно тогда, когда нужно, чтобы не было всяких там "пш-пш". Поэтому мой #sndiod должен иметь право разогнать вообще всех, не только фоновый компилятор clang, а еще и условное прерывание дисковой подсистемы, или там сетевухи.

* D-Bus broker. Это, с ходу, может быть не очень очевидным, но всякого рода message passing может (очень легко!) стать причиной https://en.wikipedia.org/wiki/Priority_inversion, и, поэтому, на всякий случай, dbus стоит сделать RT процессом, чтобы он уж точно не стоял на пути "важного" сообщения.

Есть "серые зоны".

Например, я для себя пока не составил в голове модель того, нужно ли быть RT процессом wayland композитору, или это будет, скорее, вредным для всей системы.

Рубрика "растоманы украли С/asm и продают".

Гля какая интересная новость - https://www.phoronix.com/news/Rustls-Faster-Than-OpenSSL

Пишут, что rustls обогнал boringssl/openssl, причем довольно значительно.

Если пройти по ссылке к новости, https://www.memorysafety.org/blog/rustls-performance-outperforms/, то там есть интересное:

"These tests connect one client to one server over a memory buffer, and then measure the time elapsed in client and server processing — therefore, they give an upper bound on performance given no network latency or system call overhead"

Подлог номер 1 - нам продали не настоящую latency, а за вычетом сети. С сетью разница была бы на порядок меньше.

Дальше идем по ссылкам на уже менее красивую страницу, с деталями тестов - https://gist.github.com/ctz/deaab7601f20831d0f9d4bf5f3ac734a

Для boringssl/openssl использовался какой-то васянский бенчмарк - https://github.com/ctz/openssl-bench/tree/d5de57d92d483169cabf8ec22c351fe3819ba656 (7!!!, сука, 7 звезд!!!)

"The benchmarking tool used for both OpenSSL and BoringSSL was openssl-bench d5de57d9"

openssl собрали сами:

"OpenSSL was built from source with ./Configure ; make -j12"

Будет время - проверю, точно ли это релиз. И вообще, почему нельзя было взять готовый, чтобы точно без валенков на пульте сборки?

Ссылок на код бенчмарка именно для rustls тут вообще нет, или покажите, где я в глаза долблюсь - https://gist.github.com/ctz/deaab7601f20831d0f9d4bf5f3ac734a

Ну и, в общем, самая мякотка:

"AVX-512 support shows up twice in these results:

rustls/aws-lc and OpenSSL's performance advantage in throughput tests is due to use of AVX-512F/VAES.

rustls/aws-lc and OpenSSL's performance advantage in server-side full handshake tests is due to use of AVX-512IFMA-accelerated RSA"

Выиграл не rustls, а крипта от Амазона, в которую добавили поддержку AVX-512, причем код там на C и ассемблере:

https://github.com/aws/aws-lc
https://github.com/aws/aws-lc/tree/main/generated-src
https://github.com/aws/aws-lc/tree/main/ssl
https://github.com/aws/aws-lc/tree/main/crypto

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

В общем, как в том анекдоте:

"Говорят вы машину выиграли? - Не машину, а квартиру, и не в лотерею, а в покер. И не выиграл, а проиграл"

https://sqlite.org/forum/forumpost/b7e2d83c0bcfae1e

sqlite меняет систему сборки. С autoconf на autosetup.

Говорят, что им не нравится gnu M4 + shell, поэтому меняют его на TCL. А, так как TCL ни у кого нет, то они его будут носить с собой (на самом деле, уже давно носят, но это неважно).

Цензурных слов у меня про это нету, поэтому все.

https://www.phoronix.com/news/Linus-Torvalds-Russian-Devs

Линус хорош.

В отличие от остальных трусливых хуесосов, не стал прятаться, и назвал вещи своими именами.

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

Несколько тезисов:

1) "опенсорс сломали".

Удивительно, но мало кто понимает, что такое open source.

Open source - это код, который распространяется по open source лицензии. Сообщество, взаимодействие, конференции (и перепихоны с фурри после) - это люди сами себе напридумывали.

Linux как был open source, так им и остался. Ты можешь пойти, и скачать его, и модифицировать, и распространять результат. Больше тебе и не обещали.

А патчи никто принимать не обязывал. Не верите - покажите в GPL место, которое обязывает Линуса разговаривать с тем или иным мейнтейнером.

Или зашлите патч в sqlite ("Open-Source, not Open-Contribution" https://sqlite.org/copyright.html) - у вас не выйдет. Уже не open source? Или "плохой" open source? Нет, автор просто хочет иметь полный контроль, и он в своем праве.

2) "https://www.linuxfoundation.org/resources/publications/understanding-us-export-controls-with-open-source-projects явно разрешает взаимодействовать с open source проектами"

Нет, этот текст разрешает экспортировать код куда угодно, если он open source. И это совсем не противоречит той модели open source, которую я описал выше. А только ее усиливает.

Типа, распространять точно можно.

3) "удалением имен мейнтейнеров нарушено авторское право"

Нет, не нарушено, они все еще есть в git, и там и останутся.

4) "надо было скоммуницировать иначе"

Кому надо, и почему надо? Все в своем праве. Никто ничьих прав не нарушил, как я показал выше.

Некрасиво?

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

На самом деле, что произошло реально - это запрет Linux Foundation разговаривать с каким-то количеством подсанкционных компаний (и программистов из них).

И, что самое удивительное, Linux Foundation все еще хочет патчей от этих оргов и людей, и они будут попадать в ядро, так или иначе.