LINUX.ORG.RU

Сообщения dataman

 

Box3D 0.1.0

 , , box3d, ,

30 июня Эрин Катто, автор двумерного физического движка Box2D, опубликовал первую публичную альфа-версию 0.1.0 кроссплатформенного трёхмерного физического движка Box3D.

Проект написан на языке C (стандарт C17) и распространяется по лицензии MIT.
БЯМ использовались автором только для написания тестов и бенчмарков, примеров, миграции кода Box2D -> Box3D, рецензирования кода и конфигураций сборки.

На данный момент Box3D используется в игре The Legend of California (выйдет в этом году) студии Kintsugiyama, в которой Эрин сейчас и работает.

( читать дальше... )

>>> Анонс Box3D в блоге
>>> Видеопрезентация на youtube
>>> Документация

dataman
()

Git 2.55

 , , , ,

Git 2.55
Группа Разработка

Представлен релиз распределенной системы управления исходными текстами Git 2.55. Среди ключевых изменений: включение по умолчанию сборки с Rust, реализация для Linux процесса fsmonitor, новая стратегия переупаковки инкрементального MIDX-индекса, команда git history fixup для исправления коммита, оптимизация генерации битовых карт доступности объектов, поддержка параллельного выполнения хуков, команда git format-rev. Код Git распространяется под лицензией GPLv2+.

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

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
()

curl 8.21.0

 , , , ,

Группа Интернет

24 июня, после почти двух месяцев разработки, 531 коммита и исправления 276 ошибок, состоялся выпуск 8.21.0 (№275) кроссплатформенной многофункциональной консольной утилиты и библиотеки curl, написанных на языке C и распространяемых по лицензии curl.

( читать дальше... )


>>> Полный список изменений на curl.se (и в первой редакции этой новости)

>>> Видеопрезентация 8.21.0 на youtube

>>> Документация

>>> Страница загрузки

>>> Исходный код на GitHub

>>> Новость в блоге Даниэля Стенберга (haxx.se)

dataman
()

Stellarium 26.2

 , , , ,

Группа Open Source

24 июня состоялся выпуск 26.2 популярного свободного кроссплатформенного планетария Stellarium — второй в этом году.

( читать дальше... )

>>> Источник: stellarium.org (stellarium.org)

dataman
()

Показывать ли в профиле количество игнорирующих?

 , ,

Для участия в опросе войдите или зарегистрируйтесь.

>>> Результаты

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
()

fooyin 0.11.0 и 0.11.1

 , , , ,

Группа Мультимедиа

22 июня состоялись выпуски 0.11.0 и 0.11.1 fooyin — музыкального плеера, ориентированного на индивидуальную настройку. Он предоставляет множество виджетов для управления и воспроизведения локальной коллекции музыки. Плеер обладает широкими возможностями расширения благодаря системе плагинов и включает в себя FooScript — язык сценариев для расширенной настройки виджетов.

Вы можете полностью настроить пользовательский интерфейс, перейдя в режим редактирования макета: начав с нуля или воспользовавшись готовым.

( читать дальше... )

>>> Документация

>>> Исходный код

>>> Источник: CHANGELOG.md (raw.githubusercontent.com)

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
()

GNU nano 9.1 «met een hongerig paard aan ons been»

 , , , ,

Группа Open Source

23 июня состоялся выпуск 9.1 «met een hongerig paard aan ons been» консольного редактора GNU nano.

Изменения:

  • Область просмотра при поиске по возможности выравнивается по левому краю.
  • Удалена возможность чтения и записи файлов в старом формате Mac (то есть файлов, в которых в качестве символа конца строки используется одиночный символ возврата каретки).
  • Удалён переключатель ^T между командами WhereIs и GotoLine.
  • Исправлены проблемы резервного копирования файлов (с включенным параметром --backup).
  • Исправлена ошибка назначения прав и владельца файла .save, когда процесс nano был «убит» или «падал».
  • Теперь можно переназначать сочетания клавиш M-Ins и M-Del.

>>> Источник: nano-editor.org (nano-editor.org)

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
()

ZXC 0.12.0

 , , , ,

Группа Open Source

18 июня, после более месяца разработки, состоялся выпуск 0.12.0 библиотеки и кроссплатформенной консольной утилиты ZXC (github.com), реализующих высокопроизводительное многопоточное асимметричное сжатие без потерь и оптимизированное для игровых ресурсов, прошивок и пакетов приложений. Формат разработан по принципу «один раз записать, многократно читать» (WORM).

В отличие от таких кодеков, как LZ4, ZXC жертвует скоростью сжатия ради максимальной пропускной способности при распаковке.

Декларируется скорость распаковки на 10-47% выше, чем у LZ4 с уровнем компрессии по умолчанию, с равным или более высоким коэффициентом сжатия.

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

Версия формата контейнера обновлена до v6, а версия библиотеки SOVERSION увеличена с 3 до 4.

Проект написан на языке C и распространяется по лицензии BSD 3.

( читать дальше... )

>>> Подробности на GitHub (github.com)

dataman
()

Darktable 5.6.0

 , ,

Группа Мультимедиа

Представлен релиз программы для обработки цифровых фотографий Darktable. Darktable специализируется на недеструктивной работе с raw-изображениями и может использоваться в качестве свободной альтернативы Adobe Lightroom. Программа позволяет вести базу фотографий, осуществлять наглядную навигацию по имеющимся снимкам, а также корректировать искажения, устранять шумы, управлять цветом и улучшать качество фотографии, сохраняя при этом исходный снимок и всю историю операций с ним. Код проекта написан на языке Си и распространяется под лицензией GPLv3. Интерфейс построен с использованием библиотеки GTK. Бинарные сборки подготовлены для Linux (AppImage, в процессе подготовки flatpak и snap), Windows и macOS.

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

dataman
()

systemd 261 и liberated-systemd 261

 , , ,

Группа Linux General

После трёх месяцев разработки доступен релиз системного менеджера systemd 261. Ключевые изменения: подготовка к поддержке API для верификации возраста, поддержка подсистем Kexec Handover и Live Update Orchestration для перезапуска без потери состояния, подсистема IMDS (Instance Metadata Service), функциональность для защиты загрузки на системах без физического TPM (Trusted Platform Module), компонент systemd-sysinstall с реализацией инсталлятора.

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

dataman
()

whisper.cpp 1.9.0 и 1.9.1

 , , , ,

17 и 19 июня состоялись выпуски 1.9.0 и 1.9.1 высокопроизводительной системы автоматического распознавания речи whisper.cpp, реализующей модель Whisper от OpenAI, и основанной на тензорной библиотеке машинного обучения GGML и двоичном формате GGUF.

Предоставляется библиотека libwhisper, демонстрационные примеры и консольные утилиты: whisper-bench, whisper-cli, whisper-command, whisper-lsp, whisper-quantize, whisper-server, whisper-stream, whisper-vad-speech-segments, parakeet-cli и parakeet-quantize.

Проекты написаны на языках C и C++ и распространяются по лицензии MIT.

Изменения:

  • добавлена консольная утилита parakeet-cli, поддерживающая модель NVIDIA Parakeet;
  • во враппер Ruby также добавлена поддержка NVIDIA Parakeet.

( читать дальше... )

>>> Подробности на GitHub (github.com)

dataman
()

Файловая система Bcachefs официально перестала быть экспериментальной

 , , , ,

Группа Linux General

Кент Оверстрит (Kent Overstreet) опубликовал выпуск файловой системы Bcachefs 1.38.6 и объявил об официальном снятии с проекта метки экспериментальной разработки. Последнее время число поступающих сообщений о проблемах сократилось, а выявляемые ошибки стали менее серьёзными и замысловатыми.

Выпуск охватывает два пакета: bcachefs-kernel-dkms с модулем ядра, собираемым при помощи системы DKMS (Dynamic Kernel Module Support), и bcachefs-tools с запускаемой в пространстве пользователя утилитой bcachefs, реализующей команды для создания (mkfs), монтирования, восстановления и проверки ФС. Пакеты собраны для Debian, Ubuntu, Arch Linux и ожидаются для Fedora, openSUSE и NixOS. DKMS-модуль поддерживает работу с ядрами Linux, начиная с 6.16.

Несмотря на непримечательный номер версии, обусловленный отсутствием изменений в дисковом формате, выпуск 1.38.6 включает ряд серьёзных оптимизаций производительности. В код для работы со структурами в формате btree, журналирования и обеспечения работы файловой системы внесено около 200 изменений, повышающих производительность. Логика подтверждения транзакций ужата в 4КБ машинного кода, добавлены оптимизации для исключения возникновения конкурирующих блокировок (lock contention) при работе с btree, полностью избавлен от блокировок процесс сброса состояния журнала (journal flush).

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

dataman
()

pugixml 1.16

 , , , ,

Группа Разработка

16 июня, после почти полутора лет разработки, состоялся выпуск 1.16 pugixml — быстрой кроссплатформенной библиотеки для парсинга и обработки XML (лицензия MIT).

Библиотека предоставляет DOM-подобный интерфейс с возможностями обхода узлов документа и их изменения. Также поддерживается XPath 1.0 и полная поддержка Юникода (UTF-8, UTF-16 (BE/LE), UTF-32 (BE/LE) и UCS-2), с автоматическим преобразованием кодировок.

Поддерживается использование без стандартной библиотеки и исключений C++, и режим «только заголовочные файлы».

( читать дальше... )

>>> Репозиторий на GitHub

>>> Подробности на pugixml.org (pugixml.org)

dataman
()

Стандартизирован HTTP-метод QUERY, комбинирующий возможности GET и POST

 , , ,

Группа Интернет

Инженерный комитет IETF (Internet Engineering Task Force), занимающийся развитием протоколов и архитектуры сети Интернет, придал HTTP-методу QUERY статус «Предложенного стандарта» и опубликовал связанную с ним спецификацию RFC 10008. Метод QUERY по способу отправки данных на сервер повторяет метод POST, но отличается от него ориентацией не на запись данных и изменение состояния, а на формирование запросов на чтение.

По решаемым задачам новый метод близок к GET и позволят отправлять запросы, которые могут быть повторены или перезапущены без изменения состояния на сервере. Как и в методе POST параметры запроса в QUERY передаются не в URI, а в теле запроса. Подобный подход даёт возможность передавать большой объём параметров в запросе, превышающий лимит на размер параметров в методе GET (8000 байт).

( читать дальше... )

>>> Источник: OpenNET (opennet.ru)

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
()

lzbench 2.3

 , , , ,

Группа Open Source

Спустя почти восемь месяцев состоялся выпуск 2.3 консольной утилиты lzbench, предназначенной для сравнения многих популярных алгоритмов компрессии и декомпрессии (их список можно получить командой lzbench -l).

Утилита написана на языках C, С++, Rust и Zig, и распространяется по лицензии GNU GPL 2 или 3 — на ваш выбор.

Изменения:

  • группы псевдонимов компрессоров были реорганизованы по типу — группа ALL теперь представляет собой объединение групп LZ, SYMMETRIC и MISC; кодеки BWT/PPM (bsc, bzip2, bzip3, ppmd8) перенесены в группу SYMMETRIC, а kanzi разбит по алгоритмам на отдельные уровни между группами LZ и SYMMETRIC.
  • добавлены псевдонимы FASTEST (все компрессоры ALL только с максимальной скоростью) и SLOW для очень медленных компрессоров (glza).
  • кодеки CUDA теперь по умолчанию отключены и компилируются только при указании параметра ENABLE_CUDA=1.
  • кодек BSC теперь обрабатывает блоки, размер которых превышает ограничение на входные данные, разбивая их на фрагменты; максимальный размер входных данных кодека — это свойство кодека, используемое при определении размера буферов;
  • добавлен флаг сборки -mno-strict-align и макрос SNAPPY_HAVE_RVV для RISC-V;
  • различные исправления для платформ x86-32 (lzham), ARM32, а также обработка размера файлов в Windows;
  • исправлено выделение памяти для буфера компреcсии, с учётом накладных расходов, связанных с буфером разбиения блоков кодека;

( читать дальше... )

>>> Подробности на GitHub (github.com)

dataman
()