После двух месяцев разработки Линус Торвальдс представил релиз ядра Linux 7.2. Среди наиболее заметных изменений: механизм потоковой передачи данных USB4STREAM, оптимизации производительности btrfs, xfs и ext4, продолжение удаления кода для поддержки CPU i486, возможность создания вложенных планировщиков SCHED_EXT, снижено потребление памяти в подсистеме подкачки, ускорены неименованные каналы, поддержка расширений Intel MBEC и AMD GMET в KVM, удаление протокола AppleTalk, начальная поддержка HDMI 2.1 FRL в драйвере AMDGPU.

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

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

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

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

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

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

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

13 августа состоялся выпуск 2.4.0 кроссплатформенного аудиоплеера Qmmp.

Некоторые возможности плеера:

• Поддержка операционных систем GNU/Linux, FreeBSD и Microsoft Windows.
• Поддержка большого количества мультимедийных форматов.
• Аудио и визуальные эффекты.
• Поддержка систем вывода звука:
  • OSS4 (FreeBSD)
  • ALSA (Linux)
  • PulseAudio
  • PipeWire
  • JACK
  • QtMultimedia
  • Icecast
  • WaveOut (Win32)
  • DirectSound (Win32)
  • WASAPI (Win32)
• Поддержка обложек XMMS и Winamp 2.x.
• Альтернативный пользовательский интерфейс с использованием стандартного оформления.
• 10-полосный эквалайзер.
• И многое другое.

Проект написан на языке программирования C++ с использованием фреймворка Qt6 и распространяется по лицензии GNU GPL 2.
Поддерживается расширение возможностей плагинами.

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

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

После четырёх месяцев разработки состоялся выпуск 2.42.0 высокопроизводительного кроссплатформенного линкера mold.

Проект написан на языке C++ (стандарт C++20) и распространяется по лицензии MIT.

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

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

5 августа состоялся выпуск 2.13. 0 консольной утилиты GCLI, поддерживающей API нескольких популярных сервисов хостинга Git-проектов, и позволяет создавать, просматривать и взаимодействовать с проблемами, запросами на слияние, метками и комментариями к ним, проверять состояние CI и конвейеров, искать репозитории и многое другое.
В отличие от GitHub CLI, GCLI поддерживает не только API GitHub, но и API Codeberg, Forgejo, Gitea, GitLab и Bugzilla.

Утилита написана на языке C и распространяется по лицензии BSD-2.

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

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

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

В состав платформы включены компоненты, необходимые для разработки приложений на языке Mojo, включая компилятор, runtime, интерактивную REPL-оболочку для сборки и запуска программ, отладчик, дополнение к редактору кода Visual Studio Code (VS Code) с поддержкой автодополнения ввода, форматирования кода и подсветки синтаксиса, модуль для интеграции с Jupyter для сборки и запуска Mojo notebook. Исходный код стандартной библиотеки Mojo открыты под лицензией Apache 2.0 c исключениями от проекта LLVM, допускающими смешивание с кодом под лицензией GPLv2. Исходный код компилятора планируют открыть после завершения стабилизации внутренней архитектуры.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

31 июля состоялись выпуски 0.15.0 и 0.15.1 Mettle — языка системного программирования со статической типизацией:

• Нативная поддержка x86-64 (+ AVX2), AArch64, NVIDIA PTX, SPIR-V (OpenCL 2.0).

• Собственный линкер для Windows PE.

• Собственный отладчик на уровне исходного кода:

  • Без внешних форматов.
  • Точки останова, пошаговая отладка, а также чтение и запись переменных в реальном времени через --debug-hooks.
  • Без gdb, PDB и DWARF.

• Бэкенд CUDA.

• Без LLVM, виртуальной машины и рантайма.

• Выполнение на этапе компиляции: функции с атрибутом @test запускаются в интерпретаторе компилятора командой mettle test, без создания бинарного файла. Команда mettle trace интерпретирует одну функцию и выводит построчное отслеживание значений. Команда --pgo интерпретирует функцию main() на этапе сборки и передаёт измеренные частоты вызовов обратно в оптимизатор.

• Проверка заимствований (borrow checker):

  Описание	Пример	Аналог Rust
  Use-after-free (direct)	free(p); p[0]	ownership / Drop
  Double free	free(p); free(p)	ownership
  Use-after-free through an alias	q = p; free(q); p[0]	move semantics
  Use-after-free across a call (inferred)	consume(p); p[0] where consume frees p	move semantics
  Borrow outliving its stack scope	{ var x; g = &x[0]; } use(g)	lifetimes ('a)
  Interior pointer after realloc	q = &buf[i]; realloc(buf,..); q[0]	iterator invalidation
  Interior pointer after free	q = &buf[i]; free(buf); q[0]	dangling reference
  Returning the address of a stack local	return &local	fn() -> &T lifetime error
  Leak (no owner on any path)	var p = malloc(n); return 0	(Rust frees via Drop)

Компилятор основан на библиотеке libmtlc:

• Собственный промежуточный язык (IR).
• Классические и GNN оптимизаторы кода.
• Нативная генерация кода (x86-64 (+ AVX2), AArch64, NVIDIA PTX, SPIR-V (OpenCL 2.0)).
• Нативная компоновка.

Проекты написаны кейптаунским программистом suidvandiewereld на языке C (стандарт C99) и распространяются по лицензии Apache-2.0.

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

Зафиксирована массовая атака на пакеты в репозитории NPM, проводимая с использованием нового самораспространяющегося червя ChainDrop, подставляющего вредоносное ПО в зависимости. В результате атаки опубликовано 2212 вредоносных выпусков для 444 пакетов. Наиболее популярные из скомпрометированных пакетов keyv, flat-cache и file-entry-cache насчитывают 154, 149.9 и 147.6 миллионов загрузок в неделю.

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

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

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

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

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

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

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

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

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

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

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

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

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

После почти четырёх месяцев разработки состоялся выпуск 9.0 проекта FFmpeg, с кодовым именем «Lei».

Это набор свободных библиотек и утилит с открытым исходным кодом на языке Си, позволяющих записывать, конвертировать и передавать цифровые аудио- и видеозаписи в различных форматах. Название происходит от названия экспертной группы MPEG и FF, означающего «fast forward».

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

>>> Подробности на GitHub и в первой редакции новости (github.com)

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

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

В этом выпуске основное внимание уделено средствам визуализации: добавлены новые плагины «Спектрограмма», «Осциллограф» и «projectM/MilkDrop». Кроме того, реализована функция конвертирования аудиофайлов в распространённые аудиоформаты.

Также внесены многочисленные улучшения, в том числе опциональная автоматическая передискретизация, сохранение путей импорта/экспорта плейлистов, а также исправления, касающиеся воспроизведения, метаданных, тегирования, операций с файлами и интерфейса. Проект написан на языке C++ и фреймворке Qt6, и распространяется по лицензии GNU GPL 3.

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

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

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

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

Компания Oracle опубликовала плановый выпуск обновлений своих продуктов (Critical Patch Update), нацеленный на устранение критических проблем и уязвимостей. Отмечается, что июльское обновление стало крупнейшим в истории по числу уязвимостей — устранено 1449 проблем с безопасностью, затрагивающих 334 продукта Oracle. Всплеск числа уязвимостей объясняется разбором проблем, выявленных благодаря применению AI-инструментов.

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

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

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

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

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

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

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

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

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

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

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

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

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

12 июля состоялся выпуск 0.3 FSearch — утилиты для быстрого поиска файлов, созданной по образцу Everything для Windows.

Проект написан на языке C и GTK3, и распространяется по лицензии GNU GPL 2.0.

Возможности FSearch:

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

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

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

После года разработки опубликован релиз новой стабильной ветки языка программирования Perl — 5.44. При подготовке нового выпуска было изменено около 270 тысяч строк кода (без документации и автоматически сгенерированного кода — 110 тысяч), изменения затронули 860 файлов, в разработке принял участие 71 разработчик.

Ветка 5.44 выпущена в соответствии с утверждённым тринадцать лет назад фиксированным графиком разработки, подразумевающим выпуск новых стабильных веток раз в год и корректирующих релизов — раз в три месяца. Примерно через месяц планируется выпустить первый корректирующий релиз Perl 5.44.1, в котором будут исправлены наиболее значительные ошибки, выявленные в процессе внедрения Perl 5.44.0. Одновременно с выходом Perl 5.44 прекращена поддержка ветки 5.40, для которой обновления могут быть выпущены в будущем только в случае выявления критических проблем с безопасностью. Начался процесс разработки экспериментальной ветки 5.45, на базе которой в первой половине 2027 года будет сформирован стабильный релиз Perl 5.46, если не будет принято решение перейти к нумерации 7.x.

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

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