Упомянутый в 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.

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

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

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

Главное изменение этих версий — новый уровень сжатия 7 (ультра) с использованием сравнительно недавно опубликованным SIMD-оптимизированным алгоритмом PivCo-Huffman («pivot-coded Huffman») (репозиторий), который позволяет превысить коэффициент сжатия zstd (-1), при этом скорость декодирования остаётся примерно в 2 раза выше, чем у zstd. Энтропийное декодирование было переработано, что позволило увеличить её скорость на уровне 6 на 5–13% на всех эталонных процессорах.

Формат контейнера обновлён до версии 7 и это последнее запланированное изменение формата. Версия 0.13 является последним этапом перед выпуском версии 1.0, в которой формат контейнера ZXC будет зафиксирован, что обеспечит его стабильность и обратную совместимость.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. На это Полл ответил, что «этот корабль уплыл уже очень давно».

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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)

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 места:

7. Кластер Eagle (Microsoft Azure, 2 млн процессорных ядер (CPU Xeon Platinum 8480C 48C 2GHz), производительность 561 петафлопс, ОС Ubuntu 22.04.
8. Кластер HPC6 (итальянская нефтегазовая компании «Эни», 3 млн процессорных ядер (AMD EPYC 64C 2GHz), производительность в 477 петафлопса, ОС RHEL 8.9.
9. Кластер Fugaku (институте физико-химических исследований RIKEN (Япония), 158976 узлов на базе SoC Fujitsu A64FX (48-ядерные CPU Armv8.2-A SVE 2.2GHz), производительность 442 петафлопса, ОС Red Hat Enterprise Linux.
10. Кластер 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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)

Кент Оверстрит (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)

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)