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

Еще в тему фаззинга CPU.

На этот разу улов интереснее, правда, не в столь массовых процессорах.

Особенно доставляет

"Одна ошибка классифицирована как возможность встраивания скрытой логики на этапе проектирования чипа. Проблема присутствует в открытом пакете Yosys, предназначенном для синтеза уровня регистровых передач (RTL) и применяемом при проектировании и эмуляции CPU. Ошибка привела к синтезу некорректной логики в FPU процессора CVA6. Злонамеренный участник разработки может использовать данную проблему для внесения скрытой ошибки в проект, в котором для синтеза логики применяется Yosys, через передачу внешне безобидного описания уровня регистровых передач (RTL)"

Злонамеренный код в тулинге для разработки CPU!

Если это правда, то это даже круче, чем атака Томпсона https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf

Внезапно понял, что проморгал, что каналу исполнилось два года!

Принимаю поздравления, а так же предлагаю like, шер, ретвит, если канал по душе!

#хозяйке_на_заметку, #я_просто_оставлю_это_здесь, #llvmweekly

https://www.npopov.com/2023/10/22/How-to-reduce-LLVM-crashes.html

Мало кому будет интересно, но вот если вы ловили ICE в clang, и вам ОЧЕНЬ нужно это зарепортить, то по ссылке способ получения minimal test case.

https://unixsheikh.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html

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

Пишет, что люди все больше и больше учатся какому-то такому слою абстракций (e.g. framework, tool, etc), нежели понимают, как все работает "на самом деле".

Мне тут, конечно, в голову сразу приходит аналогия с Foundation Айзека Азимова, конкретно, с частью, где описывается Трантор, как работающая система, которая стала настолько сложна, что постепенно приходит в упадок, потому что никто не понимает, как ее чинить.

Я не согласен с автором!

Даже в рамках этого блога я кидал десятки ссылок на то, как люди, когда "припрет", находили багу от очередного JS framework, до V8, и дальше, вглубь, до ошибок защиты OS/процессора/whatever.

Короче, системы у нас пока не такие сложные, при желании, все можно понять.

Отдельно хочу поговорить с телевизором подискутировать с

"Everything in the tech industry is driven with a very hardcore eye for profit and very little interest in anything else. So you need to be able to push out new products or new services as fast as possible. This means more abstraction and more automation, less and less people, and less deeper understanding.

Today programmers and system administrators no longer exist, instead we have DevOps and even DevSecOps, in which the industry is trying very hard to stuff every single task into the job description of a single individual"

Слушайте, ну это какое-то явное непонимание сути devops. DevOps - это не про то, чтобы суммарно людей, которые пилят продукт, стало меньше (или дешевле), это, в первую очередь, про ответственность - надо, чтобы когда разработчик послал плохую программу в прод, то он просыпался ночью от звонков мониторинга.

Вот такой вот простой и тупой feedback loop - наговнокодил - не спи ночью.

Кстати, именно поэтому, когда я вижу вакансии "devops", у меня волосы шевелятся на всех частях тела, потому что это очередное извращение идеи. Вместо перекладывания ответственности на программиста, происходит подмена понятия, и "devops" получается такой современный "администратор, который автоматизирует свою работу", что, конечно же, треш, угар, и содомия.

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

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), хехе.