· | 17.02.2025 | Опубликована AI-модель синтеза речи Zonos, поддерживающая клонирование голоса (30 +3) |
Компания Zyphra опубликовала под лицензией Apache 2.0 первый бета-выпуск AI-модели для синтеза речи Zonos. Предлагаемый вместе с моделью инструментарий поддерживает функцию клонирования голоса, позволяющую синтезировать речь желаемым голосом, для воспроизведения которого модели достаточно предоставить 30-секундную эталонную запись речи говорящего. Поддерживается синтез на английском, японском, китайском, французском и немецком языках.
Модель охватывает 1.6 млрд параметров и обучена на 200 тысячах часов аудиозаписей. Поддерживается синтез монотонной (как в аудиокнигах) и эмоциональной речи (как в живом разговоре), а также синтез на основе заданного префикса (приводится аудиозапись с началом речи, на основе которой модель синтезирует продолжение по указанному тексту, воспроизводя исходные характеристики речи, например, продолжая говорить шёпотом). На выходе генерируется звук с частотой дискретизации 44kHz. Поддерживается подстановка синтезируемых вставок для симуляции выступлений с несколькими говорящими или построения интерактивных диалогов, а также добавление меток для управления скоростью речи, тональностью и выражением эмоций, таких как радость, страх, печаль и гнев. По заявлению разработчиков, по качеству генерируемой речи модель не уступает или превосходит все публично доступные открытые и коммерческие системы синтеза (в тестах приводится сравнение с ElevenLabs, Cartesia и FishSpeech). Из недостатков отмечается более высокая концентрация звуковых артефактов, таких как кашель, звук дыхания или скрипы, в начале или в конце формируемого звукового материала.
Для использования модели на своей системе подготовлен готовый к работе образ для системы Docker, в состав которого входит web-интерфейс для управления синтезом, основанный на платформе Gradio. Для начала работы достаточно установить образ командой "git clone https://github.com/Zyphra/Zonos.git; cd Zonos; docker compose up" и открыть в браузере страницу "http://localhost:7860". Для работы рекомендуется наличие GPU NVIDIA как минимум серии 3000 с 6 Гб видеопамяти. Производительность работы на системе с GPU RTX 4090 в два раза превышает возможности, необходимые для синтеза в режиме реального времени. ![]()
| ||
Обсуждение (30 +3) |
Тип: К сведению |
| ||
· | 16.02.2025 | В PostgreSQL устранена уязвимость, использованная при атаке на BeyondTrust (16 +10 ↻) |
Сформированы корректирующие обновления для всех поддерживаемых веток PostgreSQL 17.3, 16.7, 15.11, 14.16 и 13.19, в которых исправлено более 70 ошибок и устранена уязвимость (CVE-2025-1094), в конце декабря задействованная в атаке на компанию BeyondTrust и Министерство финансов США. Проблема в PostgreSQL выявлена при анализе удалённой уязвимости (CVE-2024-12356) в сервисах BeyondTrust PRA (Privileged Remote Access) и BeyondTrust RS (Remote Support), при эксплуатации которой дополнительно была задействована ранее неизвестная (0-day) уязвимость в libpq.
В результате атаки злоумышленникам удалось получить ключ для доступа к API, применяемому для удалённого оказания услуг технической поддержки клиентам SaaS-сервисов BeyondTrust. Данный API был использован для сброса пароля и компрометации инфраструктуры Министерства финансов США, пользующегося продуктами BeyondTrust. В ходе атаки злоумышленники смогли загрузить конфиденциальные документы и получили доступ к рабочим станциям сотрудников министерства. Уязвимость проявляется в библиотеке libpq, предоставляющей API для взаимодействия с СУБД из программ на языке Си (поверх библиотеки также реализованы библиотеки-обвязки для C++, Perl, PHP и Python). Проблема затрагивает приложения, использующие для экранирования спецсимволов и нейтрализации кавычек функции PQescapeLiteral(), PQescapeIdentifier(), PQescapeString() или PQescapeStringConn(). Атакующий может добиться подстановки своего SQL-кода, если получаемый извне текст перед использованием внутри SQL-запроса экранируется при помощи вышеотмеченных функций libpq. В приложениях BeyondTrust экранированные подобным образом запросы передавались через утилиту командной строки psql. Уязвимость вызвана отсутствием проверки корректности Unicode-символов в функциях экранирования, что позволяет обойти нормализацию кавычек через указание некорректных многобайтовых последовательностей UTF-8. Для эксплуатации уязвимость можно использовать некорректный UTF-8 символ, состоящий из байт 0xC0 и 0x27 ("└'"). Байт 0x27 в ASCII-кодировке соответствует одинарной кавычке ("'"), подлежащей экранированию. В коде экранирования сочетание байтов 0xC0 и 0x27 обрабатывается как один Unicode-символ. Соответственно, байт 0x27 в такой последовательности остаётся не экранирован, при том, что при обработке SQL-запроса в утилите psql он обрабатывается как кавычка. При запуске SQL-запросов при помощи утилиты psql для организации выполнения произвольного кода можно использовать подстановку в строку команды "\!", предназначенной в psql для запуска произвольных программ. Например, для запуска на сервере утилиты "id" можно передать значение "hax\xC0'; \! id #". В примере ниже для экранирования вызывается PHP-скрипт dbquote, использующий PHP-функцию pg_escape_string, работающую поверх функции PQescapeString из libpq: $ echo -e "hello \xC0'world'" | ./dbquote 'hello └'world''' $ quoted=$(echo -e "hax\xC0'; \! id # " | ./dbquote) $ echo "SELECT COUNT(1) FROM gw_sessions WHERE session_key = $quoted AND session_type = 'sdcust' AND (expiration IS NULL OR expiration>NOW())" | psql -e SELECT COUNT(1) FROM gw_sessions WHERE session_key = 'hax└'; ERROR: invalid byte sequence for encoding "UTF8": 0xc0 0x27 uid=1000(myexamplecompany) gid=1000(myexamplecompany) Дополнение: Внесённое в libpq исправление привело к появлению регрессии (функция PQescapeIdentifier перестала учитывать поле с размером). Для устранения регрессии 20 февраля планируют опубликовать внеплановое обновление.
| ||
Обсуждение (16 +10 ↻) |
Тип: Проблемы безопасности |
| ||
· | 15.02.2025 | Мэйнтейнер драйвера Nouveau сложил полномочия из-за проблем с инклюзивностью в сообществе (308 +32) |
Следом за Гектором Мартином о снятии с себя обязанностей мэйнтейнера и прекращении участия в рецензировании патчей объявил Карол Хербст (Karol Herbst), сопровождавший драйвер Nouveau и механизм трассировки MMIO (MMIOTRACE), работающий в компании Red Hat. После ухода в ядре останутся ещё два мэйнтейнера, поддерживающие драйвер Nouveau, которые, по мнению Карола, прекрасно справляются со своей работой.
В качестве причины ухода упоминается отсутствие атмосферы инклюзивности в среде разработчиков ядра. Карол убеждён, что в сообществе, занимающемся разработкой открытого ПО, работа должна вестись с уважением, на равных и без заигрывания властью. По словам Карола последней каплей стало сообщение Теодора Тс'о, в котором он сравнил мэйнтейнеров с "тонкой синей линией" (отождествляется с правоохранительными органами и символизирует грань между порядком и анархией), добивающейся, чтобы принимаемый в ядро код был поддерживаемым и качественным. По мнению Карола, говорящий такие слова не может занимать пост сопровождающего, независимо от того насколько он важен для проекта, и его следует исключить до того, как он осознает, что эти слова значат для многих маргинализированных людей и какие ужасы они вызывают в их умах. Карол уходит, так как не может оставаться в сообществе, в котором могут терпеть такие слова. Теодор Тс'о привёл сравнение с тонкой синей линией в процессе обсуждения сопротивления старых разработчиков продвижению Rust в ядро. Он написал, что власть мэйнтейнеров ограничена и они не могут влиять на продолжение разработки уже принятых изменений, так как не имеют возможности приказать людям заниматься доработками и улучшением инфраструктуры тестирования. Единственным инструментом обеспечения качества является способность мэйнтейнеров помешать включению в ядро сырых и вызывающих сомнение изменений. Как только код принят, мэйнтейнеры теряют рычаги воздействия на разработчиков и становятся лично ответственными за этот код. Принимая значительное изменение, мэйнтейнеры должны быть уверены, что изменение полностью работоспособно, а его разработчики способны поддерживать код после приёма в ядро и не оставят этот код без присмотра. Теодор приводит в качестве примера команды, заинтересованные только в продвижении своего детища, которые, как только код принят, исчезают и больше не появляются, а мэйнтейнерам приходится расхлёбывать все допущенные недоработки. От некоторых поступают обвинения в двойных стандартах, из-за того, что код одних разработчиков принимается почти сразу, а код других долго перемалывается. В этом вопросе важно установившееся доверие и заслуженная репутация. Если разработчик уже показал свою способность отвечать за переданные изменения - согласования проходят быстро. Для новичков приём изменений может затянутся, так как сопровождающий должен понять, сможет ли участник отвечать за свой код. Поэтому, участникам, особенно пытающимся продвигать радикальные изменения, требуется потратить много времени, чтобы стать частью сообщества. Например, на интеграцию изменений для сборки ядра компилятором Clang потребовалось 10 лет.
| ||
Обсуждение (308 +32) |
Тип: Тема для размышления |
| ||
· | 14.02.2025 | Уязвимость в Musl, эксплуатируемая при перекодировании текста в кодировке EUC-KR (109 +9) |
В стандартной Си-библиотеке Musl выявлена уязвимость (CVE-2024-2961), приводящая к переполнению буфера при преобразовании специально оформленного текста из кодировки EUC-KR в UTF-8 при помощи функции iconv(). Уязвимость проявляется начиная с версии musl 0.9.13 и будет исправлена в готовящемся к публикации выпуске 1.2.6 (до публикации обновления следует использовать патч). Уязвимость выявлена сопровождающим библиотеку libxml2 в процессе fuzzing-тестирования.
Уязвимость может использоваться для совершения атак на приложения, собранные с библиотекой Musl и выполняющие перекодирование текста, получаемого из внешних источников. Эксплуатация уязвимости возможна при вызове в приложении функции iconv_open() c указанием исходной кодировки EUC-KR и целевой кодировки UTF-8. В качестве примера потенциально уязвимых приложений упоминаются программы, перекодирующие XML, HTML и почтовые сообщения на основании кодировки, указанной в заголовке с MIME-типом (например, "text/plain; charset=EUC-KR"). Например, подобное перекодирования выполняют программы, использующие библиотеку libxml2. Уязвимость вызвана комбинацией из двух ошибок. Первая ошибка связана с отсутствием должной проверки некорректных многобайтовых последовательностей в декодировщике EUC-KR. Вторая ошибка присутствует в кодировщике UTF-8, который не был рассчитан на то, что декодировщик входных данных может вернуть недопустимые скалярные значения Unicodе. В итоге, обработка последовательностей вида "\xc8\x41" приводит к записи значений в область за границей выделенного буфера.
| ||
Обсуждение (109 +9) |
| ||
· | 14.02.2025 | Проекту Fedora пригрозили иском из-за поставки сбойного flatpak-пакета с OBS Studio (315 +59) |
Разработчики системы потокового видеовещания OBS Studio предъявили проекту Fedora претензию, связанную с поставкой некорректно работающего неофициального flatpak-пакета в форме, создающей у пользователей впечатление, что они используют официальный пакет. Проблема в том, что разработчики OBS Studio распространяют через каталог Flathub собственный flatpak-пакет, но вместо него пользователям Fedora предоставляется другой вариант flatpak-пакета, сопровождаемый разработчиками Fedora и при установке являющийся более приоритетным.
Из-за этого пользователи Fedora направляют разработчикам OBS Studio претензии, считая, что проблемы присутствуют в официальном flatpak-пакете. Разработчики OBS Studio попросили пометить предлагаемый в Fedora пакет как неофициальный или удалить его в пользу доступного на Flathub официального пакета. Уведомление о проблеме было направлено три недели назад через системы отслеживания ошибок репозитория fedora-flatpaks, GNOME Software и fedora-workstation. Так как конструктивного обсуждения вопроса добиться не удалось и дискуссия скатилась к личным нападкам, разработчики OBS Studio официально потребовали прекратить использование в дистрибутиве Fedora любых элементов бренда OBS Studio, включая имя и логотип. Для исполнения требования предоставлена одна неделя (до 21 февраля). В случае игнорирования требования разработчики OBS Studio намерены привлечь юристов для подачи судебного иска. В ответ мэйнтейнер пакета заполнил заявку на удаление flatpak-пакета obs-studio из репозиториев Fedora. Проблемы во flatpak-пакете от проекта Fedora возникали из-за поставки версии Qt, в которой присутствуют неисправленные регрессивные изменения. В официальном flatpak-пакете от OBS Studio в обход flatpak-runtime поставляется старая версия Qt, в которой данные регрессии не проявляются. Так как срок сопровождения лишённой регрессий старой версии Qt истёк, в Fedora собирался свой вариант flatpak-пакета с актуальным выпуском Qt.
| ||
Обсуждение (315 +59) |
Тип: К сведению |
| ||
· | 13.02.2025 | Лидер Asahi Linux покинул проект после проблем с продвижением Rust в ядро Linux (343 +58) |
Гектор Мартин (Hector Martin), основатель проекта Asahi Linux, занимающегося портированием Linux для работы на компьютерах Mac с ARM-чипами Apple Silicon, объявил о снятии с себя полномочий лидера и прекращению разработки. Участники Asahi Linux сформировали управляющий совет, в который вошли 7 разработчиков. Совет будет коллегиально принимать решения и совместно координировать работу проекта.
В качестве причины ухода Гектор называет выгорание и потерю интереса к дальнейшей разработке в условиях недооценки выполняемой работы и проблем с продвижением наработок проекта в основной состав ядра. В своём сообщении Гектор упоминает излишне потребительское отношение пользователей, способных лишь требовать и возмущаться отсутствуем желаемой функциональности, при том, что развитием проекта занимаются энтузиасты, а пожертвования на разработку со временем постоянно уменьшаются. Переломным моментом, после которого исчезла мотивация продолжать работу, стало сопротивление продвижению в ядро Linux наработок "Rust for Linux" и создание враждебной атмосферы для участников данного проекта. Для Asahi Linux включение поддержки языка Rust в ядро Linux является важным, так как данный язык использован для разработки трёх драйверов (по словам Гектора, успех в разработке драйвера drm-asahi обусловлен выбором для него языка Rust). На поддержание ветки ядра с собственными изменениями тратится много ресурсов и по мере увеличения не принятого в основной состав ядра кода сопровождение всё больше усложняется. Гектор считает, что следовало форсировать продвижение Rust в состав ядра и оказать его участникам активную поддержку, но Линус Торвальдс занял позицию бездействующего наблюдателя, не вмешивающегося в злоупотребления некоторых мэйнтейнеров, тормозящих интеграцию компонентов для поддержки Rust. Также отмечается, что веру в сообщество разработчиков ядра подорвало лицемерие некоторых участников, которые при личном общении поддерживали Гектора, а за его спиной высказывали недовольство. Кроме того упоминается общий упадок сообщества разработчиков ядра, в котором не осталось былых энтузиастов, а всем заправляют работники корпораций. На прошлой неделе Гектор ушёл с поста мэйнтейнера платформы ARM/Apple в ядре Linux после замечания Линуса Торвальдса о его излишней самоуверенности в желании реформировать процесс разработки ядра и привлечении социальных сетей для раздувания внутренних разбирательств. Судя по всему, Гектор излишне эмоционально реагирует на возникающие трудности и принимает близко к сердцу то, что ему кажется несправедливостью, и при этом не готов учитывать интересы других людей, находить компромиссные решения, вникать в мотивы чужих поступков и допускать, что его мнение может не быть единственным правильным.
| ||
Обсуждение (343 +58) |
Тип: Тема для размышления |
| ||
· | 13.02.2025 | Релиз СУБД DuckDB 1.2.0 (44 +10) |
Опубликован выпуск СУБД DuckDB 1.2.0, ориентированной на выполнение аналитических запросов и концептуально напоминающей SQLite. DuckDB сочетает такие свойства SQLite, как компактность, подключение в форме встраиваемой библиотеки, хранение БД в одном файле и CLI-интерфейс, с возможностями и оптимизациями для выполнения аналитических запросов, охватывающих значительную часть хранимых данных, например, выполняющих агрегирование всего содержимого таблиц или слияние нескольких больших таблиц. Код проекта написан на языке C++ и распространяется под лицензией MIT.
DuckDB предоставляет расширенный диалект языка SQL, включающий дополнительные возможности для обработки очень сложных и длительно выполняемых запросов. Возможно использование сложных типов (массивы, структуры, объединения), а также выполнение произвольных и вложенных коррелирующих подзапросов. Поддерживается одновременное выполнение нескольких запросов, выполнение запросов напрямую из файлов в форматах CSV и Parquet. Доступна поддержка импорта из СУБД PostgreSQL. Проектом используется оболочка из SQLite, парсер из PostgreSQL, компонент Date Math из MonetDB, своя реализация оконных функций (на базе алгоритма Segment Tree Aggregation), обработчик регулярных выражений на основе библиотеки RE2, собственные оптимизатор запросов, MVCC-механизм управления одновременным выполнением заданий (Multi-Version Concurrency Control), а также векторизованный движок выполнения запросов на базе алгоритма Hyper-Pipelining Query Execution, позволяющий в одной операции разом обрабатывать большие наборы значений. В новой версии:
| ||
Обсуждение (44 +10) |
Тип: Программы |
| ||
· | 12.02.2025 | Для systemd развивается возможность загрузки системных образов по HTTP (204 –6) |
Леннарт Поттеринг (Lennart Poettering) предложил включить в системный менеджер systemd изменение, позволяющие загружать систему с использованием образа корневой ФС, получаемого c внешнего хоста по протоколу HTTP. Изменение сводится к расширению systemd возможностью не только скачивать дисковый образ по HTTP на начальной стадии загрузки, но и распаковывать загруженный образ, связывать с блочным устройством в loopback-режиме, монтировать блочное устройство как /sysroot и загружать с него систему.
Поддержка скачивания дисковых образов во время загрузки системы при помощи systemd-import-generator уже включена в состав systemd 257. Остальная функциональности пока находится на стадии рабочего прототипа, требующего доработки. В реализации пока не поддерживается полный цикл загрузки, но в дальнейшем функциональность планируют довести до загрузки через UEFI HTTP Boot универсальных образов ядра UKI (Unified Kernel Image), объединяющих в одном файле загрузчик для UEFI (UEFI boot stub), образ ядра Linux и загружаемое в память системное окружение initrd. URL для загрузки системного образа планируют вычислять на основании URL, заданного для EFI-образа в настройках UEFI HTTP Boot (например, при загрузке через EFI HTTP Boot "http://example.com/somedir/myimage.efi", присутствующий в UKI initrd-обработчик загрузит образ rootfs как "http://example.com/somedir/myimage.raw.xz"). В дальнейшем помимо HTTP в качестве транспорта для получения образа планируется добавить поддержку технологии NVMe-over-TCP, позволяющей обращаться к NVMe-накопителям по сети (NVM Express over Fabrics), используя протокол TCP. Предполагается, что загрузка с образов, получаемых с внешнего хоста, упростит организацию тестирования современных неизменяемых ("immutable") операционных систем на реальном оборудовании. Разработчик может на своём компьютере сформировать образ с системным окружением утилитой mkosi и сделать его доступным через HTTP командой "mkosi -f serve". На компьютере, на котором требуется протестировать работу системы, достаточно включить в EFI загрузку по HTTP и добавить URL загружаемого образа командой: kernel-bootcfg --add-uri=http://192.168.47.11:8081/image.efi --title=testloop --boot-order=0 После чего можно просто перезагрузить компьютер, и он загрузит типовой образ ядра UKI, который затем загрузит подготовленный разработчиком дисковый образ с корневой ФС. До отключения в EFI загрузки по HTTP каждая последующая перезагрузка компьютера будет приводить к загрузке свежего системного образа. При подобном тестировании никак не затрагиваются локальные диски.
| ||
Обсуждение (204 –6) |
Тип: К сведению |
| ||
· | 12.02.2025 | Выпуск языка программирования Go 1.24 (262 +18) |
После шести месяцев разработки представлен релиз языка программирования Go 1.24, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно, без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си. Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах. Например, на уровне операторов реализованы средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за границы буфера и обеспечивает возможность использования сборщика мусора. Среди изменений в новом выпуске:
| ||
Обсуждение (262 +18) |
Тип: Программы |
| ||
· | 11.02.2025 | Опубликован свободный звуковой кодек FLAC 1.5 (240 +41) |
Сообщество Xiph.Org опубликовало обновление свободного звукового кодека FLAC 1.5.0, позволяющего сжимать звук без потери качества. FLAC использует только методы кодирования без отбрасывания данных (lossless), что гарантирует полную сохранность изначального качества звукового потока и его идентичность с эталонным вариантом, подвергнутым кодированию. При этом используемые методы сжатия без потерь позволяют уменьшить размер исходного звукового потока на 50-60%. FLAC является полностью свободным потоковым форматом, подразумевающим не только открытость библиотек с реализацией функций кодирования и декодирования, но и отсутствие ограничений по использованию спецификаций и созданию производных вариантов. Код библиотек распространяется под лицензией BSD.
Среди изменений в новой версии:
| ||
Обсуждение (240 +41) |
Тип: К сведению |
| ||
· | 11.02.2025 | Релиз среды рабочего стола KDE Plasma 6.3 (186 +46) |
После четырёх месяцев разработки опубликован релиз среды рабочего стола KDE Plasma 6.3. Для оценки работы новых выпусков KDE можно воспользоваться сборками от проектов KDE Neon и openSUSE (Argon, основанный на openSUSE Leap, и Krypton, основанный на openSUSE Tumbleweed).
![]() Основные изменения:
| ||
Обсуждение (186 +46) |
Тип: Программы |
| ||
· | 10.02.2025 | Опубликована распределённая СУБД Citus 13.0 (60 +9) |
Компания Citus Data, принадлежащая Microsoft, опубликовала распределённую СУБД Citus 13.0, реализованную в форме расширения к PostgreSQL 17. Citus обеспечивает горизонтальное масштабирование PostgreSQL в кластере на базе типового оборудования и позволяет разносить данные по узлам при помощи шардинга (sharding) с настройкой разделения на уровне столбцов и схемы хранения. Для приложений кластер Citus выглядит как один большой сервер PostgreSQL, объединяющий ресурсы образующих его узлов. Код написан на языке Си и распространяется под лицензией AGPLv3.
Шардинг позволяет организовать хранение очень большого объёма данных, суммарный размер которых существенно превышает локальные накопители каждого из узлов кластера. Отдельные таблицы могут принудительно реплицироваться на все узлы для ускорения выполнения операций слияния и работы с внешними ключами. Для экономии дискового пространства распределённые по разным узлам данные могут хранится в сжатом виде. Распределённые запросы могут отправляться на любой из узлов кластера, но управление и изменение схемы данных должно производиться только через узел, координирующий работу кластера. Поступающие от клиентов запросы распределяются по необходимым узлам и, если они охватывают несколько узлов, то их обработка распараллеливается. Кластер можно расширять по мере роста размера хранимых данных, добавляя дополнительные узлы и инициируя ребалансировку. В качестве типовых примеров использования Citus отмечается выполнение аналитических запросов и обработка больших массивов данных в форме временного ряда (например, логи или опрос состояния датчиков). Citus также подходит для модернизации имеющейся инфраструктуры на базе одиночного сервера PostgreSQL, производительности и накопителей на котором перестало хватать из-за увеличения нагрузки или объёма поступающих данных. При помощи инструментария Patroni можно создавать отказоустойчивые конфигурации с реплицированными запасными узлами, способными в случае сбоя занять место основных узлов. Изменения в выпуске Citus 13.0:
| ||
Обсуждение (60 +9) |
Тип: Программы |
| ||
· | 09.02.2025 | Первый выпуск платформы виртуализации SEAPATH (82 +18) |
После пяти лет разработки организация Linux Foundation представила релиз платформы виртуализации SEAPATH 1.0, разработанной с учётом требований к информационным системам для цифровых подстанций в энергосетях. Платформа учитывает специфику энергосетей, но может применяться и в других областях, в которых требуется высокая надёжность. Код платформы опубликован под лицензией Apache 2.0. Выпуск SEAPATH 1.0 признан готовым для промышленного применения и использования в критически важных системах (mission-critical). Платформа уже задействована в рабочей инфраструктуре энергетической компании RTE и проходит тестовое внедрение в компаниях GE Vernova, Alliander, ABB, Red Hat и Enedis. В разработке платформы принимают участие компании RTE, Alliander, GE Vernova, Savoir-faire Linux, Welotec и Red Hat.
Для мониторинга, автоматизации, сопровождения и управления распределением энергопотоков на цифровых подстанциях в современных энергосетях задействованы специализированные приложения от различных поставщиков, которые предлагается запускать в отдельных изолированных виртуальных машинах. SEAPATH реализует платформу для организации работы подобных виртуальных машин, виртуализированные приложения (vPAC - Virtualized Protection, Automation and Control) в которых могут выполняться в режиме реального времени. ![]() Для развёртывания узлов с хост-окружением SEAPATH предоставляется два дистрибутива на базе Debian GNU/Linux 12 и Yocto Scarthgap. Платформа не привязана к какому-то определённому оборудованию, не зависит от отдельных поставщиков и может использоваться на различных типах серверов и аппаратных архитектур. Допускается выполнение приложений для электроподстанций, поддерживающих стандарт МЭК-61850. Отказоустойчивость обеспечивается благодаря применению кластерных конфигураций с резервированием оборудования, а также размещению данных и образов виртуальных машин в распределённом хранилище, реплицированном на разные узлы кластера. Обновления автоматически устанавливаются с внешнего сервера. Управление конфигурацией и администрирование осуществляется централизованно с использованием концепции инфраструктура как код. Платформа построена с использованием уже существующих открытых проектов, для проверки надёжности которых подготовлен тестовый набор, включающий более 700 unit-тестов. Виртуализация реализована с использованием гипервизора KVM и ядра Linux, собранного с опцией PREEMPT_RT для работы в режиме реального времени. В качестве распределённого хранилища, охватывающего весь кластер, используется Ceph. Для виртуализации устройств применяется QEMU, а для виртуализации сети - Open vSwitch. Для управления виртуальными окружениями задействован инструментарий Libvirt. Для управления ресурсами в кластере, обеспечения отказоустойчивости и организации взаимодействия между узлами применяются Pacemaker и Corosync. Централизованное управление инфраструктурой и оркестровка виртуальных машин реализована при помощи Ansible. ![]()
| ||
Обсуждение (82 +18) |
Тип: Программы |
| ||
· | 08.02.2025 | Проект TuxTape для развёртывания инфраструктуры live-патчей к ядру Linux (64 +13) |
Страховая компания GEICO опубликовала предварительный выпуск инструментария TuxTape, позволяющего развернуть собственную инфраструктуру для создания, сборки и доставки live-патчей для ядра Linux. Live-патчи позволяет применять исправления к ядру Linux на лету, без перезагрузки и остановки системы. Код проекта написан на языке Rust и распространяется под лицензией Apache 2.0.
Live-патчи с устранением уязвимостей предоставляют для своих дистрибутивов такие компании, как Red Hat, Oracle, Canonical и SUSE, но открытым у них является лишь низкоуровневый инструментарий для работы с патчами, а сами патчи формируются за закрытыми дверями. Дистрибутивы Gentoo и Debian пытались развивать открытые проекты elivepatch и linux-livepatching, но первый уже 6 лет находится в заброшенном состоянии, а второй затормозил на стадии создания тестового прототипа. TuxTape нацелен на организацию работы собственной системы для создания и доставки live-патчей, не зависящей от сторонних поставщиков и адаптируемой для любых ядер Linux, а не только для пакетов с ядром конкретных дистрибутивов. TuxTape может формировать live-патчи, совместимые с инструментарием kpatch, разработанным компанией Red Hat (помимо kpatch существуют похожие инструменты: kGraft от SUSE, Ksplice от Oracle и универсальный livepatch). Патчи формируются в виде загружаемых модулей ядра, которые заменяют функции в ядре, используя подсистему ftrace для перенаправления на новые функции, включённые в модуль.
![]() TuxTape может отслеживать информацию об исправлении уязвимостей в ядре Linux, публикуемую в списке рассылки linux-cve-announce и в Git-репозитории, ранжировать уязвимости по степени опасности, определять применимость к обслуживаемым ядрам Linux и генерировать live-патчи на основе обычных патчей к LTS-веткам ядра. Применимость исходных патчей оценивается через профилирование сборок ядра. Патчи с не затрагивающими целевое ядро уязвимостями игнорируются. TuxTape включает в себя систему для отслеживания новых уязвимостей в ядре, построитель БД патчей и уязвимостей, сервер для хранения метаданных, систему диспетчеризации сборки ядра, сборщик ядра, генератор патчей, архив патчей, клиент для получения патчей для конечных хостов и интерактивный интерфейс для управления формированием live-патчей.
![]() Разработка находится на стадии экспериментального прототипа. Для начального тестирована предложены: tuxtape-cve-parser для разбора информации об уязвимостях и построения БД с патчами; tuxtape-server c реализацией интерфейса gRPC для сервисов генерирующих патчи; tuxtape-kernel-builder для сборки ядра в заданной конфигурации и формирования профиля сборки; tuxtape-dashboard - консольный интерфейс для рецензирования и создания live-патчей на основе исходных патчей, полученных из tuxtape-server. ![]()
| ||
Обсуждение (64 +13) |
Тип: Программы |
| ||
· | 08.02.2025 | Выпуск компилятора ISPC 1.26, развиваемого Intel для языка Си с расширениями SPMD (32 +10) |
Компания Intel опубликовала компилятор ISPC 1.26 (Implicit SPMD Program Compiler), предназначенный для сборки кода на языке Си с расширениями параллельного программирования SPMD (Single Program, Multiple Data), позволяющими добиться параллельного выполнения нескольких экземпляров одной программы с разными наборами входных данных. Код проекта написан на языке С++ и распространяется под лицензией BSD. Поддерживается работа в Linux, Windows, macOS и FreeBSD.
Си-программы с расширениями SPMD компилируются для выполнения на вычислительных блоках SIMD, предоставляемых CPU и GPU, что позволяет задействовать механизмы векторизации SIMD без низкоуровневых оптимизаций и явного применения в коде SIMD-инструкций. Для написания распараллеливаемых функций используется привычный синтаксис и идиомы языка Си - SPMD-функции напрямую взаимодействуют с функциями и структурами, написанными на C/C++. Для отладки программ могут применяться существующие отладчики. В качестве бэкенда для генерации кода и оптимизации в ISPC используется инфраструктура LLVM. Поддерживаются векторные инструкции x86 (SSE2, SSE4, AVX, AVX2, AVX512) и ARM (NEON), а также вынос вычислений на сторону GPU (Intel Gen9 и Xe). На архитектурах с векторными блоками SSE, обрабатывающими по 4 элемента за раз, применение ISPC даёт возможность добиться ускорения выполнения программы в 3 или более раз, а на архитектурах с векторными блоками AVX, обрабатывающими по 8 элементов за раз, ускорение может достигать 5-6 раз. При этом помимо размера векторного блока, масштабирование также обеспечивается за счёт выполнения на разных процессорных ядрах. Основные новшества, добавленные в версии ISPC 1.26:
| ||
Обсуждение (32 +10) |
Тип: Программы |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |