https://lwn.net/ml/all/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/

https://lwn.net/ml/all/CAHk-=wi=ZmP2=TmHsFSUGq8vUZAOWWSK1vrJarMaOhReDRQRYQ@mail.gmail.com/

Схватился дед с батей автор #asahi, и Linus.

Гектор решил поиграть в SJW, и пошеймить процесс разработки ядра (в связи со всей этой растоисторией https://www.tgoop.com/itpgchannel/2683), и получил ответ.

"However, I will say that the social media brigading just makes me not want to have anything at all to do with your approach.

Because if we have issues in the kernel development model, then social media sure as hell isn't the solution. The same way it sure as hell wasn't the solution to politics."

"И эти люди мне будут рассказывать, что расто community не токсичное", ага:

https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/

"Rust folks: Please don't waste your time and mental cycles on drama like this. It's not worth your time. Either Linus likes it, or he doesn't. Everything else is distractions orchestrated by a subset of saboteur maintainers who are trying to demoralize you until you give up, because they know they're going to be on the losing side of history sooner or later. No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages"

Вот за это и не любят, за "blazingly fast more memory safe изо всех щелей No amount of sabotage from old entrenched maintainers is going to stop the world from moving forward towards memory-safe languages".

(kernel community так-то тоже не очень, но это не извиняет)

И это может звучать несколько противоречиво, но сердцем-то я на стороне этих новичков, потому что, если не принимать во внимание форму, тут все очень верно написано - https://lwn.net/ml/all/208e1fc3-cfc3-4a26-98c3-a48ab35bb9db@marcan.st/, и почему я лично не притронусь к ядру, пока оно вот такое, ни за какие деньги.

Изначальная картинка взята из этой статьи

NowSecure Uncovers Multiple Security and Privacy Flaws in DeepSeek iOS Mobile App
https://www.nowsecure.com/blog/2025/02/06/nowsecure-uncovers-multiple-security-and-privacy-flaws-in-deepseek-ios-mobile-app/

https://herecomesthemoon.net/2024/11/two-factions-of-cpp/

Классный текст про современное состояние С++ (спойлер - мы все обречены), а я пропустил.

Самое интерeсное (по мне) в этом тексте - это утверждение "там, где система сборки хорошая, там и кодовая база С++ тоже норм, а если нет, то нет". Это не совсем очевидно, но, чем больше про это думаешь, тем лучше видна связь.

https://lwn.net/ml/linux-fsdevel/CAHk-=win2x_KORa1CJTaX0VrBy9ug_GXNwPpcPXVQbedHSYhsg@mail.gmail.com/

Linus про https://github.com/facebook/folly

"The fact that you think that some completely broken C++ code was "written with high quality", and you think that is an excuse for garbage is just sad.

Those C++ libraries WERE INCREDIBLE CRAP. They were buggy garbage. And no, they are in no way going to affect the kernel and make the kernel do stupid and wrong things"

Полностью поддерживаю!

Теперь тот же самый мейнтейнер жалуется на тяжелую жизнь:

https://lwn.net/ml/all/20250208204416.GL1130956@mit.edu/

"And note, this has nothing to do with who employs me; the 15-20 hours that I spent working on creating the fix and the test scripts was purely on my own time, on the weekend, or late at night. The time that I spend doing this isn't reflected in my performance reviews, or promotion propects --- in fact, arguably, over the past 15 years, this has probably slowed down my promotion prospects; I've only been promoted once since joining said big tech company..."

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

Хотите помощи - принимайте и что-то новое.

Есть цитата, приписываемая Эйнштейну (не говорил https://pikabu.ru/story/govoril_li_yeynshteyn_samaya_bolshaya_glupost__delat_to_zhe_samoe_i_nadeyatsya_na_drugoy_rezultat_8432127) "Самая большая глупость — делать то же самое и надеяться на другой результат" - вот она тут хорошо подходит.

Надо делать что-то новое.

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 завязаны многие его оптимизации, и они просто сломаются, будет генериться некорректный код.