· | 15.02 | Дистрибутив Serpent OS переименован в AerynOS (9 –1) |
Разработчики дистрибутива Serpent OS объявили о переименовании проекта в AerynOS и проведении ребрендинга. Завершить миграцию инфраструктуры на новое имя планируют 17 марта. Отмечается, что при основании проекта имя Serpent OS было выбрано поспешно, без учёта того, что слово "serpent" воспринимается некоторыми людьми в негативной коннотации (змей-искуситель, мстительный человек). Разработчикам поступает много жалоб о неудачном выборе имени, поэтому решено воспользоваться моментом, пока проект не вышел из стадии альфа-тестирования, и поменять имя.
Проект Serpent OS преподносится как следующий этап в эволюции дистрибутивов Linux. Разработка ведётся старой командой разработчиков дистрибутива Solus, в число которых входят Айки Доэрти (Ikey Doherty) - создатель Solus и Джошуа Стробл (Joshua Strobl) - ключевой разработчик среды рабочего стола Budgie. Дистрибутив использует собственный пакетный менеджер moss с собственным форматом пакетов Stone и инструментами для управления состоянием системы. Для экономии дискового пространства при хранении нескольких версий пакетов применяется дедупликация на основе жёстких ссылок. Обновление производится в атомарном режиме с заменой содержимого раздела /usr. В случае сбоя во время установки обновления система откатывается на прошлое рабочее состояние. За исключением ядра и некоторых системных компонентов изменения применяются на лету, без необходимости перезагрузки. Большая часть пакетов, включая ядро Linux, собрана при помощи компилятора Clang. Проектом также развиваются инсталлятор Lichen, система сборки boulder, панель управления summit, менеджер загрузки blsforme и система контейнеров moss-container.
| ||
Обсуждение (9 –1) |
Тип: К сведению |
| ||
· | 14.02 | Выпуск дистрибутива Chimera 20250214, сочетающего ядро Linux с окружением FreeBSD (31 –3) |
Опубликовано обновление сборок дистрибутива Chimera Linux, примечателеного использованием ядра Linux в сочетании с утилитами из FreeBSD, системным менеджером dinit и стандартной Си-библиотекой Musl. Сборка осуществляется компилятором Clang. Загрузочные Live-образы сформированы для архитектур x86_64, ppc64le, aarch64, riscv64 и ppc64 в вариантах с GNOME (1.5 ГБ), KDE (2.1 ГБ) и урезанным окружением (806 Мб).
Проект нацелен на создание Linux-дистрибутива с альтернативным инструментарием и развивается с учётом опыта разработки Void Linux (автор Chimera является бывшим мэйнтейнером Void, отвечавшим за архитектуры POWER и PowerPC). Как и Void Linux, проект развивается с использованием непрерывного цикла обновления версий программ (rolling-модель). Пользовательские компоненты FreeBSD выбраны как менее усложнённые и более подходящие для легковесных и компактных систем, чем штатный инструментарий GNU. Помимо утилит из FreeBSD, поставляемых вместо таких пакетов, как coreutils, findutils, diffutils, sed и grep, в дистрибутиве задействованы GNU Make, util-linux, syslog-ng, udev, pam, dinit, clang, lld, libc++ и musl. Функции выделения памяти в musl заменены на mimalloc. В качестве файловой системы применяется ZFS. Раздел /var не сохраняет своё состояние между перезапусками (stateless). Для управления мультимедийными потоками применяется PipeWire. В графических окружениях по умолчанию используется Wayland. Для установки дополнительных программ предлагаются как бинарные пакеты, так собственная система сборки из исходных текстов - cports, написанная на Python. В настоящее время сопровождается более 4000 портов. Сборочное окружение запускается в отдельном непривилегированном контейнере, создаваемом при помощи инструментария bubblewrap. Для управления бинарными пакетами задействован пакетный менеджер APK (Alpine Package Keeper, apk-tools), а в качестве опции может использоваться Flatpak. В новом выпуске:
![]()
| ||
Обсуждение (31 –3) |
Тип: Программы |
| ||
· | 14.02 | Уязвимость в Musl, эксплуатируемая при перекодировании текста в кодировке EUC-KR (97 +6) |
В стандартной Си-библиотеке 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" приводит к записи значений в область за границей выделенного буфера.
| ||
Обсуждение (97 +6) |
| ||
· | 14.02 | Проекту Fedora пригрозили иском из-за поставки сбойного flatpak-пакета с OBS Studio (266 +47) |
Разработчики системы потокового видеовещания 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.
| ||
Обсуждение (266 +47) |
Тип: К сведению |
| ||
· | 13.02 | Лидер Asahi Linux покинул проект после проблем с продвижением Rust в ядро Linux (308 +54) |
Гектор Мартин (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 после замечания Линуса Торвальдса о его излишней самоуверенности в желании реформировать процесс разработки ядра и привлечении социальных сетей для раздувания внутренних разбирательств. Судя по всему, Гектор излишне эмоционально реагирует на возникающие трудности и принимает близко к сердцу то, что ему кажется несправедливостью, и при этом не готов учитывать интересы других людей, находить компромиссные решения, вникать в мотивы чужих поступков и допускать, что его мнение может не быть единственным правильным.
| ||
Обсуждение (308 +54) |
Тип: Тема для размышления |
| ||
· | 13.02 | Обсуждение увеличения частоты таймера в ядре Linux до 1000 Гц по умолчанию (139 +22) |
Инженер из компании Google предложил повысить частоту генерации прерываний от таймера в ядре Linux до 1000 Гц по умолчанию, что приведёт к увеличению частоты переключения задач и уменьшению кванта времени в планировщике задач. В данный момент по умолчанию используется 250 Гц, как некий компромисс между производительностью, задержками и энергопотреблением.
При использовании дисплеев с частотой обновления 120 Гц, типичных для современных ПК и мобильных устройств, при частоте таймера 250 Гц неточность квантования времени составляет примерно половину времени кадра, что снижает эффективность распределения ресурсов и не позволяет добиться оптимального соотношения производительности к потреблению энергии. Энергопотребление систем при низкой частоте таймера может оказаться выше, поскольку механизм DVFS (Dynamic Voltage and Frequency Scaling) использует более агрессивную стратегию выбора частоты, чтобы не замедлять выполнение задач. Возникают ситуации, когда задача уже отработала желаемые операции, требовавшие активных вычислений, но процессор продолжает работу на повышенной частоте из-за конечности кванта времени, который ещё не закончился. Повышение частоты переключения задач может привести к снижению потребления энергии из-за повышения эффективности динамического управления частотой (DVFS), более точного распределения интервалов планировщиком задач, более частого обновления статистики загрузки CPU и уменьшения времени нахождения задач в состоянии ожидания. Другой инженер из Google предложил оставить частоту таймера как есть (250 Гц), так как повышение частоты генерации прерываний таймера может привести к повышению энергопотребления на маломощных устройствах, таких как платы для интернета вещей. По его оценке при выставлении частоты в 1000 Гц даже на устройствах под управлением Android в некоторых ситуациях зафиксировано повышение потребления энергии процессором на 7%. При увеличении частоты таймера также наблюдается более частое пробуждение CPU, так как при частоте 250 Гц таймеры, установленные на интервалы t + 1 мс, t + 2 мс, t + 3 мс и t + 4 мс, будут сгруппированы и приведут к одному пробуждению, а в случае 1000 Гц произойдёт четыре отдельных пробуждения. Ресурс Phoronix провёл сравнение производительности ПК на базе CPU AMD Ryzen 9 9950X. Конфигурация с 1000 Гц оказалась быстрее в тестах Llama.cpp, nginx, SuperTuxKart, Selenium и при измерении времени сборки ядра. В тестах Darktable, PostgreSQL, Unvanquished, Xonotic, Blender, SVT-AV1, RawTherapee производительность была выше при установке 250 Гц. При 1000 Гц среднее потребление энергии составило 144.2 Вт, минимальное - 0.18 Вт, максимальное - 202.13 Вт, а при 250 Гц: среднее 144.37 Вт, минимальное 0.07 Вт, максимальное - 202 Вт.
![]()
| ||
· | 13.02 | Обновление дистрибутива для одноплатных ПК DietPi 9.10 (46 +5) |
Сформирован выпуск DietPi 9.10, дистрибутива для одноплатных ПК на базе архитектур ARM и RISC-V, таких как Raspberry Pi, Orange Pi, NanoPi, BananaPi, BeagleBone Black, Rock64, Rock Pi, Quartz64, Pine64, Asus Tinker, Odroid и VisionFive 2. Дистрибутив построен на пакетной базе Debian и доступен в сборках для более, чем 50 плат. DietPi также может применяться для создания компактных окружений для виртуальных машин и обычных ПК на базе архитектуры x86_64. Сборки для плат отличаются небольшим размером (в среднем 130 МБ) по сравнению с Raspberry Pi OS и Armbian. Инструментарий для сборки и сопровождения дистрибутива распространяется под лицензией GPLv2.
Проект оптимизирован для минимального потребления ресурсов и развивает несколько собственных утилит: интерфейс для установки приложений DietPi-Software, конфигуратор DietPi-Config, система резервного копирования DietPi-Backup, механизм ведения временных логов DietPi-Ramlog (также поддерживается rsyslog), интерфейс для установки приоритетов выполнения процессов DietPi-Services и система доставки обновлений DietPi-Update. Утилиты предоставляют консольный интерфейс пользователя с меню и диалогами на базе whiptail. Поддерживается режим полной автоматизации установки, позволяющий провести инсталляцию на платы без участия пользователя. Среди изменений:
| ||
Обсуждение (46 +5) |
Тип: Программы |
| ||
· | 13.02 | Дистрибутив openSUSE Tumbleweed перешёл на использование SELinux по умолчанию (59 +3) |
Разработчики проекта openSUSE объявили о переводе дистрибутива openSUSE Tumbleweed, в котором применяется непрерывный цикл обновления версий программ (rolling-обновления), на использование системы принудительного контроля доступа SELinux. Начиная с обновления 20250211 для новых установок openSUSE Tumbleweed по умолчанию предлагается SELinux в режиме "enforcing". Готовые сборки виртуальных машин openSUSE Tumbleweed minimalVM будут поставляться по умолчанию с SELinux.
Поддержка AppArmor сохранится в полном объёме - в уже существующих конфигурациях продолжит использоваться AppArmor, а в инсталляторе можно выбрать опцию для активации AppArmor в новых установках. Для пользователей, в системах которых применяется AppArmor, но которые желают переключиться на SELinux, предложена инструкция по миграции. Дистрибутив openSUSE Leap 15.x продолжит использование AppArmor. Продвижение SELinux обусловлено ранее принятым решением по расширению использования данной системы управления доступом в SUSE и openSUSE, так как SELinux превосходит AppArmor по функциональности и востребован в корпоративных системах. SELinux применяется в Red Hat Enterprise Linux, а AppArmor в Ubuntu. AppArmor прост в настройке и при определении профилей доступа привязывается к файловым путям. SELinux применяет более сложный, но и более гибкий язык описания политик безопасности, охватывает различные типы ресурсов и базируется на концепции меток и контекстов безопасности. SELinux позволяет обрабатывать сложные сценарии контроля доступа и детально контролировать взаимодействие между процессами, в то время как AppArmor в основном ограничивается определением действий, разрешённых для отдельных приложений.
| ||
Обсуждение (59 +3) |
Тип: К сведению |
| ||
· | 13.02 | Релиз СУБД DuckDB 1.2.0 (43 +8) |
Опубликован выпуск СУБД 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, позволяющий в одной операции разом обрабатывать большие наборы значений. В новой версии:
| ||
Обсуждение (43 +8) |
Тип: Программы |
| ||
· | 12.02 | Для systemd развивается возможность загрузки системных образов по HTTP (202 –5) |
Леннарт Поттеринг (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 каждая последующая перезагрузка компьютера будет приводить к загрузке свежего системного образа. При подобном тестировании никак не затрагиваются локальные диски.
| ||
Обсуждение (202 –5) |
Тип: К сведению |
| ||
· | 12.02 | Выпуск языка программирования Go 1.24 (262 +17) |
После шести месяцев разработки представлен релиз языка программирования Go 1.24, развиваемого компанией Google при участии сообщества. Язык сочетает высокую производительность, свойственную компилируемым языкам, с такими достоинствами скриптовых языков, как простота написания кода, высокая скорость разработки и защита от ошибок. Код проекта распространяется под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Оберон. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно, без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов), что позволяет добиться производительности, сопоставимой с программами на языке Си. Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах. Например, на уровне операторов реализованы средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за границы буфера и обеспечивает возможность использования сборщика мусора. Среди изменений в новом выпуске:
| ||
Обсуждение (262 +17) |
Тип: Программы |
| ||
· | 11.02 | Обновление OpenSSL 3.4.1 с устранением уязвимостей (14 +14) |
Доступны корректирующие выпуски криптографической библиотеки OpenSSL 3.0.16, 3.1.8, 3.2.4, 3.3.3 и 3.4.1. В версиях 3.2.4, 3.3.3 и 3.4.1 устранена уязвимость (CVE-2024-12797), которой присвоен высокий уровень опасности. Уязвимость позволяет организовать MITM-атаку на соединения TLS и DTLS. Проблема проявляется только в системах, использующих для аутентификации клиентов открытые ключи RPK (Raw Public Key, RFC 7250). По умолчанию поддержка RPK отключена на стороне клиента и сервера.
Уязвимость вызвана тем, что OpenSSL не возвращает клиенту информацию о сбое аутентификации сервера при установке соединения с использованием режима верификации SSL_VERIFY_PEER, так как процесс согласования соединения не разрывается должным образом. Атакующий может устроить MITM-атаку и перенаправить трафик на свой хост вместо целевого сервера, а клиент не получит информацию, что сервер не аутентифицирован. Проблема проявляется начиная с ветки OpenSSL 3.2, в которой появилась возможность использования RPK вместо сертификатов X.509. Кроме того, в обновлениях OpenSSL исправлена уязвимость CVE-2024-13176, позволяющая осуществить атаку по сторонним каналам для воссоздания закрытого ключа ECDSA через анализ задержек, возникающих при генерации цифровой подписи. Суть уязвимости в том, что для некоторых видов эллиптических кривых, например, NIST P-521, из общей массы можно выделить вычисления с нулевыми старшими битами инвертированного значения вектора инициализации (nonce), время обработки которых отличается на 300 наносекунд. В случае ECDSA, определения даже нескольких битов с информацией о векторе инициализации достаточно для совершения атаки по последовательному восстановлению всего закрытого ключа. Для успешного совершения атаки у атакующего должен быть доступ к локальной системе, на которой выполняется приложение, формирующее цифровые подписи, или высокоскоростной сетевой доступ к приложению с очень низкими задержками. Атакующий также должен иметь возможность с большой точностью проанализировать время генерации большого числа цифровых подписей, созданных над известными ему данными.
| ||
Обсуждение (14 +14) |
Тип: Проблемы безопасности |
| ||
· | 11.02 | Опубликован свободный звуковой кодек FLAC 1.5 (233 +39) |
Сообщество Xiph.Org опубликовало обновление свободного звукового кодека FLAC 1.5.0, позволяющего сжимать звук без потери качества. FLAC использует только методы кодирования без отбрасывания данных (lossless), что гарантирует полную сохранность изначального качества звукового потока и его идентичность с эталонным вариантом, подвергнутым кодированию. При этом используемые методы сжатия без потерь позволяют уменьшить размер исходного звукового потока на 50-60%. FLAC является полностью свободным потоковым форматом, подразумевающим не только открытость библиотек с реализацией функций кодирования и декодирования, но и отсутствие ограничений по использованию спецификаций и созданию производных вариантов. Код библиотек распространяется под лицензией BSD.
Среди изменений в новой версии:
| ||
Обсуждение (233 +39) |
Тип: К сведению |
| ||
· | 11.02 | Релиз среды рабочего стола KDE Plasma 6.3 (185 +45) |
После четырёх месяцев разработки опубликован релиз среды рабочего стола KDE Plasma 6.3. Для оценки работы новых выпусков KDE можно воспользоваться сборками от проектов KDE Neon и openSUSE (Argon, основанный на openSUSE Leap, и Krypton, основанный на openSUSE Tumbleweed).
![]() Основные изменения:
| ||
Обсуждение (185 +45) |
Тип: Программы |
| ||
· | 11.02 | В Chrome добавлен AI-режим для автоматической смены скомпрометированных паролей (79 –25) |
В тестовые сборки Chrome Canary добавлена функция автоматической смены пароля, основанная на использовании AI. Возможность включается в разделе "Экспериментальные ИИ-функции" (chrome://settings/ai). Если пароль признан скомпрометированным, то при попытке входа c данным паролем на сайт Chrome выведет предупреждение с предложением изменить пароль. При согласии браузер сгенерирует стойкий к подбору пароль, сменит пароль на сайте и сохранит новый пароль в менеджере паролей.
Проверка компрометации паролей пользователя, сохранённых в менеджере паролей, появилась в Chrome около 5 лет назад и основывается на провеке логинов и паролей по базе данных скомпрометированных учётных записей. Размер базы Google не раскрывается, но похожая БД от проекта haveibeenpwned.com охватывает около 15 миллиардов аккаунтов, фигурировавших в утечках пользовательских баз. Для сохранения приватности применяется сверка хэш-префикса на стороне пользователя, а сами пароли и их полные хэши не передаются во вне. Применение AI в предложенной для тестирования новой реализации сводятся к автоматизации смены паролей на сайтах - AI сам заполнит и отправит нужные web-формы на необходимом сайте и обновит сохранённый пароль. ![]() ![]() ![]() ![]()
| ||
Обсуждение (79 –25) |
Тип: К сведению |
| ||
Следующая страница (раньше) >> |
Закладки на сайте Проследить за страницей |
Created 1996-2025 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |