Опубликована стабильная версия набора базовых системных утилит GNU Coreutils 9.10, в состав которого входят такие программы, как sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64742

Представлен выпуск GCompris 26.0, свободного обучающего центра для детей дошкольного и младшего школьного возраста. Пакет предоставляет 197 мини-уроков и модулей,  предлагающих от простейшего графического редактора, головоломок и клавиатурного тренажера до уроков математики, географии и обучения чтению. GCompris использует библиотеку Qt и развивается сообществом KDE. Готовые сборки сформированы для Linux, macOS, Windows, Raspberry Pi и Android...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64741

Организация The Document Foundation  опубликовала релиз офисного пакета LibreOffice 26.2. Готовые установочные пакеты подготовлены для различных дистрибутивов Linux, Windows и macOS. В версии 26.2 проект прекратил поставляться с меткой "Community" (LibreOffice Community) и...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64739

Европейская академия открытого ПО (EOSA, European Open Source Academy)...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64736

При работе с llama.cpp имеется постоянная необходимость её пересобирать, так как в отличие от ONNX Runtime GGUF-файлы не хранят сериализованный граф вычислений, вместо этого процедура инференса вручную кодится в C++-коде, и за счёт применения информации, которую в ONNX обычно не сериализуют (ONNX обычно экспортируется автоматически, но знания можно туда встроить, если закодировать конструирование ONNX-графа вручную), может быть достигнута большая эффективность (по потреблению ресурсов) инференса.

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

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

Однако проект имеет некоторые проблемы. Которые, впрочем, "никому" "не мешают", так как нейросети (стереотипно "тяжёлое" приложение, не смотря на то, что существуют мелкие нейросети размером в несколько мебибайт) запускать на "калькуляторе", "обогревателе" и "музейном хламе со свалки" никто "в здравом уме" (со слов "здравомыслящих") не будет. Проблемы заключаются в том, что проект долго компилируется и долго линкуется, и при этом имеет тенденцию требовать пересборки и перелинковки при малейших вроде-бы безобидных изменениях, вроде изменения переменной "CMAKE_INSTALL_LIBDIR". Я проанализировал и исправил некоторые, но не все, причины подобного поведения. Причины заключаются в том, что в проекте использованы приёмы, являющиеся антипаттернами, которые было бы неплохо разобрать, чтобы вы так не делали.

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

2. Проект имеет в нескольких местах "add_library(${TARGET} STATIC". Это приводит к тому, что некоторые куски кода линкуются статически в некоторые другие куски кода. Это, конечно, должно приводить к более быстрому коду при линковке с LTO, но линковка с LTO тот ещё тормоз, а инструментов в проекте мнооогооо, и никто и не задавался вопросом, нужна ли конкретно вон там максимальная производительность, достигаемая инлайном и стиранием границы между модулями, или всё же heavy lifting у нас делает GGML, и основная часть вычислений жрётся инференсом, а оптимизация консольной обёртки вокруг GGML даст очень немного.
При этом хардкод STATIC а равно SHARED является антипаттерном, так как в проектах на CMake это решение принимается теми людьми, кто исходник собирает в бинарники, и выставляется через стандартную переменную CMake "BUILD_SHARED_LIBS". Поэтому целесообразно там стереть STATIC, и при "set(BUILD_SHARED_LIBS ON)" это нам срежет время линковки. Поскольку библтотеки теперь могут быть SHARED, добавляем их установку ([[https://opennet.ru/soft/PNXG.patch  патч]]).

3. В проекте присутствует код

   cmake
   target_compile_definitions(ggml-base PRIVATE
       GGML_VERSION="${GGML_INSTALL_VERSION}"
       GGML_COMMIT="${GGML_BUILD_COMMIT}"
   )

При этом "GGML_BUILD_COMMIT" и "GGML_INSTALL_VERSION" динамически генерятся при запуске CMake. "ninja" автоматически определяет, какие объектные файлы нуждаются в перекомпиляции, и изменение аргументов вызова компилятора - это показание к перекомпиляции. Что приводит к тому, что при любом коммите "ggml-base" пересобирается полностью, а линкующие его бинари - перелинковываются, а от "ggml-base" транзитивно зависит почти весь проект.

Указанные макроопределения используются ровно в одних местах - в реализациях методов, возвращающих указанные значения, дальнейший доступ к этим значениям идёт исключительно через методы. Имеет смысл вынести указанные методы в отдельную библиотеку. Линковать я её бы, разумеется, предпочёл бы в соответствии с "BUILD_SHARED_LIBS", но так как смысл этих методов - быть прибитыми к файлу библиотеки ggml-base гвоздями, то вот тут как раз хардкодим "STATIC" ([[https://www.opennet.dev/soft/PNXD.patch патч]]).

4. В проекте присутствует

   cmake ()
   target_compile_definitions(ggml PUBLIC GGML_BACKEND_DIR="${GGML_BACKEND_DIR}")
  
, при этом макроопределение "GGML_BACKEND_DIR" за пределами библиотеки "ggml" не используется. Использование "PUBLIC" приводит к тому, что все бинари, которые линкуют "ggml", получат в командной строке вызова своего компилятора это определение. Соответственно, если вы потрогаете эту переменную, то это приведёт к почти полной перекомпиляции проекта. При этом это макроопределение используется в коде ровно в одном месте: "search_paths.push_back(fs::u8path(GGML_BACKEND_DIR));", и поэтому "PUBLIC" нужно смело менять на "PRIVATE".

По-хорошему путь вообще не должен хардкодиться, а должен определяться относительно бинарей. В проекте используется поиск в директории бинарей, но путь относительно неё не конфигурируется, а задание "GGML_BACKEND_DIR" используется для того, чтобы shared-библиотеки бэкендов легли не в "/usr/bin". Подход в некоторой степени странный. Логичнее сделать конфигурируемым путь относительно директории бинарника, тогда при изменении префикса пересобирать библиотеку не придётся, ибо относительный путь останется тем же ([[https://www.opennet.dev/soft/PNXk.patch патч]]).

5. В директории "common" в "CMakeLists.txt" есть кусочек

   cmake
   set(TEMPLATE_FILE "${CMAKE_CURRENT_SOURCE_DIR}/build-info.cpp.in")
   set(OUTPUT_FILE   "${CMAKE_CURRENT_BINARY_DIR}/build-info.cpp")
   configure_file(${TEMPLATE_FILE} ${OUTPUT_FILE})

   set(TARGET build_info)
   add_library(${TARGET} OBJECT ${OUTPUT_FILE})

, где файл шаблона

   c++
   int LLAMA_BUILD_NUMBER = @LLAMA_BUILD_NUMBER@;
   char const *LLAMA_COMMIT = "@LLAMA_BUILD_COMMIT@";
   char const *LLAMA_COMPILER = "@BUILD_COMPILER@";
   char const *LLAMA_BUILD_TARGET = "@BUILD_TARGET@";

Проблема такого решения в том, что при каждом запуске CMake пересоздаётся файл "${OUTPUT_FILE}", а от него уже транзитивно зависят все инструменты, что приведёт к их перелинковке. Ninja не считает хеши файлов, он определяет изменения файлов по атрибутам уровня файловой системы, за хешами - к "ccache". В то же время Ninja отслеживает изменения в командной строке компилятора по контенту, поэтому в данном случае предпочтительнее не пересоздавать файл исходного кода, а использовать макроопределения. Ещё я заменил OBJECT на STATIC. OBJECT в CMake поддерживается не особо официально, долгое время он был вообще недокументированой внутренней возможностью, о которой, тем не менее, все знали, и по-прежнему ломается в очень многих случаях ([[https://www.opennet.dev/soft/PNXn.patch патч]]).

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

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

8. Ещё имеет смысл запачить сборку ненужных бэкендов (она не настраивается гибко, и не мне это исправлять).

===

Другие патчи исправляют ошибки и добавляют улучшения, обсуждать их не имеет смысла, так как с антипаттернами, влияющими на скорость сборки, они не связаны. Апстрим всех патчей, как всегда, на вас, все что можно идёт под Unlicense (но содержат код, производный от оригинала под MIT), можете вообще от своего имени.

Единственное, что надо отметить: вы не можете просто взять и переместить библиотеки в другую директорию, как это сделано в Дебиане, из-за ошибки CMake: https://gitlab.kitware.com/cmake/cmake/-/issues/22621 . Дело в том, что по факту CMake не поддерживает установку библиотек в какие-либо директории, которые и так не находятся в RPATH, потому что машинерия CMake, которая патчит RPATH в бинарях при установке, не пытается собирать RPATH из путей установки линкуемых библиотек.

Соответственно все библиотеки и приложения, которые залинковали библиотеку, устанавливаемую не в место по умолчанию, её не найдут. В CMake нет опции, позволяющей это поправить, все опции, которые вы можете нагуглить для верси 4.2 делают другие вещи. Это определённо баг, так как функциональность установки CMake вместе с CPack должна собирать работоспособные пакеты, а место установки - оно определяется не в скрипте сборки, а собирающим.

Можно данную проблему поправить на уровне костыльного CMake-кода, ставящего RPATH вручную, если он не совпадает с "CMAKE_INSTALL_LIBDIR", но определённо это должно не так работать, и в этом проекте для этого придётся править код каждого инструмента, скорее всего апстрим такое не примет.

В Дебиане проблему решают (см. https://salsa.debian.org/deeplearning-team/llama.cpp и https://salsa.debian.org/deeplearning-team/ggml.git ) собирая GGML из отдельного репозитория (что в общем-то было бы правильно, но...), и для каждого вызова CMake вручную ставя RPATH в "debian/rules", но проблема в том, что отдельный репозиторий для GGML теперь не является основным, а основной "ggml" живёт в репозитории llama.cpp и иногда синхронизируется в ggml-евский и "whisper.cpp" копированием кода ("whisper.cpp" давно пора удалить, так как поддержка новых мультимодальных моделей (включая модели для TTS и ASR) завозятся в "llama.cpp"). Это неправильно и грязно, но это не мне решать, раз разрабам llama так удобно - то пусть в монорепе держат. Но в таком случае по-хорошему репозиторий "ggml" не мешало бы либо просто удалить, чтобы сломать всем скрипты сборки и делом довести до сведения, откуда надо теперь ggml ставить, либо заменить на CMake скрипт, использующий "FetchProject". А пока есть шанс, что в Дебиане llama будет слинкована с неподходящим ggml.

Все патчи можно скачать [[https://www.opennet.dev/soft/PN8z.7z единым архивом]]. Архив имеет 2 директории, в одной патчи для ускорения пересборки, а в другой - другие патчи, исправляющие некоторые проблемы и потенциальные проблемы в скриптах сборки, и имеющие некоторое отношение к пакетированию. Желателен апстрим всех. Ещё желателен рефактор ggml-части с разносом файлов исходников по директориям.

URL: https://github.com/ggml-org/llama.cpp/compare
Обсуждается: http://www.opennet.dev/tips/info/3291.shtml

Компания Google объявила о переименовании  SQL-анализатора ZetaSQL в GoogleSQL. Проект развивает инструментарий для разбора и анализа грамматики, семантики, типов, модели данных и функций для языка SQL и диалекта  GoogleSQL. Диалект GoogleSQL примечателен возможностью объединения запросов при помощи неименованных каналов (pipe) и  применяется в различных продуктах и сервисах Google, среди которых BigQuery, Spanner, F1, BigTable, Dremel и Procella. Код проекта написан на языке С++ и распространяется под лицензией  Apache 2.0...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64735

Доступен выпуск  приложения Calibre 9, автоматизирующего поддержание коллекции электронных книг. Calibre предлагает интерфейсы для навигации по библиотеке, чтения книг, преобразованию форматов, синхронизации с портативными устройствами на которых осуществляется чтение, просмотра новостей о появлении новинок на популярных web-ресурсах. В состав также входит реализация сервера для организации сетевого доступа к домашней коллекции. Код проекта написан на языке Python и распространяется под лицензией GPLv3...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64734

Опубликован релиз свободной загрузочной прошивки Libreboot 26.01, который получил статус стабильного выпуска. Проект развивает готовую сборку проекта Coreboot, предоставляющую замену проприетарным прошивкам UEFI и BIOS, отвечающим за инициализации CPU, памяти, периферийных устройств и других компонентов оборудования, с минимизацией бинарных вставок...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64733

Разработчики проекта Tor опубликовали выпуск Arti 2.0.0, официально развиваемого варианта инструментария Tor, написанного на языке Rust. Реализация отмечена как пригодная для использования обычными пользователями и обеспечивающая тот же уровень  конфиденциальности, юзабилити и стабильности, что и основная реализация на языке Си.  Когда код на Rust достигнет уровня, способного полностью заменить вариант на Си, разработчики намерены придать Arti статус основной реализации Tor и постепенно прекратить сопровождение варианта на Си. Код распространяется под лицензиями Apache 2.0 и MIT...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64732

Представлен релиз распределенной системы управления исходными текстами Git 2.53. Git отличается высокой производительностью  и  предоставляет средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, а также удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.  Код Git распространяется под лицензией GPLv2+...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64731

Опубликован выпуск проекта uutils coreutils 0.6.0 (Rust Coreutils), развивающего аналог пакета GNU Coreutils, написанный на языке Rust. В состав coreutils входит более ста утилит, включая sort, cat, chmod, chown, chroot, cp, date, dd, echo, hostname, id, ln и ls. Целью проекта является создание кроссплатформенной альтернативной реализации Coreutils, среди прочего способной работать на платформах Windows, Redox и Fuchsia...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64730

Брюс Дуббс (Bruce Dubbs), главный редактор проекта Linux From Scratch, объявил о прекращении обновления версий руководств Linux From Scratch (LFS) и  Beyond Linux From Scratch (BLFS) в конфигурации с системой инициализации SysVinit. Доступ к руководству LFS/BLFS 12.4  с SysVinit будет сохранён, но намеченный на 1 марта выпуск  LFS/BLFS 13.0 будет сформирован только в варианте  с системным менеджером systemd...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64728

Крис Мейсон (Chris Mason), создатель и мэйнтейнер файловой системы Btrfs, опубликовал проект review-prompts, содержащий коллекцию скриптов и подсказок для настройки процесса рецензирования изменений в ядре Linux и системном менеджере systemd, используя AI-ассистенты, такие как Сlaude Code. В состав включены файлы для уточнения особенностей работы различных подсистем и протоколов, позволяющие AI-ассистенту лучше понимать контекст при рецензировании, отладке и проверке изменений...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64709

Разработчики проекта GNU/Hurd  представили доклад о недавних достижениях и текущем состоянии проекта. Среди недавних достижений GNU/Hurd:...

Подробнее: https://www.opennet.dev/opennews/art.shtml?num=64727