| · | 31.05.2026 | Доступен дистрибутив NixOS 26.05, использующий пакетный менеджер Nix (20 +8) |
|
Представлен релиз дистрибутива NixOS 26.05, основанного на пакетном менеджере Nix и предоставляющего собственные разработки для упрощения настройки и сопровождения системы. В NixOS вся настройка системы осуществляется через единый файл системной конфигурации configuration.nix. Предоставляются возможности для быстрого отката системы на предыдущую версию конфигурации и переключения между различными состояниями системы. Поддерживается установка индивидуальных пакетов отдельными пользователями и возможность одновременного использования нескольких версий одной программы. Обеспечены воспроизводимые сборки. Для архитектур x86_64 и ARM64 подготовлены установочный образы с графическим окружением (3.7 ГБ) и сокращённым консольным вариантом (1.6 ГБ).
При использовании Nix результат сборки пакетов хранится в отдельном подкаталоге в /nix/store. Например, после сборки пакет firefox может записываться в /nix/store/8onlv1pc3ed6n5nskg6ad4twcfd0d5ae4ed5c4-firefox-151.0.2/, где "8onlv1pc3ed6n5nskg6ad4twcfd0d5ae4ed5c4" является хешем всех его зависимостей и инструкций сборки. Под установкой пакета подразумевается его сборка или скачивание уже собранного (при условии, что он был уже собран на Hydra - сервисе сборки проекта NixOS), а также формирование директории с символическими ссылками на все пакеты в профиле системы или пользователя, с последующим добавлении этой директории в список PATH. Аналогичный подход применяется в пакетном менеджере GNU Guix, который основан на наработках Nix. Коллекция пакетов представлена в специальном репозитории Nixpkgs. Основные новшества:
| ||
|
Обсуждение (20 +8) |
Тип: Программы |
| ||
| · | 30.05.2026 | Первый стабильный выпуск эталонной реализации видеокодека AV2 (119 +28) |
|
Альянс Open Media (AOMedia), курирующий разработку форматов кодирования видео AV1/AV2, формата объёмного звука IAMF и формата изображений AVIF, опубликовал релиз проекта AVM 1.0.0, развивающего официальную эталонную реализацию кодировщика и декодировщика формата кодирования видео AV2. AVM включает оптимизации для процессоров на базе архитектуры ARM64, x86_64 и MIPS, реализованные с использованием расширенных наборов инструкций NEON, AVX2, SSE2/3/4, MSA и DSPr2. Код AVM написан на языке Си и распространяется под лицензией BSD. Одновременной опубликован финальный вариант спецификации AV2.
Кодек AV2 не требует лицензионных отчислений и развивается в качестве преемника формата AV1. Особенности кодека AV2:
При тестировании одного из экспериментальных выпусков библиотеки avm использование кодека AV2 позволило добиться снижения битрейта на 32.59% по сравнению с кодеком AV1 при аналогичном уровне качества, при использовании метрик оценки качества VMAF (Video Multi-Method Assessment Fusion), разработанных компанией Netflix. При использовании метрик PSRN-YUV (Peak-Signal-to-Noise Ratio 14:1:1) битрейт удалось снизить на 28.63%. При этом судя по отзывам пользователей, опробовавших библиотеку AVM, производительность и качество кодирования на высоких битрейтах пока оставляет желать лучшего. Также как и в кодеке AV1, в AV2 задействована гибридная блочно-ориентированная структура, но в отличие от AV1 поддерживается более крупные суперблоки 256×256, полностью рекурсивное секционирование (partitioning) и более эффективное разделение параметров яркости и цветности. В AV2 используеся унифицированный экспоненциальный квантизатор, охватывающий более широкий диапазон яркости и обеспечивающий большую точность квантования для 8-, 10- и 12-битного видео, а также лучше управляющий низкими битрейтами. Возможности предсказания межкадровых изменений модернизированы для повышения качества моделирования изменения яркости и цветности, учитывают при построении модели до 7 предыдущих кадров, поддерживают временну́ю (temporal) интерполяцию и лучше обрабатывают движение в видео с высоким разрешением или быстро меняющимся содержимым.
| ||
|
Обсуждение (119 +28) |
Тип: К сведению |
| ||
| · | 30.05.2026 | Каталог GNOME Circle не будет принимать приложения, созданные с использованием AI (71 +15) |
|
Комитет, управляющий каталогом GNOME Circle, утвердил новые правила, запрещающие публикацию приложений, сгенерированных при помощи AI-инструментов. GNOME Circle предоставляет площадку для размещения приложений и библиотек, созданных сторонними разработчиками с использованием технологий GNOME, для упрощения их вхождения в экосистему GNOME.
В GNOME Circle теперь не будут приниматься проекты, имеющие признаки использования AI для генерации кода, такие как бессмысленные вставки в коде, разнобой в стиле, надуманное использование API и наличие комментариев с подсказами для AI. В новых правилах также упоминается, что разработчики должны хорошо разбираться в присланном коде, быть способны обосновать используемые методы и ответить на связанные с кодом вопросы. При этом использование AI для обучения и решения сопутствующих разработке задач, таких как автодополнение кода, не запрещается. Основной причиной запрета генерации кода через AI является попытка ускорить прохождение обязательного рецензирования проектов, предлагаемых для включения в коллекцию GNOME Circle. Очередь на проверку достигла значительного размера и некоторым приложениям приходится ждать годы до принятия решения по их включению в каталог. Наблюдаемый в последнее время рост публикаций низкокачественных программ, сгенерированных через AI, создаёт дополнительную нагрузку на рецензирующих и ещё больше забивает очередь заявок. Чтобы разобрать накопившиеся завалы приём любых новых заявок на рецензирование временно приостановлен. После отмены приостановки для высвобождения ресурсов новые проекты, созданные через AI, будут отклоняться без проверки (уже отправленные до введения новых правил заявки будут рассмотрены). Второй причиной запрета применения AI называется ужесточение правил в каталоге Flathub, который используется для размещения пакетов программ, представленных в GNOME Circle. Косвенно правила Flathub распространяются и на проект GNOME Circle, в котором пропадает смысл тратить время на проверку программ, пакеты с которыми не будут приняты во Flathub. Опрос, проведённый среди сопровождающих GNOME Circle, показал, что 62% участников не используют AI, 34% обращаются к AI-ассистентам по мелким вопросам или для подготовки небольших отрывков кода, и лишь 3% генерируют крупные порции кода через AI. Ни один из сопровождающих не признался, что полностью отказался от собственноручного написания кода в пользу генерации через AI.
| ||
|
Обсуждение (71 +15) |
Тип: К сведению |
| ||
| · | 30.05.2026 | Опубликована новая LTS-ветка СУБД MariaDB 12.3 (5 +8) |
|
Представлен выпуск СУБД MariaDB 12.3.2, который отмечен как первый стабильный релиз ветки 12.3. Ветка MariaDB 12.3 отнесена к выпускам с длительным сроком поддержки и будет сопровождаться до июня 2029 года. Одновременно доступен выпуск MariaDB 13.0.1, имеющий статус кандидата в релизы.
Проектом MariaDB развивается ответвление от MySQL, сохраняющее обратную совместимость и отличающееся интеграцией дополнительных движков хранения и расширенных возможностей. Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с открытым и прозрачным процессом разработки, не зависящим от отдельных производителей. MariaDB поставляется вместо MySQL во многих дистрибутивах Linux (RHEL, SUSE, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian) и внедрён в таких крупных проектах, как Wikipedia, Google Cloud SQL и Nimbuzz. Среди изменений в ветке MariaDB 12.3 по сравнению с прошлым LTS-выпуском MariaDB 11.8:
| ||
|
Обсуждение (5 +8) |
Тип: Программы |
| ||
| · | 30.05.2026 | Во Flathub запрещено размещение приложений, сгенерированных при помощи AI (118 +27) |
|
Барт Пиотровски (Bart Piotrowski), сопровождающий инфраструктуру каталога приложений Flathub, объявил о внесении в правила Flathub изменений, запрещающих использование AI как для разработки размещаемых в каталоге приложений, так и для автоматизации процесса публикации во Flathub. Под действие правил подпадают публикуемые приложения, дополнения, файлы с манифестами, метаданные, патчи, сборочные скрипты, pull-запросы и любые артефакты, создаваемые через flatpak-builder.
В ранее действующих правилах допускалось размещение приложений и изменений, часть которых была сгенерирована через AI и прошла ручное рецензирование. В новых правилах запрещена публикация приложений, содержащих любой код, документацию и прочие компоненты, созданные при участии AI, но предусмотрена возможность предоставления отдельных исключений для зрелых и качественно сопровождаемых проектов. Ограничения распространяются только на новые проекты, размещаемые после изменения правил, и не повлияют на уже опубликованные в каталоге приложения, созданные через AI. В примечании Барт отметил, что большие языковые модели могут быть полезным инструментом и со временем всё меньше кода будет создаваться без их участия. Но в настоящее время реальность такова, что авторы программ, созданных через AI, зачастую не готовы прилагать усилия для создания и оттачивания полноценного продукта и выступают лишь посредниками, поставившими задачу AI-агенту и опубликовавшими результат. Указано, что Барт устал от обострившихся за последний месяц конфликтов с высокомерными авторами, возникающих после отказа принимать в каталог сырые программы, созданные через AI. По словам Барта, подобные авторы ведут себя так, будто дарят гениальное ПО, а какие-то идиоты отказываются его принимать.
| ||
|
Обсуждение (118 +27) |
Тип: К сведению |
| ||
| · | 29.05.2026 | Выпуск Rust 1.96. Оценка пригодности Rust для создания прошивок к микроконтроллерам (140 +9) |
|
Опубликован релиз языка программирования Rust 1.96, основанного проектом Mozilla, но ныне развиваемого под покровительством независимой некоммерческой организации Rust Foundation. Язык сфокусирован на безопасной работе с памятью и предоставляет средства для достижения высокого параллелизма выполнения заданий, при этом обходясь без использования сборщика мусора и runtime (runtime сводится к базовой инициализации и сопровождению стандартной библиотеки).
Методы работы с памятью в Rust нацелены на исключение ошибок при манипулировании указателями и защиту от проблем, возникающих из-за низкоуровневой работы с памятью, таких как обращение к области памяти после её освобождения, разыменование нулевых указателей, выход за границы буфера и т.п. Для распространения библиотек, обеспечения сборки и управления зависимостями проектом развивается пакетный менеджер Cargo. Для размещения библиотек поддерживается репозиторий crates.io. Безопасная работа с памятью обеспечивается в Rust во время компиляции через проверку ссылок, отслеживание владения объектами, учёт времени жизни объектов (области видимости) и оценку корректности доступа к памяти во время выполнения кода. Rust также предоставляет средства для защиты от целочисленных переполнений, требует обязательной инициализации значений переменных перед использованием, лучше обрабатывает ошибки в стандартной библиотеке, применяет концепцию неизменяемости (immutable) ссылок и переменных по умолчанию, предлагает сильную статическую типизацию для минимизации логических ошибок. Основные новшества:
Дополнительно можно отметить публикацию (PDF) результатов анализа пригодности языка Rust для разработки прошивок для микроконтроллеров и встраиваемых систем с ограниченными ресурсами. Исследование проведено компанией STMicroelectronics при участии нескольких европейских университетов. Двум изолированным командам разработчиков была поставлена задача по реализации одной и той же прошивки для микроконтроллеров STM32U585AI с ядром Arm Cortex-M33. Первая команда создавала прошивку на Си, а вторая на Rust. Тестирование выполненной работы не выявило заметных преимуществ в использовании языка Си вместо Rust при разработке прошивок для микроконтроллеров при сравнении потребления памяти и производительности. Более того, задействование написанного на Rust системного runtime от открытого проекта Ariel OS позволило добиться потребления памяти в проекте на Rust ниже, чем в реализации на языке Си, использующей традиционный стек для разработки прошивок на базе библиотеки newlib. Размер результирующей прошивки составил 84100 байт в проекте на Rust и 76744 байта в проекте на Си (на 10% меньше), но потребление оперативной памяти в прошивке на Rust оказалось значительно ниже - 24640 байтов против 42608 байтов. Что касается производительности, то при тестировании начальных прототипов, разработанных за 6 недель, реализация на Rust в два раза опережала, реализацию на Си, но обе реализации значительно отставали от расчётной максимальной производительности. После 4 недель, выделенных на оптимизацию, обе реализации достигли примерно одинакового результата, близкого к расчётному максимуму.
![]()
| ||
|
Обсуждение (140 +9) |
Тип: Программы |
| ||
| · | 29.05.2026 | CIFSwitch - уязвимость в CIFS-подсистеме ядра Linux, позволяющая получить права root (75 +14) |
|
Раскрыты детали и опубликован эксплоит для уязвимости CIFSwitch (CVE пока не присвоен) в модуле ядра CIFS и инструментарии cifs-utils, позволяющей непривилегированному пользователю получить права root в системе. Исправление доступно только в виде патча, который опубликован 16 мая и 19 мая был принят в основную ветку ядра Linux (корректирующие выпуски ядра ещё недоступны).
Уязвимость затрагивает код, обеспечивающий поддержку механизма cifs.spnego для выполнения аутентификации по протоколу SPNEGO (Simple and Protected GSSAPI Negotiation) при подключении к SMB-серверам. При использовании cifs.spnego для определения ключей из Kerberos/SPNEGO ядро вызывает обработчик cifs.upcall, предоставляемый пакетом cifs-utils и выполняемый в пользовательском пространстве с правами root. Непривилегированный пользователь может инициировать вызов обработчика через отправку запроса, требующего получения ключа "cifs.spnego", с поддельным описанием "CIFS SPNEGO". В обработчике cifs.upcall не выполняются дополнительные проверки корректности параметров, переданных через ядро, среди прочего он воспринимает заслуживающими доверия значения полей pid, uid, creduid и upcall_target. После активации обработчик cifs.upcall переключается в пространства имён пользовательского процесса, через который был отправлен запрос, и до сброса привилегий выполняет поиск в системной базе NSS (Name Service Switch). Атакующий может запустить свой процесс в отдельном пространстве имён точек монтирования, что приведёт к выполнению обращения к NSS в его контексте. Для эксплуатации уязвимости достаточно внутри созданного атакующим окружения разместить собственный файл конфигурации /etc/nsswitch.conf и набор подставных библиотек libnss_*.so.2. Выполнение NSS-запроса обработчиком cifs.upcall приведёт к загрузке подставленных атакующим библиотек с правами root. Для эксплуатации уязвимости в системе должно быть разрешено создание пространств имён идентификаторов пользователей (user namespace) или точек монтирования (mount namespace), а также требуется наличие в системе установленного пакета cifs-utils. Дистрибутивы, в которых возможна эксплуатация уязвимости в конфигурации по умолчанию:
Дистрибутивы, в которых для работы эксплоита требуется установка пакета cifs-utils:
Дистрибутивы, в которых в конфигурации по умолчанию применяются настройки, блокирующие эксплуатацию уязвимости через SELinux или Apparmor, даже при наличии пакета cifs-utils:
В качестве обходного пути защиты можно заблокировать автоматическую загрузку модуля ядра cifs: sh -c "printf 'install cifs /bin/false\n' > /etc/modprobe.d/cifs.conf; rmmod cifs 2>/dev/null; true" Также можно запретить использование user namespace ("sysctl -w kernel.unprivileged_userns_clone=0") и удалить или переопределить правило cifs.spnego в настройках cifs-utils:
cat >/etc/request-key.d/cifs.spnego.conf <'EOF'
create cifs.spnego * * /usr/sbin/keyctl negate %k 30 %S
EOF
Тем временем, за 28 мая опубликовано 137 отчётов об уязвимостях в ядре Linux, а за 27 мая - 277 отчётов.
| ||
|
Обсуждение (75 +14) |
Тип: Проблемы безопасности |
| ||
| · | 28.05.2026 | Определение посещаемых сайтов через анализ активности SSD из web-браузера (54 +17) |
|
Группа исследователей из Грацского технического университета (Австрия), разработала технику атаки по сторонним каналам FROST (Fingerprinting Remotely using OPFS-based SSD Timing), позволяющую через анализ активности SSD-накопителя из выполняемого в браузере JavaScript-кода определить открываемые пользователям сайты с точностью 88.95%, а также запускаемые в системе приложения с точностью 95.83%. Метод также можно использовать для организации скрытого канала связи между локально работающим приложением и выполняемым в браузере JavaScript-кодом. Производительность такого обмена данными в Linux составила 661 bit/s, а в macOS - 892 bit/s.
Атака основана на том, что характер изменения времени доступа к SSD-накопителю во время открытия сайта или запуска web-приложения специфичен для конкретного сайта и приложения. Используя типовые слепки изменения времени доступа для заранее измеренных сайтов и приложений можно выделять свойственную им активность на фоне других операций ввода/вывода. В контексте реализованной атаки для сопоставления задержек при вводе/выводе с сигнатурами сайтов и приложений задействована свёрточная нейронная сеть, способная выявлять закономерности на фоне шума от постороннего ввода/вывода. Для работы метода в браузере задействован API OPFS (Origin-Private FileSystem), позволяющий создавать файлы в локальной файловой системе (файлы создаются в привязанной к сайту изолированной части ФС). Анализ времени доступа к SSD-накопителю осуществляется путём измерения задержек при одинаковых операциях с данными. Для обхода влияния на операции с файлом страничного кэша в ходе атаки требуется создание файлов очень большого размера, превышающего размер доступной оперативной памяти. В качестве меры для противодействия атаке производителям браузеров предложено запрашивать у пользователя отдельное подтверждение доступа к API OPFS или ограничить максимальный размер файла значением, не превышающим размер оперативной памяти. В настоящее время Chrome и Safari позволяют через API OPFS создавать файлы, занимающие до 60% имеющегося дискового пространства. Разработчики Chromium из компании Google не признают подобные атаки по сторонним каналам уязвимостями. Разработчики Safari из Apple не исключают внедрение в будущем методов для противодействия атаке. Компания Mozilla признала наличие проблемы, но пока не реализовала исправление.
| ||
|
Обсуждение (54 +17) |
Тип: Проблемы безопасности |
| ||
| · | 28.05.2026 | IBM и Red Hat вложат $5 млрд в обеспечение безопасности открытого ПО (81 +8) |
|
IBM и Red Hat представили проект Lightwell, в который будет инвестировано 5 миллиардов долларов для помощи в повышении безопасности открытого ПО, применяемого на предприятиях. В проекте будут задействованы новые возможности AI в сочетании экспертизой команды, насчитывающей более 20 тысяч инженеров. Предполагается, что Lightwell поможет сформировать новую модель использования открытого ПО на предприятиях, охватывающую процессы от разработки открытых проектов в upstream до поддержания рабочих внедрений.
Внутри проекта будет сформирован информационно-координационный центр, отвечающий за решение вопросов, связанных с безопасностью, и использующий AI для проверки и тестирования исправлений в открытых кодовых базах. Создаваемое подразделение позволит предприятиям привлекать инженеров IBM и Red Hat для решения критических проблем с безопасностью, обеспечивая при этом передачу исправлений разработчикам upstream-проектов. Проект будет выступать площадкой, на которой предприятия смогут сообщать о выявлении проблем, устранять уязвимости, получать проверенные патчи, применимые как к продуктам Red Hat, так и к развиваемому сообществом коду, и скоординировано передавать исправления в upstream-проекты. Помимо этого IBM и Red Hat привлекут своих инженеров и AI для содействия в сопровождении upstream-проектов и корпоративных окружений, рецензирования выявляемых уязвимостей, разработки патчей и продвижения исправлений учётом сложных цепочек зависимостей.
| ||
|
Обсуждение (81 +8) |
Тип: К сведению |
| ||
| · | 28.05.2026 | Грег Кроа-Хартман рассказал о том, как Rust может помочь в борьбе с ошибками в ядре Linux (284 +7) |
|
Грег Кроа-Хартман (Greg Kroah-Hartman), отвечающий за поддержку стабильной и "staging" веток ядра Linux и занимающий пост мэйнтейнера в 16 подсистемах ядра, выступил с докладом на конференции Rust Week 2026, в котором рассказал, как язык Rust может помочь в предотвращении появления в ядре уязвимостей, возникающих из-за типичных ошибок разработчиков на языке Си при работе с памятью, блокировками, обработкой ошибок и работой с не заслуживающими доверия данными. В качестве основного преимущества Rust называется возможность выявлять подобные ошибки на этапе сборки, а не рецензирования кода людьми. При этом Rust не рассматривается как панацея, способная избавить от всех проблем, и никто не собирается переписывать ядро на Rust: ожидается постепенное внедрение Rust через его использования для новых драйверов и подсистем.
В качестве примера ошибок в ядре, которые удалось бы избежать при использовании Rust, упомянута ошибка в подсистеме Bluetooth, остававшаяся незамеченной 15 лет, и проблема в гипервизоре Xen. В первом случае разработчик выполнил разыменование указателя без проверки, а во втором забыл снять блокировку в коде обработки ошибок. По словам Грега, большинство ошибок в ядре вызваны подобными мелочами, которые со временем накапливаются и всплывают как уязвимости. В Rust многие из подобных проблемы предотвращаются компилятором, например, Rust-абстракции для блокировок в ядре допускают получение доступа к внутренним указателям структур только после захвата соответствующей блокировки, которая снимается автоматически. Без захвата блокировки получить доступ к указателям структур на Rust не получится. Грег считает, что подобные возможности Rust не допустили бы появления 60% ошибок, выявляемых в ядре, а выполняемые компилятором проверки избавили бы сопровождающих от траты времени на обсуждение с авторами корректности обработки ошибок и обоснованности выставления блокировок в нужном месте. Более того, внедрение поддержки Rust уже оказало благотворное влияние и на Си-код в ядре благодаря приведению в порядок Си-кода и интерфейсов, а также заимствованию некоторых приёмов разработки (например, были реализованы блокировки с ограниченной областью видимости). Благодаря системе типов, гарантирующей соблюдение заданных правил, и применению систем непрерывной интеграции, проверяющих код на этапе сборки, при рецензировании изменений на Rust сопровождающие могут сосредоточиться на проверке логики работы, а не отслеживании манипуляций с ресурсами. Применение Rust также позволяет более внимательно относиться к данным, поступающим от оборудования или из внешних систем. Подобное достигается благодаря явному разграничению заслуживающих и не заслуживающих доверия данных на уровне системы типов: разработчику достаточно выполнить анализ при переходе из недоверительного в доверительное состояние. Последнее время команда, отвечающая за безопасность в ядре, публикует каждый день примерно 13 отчётов об уязвимостях, что на фоне прошлой динамики выявления уязвимостей воспринимается как какое-то безумие (для примера за вчерашний день было опубликовано 277 отчётов об уязвимостях в ядре). По мнению Грега, использование Rust является одним из реальных способов добиться снижения числа ошибок в ядре, вызванных традиционными оплошностями при обработке ошибок и управлении ресурсами. В ядре поддержка Rust уже вышла за рамки эксперимента и в конце прошлого года была признана штатной возможностью ядра.
| ||
|
Обсуждение (284 +7) |
Тип: К сведению |
| ||
| · | 28.05.2026 | Опубликована система хранения Blockstor, являющаяся альтернативой LINSTOR (65 +3) |
|
Доступен первый выпуск Blockstor - открытой системы управления распределённым блочным хранилищем для Kubernetes, обеспечивающей репликацию данных поверх DRBD. Blockstor совместим по REST API с LINSTOR и способен без изменений работать с существующей экосистемой клиентов, включая командную утилиту linstor, CSI-драйвер, оператор Piraeus, ha-controller и библиотеку golinstor. Проект представляет собой полностью самостоятельную (clean-room) реализацию на языке Go, не использующую исходный код оригинала. Код распространяется под лицензией Apache 2.0 и развивается в рамках платформы Cozystack (проект CNCF Sandbox).
Автор проекта - Андрей Квапил (@kvaps), основатель Cozystack и участник некоммерческой организации Piraeus, в рамках которой развиваются оператор и CSI-драйвер LINSTOR для Kubernetes. Автор известен в Kubernetes-сообществе как популяризатор LINSTOR и неоднократно выступал с техническими докладами по теме. Изначально разработка задумывалась как небольшая "пятничная" инициатива, однако в итоге превратилась примерно в 20 дней непрерывной работы. На текущий момент проект развивается как исследовательский, однако в перспективе рассматривается как возможная замена LINSTOR в роли системы хранения по умолчанию в Cozystack. В качестве причин создания нового проекта упоминаются сложности с сопровождением оригинального проекта и передачей изменений в основной проект, а также архитектурные ограничения LINSTOR. Оригинальный проект использует "request-based" модель обработки запросов в реальном времени, который показывает проблемы на масштабах, тогда как декларативный reconciliation-подход Kubernetes и framework controller-runtime, по мнению автора, значительно лучше подходит для построения распределённых систем. В отличие от LINSTOR, архитектура Blockstor полностью основана на подходе Kubernetes controller-runtime. Конфигурация и текущее состояние системы представлены в виде Kubernetes CRD-объектов, а сама система не рассчитана на работу вне Kubernetes-кластера. Среди основных возможностей Blockstor:
Особенностью проекта стало активное использование AI-инструментов при разработке. Практически весь код был подготовлен с помощью Claude Code (модель Opus 4.7) компании Anthropic. Разработка велась почти круглосуточно в течение примерно 20 дней. В отдельные моменты одновременно работало до 60 AI-агентов, а общий диалог разработки составил около 1320 запросов со стороны автора и порядка 36 тысяч ответов модели в рамках одной непрерывной сессии. На выходе получилось 1500 коммитов, в которых 83 тысячи строк кода заняла реализация и ещё 137 тысяч строк кода тесты. По предварительной оценке, суммарно было израсходовано около 18.9 млрд токенов, а эквивалентная стоимость такого объёма при использовании API-тарифов составила бы около 40 тысяч долларов. Автор первоначально рассчитывал на почти полностью автономную разработку силами AI-модели, однако сложная логика DRBD потребовала постоянного участия человека. Наиболее сложными оказались сценарии схождения DRBD-состояний, работа с Generation Identifier (GI), пропуска изначальной синхронизации и обработка split-brain сценариев. Поскольку оригинальный LINSTOR распространяется под лицензией GPL, использовать его код напрямую было нельзя. Основная часть реализации создавалась на основе анализа API-контрактов, поведения утилит, Python-клиента LINSTOR, а также совместимых по лицензии проектов, включая piraeus-operator и CSI-драйвер. В наиболее сложных случаях применялась схема с разделением ролей AI-агентов: один агент анализировал исходный код LINSTOR и формировал текстовую спецификацию поведения, после чего другой агент реализовывал функциональность исключительно по этой спецификации без прямого копирования исходного кода. Из-за отсутствия открытых тестов у оригинального проекта тестовую базу пришлось формировать самостоятельно.
| ||
| · | 27.05.2026 | Обновление Wolvic, web-браузера для устройств виртуальной реальности (19 +1) |
|
Опубликованы новые версии web-браузеров Gecko Wolvic 1.9 и Chromium Wolvic 1.3, предназначенных для использования в системах дополненной и виртуальной реальности. Браузеры предоставляют 3D-интерфейс для навигации по сайтам при помощи 3D-шлема, и, помимо традиционных плоских страниц, позволяют web-разработчикам создавать трехмерные web-приложения для систем виртуальной реальности, используя API WebXR, WebAR и WebVR. Отличия браузеров сводится к тому, что в Gecko Wolvic применяется web-движок GeckoView, а в Chromium Wolvic задействован движок Chromium.
Навигация в браузерном интерфейсе осуществляется при помощи VR-контроллеров или через отслеживание движения глаз, а для ввода данных в web-формы применяется виртуальная клавиатура или система голосового ввода, дающая возможность заполнять формы и отправлять поисковые запросы с использованием развиваемого системы распознавания речи. Возможен просмотр в браузере пространственных видео, снятых в режиме 360 градусов. В качестве стартовой страницы браузер предоставляет интерфейс для доступа к избранному контенту и навигации по коллекции, адаптированных для 3D-шлемов игр, web-приложений, 3D-моделей и пространственных видео. Готовые сборки формируются для платформы Android и поддерживают такие 3D-шлемы, как Huawei VR Glass, Huawei Vision Glass, VIVE Focus, Lynx R1, Lenovo A3, Magic Leap 2, Meta Quest 2/3/Pro, Oculus Quest и Pico 4/4E. В режиме тестирования возможен запуск на обычном Android-смартфоне без 3D-шлема. Код Wolvic написан на языках Java и C++, и распространяется под лицензией MPLv2. Среди изменений в новых выпусках:
| ||
|
Обсуждение (19 +1) |
Тип: Программы |
| ||
| · | 27.05.2026 | Проект Pavona развивает дистрибутив открытых аппаратных компонентов для создания чипов (71 +23) |
|
Консорциум GlobalPlatform анонсировал проект Pavona, развивающий открытый дистрибутив аппаратных компонентов, из которых можно компоновать готовые к производству защищённые чипы на ядрах с микроархитектурой RISC-V. Дистрибутив предоставляет модульную библиотеку IP-блоков и эталонные реализации чипов, готовые к сертификации и проверенные на пригодность к производству (tapeout-proven). Комбинируя элементы из данной библиотеки можно собирать собственные чипы для различных областей применения, от датацентров, AI-ускорителей и специализированных контроллеров до встраиваемых систем с ограниченными ресурсами и устройств интернета вещей (IoT). Наработки проекта распространяются под лицензией Apache 2.0.
В числе основателей проекта выступили 12 компаний и организаций, среди которых Qualcomm Technologies, Meta, Analog Devices, Baochip, SIMPLE Crypto Association, Tenstorrent, Winbond и ZeroRISC. Проект развивается на нейтральной площадке, не зависящей от отдельных производителей, и управляется участниками из образованного вокруг него сообщества. Pavona предоставляет IP-блоки с ядрами RISC-V (Ibex RV32IMCB и VexII), криптоускорителями с поддержкой классических и постквантовых криптоалгоритмов, контроллерами OTP/flash, SRAM, JTAG, ADC, I2C, GPIO и SPI. Среди реализованных на аппаратном уровне криптоалгоритмов: HMAC, KMAC, AES, EDN, ASCON, ML-KEM, ML-DSA, DSA-SHA2 и SLH-DSA-SHAKE. Предоставляется полная документация и ресурсы для верификации перед производством (Design Verification collateral) и RTL-код. Помимо аппаратных компонентов проектом также предоставляется программное обеспечение, такое как криптографическая библиотека для интеграции с криптоускорителями, прошивки и сопутствующие утилиты. На базе Pavona подготовлены две эталонные реализации: обособленный чип со встроенными криптографическими возможностями для использования в роли "Root of Trust" и реализация "Root of Trust" для архитектуры чиплетов, опробованные в производстве с использованием техпроцесса TSMC 3nm (N3). Чиплеты позволяют создавать комбинированные гибридные интегральные схемы (многочиповые модули), образованные из независимых полупроводниковых блоков. Отмечается, что Pavona стал первым проектом, предоставляющим готовый к производству встраиваемый в чипы открытый стек с поддержкой постквантовых криптографических алгоритмов (PQC).
| ||
|
Обсуждение (71 +23) |
Тип: К сведению |
Интересно
| ||
| · | 26.05.2026 | Релиз AlmaLinux 9.8 и 10.2 (72 +5) |
|
Представлен релиз дистрибутива AlmaLinux 10.2, а также обновление прошлой ветки - AlmaLinux 9.8. Релизы синхронизированны c Red Hat Enterprise Linux 9.8 и 10.2, и содержат все предложенные в данных выпусках изменения. Установочные образы подготовлены для архитектур x86_64_v3, x86_64_v2, ARM64, ppc64le и s390x в форме загрузочного (1 ГБ), минимального (1.6 ГБ) и полного образа (10 ГБ). Позднее будут сформированы Live-сборки с GNOME, KDE, MATE и Xfce, а также образы для плат Raspberry Pi, контейнеров, WSL (Windows Subsystem for Linux) и облачных платформ.
Дистрибутив по возможности бинарно совместим с Red Hat Enterprise Linux и может использоваться в качестве замены RHEL 10.2 и CentOS 10 Stream. Помимо ребрендинга и удаления специфичных для RHEL пакетов в AlmaLinux 10.2 отмечены следующие отличия от RHEL 10.2:
Дистрибутив AlmaLinux основан компанией CloudLinux в ответ на преждевременное сворачивание поддержки CentOS 8 компанией Red Hat (выпуск обновлений для CentOS 8 прекращён в конце 2021 года, а не в 2029 году, как предполагали пользователи). Проект курирует отдельная некоммерческая организация AlmaLinux OS Foundation, которая была создана для разработки на нейтральной площадке с участием сообщества и c использованием модели управления, похожей на организацию работы проекта Fedora. Дистрибутив бесплатен для всех категорий пользователей. Все наработки AlmaLinux публикуются под свободными лицензиями. Кроме AlmaLinux, в качестве альтернатив классическому CentOS также позиционируются Rocky Linux (развивается сообществом под руководством основателя CentOS), Oracle Linux, SUSE Liberty Linux и EuroLinux. Кроме того, компания Red Hat предоставила возможность бесплатного использования RHEL в организациях, развивающих открытое ПО, и в окружениях индивидуальных разработчиков, насчитывающих до 16 виртуальных или физических систем.
| ||
|
Обсуждение (72 +5) |
Тип: Программы |
| ||
| · | 26.05.2026 | Google случайно раскрыл детали неисправленной уязвимости в Chromium (112 +29) |
|
Компания Google случайно открыла публичный доступ к отчёту (общедоступная копия), содержащему детальное пояснение и пример эксплоита для уязвимости, ещё не исправленной в движке Chromium. Уязвимость признана опасной и выявившему проблему исследователю было выплачено вознаграждение в $1000. Информация о проблеме была отправлена ещё в 2022 году, и с тех пор обсуждение по её исправлению периодически поднималось, но не доводилось до конца (требовалась реализация новых лимитов на непрерывную загрузку). В одном из таких обсуждений разработчики по ошибке посчитали уязвимость исправленной и открыли публичный доступ к информации, хотя проблема оставалась нерешённой.
Уязвимость позволяет добиться продолжения выполнения фонового JavaScript-обработчика (Service Worker) даже после закрытия окна браузера, что даёт возможность атакующему организовать постоянный контроль за браузером с возможностью загрузки и выполнения в любой момент своего JavaScript-кода в контексте своей страницы. Сценарий атаки сводится к тому, что атакующий может добиться открытия своей страницы в версии браузера, не содержащей уязвимостей, после чего дождаться выявления серьёзной уязвимости в браузере и организовать выполнение эксплоита без необходимости повторного открытия пользователем страницы атакующего. Суть метода в создании страницы с Service Worker-ом, выполняющей операцию загрузки данных, которая никогда не прерывается. По мнению выявившего проблему исследователя, уязвимость может использоваться для создания ботнета из браузеров, пользователи которых не подозревают, что один раз закрепившись, атакующий может удалённо выполнить JavaScript-код на их устройстве без совершения действий с их стороны. Подобный ботнет и без эксплуатации других уязвимостей может применяться для организации DDoS-атак и проксирования вредоносного трафика через системы жертв. Проблема затрагивает все браузеры на движке Chromium.
| ||
|
Обсуждение (112 +29) |
Тип: Проблемы безопасности |
| ||
| Следующая страница (раньше) >> | ||
|
Закладки на сайте Проследить за страницей |
Created 1996-2026 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |