https://www.phoronix.com/news/RadeonSI-ACO-Complete #aco

Совершенно классная новость - коллеги из #mesa добавили в драйвер opengl radeonsi возможность использовать компилятор шейдеров ACO, из vulkan драйвера radv.

Я напомню, что одной из причин моих мучений с #zink как раз была необходимость собирать (и влинковывать во все программы, которым нужно 3D ускорение) толстые запчасти из LLVM.

Теперь zink становится для меня существенно менее релевантным, хотя я и продолжаю считать, что в long term opengl драйверы должны исчезнуть, как класс, остаться должны только vulkan драйверы, ну и zink, как generic opengl поверх. В этом контексте можно упомянуть https://www.phoronix.com/news/Mesa-23.3-rc1-Released - open source vulkan для NVidia цветет, пахнет, и развивается, что тоже очень хорошо.

И таки шо, вы поверили, что это мой ДЦ?

Мой ДЦ вот на этой вот картинке!

6 юнитов, суммарно 38 + 56 + 3 * 8 + 88 == 206 ядер, диска и прочего пофиг сколько.

Вообще, удивительно, сколько стоит б/у compute, после амортизации в 3 года.

Одно ядро (вместе со всем обвязом и памятью) стоит < 10$.

Хороший стоечный сервер стоит дешевле, чем хороший ноутбук - https://anyserver.ru/catalog/servery_b_u/server_supermicro_6018u_xeon_2x_e5_2696v4_192gb_2133p_ddr4_4x_nohdd_3_5_raid_c612_sata_ssd_psu_2_750/

В странном мире живем, товарищи!

У нас сегодня задачка на #bootstrap!

Вводные:

* у нас есть Wayland, Xorg, и XWayland
* у нас есть session/display manager (в широком смысле этого слова) - это штуки, которые управляют запущенными пользовательскими сессиями, которые могут быть консольными, а могут быть как выше написано.
* у нас есть sway, и прочие wlroots-based композиторы, которым не нужен display manager, и которые просто запускаются вот в том kms tty, в котором вы их запустили

Задача:

Как сделать так, чтобы при закрытии крышки ноутбука компьютер ушел в сон, а потом во всех сессиях показал окно ввода пароля (lock screen)?

Если первая задача вам показалось слишком сложной (ну вот как мне) - то как это сделать хотя бы для текущей сессии в sway? Если вам это кажется простым, то продумайте, как устроено взаимодействие того же swaylock, штуки, которая слушает acpi events, и штуки, которая может отправить ваш ноутбук в сон по событию "закрылась крышка ноутбука".

UPD: если мы готовы переписать кучу кода, и заставить все системы "стать ежиками", то эту задачу примерно понятно, как решать. Задача, конечно, про то, как это сделать "сейчас"!

https://www.jeffgeerling.com/blog/2023/everything-ive-learned-building-fastest-arm-desktop

Совершенно бессмысленный текст про то, как автор запилил самый быстрый десктоп на arm. Я-то думал, что там что-то интересное, но ничего подобного, чувак просто купил референсную платформу от Amper.

Зачем я тогда про это пишу?

Потому что из текста я узнал про существование https://www.ipi.wiki/products/ampere-altra-developer-platform?variant=42970872086690!

Если, вдруг, вы неприлично богаты, и всегда хотели подарить мне что-то на день рождения или на новый год - то вот, пожалуйста, у вас есть такая возможность!

Реально, очень крутая штука, жалко, что пощупать ее нет никакой возможности.

Новости из мира Linux:

https://www.phoronix.com/news/Bcachefs-Merged-Linux-6.7 #bcachefs

bcachefs вот так взяли, и смержили в 6.7. Видимо, #Kent нашел правильное место, куда надо лизнуть, потому что иначе такой прогресс сложно объяснить.

Вышло ядро 6.6 - https://www.opennet.ru/opennews/art.shtml?num=60016 #scheduler

В нем, из прямо очень интересного, - совсем новый шедулер процессов. На этот раз коллеги, прежде чем велосипедить почем зря, прочли какую-то статью, из академии - https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=805acf7726282721504c8f00575d91ebfd750564 Я эту статью пытался прочесть уже раза 3, но где-то посередине текста мне становится очень скучно, и я откладывал ее на полочку. Радует, что там есть какая-то понятная модель, и, какой-никакой, но матан!

#llvmweekly #cplpl_doomed

https://discourse.llvm.org/t/abi-break-in-libc-for-a-17-x-guidance-requested/74483

"The libc++ has informed me that would like to break the libc++ ABI for the next point release of 17.x because of a bad bug in std::expected. See issues here"

Коллеги хотят сломать ABI в libc++.

Не просто так, а чтобы починить баг, в каком-то классе, который раньше был experimental (поэтому баг никто не замечал), а в 17 кленге его вывели в stable.

#abi - зло. Хотя бы потому, что заставляет несколько важных (и занятых) дядек обсуждать эту херню на серьезных щщах.

"Ах, отвести ли нам 17.1, ох, нет, давайте вмержим в 17.0.4"

ABI - одна из многих причин, которая тянет С++ на дно.

Нет чтобы пересобрать приложение, и забыть про этот баг, как про страшный сон.

https://github.com/llvm/llvm-project/commit/f364a7a8b491 #llvmweekly

В продолжение истории про то, что в llvm libc не должно быть файлов на ассемблере.

Как говорится, "если нельзя, но очень хочется - то можно"!

Если нам нельзя писать на ассемблере, то мы будем аугментировать код до тех пор, пока компилятор не поймет, чего мы от него хотим - https://github.com/llvm/llvm-project/commit/f364a7a8b491#diff-ae0a68397a667201eac91b06463249422d986f6f0a3b5ac54bc1d8e03a9bea7eR102-R103

Всратая policy, всратые workaround.

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

Не делайте так.

Искал тут в инторнетах ответ на вопрос "а как напечатать содержимое thread local переменной в статически слинкованной программе в gdb" (ответ, кстати, совершенно нетривиальный, но про это в другой раз)

В процессе поиска наткнулся на совершенно шедевральный труд - https://fasterthanli.me/series/making-our-own-executable-packer

Все про #elf, #dwarf, #gdb, #glibc, shared/static linking, устройство thread local, и все такое.

Чувак про это пишет в контексте разработки executable packer (на Rust, а как же иначе), я до сих пор читаю (549 minute read!!!), и вы почитайте.

#gold

https://nixcademy.com/2023/10/31/cpp-with-nix-in-2023-part-1-shell/

Продолжение темы про использование #ix/nix/guix в качестве dev окружений. #dev_shell #ix_run

Мне мой "ix run", конечно, кажется более простым и лаконичным, чем то, что по ссылке, но, все равно, и то, и другое, - много лучше альтернатив.

Важное отличие #ix от nix/guix - мои артефакты можно невозбранно использовать в любом Linux, а не только там, где есть подходящий store с сотней .so-шек.

#bug12309

Слушайте, а вы обратили внимание, что, "тихо и незаметно", 12309 таки починили?

Я это связываю с внедрением MGLRU - https://www.kernel.org/doc/html/next/admin-guide/mm/multigen_lru.html

Вообще, удивительно, механизм делали чтобы починить 12309, и он его таки и чинит - довольно необычно в kernel community. Наверное, потому что это запилил Google, а не какой-нить рандомный васян.

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

https://www.phoronix.com/review/bcachefs-linux-67 #Kent

А вот подоспели бенчмарки #bcachefs от Михаила.

(напомню, что его бенчмаркам веры нет - https://xn--r1a.website/itpgchannel/1402, но, думаю, для троллинга автора bcachefs они сойдут)

Спойлер - у bcachefs все не очень, как с перфом (последние места на почти всех нагрузках), и с надежностью (не любой ssd можно под нее отформатировать).

Зато этот бенчмарк подтверждает мой старый тезис - "#xfs - лучшая FS в Linux". Вот, реально, не знаешь, что выбрать - выбери #xfs.

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

"Опубликован репозиторий OpenELA для создания дистрибутивов, совместимых с RHEL"

А вот это, КМК, знаковое событие.

Потому что чем сильна RHEL, и centos (ранее)?

Тем, что вендоры выдают сертификат на софт или на железо, и этот сертификат довольно много кому важен.

Понятное дело, что на все там Генты и прочие #stal/IX сил у вендора не хватит, и он выдаст его на два самых популярных дистрибутива (догадайтесь, каких).

Теперь же ситуация может радикально поменяться - будут выдавать сертификат на вот этот вот OpenELA (or compatible), с которым будет совместим много кто.

Ну и, конечно, рекурсивно замкнуть эти рассуждения надо предположением, что однажды RHEL/CentOS придется сертифицироваться на соответствие OpenELA (который, напомню, должен быть изначально совместим с RHEL/CentOS), хехе.

https://mjg59.dreamwidth.org/68350.html

Хороший текст про ACPI, зачем это, и с чем его едят.

TL;DR - это набор хуков на некотором интерпретируемом байткоде, которые может дернуть OS, чтобы firmware сделало что-то для OS.

В целом, ACPI очень позитивно сказалась на портабельности Linux на новое железо.

КМК, это хорошо коррелирует с темой, которую я загонял в цитируемом посте (https://xn--r1a.website/itpgchannel/218), что, мол, Linux-у отведена роль реализации POSIX API поверх черного ящика, которое обеспечивает настоящая, bare metal, OS (firmware), которую Linux будет дергать вот такими вот "ACPI"-подобными хуками.

Будни #bootstrap, #rant

Вышла новая elfutils - https://sourceware.org/elfutils/.

Ну вышла и вышла, с кем не бывает.

Как обычно, авторы гнутых тулчейнов делают вид, что, кроме gnu, в этом мире ничего и нет:

checking for __cxa_demangle in -lstdc++... no
configure: error: __cxa_demangle not found 
    in libstdc++, use --disable-demangler 
    to disable demangler support.

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

И не рассказывайте мне, что они там про это не знают, или что более хороший тест на проверку наличия написать сложнее. Знают, не сложнее, просто им наличие альтернативы в мире open source - как кость в горле.

Конечно, приятнее быть the open source toolchain, а не одними из многих, с которыми нужно договариваться.

Починил я это так - https://github.com/pg83/ix/blob/main/pkgs/lib/elfutils/t/ix.sh#L23 Я уже давно перестал патчить исходники про такое. Ну вот хотят люди libstdc++ - ну получат они пустую фейковую библиотеку, а функция появится из другого места.

elfutils эти, кстати, сломанные, с ними не собирается ядро Linux, пришлось откатить.