https://www.phoronix.com/news/Rust-Debian-2025

"around 8% of the source packages in Debian Sid are building against at least one librust-* package. That 8% figure for Debian source packages building against at least one Rust library package is around double of what it is for Debian 12 "Bookworm". Quite a significant uptake over the past few years and it's only continuing to grow with more open-source projects introducing varying levels of Rust integration"

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

У меня против Rust собирается ровно 0 от базовой системы, потому что librsvg для загрузки иконок в gtk я переписал на кастомный #svg loader over #lunasvg/#skia/#svgren (по выбору), и убрал все эти опциональные зависимости.

Ну просто потому, что Rust не является #bootstrap абельным (я не могу собрать его из исходников, не имея под рукой готовый компилятор Rust, подробности в моей эпопее с #mrustc), а это зашквар.

Пока вы спите там Let's Encrypt поплохело

https://letsencrypt.status.io/

Incident Status
Service Disruption

Components
acme-v02.api.letsencrypt.org (Production), {e,r}[1-14].o.lencr.org, acme-staging-v02.api.letsencrypt.org (Staging), stg-{e,r}[1-14].o.lencr.org

Принятие законопроекта, запрещающего, в частности, поиск экстремистских материалов в интернете, является альтернативой полной блокировке в России зарубежных платформ, объяснил в Госдуме глава Минцифры Максут Шадаев

Спасибо

Это отличная новость

Компания Google представила проект OSS Rebuild, предназначенный для выявления скрытых изменений в готовых пакетах, публикуемых в репозиториях. Работа OSS Rebuild основана на концепции воспроизводимых сборок и сводится к проверке соответствия размещённого в репозитории пакета с пакетом полученным на основе пересборки из эталонного исходного кода, соответствующего заявленной версии пакета.

В настоящее время в OSS Rebuild реализована поддержка верификации пакетов из репозиториев NPM (JavaScript/TypeScript), PyPI (Python) и Crates.io (Rust). В будущем число поддерживаемых репозиториев планируют расширить. На практике инструментарий позволяет выявлять варианты атаки класса "supply chain", в ходе которых после компрометации учётных записей сопровождающих или диверсии внутри проекта в репозитории публикуется вредоносное обновление. При этом код в исходном репозитории основного проекта остаётся корректным, а вредоносные изменения вносятся только в готовые пакеты.

Система по возможности автоматически формирует сценарий для воспроизводимой сборки выбранного пакета, используя эвристику и подбирая параметры, позволяющие добиться идентичности артефактов, поставляемых в пакете. Если автоматически не удаётся воспроизвести размещённый в репозитории пакет, возможно ручное добавление сборочной спецификации. После того как удалось воспроизвести пакет, инструментарий OSS Rebuild сохраняет описание процесса сборки для последующей проверки новых версий пакета. Дополнительно публикуется информация для верификации с использованием фреймворка SLSA.

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

Google представил проект OSS Rebuild для выявления скрытых изменений в пакетах
https://www.opennet.ru/opennews/art.shtml?num=63613

Репа
https://github.com/google/oss-rebuild

Оригинал
Introducing OSS Rebuild: Open Source, Rebuilt to Last
https://security.googleblog.com/2025/07/introducing-oss-rebuild-open-source.html

К слову о дичи, я тут давеча с ресурсами и реквестами разбирался в одном кластере. Написал целую тулзу kubectl ps, это эдакий kubectl top но на стеройдах, умеет реквесты/лимиты показывать и по всякому их сравнивать с реальным потреблением.

Возможно кому-то будет полезно
https://github.com/aenix-io/kubectl-ps

Синтаксис позабористее чем у ps aux получился, в общем любой фидбек приветствуется

https://github.com/aenix-io/kubectl-ps

Под этот пост https://t.iss.one/mem_b0lt_Genona/290 пришёл подписчик со странным, но интересным

> Раз речь зашла, кто-нибудь поднимал selinux-sandbox на arch? Че за приколы там с политиками? Какого болта их нет?

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

> У меня арч на личном ноутбуке, решил что пора забуриться в MAC
Считай, из любопытства ноги себе отгрызаю
Ну и хотел песочницу для запуска LLM-генерированного кода, чтобы оно мне патч бармина не спрятало никуда, но это и без селинукса решаемо

Есть у кого опыт, может кто-то что-то подсказать? 🌝

Вот вам небольшая пятничная история. Что делать когда Talos Linux сдох, и вот непонятно из-за чего.
Kubernetes API недоступен (не запускается CRI), у вас нет ничего, кроме доступа к Talos API.

Казалось бы всё. SSH нет, доступа на запись тоже нет. Только ребут или как предлагают сами разработчики Talos Linux:
<irony>нода сдохла, выкинь и заведи новую</irony>

Но не всё так просто, а как же отдебажить что там произошло. Собрать информацию, подготовить баг-репорт, отослать разработчикам containerd и Kubernetes.

Я не хочу чтобы такая ситуация повторялась в принципе когда-либо. Встаёт вопрос: как же нам войти в запущенную дефектную систему.

Здесь стоит немного уточнить что в логике Talos заложено запуск двух containerd.

Один - системный, он запускает контейнеры с талосовые демонами и экстеншенами, а так же etcd и kubelet.
Второй - прикладной, он запускает всё что в кубе, в том числе статик поды.

Сделано это намерено, чтобы кубовый ворклоад не мог заафектить систему. Т.к. чаще всего проблемы возникают именно со вторым ввиду активного пуллинга имаджей, а первый containerd остаётся живым. Но как же запустить контейнер для дебага без работающего Kubernetes API? Ответ - никак. Придётся хитрить.

Talos позволяет указать кастомные image для запуска kubelet и etcd. Этим мы и воспользуемся.

Для начала соберём кастомный образ kublet. Добаляем busybox в имадж и слегка модифицируем код:
https://github.com/kvaps/kubernetes/commit/3e45ecd4a2718bc50f2d951c344b4c439f79e3ae

Собираем Dockerfile, пушим его куда-то и заменяем путь до образа в конфиге Talos.

Вуаля, у нас появляется доступ к системе:

echo 'uname -r' | nc 192.168.1.21 12345
6.12.18-talos

kubelet работает с полными административными правами, поэтому его привилегий должно быть достаточно для дебага всего что необходимо.

Представлены правила для AI-ассистентов, применяемых при разработке ядра Linux
https://www.opennet.ru/opennews/art.shtml?num=63631

Определены следующие ключевые принципы для AI:

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

Документация, которую должен учитывать AI-ассистент:

- Руководство, как стать разработчиком ядра.
- Информация о процессе разработки ядра.
- Руководство по передаче своего кода в ядро.
- Чек-лист проверок перед отправкой кода в ядро.
- Требования к стилю и оформлению кода (использование табуляции для выравнивания, не больше 80 символов в строке, отдельные правила форматирования функций и условных выражений).
- Требования к языкам программирования и стандартам.
- Запрет использования устаревших программных интерфейсов и возможностей.
- Правила отправки патчей для включения в ядро.
- Настройки почтового клиента для отправки патчей.
- Правила приёма патчей.
- Правила лицензирования кода для ядра (лицензия GPL-2.0 c исключениями для системных вызовов, наличие SPDX-идентификаторов лицензии в каждом файле).
- Инструкция по добавлению нового системного вызова.
- Правила для отправки патчей к стабильным веткам ядра.
- Обработка проблем с безопасностью.
- Действия при выявлении регрессий.
- Руководство по взаимодействию с сопровождающими.
- Руководства, специфичные для подсистем.

Для выделения изменений, подготовленных с использованием AI, к коммиту предписывается прикреплять тег "Co-developed-by: $AI_NAME $AI_MODEL $AI_VERSION". Например: "Co-developed-by: Claude claude-3-opus-20240229", "Co-developed-by: GitHub-Copilot GPT-4 v1.0.0" и "Co-developed-by: Cursor gpt-4-turbo-2024-04-09". При этом AI-ассистент не должен добавлять себя в тег "Signed-off-by".

Вообще, судя по списку, проще отказаться от использования AI-ассистентов, чем контролировать соблюдение ими всех требований 🌝

Оригиналы сообщений
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/
https://lore.kernel.org/lkml/[email protected]/

Я это мнение слышал и читал много раз: быть таким же успешным как Red Hat с open source может только Red Hat.

Текста в посте изначальном сильно больше, я постарался оставить у себя основные выдержки.

Giant value creation, very little value capture. That is the Red Hat model. The first company to successfully commercialize open source software at scale, Red Hat managed to make a billion-dollar business out of selling vetted open source updates and providing multi-product support, services, and training. At first, the model seemed like it could be the blueprint for commercial open source software. The only problem is no other company has been able to replicate this model successfully.

Low rake

he company generates way more value than it captures and has a low rake out of necessity—none of the software it creates is proprietary. If Red Hat tried to force people to pay too much, everyone would switch to the freely distributed versions (AlmaLinux, Rocky Linux, etc.).

A complicated model under constant threat

Red Hat’s 30+ products span a huge range of categories, from platforms to application services to cloud computing, data services, and automation. According to Gartner, the company competes with nearly every major technology company. It’s under constant threat of being disrupted or undermined by other open source providers.

The open core model

Most open-source-based startups today are focused on a single product. These companies generate higher rake by adopting an open core model: making some of the codebase proprietary but source-available. Many companies have started with a similar updates and services model, but the open source companies that have shown exponential growth ultimately went public with an open core model.

The Red Hat model won’t be repeated. In reality, open core is the most economically viable model for commercializing open source software. It’s poised to replace proprietary software as the default and is the path for open source projects to develop into sustainable businesses.

Support and services models don’t achieve hypergrowth

Developing features under a support model gives you no entitlement to the technology. And, if you’re good at what you do, you’ll eventually put yourself out of a job since customers can use it without help.

The Red Hat model only worked for Red Hat
https://www.opencoreventures.com/blog/the-red-hat-model-only-worked-for-red-hat