LINUX.ORG.RU

Сообщения dataman

 

В systemd-journald спустя 6 лет признали проблему избыточной нагрузки на накопители

 , ,

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

Разработчики проекта systemd приступили к изучению и устранению давней архитектурной проблемы в компоненте systemd-journald, приводящей к многократному завышению объёма записываемых на диск данных (write amplification) по сравнению с фактическим объёмом логов.

История тянется с марта 2020 года, когда в системе отслеживания ошибок был зарегистрирован отчёт, в котором было продемонстрировано, что генерирование около 500 КБ текстовых логов выливается в более чем 700 МБ физических операций записи на SSD. Разработчики systemd тогда наотрез отказались признавать проблему: мейнтейнеры заявили исследовательские претензии в духе «вы не понимаете, как работают файловые системы», отказались от проведения профилирования и закрыли заявку с вердиктом «not actionable». Комментарии разработчиков собрали сотни отрицательных оценок от пользователей, однако позиция проекта осталась непреклонной.

В начале 2026 года был отправлен повторный отчёт о проблеме, в ходе обсуждения которого независимый разработчик ValdikSS провёл подробное профилирование с использованием изолированных cgroup и loop-устройств, наглядно доказав механизм возникновения проблемы: из-за использования отображаемых в память файлов (mmap) и двоичных хэш-таблиц запись даже одного текстового сообщения размером 750 байт приводит к модификации отпечатков в памяти, вызывая сброс на диск полных 4-килобайтных страниц и генерацию от 50 до 70 КБ итогового ввода/вывода на уровне блочного устройства.

После вчерашнего попадания отчёта о проблеме на главную страницу Hacker News и публикации неопровержимых синтетических тестов мейнтейнеры проекта изменили риторику и начали работу над оптимизацией механизмов сброса кэша и структуры хранения индексов journald. В данном случае разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление.

dataman
()

Офтопик-лист, п. 27: «Я спросил у LLM...»

 , , ,

Участились жалобы на нейрослопные комментарии. Офтопик-лист (изменён 15.05.2026), п. 27 голосит:

Темы вида «Я спросил у LLM, и вот что она мне ответила».

Предлагается изменить формулировку на «Темы и комментарии вида …».
Пока не все модераторы с этим согласны. А что думаешь лично ты, %username%?

dataman
()

Объявлено о расформировании Nixpkgs Core Team

 , ,

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

Команда Nixpkgs Core Team объявила о своём расформировании в связи с выгоранием участников и накопившемся системном кризисе управления в сообществе. Команда координировала работу над репозиторием пакетов Nixpkgs, применяемом в дистрибутиве NixOS, и также выполняла такие задачи, как урегулирование разногласий между мейнтейнерами и утверждение новых участников.

В качестве основной причины самороспуска Core Team названо выгорание участников из-за необходимости выполнять большой объём управленческих и рутинных работ, отвлекающих от непосредственной разработки. В Core Team наблюдается большой отток участников из-за высокой нагрузки, но на призыв о вступлении в команду откликнулся лишь один человек и поддержание работы в нынешнем составе оказалось проблематичным.

Дополнительно упоминается конфликт c управляющим комитетом (Steering Committee), вызванный его чрезмерным вмешательством в зону ответственности Core Team, плохой коммуникацией и отсутствием полноценного делегирования полномочий. Из-за разногласий было застопорено реформирование процессов модерации и управления организацией на GitHub, а также возникли проблемы с координацией работы над GSoC (Google Summer of Code), инициативами выделения грантов и политикой в отношении применения AI-инструментов. Проблемы также возникали из-за разных подходов к принятию решений, в Core Team применялась модель на основе достижения консенсуса, а в Steering Committee - на основе мажоритарного голосования.

dataman
()

Проект Rust утвердил правила в отношении использования AI-инструментов

 , ,

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

Разработчики языка программирования Rust утвердили правила применения AI-ассистентов в проекте. За отдельными исключениями, правила запрещают передачу кода, сгенерированного через AI, но разрешают использование AI для анализа, изучения, рецензирования и проверки кода. Правила распространяются только на основной репозиторий rust-lang/rust, и отдельно утверждаются командами разработчиков субмодулей, подветок и зависимостей из каталога crates.io.

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

Запрещено применение AI для формирования комментариев, отчётов о проблемах и описаний изменений, публикуемых от имени участника. При этом разрешено цитирование выдачи от AI с явной пометкой, что контент сформирован через AI (например, прикрепление результатов диагностики через AI). Запрещено создание документации через AI. При рецензировании запрещено рассмотрение выводов AI как достаточных для приёма или отклонения изменений — результаты проверки через AI могут носить только рекомендательный характер.

С оговорками и явным упоминанием, что результат получен через AI, разрешено применение AI для машинного перевода на другие языки, поиска и верификации ошибок, а также внесения незначительных изменений в код и тексты (например, правка опечаток и подбор синонимов).

В рамках эксперимента допускается передача заранее согласованных, некритичных, досконально проверенных и хорошо протестированных изменений, изначально сгенерированных через AI. Перед отправкой pull-запроса c подобным изменением, разработчик должен заранее договориться с рецензирующими. Предлагаемые изменения должны помечаться меткой «ai-assisted» и могут затрагивать вторичные инструменты, такие как tidy и linkchecker, но не должны касаться ключевых возможностей и элементов языка. Для отслеживания результатов эксперимента изменения предписано отправлять в отдельный приватный Zulip-канал, доступ к которому предоставлен только участникам проекта.

dataman
()

Форк Midnight Commander c поддержкой панельных плагинов

 , , , ,

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

Выпущен консольный файловый менеджер Midnight Commander 6.0.3 (mc6), представляющий собой форк GNU Midnight Commander 4.8.33, расширенный поддержкой панельных плагинов и поставляемый со встроенным PTY-терминалом mcterm. Интегрированный в mc6 фреймворк панельных плагинов позволяет отображать в панелях не только файловые системы, но и контейнеры, Git-репозитории, базы данных и объекты удалённых хранилищ. Код проекта написан на языке Си и распространяется под лицензией GPLv3+. Готовые пакеты подготовлены для Debian и Ubuntu, Fedora и RHEL, а также Arch Linux в форматах DEB, RPM и pkg.tar.zst. Для Gentoo дополнительно предоставлен ebuild для установки через локальный overlay.

В состав выпуска вошли плагины для работы с архивами, FTP/SFTP/FTPS, Samba, Git, Docker, Kubernetes, MongoDB и S3-совместимыми хранилищами. Плагины поддерживают стандартные файловые операции, а переработанная поддержка архивов на базе libarchive заметно (в десятки или сотни раз) ускоряет обработку больших архивов.

Во встроенный текстовый редактор mcedit добавлены возможность сворачивания блоков кода, браузер истории Undo/Redo, средства управление макросами и поддержка сохранения файлов через sudo. В разы улучшена производительность при работе с очень длинными строками.

Просмотрщик mcview получил древовидное представление JSON, YAML и XML, интерактивную фильтрацию содержимого, базовую поддержку отображения разметки Markdown и режим воспроизведения файлов с ANSI-последовательностями.

В состав включён встроенный PTY-терминал mcterm с собственным эмулятором терминала, предназначенный для замены традиционного subshell-механизма.

dataman
()

54 из 55 выявленных через AI уязвимостей в SQLite оказались фиктивными

 , , , ,

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

Исследователи из компании JFrog проанализировали опубликованные на днях 55 отчётов об уязвимостях в SQLite. На основании данных отчётов организация MITRE присвоила всем проблемам CVE-идентификаторы. Три проблемы получили статус критических, а самой опасной уязвимости (CVE-2026-51302) компания Red Hat присвоила в своих базах уровень 10 из 10, а SUSE — 9.8 из 10. Детальное изучение заявленных ошибок показало, что 54 из 55 уязвимостей, включая отмеченную критическую проблему, являются фикциями и вызваны галлюцинациями AI-модели.

В самой опасной уязвимости было заявлено обращение к памяти после её освобождения в функции exprComputeOperands(), приводящее к возможности выполнения кода при выполнении специально оформленного запроса. Разбор показал, что данной функции не существует в кодовой базе SQLite 3.41, в которой заявлено наличие проблемы (данная функция появилась значительно позднее). Источником возникновения уязвимости было заявлено оставление висячего указателя в функции sqlite3ReleaseTempReg(), но её логика работы не подразумевает освобождением памяти и ограничивается пометкой памяти для повторного использования, что исключает возникновение проблем класса use-after-free в силу архитектуры.

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

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

dataman
()

Проект Debian проводит общее голосование о допустимости применения AI при разработке

 , ,

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

Проект Debian объявил о проведении общего голосования (GR, general resolution) разработчиков по вопросу использования больших языковых моделей и AI-инструментов в процессе разработки дистрибутива. Право голоса имеют около тысячи разработчиков, участвующих в сопровождении пакетов и поддержании инфраструктуры Debian. Рассматриваемый вопрос охватывает только применение AI в Debian (работа над пакетами, разрабатываемыми в Debian проектами, web-ресурсами, переводами, документацией и сообщениями в официальной переписке) и не затрагивает использующие AI upstream-проекты, поставку связанных с AI пакетов и принятие патчей, созданных в upstream-проектах при помощи AI. Для голосования предложено два пункта: запретить использование AI и разрешить AI при обязательном соблюдении некоторых условий. Сторонники запрета использования AI при разработке Debian полагают, что философия AI «действуй быстро, не боясь что-то сломать» противоречит принципам Debian, который заслужил репутацию стабильной платформы. Доводы против применения AI:

  • Правила Debian запрещают принимать код, имеющий неопределённую лицензию или имеющий проблемы с авторскими правами. Применение AI не может гарантировать абсолютной ясности в вопросах лицензий и авторских прав - авторские права на код, сгенерированный через AI, пока имеют неопределённый юридический статус.
  • Большие языковые модели не понимают логику, а лишь генерируют статистически вероятный текст на основе массива данных, используемого при обучении модели. В случае использования AI для создания пакетов большая языковая модель будет отталкиваться от общей информации о пакетах, созданных в разные периоды. Так как синтаксис спецификаций и предпочитаемые методы оформления пакетов со временем менялись, предполагается, что сгенерированный через AI пакет будет представлять собой смесь практик из разных периодов.
  • Проверка кода от новичков, генерирующих изменения через AI, создаст дополнительную нагрузку на рецензирующих и будет способствовать их выгоранию. Помимо этого, применяя AI, новички получают готовое решение и не учатся реальным процессам и пониманию деталей формирования пакетов, что со временем не позволит им стать полноценной заменой старым разработчикам.
  • Компании, разрабатывающие большие языковые модели, действуют неэтично и создают большую паразитную нагрузку на инфраструктуру, применяя при обучении моделей индексирующих ботов, не считающихся с правилами в robots.txt, игнорирующих лицензии и по сути устраивающих DDoS-атаки на серверы Debian, вынуждая проект тратить ресурсы на блокирование и усложнять работу легитимных пользователей (введение проверок, ограничение доступа незарегистрированным участникам, попадание под блокировку полезных ботов и т. п.).

Разработчики, выступающие за применение AI в Debian, считают, что AI-инструменты будут полезными для работы и улучшения Debian, несмотря на имеющиеся риски (проблемы с качеством, дальнейшим сопровождением кода, авторским правом, экологией и агрессивным скрапингом). Предлагается разрешить использование AI при разработке, но при выполнении следующих условий:

  • Условия использования AI-инструментов не должны накладывать ограничений, которые конфликтуют с правилами распространения, модификации и использования в контексте Debian.
  • Если результат работы AI включает чужой код или материалы, разработчик обязан убедиться, что имеет право передать этот результат под соответствующей открытой лицензией.
  • Участники несут полную ответственность за вклад, созданный при помощи AI, и должны гарантировать качество, безопасность и соблюдение лицензий. Участники обязаны полностью понимать суть предлагаемых изменений и быть готовыми их обосновать.
  • Явное информирование об использовании AI при передаче кода, обсуждении ошибок и формировании сообщений, если с его помощью выполнена значительная часть работы. Информация о применении AI может передаваться через Git-метки «Generated-By:» или «Assisted-By:».
  • Перед массовой или автоматизированной отправкой изменений, сгенерированных через AI, необходимо заранее обсудить это с сообществом. Любой автоматизированный процесс должен контролироваться человеком, берущим на себя ответственность за поведение и результаты этого процесса.
  • Запрещено использовать AI-инструменты, передающие данные сторонним провайдерам, при обработке конфиденциальной или закрытой информации, такой как приватная переписка и нераскрытые публично отчёты об уязвимостях.

https://www.debian.org/vote/2026/vote_002.

dataman
()

В ходе тестирования автономный AI-агент OpenAI без явной указки взломал инфраструктуру Hugging Face

 , , , ,

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

Компания OpenAI опубликовала сведения об инциденте, который привёл к взлому инфраструктуры платформы Hugging Face и получению доступа к учётным данным некоторых сервисов. Инцидент произошёл в ходе тестирования возможностей автономного AI-агента находить уязвимости и проводить комплексные атаки для достижения общей цели (тест ExploitGym). При тестировании использовались как существующая модель GPT‑5.6 Sol, так и более функциональная предварительная версия новой модели OpenAI, у которых были отключены механизмы, ограничивающие использование для проведения кибератак.

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

Эксплуатировав уязвимость в прокси AI-агент сумел получить доступ к узлу, имеющему выход в интернет, и получил возможность отправлять сетевые запросы за пределы изолированного тестового окружения. После этого AI-агент предположил, что на серверах Hugging Face могут находится наборы данных, модели и решения для прохождения теста ExploitGym, и сосредоточился на получении этих данных и анализе безопасности Hugging Face.

В итоге AI-агент смог выявить в Hugging Face 0-day уязвимость, позволившую выполнить свой код на узлах кластера и получить доступ к внутренним наборам данных и учётным записям, используемым в сервисах. AI-агент эксплуатировал уязвимость в загрузчике внешних наборов данных (dataset loader) через прикрепление специально оформленной конфигурации к передаваемым данным, и добился выполнения своего кода на уровне изолированного обработчика. После этого, используя присутствующие в изолированном окружении ключи подключения к облачным сервисам и кластерам, AI-агент смог выполнить свой код на рабочих узлах внутренних кластеров компании.

dataman
()

simd.dev — открытая база данных встроенных функций SIMD и векторных типов данных

 

Упомянутый в ZXC 0.13.0 и 0.13.1 автор алгоритма PivCo-Huffman работает над проектом https://simd.dev (код на GitHub):

WIP — work in progress. Schema, layout, and APIs are still moving. Expect breaking changes.

An open database of SIMD intrinsics and vector data types, with drop-in tooltip tooling for the web, the terminal, and your editor.

Среди прочего, есть расширение для браузеров (Chrome, Chromium, Edge, Firefox) для показа в офлайн информации о SIMD-типах и функциях.

Вот так выглядит в Helium: https://postimg.cc/LnXpvptd.

dataman
()

Ghost Font — шрифт, который люди читают, а «ИИ» не может

 anti-ai, ghost font, , как это развидеть,

ТГ-канал «Джейпег Малевича» пишет:

чувак создал шрифт, который люди читают, а ИИ не может.

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

Разработчик протестировал шрифт на GPT Sol 5.6 Ultra и Claude Fable — обе модели не смогли правильно расшифровать сообщение и увидели ложный текст, который специально встроили в видео.

В будущем Ghost Font хотят использовать для защиты информации на сайтах и новых каптч.

dataman
()

Автор LuaJIT вернулся к разработке и планирует выпуск LuaJIT 3.0

 , , , ,

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

Майк Полл (Mike Pall), создатель JIT-компилятора LuaJIT, отошедший от активной разработки проекта в 2015 году и ограничивавшийся с тех пор редким сопровождением ветки 2.1 (github.com), вернулся к активной работе над проектом и опубликовал план синтаксических расширений будущей ветки LuaJIT 3.0.

Среди предлагаемых для LuaJIT 3.0 расширений:

  • Битовые операторы в виде встроенного синтаксиса вместо вызовов функций bit.*: ~a (NOT), a & b (AND), a | b (OR), a ~ b (XOR), a << b, a >> b (логический сдвиг) и a ~>> b (арифметический сдвиг). XOR обозначен как ~, поскольку символ ^ в Lua занят возведением в степень.
  • Альтернативные («привычные») операторы в стиле C/JavaScript: ! (not), && (and), || (or) и != (~=).
  • Оператор целочисленного деления // с округлением в сторону минус бесконечности и метаметодом __idiv (как в Lua 5.3+).
  • Тернарный оператор a ? b : c с поддержкой сокращённого вычисления.
  • Оператор безопасной навигации ?. (a?.field, a?.[key], f?.(...), obj?.:method(...)), возвращающий nil, если левый операнд равен nil.
  • Оператор объединения с nil a ?? b, возвращающий b, только если a равно nil.
  • Составные операторы присваивания: +=, -=, \*=, /=, //=, %=, &=, |=, ~=, <<=, >>=, ~>>=, ..= и ??=. Индексное выражение в левой части вычисляется однократно.
  • Оператор continue для перехода к следующей итерации цикла, оформленный как «мягкое» ключевое слово (можно продолжать использовать как имя переменной).
  • Объявление const — блочная неизменяемая привязка локальной переменной; запрещены переприсваивание и повторное объявление в той же или вложенной области видимости (также «мягкое» ключевое слово).

В обсуждении дополнительно затрагиваются ещё не вошедшие в спецификацию идеи: выражение сопоставления с образцом через ключевое слово in, индексируемый тип для vararg (...varg, varg[i]), краткий синтаксис лямбд (|x| -> expr), оператор отложенного выполнения defer в стиле Go/Zig и присваивание в условии (if local x = ... then).

Появление расширений вызвало и критику: часть участников отметила, что нововведения окончательно превращают LuaJIT в отдельный язык, несовместимый с эталонным Lua 5.1. На это Полл ответил, что «этот корабль уплыл уже очень давно».

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

dataman
()

Проект rars подготовил свободную реализацию RAR с поддержкой создания архивов

 , , , ,

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

Представлен проект rars, развивающий свободную реализацию инструментария для формата RAR, написанную на языке Rust и поддерживающую не только распаковку, но и создание RAR-архивов. Инструментарий поддерживает как ранние форматы RAR 1.3/1.4 с сигнатурой RE~^, так и последнюю версию RAR 7. Доступны такие расширенные операции, как разбиение на тома, защита паролем, шифрование заголовков, прикрепление комментариев, RARVM-фильтры, индексы для быстрого открытия и механизмы восстановления повреждённых данных. Код распространяется под лицензиями MIT и Apache-2.0. На базе библиотеки PyO3 подготовлены обвязки для языка Python, которые реализуют API в стиле rarfile для просмотра, тестирования и извлечения архивов, а также API в стиле RarBuilder для создания или перепаковки архивов.

Особенность проекта в том, что он реализует работу с форматом RAR без использования кода утилиты unrar, распространяемой под несвободной лицензией, которая запрещает использовать код unrar для воссоздания алгоритма сжатия RAR или разработки RAR-совместимого архиватора. Из-за данного ограничения большинство свободных архиваторов ограничивались лишь функциями распаковки RAR-файлов, а для создания RAR-архивов приходилось использовать проприетарный инструментарий от RARLAB.

Отдельно создан репозиторий rar-research в котором опубликованы спецификации для форматов RAR 1.3/1.4, RAR 1.5-4.x и RAR 5.0/7.0, а также заметки по используемым алгоритмам, фильтрам, методам проверки и восстановления целостности, шифрованию, разбиению на тома и механизмам защиты. Так как на момент создания проекта rars официальной полноценной спецификации не существовало, документация была воссоздана по коду распаковщиков, старым реализациям, тестовым архивам и анализу бинарных версий RAR для DOS и Windows.

Реализация была создана с использованием AI-инструментов OpenAI Codex 5.5 и Claude Opus 4.7 в свободное от работы время примерно за пять недель. На первом этапе модели применялись для систематизации информации о формате и восполнения пробелов в описании, после чего по восстановленной спецификации был сгенерирован код на языке Rust. Для уточнения спецификации и оттачивания реализации использовалась проверка работы на реальных архивах и сравнение с эталонными реализациями.

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

Форсировать разработку удалось после появления в OpenAI Codex режима /goal, позволяющего AI-агенту длительное время работать над одной задачей, сжимая контекст и продолжая выполнение после его переполнения. В таком режиме Codex несколько раз работал больше чем 6 часов и один раз около 16 часов, реализуя значительную часть оставшейся функциональности, такой как восстановление данных, шифрование и многотомные архивы. С учётом значительной субсидии на токены было потрачено 40 фунтов стерлингов.

По уровню сжатия rars в среднем на 5-10% отстаёт от WinRAR. По скорости сжатия и распаковки rars существенно медленнее WinRAR из-за отсутствия полноценных оптимизаций. При этом в проекте уже имеется режим --features fast, применяющий оптимизации на основе SIMD-инструкций для ускорения сжатия и распаковки, но завязанный на экспериментальный API std::simd, доступных только в тестовых сборках инструментария Rust. Также реализован режим --features parallel, использующий библиотеку Rayon для распараллеливания сжатия отдельных файлов.


Евгений Рошал, создатель RAR, прокомментировал использование обратного инжиниринга старых бинарных файлов RAR при разработке rars, что запрещено лицензионным соглашением. По словам Евгения, он пока не определился, что с этим делать и намерен дождаться мнения компании win.rar GmbH.

dataman
()

Рекомендации по использованию AI при разработке открытого кода

 , , , ,

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

Правозащитная организация Software Freedom Conservancy (SFC), предоставляющая юридическую защиту свободным проектам и отстаивающая необходимость соблюдения лицензии GPL, подготовила список рекомендаций по использованию AI-систем на базе генеративных моделей машинного обучения при подготовке кода для открытых проектов. Рекомендации касаются юридических, этических и социальных особенностей применения AI при разработке кода под открытыми и свободными лицензиями, а также отражают взаимодействие разработчиков c AI, учитывая противоположные мнения в сообществе о допустимости применения AI в открытых проектах. Рекомендации пытаются свести к минимуму проблемы, которые могут возникнуть из-за использования AI-систем по своей инициативе или по требованию работодателя.

  1. Сообщество должно поддерживать, а не просто терпимо относиться к участникам, выступающим против применения генеративных AI-систем.
  2. Каждый участник имеет право на самоопределение в вопросах использования AI и никто не должен вынуждать применять подобные системы под давлением. Принятие политики недискриминации в отношении тех, кто отказывается от AI, и недопустимость принуждения работников компаний к использованию AI.
  3. Открытые проекты не должны отталкивать участников, применяющих AI, даже если проект ввёл запрет на принятие созданного через AI кода. В подобных проектах созданные через AI патчи следует рассматривать как слабую пробу пера и корректно отклонять их, приветствуя при этом само желание участвовать в разработке и вежливо объясняя, почему проект не принял патч.
  4. В случае создания материалов через AI, участник обязан потратить время на рецензирование, разбор сути и внесение доработок. Разработчики должны полностью понимать суть изменений и разбираться в передаваемом коде.
  5. Раскрытие в примечании к коммитам информации об использовании AI при подготовке изменений с детализацией уровня участия AI, используемых AI-систем и их версий.
  6. Код, сгенерированный AI-системой на основе промпта и не прошедший проверку человеком, допускается отправлять только в специально оговорённых случаях. Если возможность передачи подобного непроверенного кода не обозначена, то его следует считать нежелательным.
  7. Разработчики должны подробно и точно документировать своё взаимодействие с AI-моделью в процессе генерации кода и сохранять информацию о промптах наравне с исходным кодом.
  8. Юридические нормы, связанные с лицензированием и авторским правом на код, генерируемый при помощи AI, ещё находятся на стадии становления, поэтому не следует делать поспешные заключения о допустимости переписывания кода при помощи AI для замены лицензии с копилефт на пермиссивную или смены имущественных прав на код.
  9. Обрабатываемые в AI входные данные влияют на лицензирование результата. Вопросы влияния лицензий на код, используемый при обучении модели, пока остаются не решёнными. Но при генерации кода не «с нуля» (на основе голого промпта), а при работе с существующей кодовой базой, например, при подготовке патча или доработке кода, результат должен распространяться под копилефт-лицензией, если он создан при обработке кода c копилефт-лицензией.
  10. В качестве наиболее безопасного и жизнеспособного варианта рекомендуется использование копилефт-лицензий для нового кода, создаваемого при участии AI. Подобный подход снижает риски нарушения копилефт-лицензий на код, использованный при обучении AI-моделей. Судебных решений в этой области ещё не было и пока не сложилась юридическая практика, определяющая влияние на результат лицензий, под которыми распространяются материалы, используемые при обучении AI-моделей.
  11. Использование AI-систем, включая проприетарные, рассматривается как допустимый стратегический компромисс, если они способствуют ускорению развития открытого ПО.
  12. При разработке AI-систем рекомендуется развивать платформы, более дружественные к идеям открытого и свободного ПО.
  13. AI-системы должны расширять инструменты и опыт разработчика, а не заменять их и приводить к деградации навыков. Разработчики должны сохранять любопытство и желание разбираться в том, почему код ведёт себя так, а не иначе, и это любопытство должно распространяться на результаты работы AI.
  14. Разработчики должны осознанно подходить к использованию AI-систем, не обращаться к ним по мелочам и избегать бессмысленных вычислений, понимая, что выполнение AI-моделей приводит к значительному потреблению ресурсов и косвенно влияет на окружающую среду.
dataman
()

Опубликована 67 редакция рейтинга самых высокопроизводительных суперкомпьютеров

 , ,

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

Опубликован 67-й выпуск рейтинга 500 самых высокопроизводительных компьютеров мира. Наиболее заметным изменением в рейтинге стало занятие первого места новым китайским кластером LineShine, работающим под управлением Ubuntu Kylin. Кластер развёрнут в шэньчжэньском центре облачных вычислений, включает 13.78 миллионов процессорных ядер (304-ядерный CPU LingKun LX2 304C 1.55GHz на архитектуре ARMv9) и обеспечивает производительность почти 2.2 экзафлопса, что на 400 петафлопс больше, чем у прошлого лидера.

Четыре лидера прошлого рейтинга сместились на 2-5 места: 2. Кластер El Capitan, запущенный в Ливерморской национальной лаборатории Министерства энергетики США. Кластер насчитывает 11.3 миллионов процессорных ядер (CPU AMD EPYC 24C 1.8GH с ускорителем AMD Instinct MI300X) и обеспечивает производительность 1.809 экзафлопсов. В качестве операционной системы применяется HPE Cray OS (редакция SUSE Linux Enterprise Server 15). 3. Кластер Frontier, размещённый в Ок-Риджской национальной лаборатории Министерства энергетики США. 9 млн процессорных ядер (CPU AMD EPYC 64C 2GHz, ускоритель AMD Instinct MI250X). Производительность 1.353 экзафлопсов. Операционная система HPE Cray OS. 4. Кластер Aurora, развёрнутый в Аргоннской национальной лаборатории Министерства энергетики США. 9.2 млн процессорных ядер (CPU Xeon CPU Max 9470 52C 2.4GHz, ускоритель Intel Data Center GPU Max). Производительность 1.012 экзафлопса. Операционная система SUSE Linux Enterprise Server 15 SP4. 5. Кластер JUPITER Booster, запущенный в суперкомпьютерном центре Юлих (Германия). Кластер насчитывает 4.8 млн процессорных ядер (NVIDIA GH200 Grace Hopper Superchip 72C 3GHz) и демонстрирует производительность 1 экзафлопс. Операционная система - RedHat Enterprise Linux.

Шестое место занял новый итальянский кластер HPC7 на платформе HPE Cray EX255a, насчитывающий 3.46 млн процессорных ядер (CPU AMD EPYC 24C 1.8GHz с ускорителем AMD Instinct MI300A). Производительность 571 петафлопс. Операционная система RHEL 9.

С 7 по 10 места заняли кластеры, в прошлом рейтинге занимавшие 5-8 места:

  1. Кластер Eagle (Microsoft Azure, 2 млн процессорных ядер (CPU Xeon Platinum 8480C 48C 2GHz), производительность 561 петафлопс, ОС Ubuntu 22.04.
  2. Кластер HPC6 (итальянская нефтегазовая компании «Эни», 3 млн процессорных ядер (AMD EPYC 64C 2GHz), производительность в 477 петафлопса, ОС RHEL 8.9.
  3. Кластер Fugaku (институте физико-химических исследований RIKEN (Япония), 158976 узлов на базе SoC Fujitsu A64FX (48-ядерные CPU Armv8.2-A SVE 2.2GHz), производительность 442 петафлопса, ОС Red Hat Enterprise Linux.
  4. Кластер Alps (Швейцарский национальный суперкомпьютерный центр, 2.1 млн процессорных ядер (NVIDIA Grace 72C 3.1GHz), производительность 434 петафлопса, ОС HPE Cray OS.

Что касается отечественных суперкомпьютеров, то в рейтинг вошло 5 российских кластеров (для сравнения с ноября 2024 по июнь 2025 года в рейтинге было 6 отечественных систем, c 2021 по 2024 год - 7, в 2020 году - 2, в 2017 году - 5, а в 2012 году - 12). Созданные компанией Яндекс кластеры Червоненкис, Галушкин и Ляпунов опустились с 83, 115 и 140 мест на 101, 134 и 161 места. Данные кластеры созданы для решения задач машинного обучения и обеспечивают производительность 21.5, 16 и 12.8 петафлопса соответственно. Кластеры работают под управлением Ubuntu 16.04 и оснащены процессорами AMD EPYC 7xxx и GPU NVIDIA A100: кластер Chervonenkis насчитывает 199 узлов (193 тысячи ядер AMD EPYC 7702 64C 2GH и 1592 GPU NVIDIA A100 80G), Galushkin - 136 узлов (134 тысячи ядер AMD EPYC 7702 64C 2GH и 1088 GPU NVIDIA A100 80G), Lyapunov - 137 узлов (130 тысяч ядер AMD EPYC 7662 64C 2GHz и 1096 GPU NVIDIA A100 40G).

Развёрнутый Сбербанком кластер Christofari Neo опустился со 147 на 167 место. Christofari Neo работает под управлением NVIDIA DGX OS 5 (редакция Ubuntu) и демонстрирует производительность 11.95 петафлопса. Кластер насчитывает более 98 тысяч вычислительных ядер на базе CPU AMD EPYC 7742 64C 2.25GHz и поставляется с GPU NVIDIA A100 80GB. Второй кластер Сбербанка (Christofari) за полгода сместился с 233 на 257 место в рейтинге.

В рейтиге также присутствуют два кластера из Казахстана: 104 место занял кластер Alem.Cloud развёрнутый в Международном центре искусственного интеллекта на базе платформы HPE Cray XD670, включающий 66.8 тысяч ядер Intel Xeon Platinum 8568Y+ 48C 2.3GHz c ускорителем NVIDIA H200 SXM5 141 GB, 400g. ОС SLES 15. Производительность 20.48 петафлопса. На 122 месте находится кластер AI-Farabium развёрнутый в компании Казахтелеком на базе платформы Supermicro SYS-821GE-TNHR с 57 тысячами ядер Xeon Platinum 8558 48C 2.1GHz с ускорителем NVIDIA H200 SXM5 141 GB. ОС Ubuntu 22.04.4. Производительность 17.93 петафлопса.

Один кластер присутствует в Узбекистане - digital.uz, развёрнут в министерстве цифровых технологий и занимает 321 место в рейтинге. Кластер включает 20.7 тысяч ядер Xeon Platinum 8570 56C 2.1GHz с ускорителем NVIDIA B200 180 GB. ОС DGX OS 7.4.0 на базе Ubuntu. Производительность 4.45 петафлопса.

Наиболее интересные тенденции:

  • Распределение по количеству суперкомпьютеров в разных странах:
    1. США: 162 (172 - полгода назад). Суммарная производительность оценивается в 32.4% от всей производительности рейтинга (полгода назад - 46.5%, год назад - 48.4%, полтора года назад - 55.2%);
    2. Япония: 44 (43). Суммарная производительность - 8.8% (9.5%);
    3. Германия: 41 (40). Суммарная производительность - 8.2% (9.3%);
    4. Китай: 30 (39). Суммарная производительность - 6% (полгода назад - 1.3%, год назад - 2%, полтора года назад - 2.7%);
    5. Франция: 21 (22). Суммарная производительность - 4.2% (2.1%);
    6. Южная Корея 19 (15). Суммарная производительность - 3.8% (2.2%);
    7. Италия: 18 (18). Суммарная производительность - 3.6% (5.9%);
    8. Канада 17 (19). Суммарная производительность - 3.4% (1.1%);
    9. Великобритания: 11 (10). Суммарная производительность - 2.2% (2.6%);
    10. Тайвань: 11 (10). Суммарная производительность - 2.2% (1.4%);
    11. Бразилия 10 (10). Суммарная производительность - 2%;
    12. Швеция 9 (8);
    13. Норвегия: 8 (9);
    14. Польша: 8 (8);
    15. Саудовская Аравия 8 (7);
    16. Индия: 7 (6);
    17. Нидерланды: 7 (7);
    18. Сингапур: 7 (4);
    19. Объединённые Арабские Эмираты: 5 (5).
    20. Финляндия: 5 (3);
    21. Россия 5 (5);
    22. Австралия: 4;
    23. Швейцария 3 (3);
    24. Чехия: 3 (3);
    25. Испания: 3 (3).
    26. Израиль: 3 (3);
    27. Австрия: 3 (4);
  • В рейтинге операционных систем, используемых в суперкомпьютерах, c ноября 2017 года остаётся только Linux;
  • Распределение по дистрибутивам Linux (в скобках - 6 месяцев назад):
    • 22% (20.8%) - RHEL;
    • 16.6% (13.6%) - Ubuntu;
    • 9% (7.2%) - Rocky Linux;
    • 7% (9%) - Cray Linux;
    • 6.4% (7.6%) CentOS;
    • 3.6% (3.8%) - SUSE;
    • 2% (1.8%) - Alma Linux;
    • 0.2% (0.2%) - Amazon Linux
  • Минимальный порог производительности для вхождения в Top500 за 6 месяцев составил 2.66 петафлопса (полгода назад - 2.57 петафлопса). Десять лет назад лишь 96 кластера показывали производительность более петафлопса. Для Top100 порог вхождения вырос с 18.2 до 21.85 петафлопса, а для Top10 вырос с 241 до 434 петафлопса.
  • Суммарная производительность всех систем в рейтинге за 6 месяцев возросла с 15 до 18.7 экзафлопса (пять лет назад было 2.7 экзафлопса, десять лет назад - 0.57 экзафлопса). Система, замыкающая нынешний рейтинг, в прошлом выпуске находилась на 475 месте.
  • Общее распределение по количеству суперкомпьютеров в разных частях света выглядит следующим образом:
    • 179 суперкомпьютер находится в Северной Америке (191 - полгода назад),
    • 160 в Европе (154),
    • 144 в Азии (139),
    • 11 в Южной Америке (11),
    • 4 в Океании (4),
    • 2 в Африке (1).
  • В качестве процессорной основы лидируют CPU Intel - 53% (полгода назад было 57.2%), на втором месте AMD 38.4% (33.6%), на третьем NVIDIA Grace - 5.2% (3.6%), на четвёртом Fujitsu A64FX - 1.6% (1.8%) и на пятом IBM Power - 0.4% (0.8%).
  • 20.8% (полгода назад 20.2%) всех используемых процессоров имеют 64 ядра, 13.4% (15.2%) - 24 ядра, 13.4% (13%) - 32 ядра, 12% (10.8%) - 56 ядер, 10.8% (10.2%) - 48 ядер, 5.2% (3.8%) - 72 ядра, 5% (6.2%) - 20 ядер, 4.4% (3.6%) - 96 ядер. Суммарное число процессорных ядер во всех кластерах рейтинга за полгода сократилось возросло с 135.7 млн до 152.6 млн.
  • 274 из 500 систем (полгода назад - 252) дополнительно используют ускорители или сопроцессоры, при этом в 238 (218) системах задействованы чипы NVIDIA, в 32 (29) - AMD, в 4 (4) - Intel DataCenter GPU.
  • Среди производителей кластеров на первом месте закрепилась компания Lenovo - 25.8% (полгода назад 28%), на втором месте компания Hewlett-Packard Enterprise - 24.8% (25.2%), на третьем месте компания Bull - 11.6% (11.4%), далее следуют Dell 9.8% (9.2%), NVIDIA 7.4% (6.6%), NEC 3% (2.8%), Fujitsu 2.6% (3%), MEGWARE 1.6% (1.4%), Microsoft Azure - 1.6% (1.6%), Supermicro 1.6% (1.2%), Penguin Computing - 1% (1.4%), ASUS 1.2% (1.2%).
  • InfiniBand применяется для связи узлов в 58.6% кластеров (полгода назад 55.4%), Ethernet используется в 33.6% (33.8%) кластеров, Omnipath - 5.2% (6%). Если рассматривать суммарную производительность, то системы на базе InfiniBand охватывают 37.9% (42.6%) всей производительности Top500, а Ethernet - 45.6% (51.2%).

Одновременно опубликован новый выпуск альтернативного рейтинга кластерных систем Graph 500, ориентированного на оценку производительности суперкомпьютерных платформ, связанных с симулированием физических процессов и задач по обработке больших массивов данных, свойственных для таких систем. Рейтинги Green500, HPCG (High-Performance Conjugate Gradient) и HPL-AI объединены с Top500 и отражаются в основном рейтинге Top500.

dataman
()

Герб Саттер — отчёт о встрече по стандартам ISO C++ в июне 2026 года

 ,

https://herbsutter.com/2026/06/13/brno-trip-report.

Несколько минут назад (прим.: 13 июня 2026 г.) комитет ISO по C++ завершил первое заседание по C++29 в прекрасном городе Брно, Чехия (в гибридном формате с онлайн-участием через Zoom).

Организатором этой встречи выступил Университет имени Менделя в Брно. Благодарим всех, кто принимал участие в её проведении, и в особенности Хану Дусикову, которая возглавила работу по подготовке мероприятия! Наши хозяева обеспечили нам высококачественные условия для проведения шестидневной встречи с понедельника по субботу.

В мероприятии приняли участие около 200 человек, из которых примерно 55% присутствовали на месте, а 45% — онлайн; они официально представляли 28 стран. На каждой встрече у нас регулярно появляются новые гости, которые никогда раньше не участвовали в мероприятии, и на этот раз, помимо новых участников, являющихся официальными представителями национальных организаций, было 25 новых гостей, в основном присутствовавших на месте. Ещё раз приветствуем всех!

В настоящее время в составе комитета действуют 22 подгруппы, 11 из которых в течение недели проводили заседания в рамках 6 параллельных сессий. Некоторые группы работали всю неделю, а другие — несколько дней или часть дня, в зависимости от объёма работы. Краткое изложение процедур ISO можно найти здесь.

Принято для C++29: Изменения и новые возможности ядра языка

Эти ссылки ведут на самые последние общедоступные версии каждой статьи. Если статья была доработана на заседании перед утверждением, ссылка отслеживает изменения и автоматически найдёт обновлённую версию, как только она будет загружена на общедоступный сайт. Некоторые из принятых нововведений в языке и библиотеках уже сегодня поддерживаются в основных реализациях C++. «Принято для C++29» не означает, что «придётся ждать до 2029 года или позже, чтобы увидеть их поддержку в реальных компиляторах и стандартных библиотеках». Помимо устранения ряда проблем, основная рабочая группа одобрила 19 документов, в том числе следующие:

  • P3596R3 «Неопределённое поведение и приложения IFNDR» (авторы: Joshua Berne, Timur Doumler, Jens Maurer и Shafik Yaghmour). Данная статья дополняет стандарт C++ двумя приложениями, в которых подробно каталогизированы и задокументированы все случаи неопределённого поведения (UB) в C++, включая случаи, помеченные как «некорректная форма, диагностика не требуется» (IFNDR). Данный каталог предназначен для содействия смягчению или устранению случаев UB, в том числе с помощью профилей. Это была, простите за мой французский, целая «[метрическая] тонна» работы, проделанной на протяжении нескольких лет. Спасибо Shafik, Joshua, Timur, Jens и всем, кто помог им составить этот подробный каталог, благодаря чему теперь мы сможем систематически заняться этими случаями неопределённости (UB)! Следующим шагом станет рассмотрение каждого случая в отдельности, которое начнётся в следующем месяце с целью систематического решения этих проблем к C++29, возможно, уже в течение следующего года (подробнее об этом ниже). Здесь, в C++, мы смотрим в глаза реальности без страха и пристрастий. На случай, если это нужно повторить: «Да, Вирджиния, существует динамичный, живой и современный язык программирования под названием C++». (Только, в отличие от оригинала, эта версия — правда для взрослых).

  • P3097R3 «Контракты в C++: виртуальные функции» (авторы: Timur Doumler, Joshua Berne и Gašper Ažman). Цитата из статьи:

    «Утверждения переопределяющей функции не зависят от утверждений в переопределяемой функции. При вызове виртуальной функции оцениваются утверждения о предварительных и конечных условиях как статически выбранной функции, так и конечной переопределяющей функции. Данный подход развивает ранее предложенные решения, поддерживая более широкий спектр сценариев использования, встречающихся в существующем коде, более естественно интегрируясь с семантикой оценки контрактов и обработкой нарушений контрактов в C++26, а также лучше подходя для языка C++, чем более ограничительные модели в таких языках, как Eiffel и D».

    Добавление этой функции устраняет одну из основных претензий к контрактам в C++26, а именно то, что первоначальная версия контрактов не поддерживала виртуальные функции. Теперь, менее чем через три месяца после технического завершения работы над C++26, в проекте стандарта C++29 контракты уже поддерживают виртуальные функции. Это свидетельствует о том, что комитет серьёзно настроен на развитие контрактов C++26 в рамках C++29. Спасибо, Timur, Joshua and Gašper!

  • P3668R4 «Операции инкремента и декремента в постфиксной нотации по умолчанию» (авторы: Matthew Taylor и Alex). В данной статье добавляется поддержка =default для операторов инкремента и декремента в постфиксной нотации, что позволяет использовать каноническое определение, отсылающее к префиксным версиям, без необходимости вручную писать шаблонный код (и, возможно, допускать ошибки). Спасибо, Matthew и Alex! Например, приведённый в статье пример теперь допустим в проекте C++29:

class foo{
    int member;
public:
    constexpr foo& operator++(){
        ++member;
        return *this;
    }
    constexpr foo operator++(int) = default;
};
struct A { int a; };

struct B : A { int b; };

B{{1}, 2}         // уже допустимо в C++17
B{1, 2}           // уже допустимо в C++17

B{.a=1, .b=2}     // теперь допустимо в C++29
B{{.a=1}, .b=2}   // теперь допустимо в C++29
B{.a{1}, .b{2}}   // теперь допустимо в C++29

B{.b=2, .a=1}     // остаётся недопустимым

Кроме того, мы добавили ещё целый ряд языковых расширений и улучшений.

Принято для C++29: Изменения и новые возможности стандартной библиотеки

Помимо устранения ряда проблем, в стандартную библиотеку были включены 18 статей, в том числе следующие:

  • P3091 «Улучшенные операции поиска для map, unordered_map и flat_map» (автор: Pablo Halpern). Этот документ добавляет в C++29 поддержку вызова .lookup(key) в стиле Python для map, unordered_map и flat_map. Эта функция, возвращающая опциональный параметр, открывает возможности, недоступные сегодня с помощью оператора [], который всегда вставляет элемент, если его нет, и find, который находит только те элементы, которые присутствуют. Спасибо, Pablo! Вот пример из статьи:
constexpr double inf = std::numeric_limits<double>::infinity();

double largest = -inf;

for (int i = 1; i <= 100; ++i) {
  largest = std::max(largest, theMap.lookup(i).value_or(-inf));
}
  • P3125R6 «Маркировка указателей constexpr» (автор: Hana Dusíková, известная как «королева constexpr»). Представленный в этой статье тип указателя с тегом pointer_tag_pair<Pointer, BitsRequested = /* доступные младшие биты */, Tag = unsigned> обеспечивает переносимую поддержку хранения информации в младших битах указателей. Это библиотека низкого уровня, полезная для решения многих задач, включая обеспечение безопасности памяти и усиление защиты. Спасибо, Hana!
  • P3248 «Сделать [u]intptr_t обязательными» (автор: Gonzalo Brito Gadeschi). Формально в C и C++ до сих пор типы intptr_t и uintptr_t были «необязательными», поэтому реализация на C++ могла не поддерживать их. Поскольку они полезны для низкоуровневого кода и уже широко поддерживаются, теперь стандарт C++ будет требовать их наличия. Спасибо, Gonzalo!
    Мы также добавили ряд других расширений и улучшений библиотеки.
Другие достижения, в частности в области обеспечения безопасности работы с памятью

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

  • Систематическое решение проблемы неопределённого поведения (UB) в C++ для стандарта C++29. Подгруппа по развитию языка (EWG) также одобрила выделение значительного времени этим летом и осенью на построчное рассмотрение в режиме телеконференции документа P3100 «Концептуальная основа для систематического решения проблемы неопределённого поведения в стандарте C++» (авторы: Timur Doumler and Joshua Berne), с целью включения его в стандарт C++29. Отличное краткое изложение можно найти в аннотации к документу.
  • Спецификация профилей для C++29. Подгруппа по безопасности и защите (SG23) приняла решение разработать спецификацию профилей, которая позволит использовать правила статического и иного анализа, ограничивающие набор функций C++, с целью обеспечения того, чтобы в коде не использовались нежелательные (например, небезопасные с точки зрения памяти) операции, и тем самым усилить безопасность кода C++ определёнными способами. Эта спецификация будет включена в C++29, если она будет готова вовремя, как ожидается; в противном случае она может быть опубликована в виде технического документа одновременно с C++29.
  • Профиль инициализации. Группа SG23 также рассмотрела текущий проект документа P4222 «Профиль инициализации» (автор: Bjarne Stroustrup), и мы рассчитываем добиться дальнейшего прогресса в этой работе в течение этого года, в том числе с учётом опыта реализации по крайней мере в одной крупной кодовой базе компилятора.

Как я уже упоминал в своих предыдущих отчетах о поездках, среди других документов по профилям, над которыми я ранее работал, можно назвать P3984 «Профиль безопасности типов» (автор: Bjarne Stroustrup) и P3589R2 «Профили C++: инфраструктура» (автор: Gabriel Dos Reis), а также ряд других дополняющих их документов с предложениями по профилям.

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

  • предоставляется способ систематически решать проблемы, связанные с неопределённым поведением (UB) в C++, и
  • предоставляется способ гарантировать, что программа на C++ обладает определёнными свойствами, например, отсутствие ошибок, связанных с безопасностью работы с памятью.

Мы ещё не достигли этой цели, но обе задачи теперь явно выходят за рамки простого желания; это серьёзные рабочие задачи, по которым комитет намерен добиться значительного прогресса в ближайшем будущем. Я буду продолжать освещать эти усилия в будущих отчётах о поездках по мере продвижения работы.

Напоминание для тех, кто по-прежнему скептически относится к тому, что реализация UB на C++ когда-нибудь станет возможной: помните, что мы уже этим занимаемся. Не живите прошлым… «Уже не 2021 год». BeCPP, YouTube.

  • Код constexpr C++, который в настоящее время охватывает практически весь язык C++ и стандартную библиотеку, уже гарантированно не вызывает неопределённого поведения при выполнении на этапе компиляции.
  • В C++26 были устранены ещё два основных источника неопределённого поведения (UB): использование неинициализированных переменных стека больше не приводит к UB, а в упрочнённой стандартной библиотеке C++ добавлена защита от выхода за пределы для десятков наиболее распространённых операций с границами (эта функция уже широко внедрена для упрочнения платформ Apple и Google; подробнее об этом см. в моём предыдущем отчёте о поездке).
В заключение

Еще раз благодарим около 200 экспертов, которые приняли участие в заседании на этой неделе как очно, так и в режиме онлайн, а также всех тех, кто участвует в работе по стандартизации через свои национальные органы!

Но мы не собираемся сбавлять обороты… Мы продолжим проводить заседания подгрупп в Zoom, а наше следующее полное заседание состоится в ноябре в Армасан-дус-Бузиус, недалеко от Рио-де-Жанейро (Бразилия), где мы продолжим работу над добавлением новых возможностей в C++29. Надеюсь увидеть многих из вас там.

Спасибо всем, кто читает это сообщение, за ваш интерес и поддержку C++ и его стандартизации.

dataman
()

Новости от unclestephen

 , , , ,

Товарищи модераторы и корректоры!
Вы как хотите, а я больше не буду их подтверждать.

Особенно призываю присоединиться ко мне @cetjs2, официально. ;)

dataman
()

Регрессии в rsync 3.4.3 и принятие изменений, подготовленных с использованием AI

 , ,

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

После выхода обновления утилиты для синхронизации файлов rsync 3.4.3 с исправлением 6 уязвимостей, отмечено появление регрессий, нарушающих работоспособность ранее используемых конфигураций. Помимо этого непонимание и недовольство вызвало добавление за последние две недели в репозитории rsync около 50 изменений, подготовленных с использованием AI-модели Claude. Некоторые пользователи связали появление регрессий с генерацией низкокачественных исправлений уязвимостей при помощи AI.

Некоторые из регрессий в rsync 3.4.3:

Эндрю Триджелл (Andrew Tridgell), основатель проектов samba и rsync, два года назад вернувшийся к сопровождению rsync и добавивший проблемные коммиты, опубликовал заметку с пояснением сложившейся ситуации. По словам Эндрю, проект rsync столкнулся с лавиной отчётов об уязвимостях, многие из которых были сгенерированы через AI. В релизе rsync 3.4.3 появление регрессий стало ценой устранения уязвимостей. Эндрю сознательно предпочёл исправить уязвимости, несмотря на то, что исправления могли нарушить работу некоторых редких, но корректных сценариев использования rsync. Подобные сценарии не покрывались старым тестовым набором и ручными проверками, поэтому регрессии остались не замеченными и будут устранены в следующим выпуске 3.4.4.

Возникшая ситуация побудила Эндрю модернизировать тестовый набор, ввести проверку покрытия кода и реализовать тестирование в системе непрерывной интеграции на разных платформах, а также выполнить анализ потенциальных уязвимостей. Так как Эндрю уже почти 60 лет и он предпочёл бы путешествовать на яхте, а не тратить своё время на устранение уязвимостей в rsync, он решил привлечь AI-ассистенты для выполнения рутинных задач в условиях свалившейся лавины сообщений об уязвимостях. Эндрю разработал архитектуру, план проверки и структуру нового тестового набора, после чего при помощи AI сгенерировал его на Python и заменил им ранее применявшийся тестовый shell-скрипт. При разработке использовалась модель Claude с ручной проверкой результата и перекрёстной проверкой в Codex и Gemini.

dataman
()

Чего достиг «Джеймс Уэбб» за 4.5 года работы?

 , , , ,

https://t.me/kosmo_off/11011:

Чего достиг «Джеймс Уэбб» на настоящий момент?

Вот уже 4,5 года космический телескоп «Джеймс Уэбб» наблюдает за Вселенной. Ежесекундно он дарит астрономам новые знания о прошлом и настоящем нашего мира. Пожалуй, можно подвести некоторые итоги его работы и вспомнить самые важные его открытия.

  • «Маленькие красные точки» (LRD) – объекты ранней Вселенной, по всей видимости, представляющие собой первичные сверхмассивные черные дыры.
  • «Темные звезды» - очень яркие светила, массой порядка миллиона солнечных, излучающие энергию за счет аннигиляции темной материи. Пока идентифицированы 4 кандидата в эти объекты.
  • «Галактики-нарушители» - массивные, зрелые галактики, существовавшие примерно 400 млн лет после гипотетического Большого Взрыва. До их открытия считалось, что галактики формировались намного медленнее.
  • JuMBO – они же «бинарные объекты массы Юпитера». Это бродячие пары газовых гигантов, не привязанных к конкретной звезде. Пока не совсем понятно, как именно образуются эти объекты.
  • Атмосферы экзопланет – благодаря высокой чувствительности «Джеймс Уэбб» может проводить спектральный анализ экзопланет, находящихся в десятках и сотнях световых лет от нас. Так был обнаружен диметилсульфид в атмосфере K2-18 b или углерод в верхних слоях странного газового гиганта PSR J2322-2650b.
  • Фотографии далеких объектов – «Уэбб» получил множество прямых изображений экзопланет, а также молодых протопланетных дисков и даже астероидных поясов.
  • Темная материя в столкновениях скоплений - Уэбб подтвердил и детализировал карты распределения темной материи в скоплении Пуля — визуально видно, как горячий газ тормозит, а темная материя проходит сквозь себя без взаимодействия.

«Джеймс Уэбб» уже открыл для нас Вселенную с новой стороны, а ведь он все еще находится в начале своего пути. Впереди у него еще долгие годы активной работы и тысячи новых открытий.

https://ru.wikipedia.org/wiki/Джеймс_Уэбб_(телескоп).

dataman
()

Разработаны правила использования AI в проекте Rust

 , , ,

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

Разработчики языка программирования Rust готовят к публикации правила применения AI-ассистентов в проекте. Предложенные правила отточены в ходе обсуждения, насчитывающего более 3000 сообщений, одобрены 4 сопровождающими и ожидают публикации. За отдельными исключениями, правила запрещают передачу кода, сгенерированного через AI, в основной репозиторий rust-lang/rust, но не распространяются на субмодули, подветки и зависимости из каталога crates.io, а также другие репозитории организации. При этом правила разрешают использование AI для анализа, изучения, рецензирования и проверки кода.

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

Запрещено применение AI для формирования комментариев, отчётов о проблемах и описаний изменений, публикуемых от имени участника. При этом разрешено цитирование выдачи от AI с явной пометкой, что контент сформирован через AI (например, прикрепление результатов диагностики через AI). Запрещено создание документации через AI. При рецензировании запрещено рассмотрение выводов AI как достаточных для приёма или отклонения изменений - результаты проверки через AI могут носить только рекомендательный характер.

С оговорками и явным упоминанием, что результат получен через AI, разрешено применение AI для машинного перевода на другие языки, поиска и верификации ошибок, а также внесения незначительных изменений в код и тексты (например, правка опечаток и подбор синонимов).

В рамках эксперимента допускается передача заранее согласованных, некритичных, досконально проверенных и хорошо протестированных изменений, изначально сгенерированных через AI. Перед отправкой pull-запроса c подобным изменением, разработчик должен заранее договориться с рецензирующими. Предлагаемые изменения должны помечаться меткой «ai-assisted» и могут затрагивать вторичные инструменты, такие как tidy и linkchecker, но не должны касаться ключевых возможностей и элементов языка. Для отслеживания результатов эксперимента изменения предписано отправлять в отдельный приватный Zulip-канал, доступ к которому предоставлен только участникам проекта.

dataman
()

Во Flathub и GNOME Circle запрещено размещение приложений, сгенерированных при помощи AI

 , , , ,

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

Барт Пиотровски (Bart Piotrowski), сопровождающий инфраструктуру каталога приложений Flathub, объявил о внесении в правила Flathub изменений, запрещающих использование AI как для разработки размещаемых в каталоге приложений, так и для автоматизации процесса публикации во Flathub. Под действие правил подпадают публикуемые приложения, дополнения, файлы с манифестами, метаданные, патчи, сборочные скрипты, pull-запросы и любые артефакты, создаваемые через flatpak-builder.

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

В примечании Барт отметил, что большие языковые модели могут быть полезным инструментом и со временем всё меньше кода будет создаваться без их участия. Но в настоящее время реальность такова, что авторы программ, созданных через AI, зачастую не готовы прилагать усилия для создания и оттачивания полноценного продукта и выступают лишь посредниками, поставившими задачу AI-агенту и опубликовавшими результат. Указано, что Барт устал от обострившихся за последний месяц конфликтов с высокомерными авторами, возникающих после отказа принимать в каталог сырые программы, созданные через AI. По словам Барта, подобные авторы ведут себя так, будто дарят гениальное ПО, а какие-то идиоты отказываются его принимать.


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

Комитет, управляющий каталогом 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.

dataman
()