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 все еще хочет патчей от этих оргов и людей, и они будут попадать в ядро, так или иначе.

Снова загружен работой, не до разбора отчета( А пока шутка с внутреннего ресурса:

Сложный код создает сильных инженеров,
сильные инженеры создают простой код,
простой код создает слабых инженеров,
а слабые инженеры создают сложный код.

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

Вот, я недавно (ну как "недавно", в первый раз так-то в 22 году, когда я только начал этот quest) писал про #TMPDIR, и тут, внезапно:

https://dotat.at/@/2024-10-22-tmp.html

Годный, очень созвучный моим мыслям текст, почему общая TMPDIR - плохо.

https://systemd.io/TEMPORARY_DIRECTORIES/

А потом и авторы #systemd подтянулись (они вообще горазды пиздить у меня годные идеи, типа https://t.me/itpgchannel/1871 #suid). Чуть менее годный, но тоже неплохой, текст, на эту тему. Решение проблемы, которое озвучивается там, мне не нравится.

К сожалению, оба текста недостаточно радикальны.

Софта, в котором захардкожено /tmp или /var/tmp, не так уж и много, и его надо патчить, и исправлять. Надеюсь, теперь это станет mainstream, и кода, который хардкодит эти значения, со временем станет меньше.

https://lore.kernel.org/all/3448a096-849a-4f61-8017-c03a83e22c38@gmail.com/

https://lore.kernel.org/all/20241024095339.GA32487@imap.altlinux.org/

Линус хотел русских троллей, он их и получил.

PS: не надо так делать. Это просто мелочно.

PPS: https://lore.kernel.org/all/20241024095708.189649-1-isage.dna@gmail.com/ - тред уже свели к ad Hitlerum, можно расходиться.

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

Очень годный текст, дает ответы на все накопившиеся вопросы про произошедшее.

Полностью согласен!