AI-стартапы наглядно

Продолжаем тему https://xn--r1a.website/itpgchannel/2798 https://xn--r1a.website/itpgchannel/2673

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

"Продолжен перенос изменений из ветки Rust-for-Linux, связанных с использованием языка Rust в качестве второго языка для разработки драйверов и модулей ядра"

"Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной ветки ядра Linux, охарактеризовал текущее состояние, как "почти готовность к написанию реального драйвера на Rust" https://lore.kernel.org/lkml/Z5kokYUDYEO2Cknj@kroah.com/"

UPD - звук к процессу - https://www.youtube.com/watch?v=BzNzgsAE4F0

Будни #bootstrap

В саппортный чат #stal/ix (не ищите, там нет ничего интересного) пришел интересный коллега, и рассказал, что он случайно пришел к такому же дизайну пакетного менеджера, и OS на его основе:

https://ccx.te2000.cz/stagit/pthbs/file/README.html (диздок 1-в-1 как у IX)

Понятное дело, что тут очень много схожего с прародителями, типа Nix/Guix, но вот есть важная деталь, которая обеспечивает новизну этого дизайна:

"Jinja-based templating system for generating package definitions for pthbs"

https://ccx.te2000.cz/stagit/mrrl/file/templates/pkg/bison.html - вот, например, его пакет с bison.

Много общего с тем, как устроено у меня.

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

#llvmweekly

https://nnethercote.github.io/2025/03/19/how-to-speed-up-the-rust-compiler-in-march-2025.html

"Every LLVM major update for several years has made the Rust compiler faster. This is not due to some law of nature. Rather, it reflects sustained, excellent work from the LLVM developers. Kudos to them"

UPD:

Several years ago:

https://www.npopov.com/2020/05/10/Make-LLVM-fast-again.html

> Each LLVM release is a few percent slower than the last. LLVM 10 put some extra effort in this area, and somehow managed to make Rust compilation a whole 10% slower, for as yet unknown reasons.

(далее описывается внедрение CI с бенчмарком)

Вышел-таки релиз смака 4.0!
Авторы решились поднять мажор, чтобы подсветить изменения в обратной совместимости и аккуратно выпилить старьё времён версии 2.8.ххх, старее, и вверх до версии 3.5 - старые политики, некоторые кривые вещи, устаревшие ещё с начала 10-х годов, хотя, по изменениям релиз минорный (до февраля это был ещё релиз 3.32, жалко, что красивой цифры 3.33 мы так и не увидели).
Для поддержки сборки проектов, которые собирались на последних версиях (3.31, 3.30 и некоторых раньше) добавили переменную окружения для мейнтейнеров старья CMAKE_MINIMUM_POLICY_VERSION
, и ей надо задать версию 3.5, чтобы старые проекты не ругались на старые политики сборки, которые были удалены. Авторы смака вместе с мейнтейнерами некоторых дистров (дебиан, Федора) помогли починить кое-где сборку.
Если у вас проект, у которого стоит cmake_minimum_required(VERSION 3.4) и ниже - пора обновиться, желательно на 3.10. (у проектов, у которых нет этой команды вверху, лучше добавить эту команду, чтобы правильно применять политики обратной совместимости).
Помимо этого, там:
- в рамках тикета нашли багу в LLVM, в его поддержке модулей c++20 для clang/libc++ (Там глава Kitware зачинил багу);
- Продолжают внедрять и стабилизировать CPS - декларативный формат для внешних зависимостей, которые потом будут цепляться через find_package(libmeow COMPONENTS paws)
- Улучшают инструментацию сборки/конфигурирования проекта (активности примерно начались с версии 3.18, когда добавили простую возможность профилирования этапа конфигурации проекта), теперь можно будет получить более детальную информацию о том, что именно подтормаживает при процессе конфигурации/сборки проектов. Формат данных - flame-graph, включить в своем проекте можно через флаги --profiling-output=<filename> --profiling-format=google-trace, например: cmake -S . -B build --profiling-output=configure-profile.json --profiling-format=google-trace. Полученный JSON можно скормить служебной странице хромиумоподобных браузеров about:profiling, в случае с Firefox - на profiler.firefox.com. Также такие файлы понимают некоторые IDE, типа Qt Creator, vscode и пр.

В четвертой версии эту вещь расширили (на сборку, линковку, кастом-шаги), написали документацию, и сделали возможность задавать свои хуки на измерения, общаться через CMake File API (используется IDE-шками для сбора ВСЕЙ метаинфы о проекте, о таргетах, исходниках и пр.). Новая фича спрятана под волшебным идентификатором CMAKE_EXPERIMENTAL_INSTRUMENTATION. Такие идентификаторы описаны тут (там и про CPS, и про find_package() с CPS, и про import std, который все ещё не достаточно стабильный, и авторы CMake ходят фиксят/репортят баги в апстримах). Эта тема будет интересна для авторов IDE, для девопсов и тех, кому хочется найти узкие места сборки как локально, так и на CI/CD, и я, возможно, сделаю по этой теме отдельную заметочку;
- потихоньку улучшается дока по CMake , поэтому рекомендую периодически ее посматривать - авторы за релиз обычно много всяких полезных уточнений делают/принимают от волонтеров
- на мобильных устройствах теперь левая колонка со ссылками спрятана в "бутерброд"-кнопку контекстного меню;
- старые генераторы для MSVC, которые принимали в своем имени битность архитектуры (вида "Visual Studio 2015 64") были дропнуты в пользу флага -A <arch-name>
- Теперь можно экспортировать журнал конфигурирования проекта в формат SARIF через флаг --sarif-output=<file>
- Началась работа над генерацией SPDX SBOM
- Пачка прочих изменений (384 мерж-реквестов было слито, и там сотни файлов и тысячи строк были дропнуты после удаления старых вещей)
- также там был влит мой "фермерский" MR с фиксом кодировки текста ошибки, который можно получать через функцию FormatMessage(), там неверно интерпретировалась строка как юникод (haha, classic).

Другие изменения (а я рассказал только про удаленные вещи и про интересные экспериментальные фичи) можно глянуть в списке изменений тут: https://cmake.org/cmake/help/v4.0/release/4.0.html

#длиннопостик #смак #cmake #cpp #cxxmodules #profiling #build

v1.1.1-2025-03-09-0046

#длиннопостик@AlexFailsChannel

А кросс-компиляции как не было (https://xn--r1a.website/itpgchannel/132), так и нет. И не будет, ага.

Помните, в прошлом году делали софт для умного дома Дилдок.Лайф. Там у них мега-навороченные умные унитазы с голосовым ассистентом. Мы их предупреждали, что такое случится, но они не слушали и требовали делать всё по их ТЗ.

И вот итог:
1. Дата-центр лежит уже 3 часа.
2. Их умные унитазы из-за отсутствия соединения отказываются смывать. Ручной кнопки смыва в них не предусмотрено, всё только через голосового помощника или с телефона управляется.
3. Вся их умная бытовая техника тоже не работает или заглючила. Даже чайники не работают. А роботы-пылесосы активировали режим «skynet».
4. Техдир из Лайфа просит нас срочно что-то сделать, любые деньги предлагает.

Я ему посоветовал смывать в унитазе пока из ведра. Но у него дома умные краны, и они тоже не работают.

#стояделали

#AMDVLK #mesa #ANGLE

После того, как я понял, что, в принципе, AMDVLK умеет жить без X, потому что он так живет на Android, я таки осилил его собрать, и даже позапускать какие-то приложения.

В целом, все работает, и у меня теперь ажно 3 различных реализации vulkan - https://github.com/pg83/ix/blob/main/pkgs/lib/vulkan/drivers/ix.sh#L3-L12

Собрать было не очень сложно, сложно было скачать, потому что они распилили кодовую базу на 7 частей, и склеивают их довольно странным образом, мне пришлось все это переработать, потому что CI в сеть не должен ходить, а их скрипты ходят.

https://github.com/pg83/ix/blob/main/pkgs/lib/amd/vlk/ix.sh#L58-L100

Из неприятного - произвольный бинарь с AMDVLK становится мегабайт на 50 толще, потому что они, зачем-то, хотят очень приличный кусок от LLVM, и не только сам LLVM (его много кто хочет, для шейдеров), а еще и запчасти от clang.

https://github.com/mesonbuild/meson/issues/5024

Мучительный тред про добавление в #meson C++ modules (все еще Open).

Основная решаемая задача - надо как-то распарсить исходники, чтобы понять, в каком они модуле. Но это сложно:

#if __has_feature(frobnitz)
import frobnitz;
#else
import fallback.frobnitz;
#endif

И вторая проблема - а как и когда понять модуль сгенеренного С++ исходника.

Тред - просто сплошная боль и мучения, из серии "я сходил в clang, и они хотят вот это вот сделать так, а msvc не хочет так, а у gcc вообще свой путь".

Кажется, что они пока так и не договорились, какие расширения должны быть у исходников с модулями:

"we need a way to determine whether a C++ source should be treated as a module. VS and Clang use (different) specific extensions, gcc does not"

Понимания о том, когда парсить, как парсить, как на основе информации от компилятора обновлять dep graph, у них тоже пока нет.

Подогнали классный сайт - https://arewemodulesyet.org

TL;DR - в год примерно 4.5 проекта начинают поддерживать модули, и, такими темпами, на всеобщую поддержку понадобится 500 лет!

В целом, автора странички крупные проекты игнорируют, потому что "работать надо", а серьезный профит от модулей все еще не показан.

https://www.phoronix.com/news/Ubuntu-Details-No-O3-Everywhere

https://www.phoronix.com/news/Ubuntu-No-O3-Easier-ARM64

Внезапно в Ubuntu поняли, что O3 не нужен, и решили его откатить, потому что:

"Distro-wide O3 does not seem to provide better performance and regresses it in interactive tasks. It affects load times by up to 11.9% which is detrimental to container workloads that strive for fast application startup.

Overall, this regression is mostly caused by the increase in the executable size. In addition, in some situations -O3 and Link Time Optimization together can result in excessive function inlining which then in turn regresses performance (presumably through register pressure or instruction cache thrashing).

It is fair to say that all of this is inline with conventional wisdom: -O3 can help in some situations but is not a sensible default. But it is definitely better to verify this than just rely on folk knowledge! In addition we still want to investigate more ways to improve the performance of Ubuntu, and each time we exercise our benchmarking muscles we will get better at it"

Я как-то писал свою точку зрения про #O3 - https://xn--r1a.website/itpgchannel/448, с тех пор особо ничего не поменялось.

#infra #gitlab #selfhost

Продолжаем тему https://xn--r1a.website/itpgchannel/2544

https://vikunja.io/changelog/moving-to-github/

А вот вам совершенно взвешенный подход к делу, когда человек - не фанатик, и решает насущные проблемы:

"But right now, the practical benefits of GitHub outweigh the advantages of self-hosting"

"While self-hosting sounds great in theory, the reality is that it can create many more problems for a project of our size. By moving to GitHub, we're choosing to focus our energy on building great software and fostering a community of contributors"

Спасибо нашим радиослушателям за ссылку!

https://clickhouse.com/blog/rust

Рубрика "физики шутят". История интеграции rust в clickhouse.

"To not risk the mental health of our precious senior C++ developers, I outsourced this task to an undergrad student. To be honest, it's much easier to find Rust experts among undergrad students than inside the company"

"everyone else thinks "What a wonderful idea, and, also, Rust" and gives this project a star on GitHub. This is, by the way, how most of Rust projects get their stars on GitHub. It doesn't look like someone wants to use this language, but what we want is to ride the hype"

"Rust is a memory-safe programming language, but to the surprise of our contributors, the first attempt to add Rust code often leads to a segmentation fault"

"Also, we disabled debug info for all Rust libraries, because as Rust is safe, who needs to debug it?"

Отмечается отсутствие удобной обработки ошибок (динамические исключения), и, как следствие, лишние паники, разбросанные по коду используемых библиотек. Оказалось, что паники в Rust таки можно ловить - https://github.com/ClickHouse/ClickHouse/pull/60615, и это хорошо, можно писать простой линейный код, чтобы там не думали апологеты обработки ошибок через возвращаемые значения. Правда, я так и не понял, будут ли корректно освобождены ресурсы, если так делать.

better