Miguel Ojeda (https://ojeda.dev/) принёс в рассылку

Hi all,

Given the discussions in the last days, I decided to publish this page
with what our understanding is:

    https://rust-for-linux.com/rust-kernel-policy

I hope it helps to clarify things. I intend to keep it updated as needed.

https://lore.kernel.org/rust-for-linux/CANiq72m-R0tOakf=j7BZ78jDHdy=9-fvZbAT8j91Je2Bxy0sFg@mail.gmail.com/

Who maintains Rust code in the kernel?
The usual kernel policy applies. That is, whoever is the listed maintainer.

The "RUST" subsystem maintains certain core facilities as well as some APIs that do not have other maintainers. However, it does not maintain all the Rust code in the kernel — it would not scale.
. . .
Who is responsible if a C change breaks a build with Rust enabled?
The usual kernel policy applies. So, by default, changes should not be introduced if they are known to break the build, including Rust.

However, exceptionally, for Rust, a subsystem may allow to temporarily break Rust code. The intention is to facilitate friendly adoption of Rust in a subsystem without introducing a burden to existing maintainers who may be working on urgent fixes for the C side. The breakage should nevertheless be fixed as soon as possible, ideally before the breakage reaches Linus.
. . .
Are duplicated C/Rust drivers allowed?
The usual kernel policy applies. So, by default, no.

Rust kernel policy
https://rust-for-linux.com/rust-kernel-policy

Спасибо подписчику за наводку

Меня тут спрашивают, почему давно нет историй про #bootstrap (а мемасиков, наоборот, с лихвой).

Все потому, что, последние две недели, вечерами и выходными, я собирал Chromium.

Предыдущая попытка была ажно вот тут - https://www.tgoop.com/itpgchannel/534, и, насколько я сейчас понимаю, она была обречена на поражение, хорошо, что я тогда это гиблое дело бросил.

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

TL;DR - я сделал!

На этот раз я подошел к делу очень системно:

* Системно нашел последний snapshot Chromium в Alpine, в котором еще не было Rust - https://gitlab.alpinelinux.org/alpine/aports/-/commit/2b73ae849e016647a7b5c0d79d92b0b0574aac1a

* Системно попиздил все патчи из Alpine (потому что musl) - https://gitlab.alpinelinux.org/alpine/aports/-/tree/master/community/chromium

* Cистемно воссоздал все нужное окружение (потому что clang-17 оно собирается, а вот clang-19 - нет) - https://github.com/pg83/ix/blob/main/pkgs/bin/chromium/ix.sh#L4

* Системно продрался через ошибки сборки, потом через ошибки линковки, а потом и через падения на старте.

Падения были вокруг NSS модуля, и я думал, что я поседею, пока это дебажил:

* Найти место, где случилась ошибка, было сложно, потому что она несколько раз преобразовывалась из одного пространства error codes в другое, и грепать это было решительно невозможно.

* А потом нужно было понять, почему же падает инициализация генератора случайных чисел в NSS...

Падало оно вот в этом блоке кода - https://github.com/nss-dev/nss/blob/master/lib/freebl/drbg.c#L237-L241

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

Long story short - в NSS есть https://github.com/nss-dev/nss/blob/master/lib/freebl/drbg.c#L234 (SHA256_Update), а еще SHA256_Update есть в boringssl, которая лежит в исходниках Chromium. И, так уж получилось, версия из boringssl победила, поэтому, конечно, там получалась какая-то дичь, а не хеш.

В общем, в воскресенье оно кое-как заработало, без 3D ускорения, и без живого root CA, но заработало, и это прямо вау!

https://digitalcommons.usu.edu/cgi/viewcontent.cgi?article=5598&context=smallsat

A/B деплой, но не в датацентры, а на группировку спутников starlink.

TL;DR - все, как у всех, с поправкой на то, что там радиация, флапают биты, и слетать на орбиту с флешкой, чтобы переналить, не получится,

Каждый спутник содержит 500 встроенных компьютеров, и деплой надо оркестрировать не только по спутникам, но и по этим устройствам внутри каждого спутника:

"Each satellite is a collection of computers(referred to as “nodes”)in control of various subsystems on the vehicle. The earliest satellites have 80 nodes, the newest have 237 nodes, and future designs approach 500 independent nodes. These nodes have bidirectional communications interfaces with one anotherto achieve coordinated tasks."

#selfhost

Вот, коллеги из xiph.org так и сделали - забили на свой #gitlab, и выкатили новый релиз только на github:

https://gitlab.xiph.org/xiph/flac/-/tags
https://github.com/xiph/flac/tags

Это, безусловно, хорошо, потому что нефиг держать свою #infra, если не умеете (а вы не умеете, чуть менее чем 100%, ага).

#предложка

UPD: в gitlab тоже появилось

https://marcan.st/2025/02/resigning-as-asahi-linux-project-lead/

Штош, закономерный результат всей этой истории:

"I’m resigning as lead of the Asahi Linux project, effective immediately. The project will continue on without me, and I’m working with the rest of the team to handle transfer of responsibilities and administrative credentials. My personal Patreon will be paused, and those who supported me personally are encouraged to transfer their support to the Asahi Linux OpenCollective (GitHub Sponsors does not allow me to unilaterally pause payments, but my sponsors will be notified of this change so they can manually cancel their sponsorship)"

#asahi

тем временем, компания, которая платит деньги автору nixos (https://news.ycombinator.com/item?id=40199153), вполне себе процветает:

https://www.cnbc.com/2025/02/11/anduril-to-take-over-microsofts-22-billion-us-army-headset-program.html

(позволю себе напомнить про начало драмы в nixos - https://discourse.nixos.org/t/nixcon-na-2024-is-getting-sponsored-by-anduril-what-to-do-about-it/41258)

https://dudemanguy.github.io/blog/posts/2025-02-03-wayland-xorg-2/wayland-xorg-2.html

Пишут, что #wayland - торт.

Так же там высказывается непопулярное мнение, что все хорошее в explicit sync в Linux сделано благодаря Nvidia, что очень хорошо aligned с моей точкой зрения, что все хорошее в Linux делают корпорации (#valve) (несмотря на активно сопротивляющееся сообщество).

https://github.com/thomcc/ubrustc

rustc, но без borrow checker.

Классная штука - можно получить пакетный менеджер, норм экосистему библиотек, и не ебаться с borrow checker.

К сожалению, работать это не будет, потому что, помимо borrow checker, на семантику Rust завязаны многие его оптимизации, и они просто сломаются, будет генериться некорректный код.

https://ebpf.foundation/case-study-bytedance-uses-ebpf-to-enhance-networking-performance/

TL;DR - что только не сделают проклятые капиталисты, лишь бы быстрее доставить танцующих телочек на ваши смартфоны!

"With over a million servers running containerized applications, the company required a networking solution that could handle high throughput while maintaining stability. By leveraging eBPF technology, Bytedance successfully implemented a decentralized networking solution that improved efficiency, scalability, and performance"

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

Уязвимость в iconv() в #musl.

Я, как обычно, в домике, потому что в моей #herobora libc iconv() используется из libiconv от GNU.

Итого потребовалось 4 года 5 месяцев

https://creston.blog/wasm-will-replace-containers/

Скорее бы уже, потому что я все еще имею мечту про "правильно" устроенный Linux:

* Все компилируется в #WASI #WebAssembly

* Есть одна большая WebAssembly VM, в которую статически слинкованы "системные" библиотеки - API opengl/vulkan, драйвера для opengl/vulkan (mesa), libc, ABI ядра, fontconfig, harfbuzz, и так далее - все, что имеет стабильный ABI.

* Все пользовательские приложения - тонкие клиенты к этой VM. В них нет свох кешей шейдеров, своих кешей шрифтов, и так далее, все это живет в VM.

* WebAssembly VM - идеальный клей между языками и рантаймами (CGO - тихий ужас, а вот загрузить Rust модуль в #wazero - это заебись. Линковать mesa в каждую программму - тихий ужас, а вот иметь OpenGL как "тонкий клиент" в VM - очень даже хорошо).

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

"Пользователям KDE рекомендовано попробовать перейти на использование сеанса на базе протокола Wayland, так как разработчики KDE практически прекратили тестирование сеанса на базе X11"

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