После года разработки и 25 экспериментальных версий представлен стабильный релиз открытой реализации Win32 API - Wine 11.0, который вобрал в себя более 6300 изменений и 600 исправлений ошибок. Из ключевых достижений в новой версии выделяется полная поддержка NTSYNC, реализация механизма Reparse Point и задействование новой реализации архитектуры WoW64.
В Wine подтверждена полноценная работа 5419 программ для Windows (год назад 5372, два года назад 5336, три года назад 5266), ещё 4500 программ (год назад 4435, два года назад 4397, три года назад 4370) прекрасно работают при дополнительных настройках и внешних DLL. У 4086 программ (год назад 4020, два года назад 3943, три года назад 3888) наблюдаются небольшие проблемы в работе, которые не мешают использованию основных функций приложений.
Полная поддержка драйвера ntsync, позволяющего существенно поднять производительность Windows-игр, запускаемых при помощи Wine. Драйвер входит в состав ядра Linux начиная с выпуска 6.14 и реализует символьное устройство /dev/ntsync и набор примитивов для синхронизации, применяемых в ядре Windows NT. Значительный прирост производительности достигается благодаря избавлению от накладных расходов, связанных с применением RPC в пространстве пользователя.
Добавлена возможность настройки приоритетов потоков в Linux и macOS.
В ntdll добавлен API синхронизации "Synchronization barriers", позволяющий приостановить выполнение нескольких потоков до достижения определённой точки выполнения во всех потоках (например, дождаться пока все потоки достигнут определённой стадии при параллельном выполнении одного и тот же кода).
Переведена в разряд полностью поддерживаемых новая реализация прослойки WoW64 (64-bit Windows-on-Windows), позволяющая выполнять 32-разрядные Windows-приложения в 64-разрядных Unix-системах. В отличие от старой реализации WoW64, в которой 32-разрядные приложения запускались в 32-разрядных Unix-процессах, новый WoW64 обеспечивает запуск 32-разрядного кода внутри 64-разрядного процесса.
Реализована поддержка запуска 16-разрядных приложений в режиме WoW64.
Во всех модулях, обращающихся к Unix-библиотекам, задействованы преобразователи системных вызовов WoW64 (thunk), позволяющие 32-разрядным модулям в формате PE обращаться к 64-разрядным Unix-библиотекам.
Добавлена возможность запуска старых установок WoW64 в новом режиме через выставление переменной окружения "WINEARCH=wow64". 32-разрядные префиксы, создаваемые при выставлении WINEARCH=win32, объявлены устаревшими и не поддерживаются в новом режиме WoW64. Удалён отдельный загрузчик wine64, вместо которого задействован универсальный загрузчик, определяющий режим по разрядности запускаемого файла.
Ядро (интерфейсы ядра Windows)
Реализован механизм Reparse Point, при помощи которого можно прикреплять к файлам и каталогам дополнительные данные, идентифицируемые через теги. Поддерживаются такие типы Reparse Point, как символические ссылки и точки монтирования.
Для повышения производительности отслеживания операций записи в память задействован механизм UFFD (userfaultfd), дающий возможность создавать обработчики обращений к невыделенным страницам памяти (page faults) в пространстве пользователя. В проведённых тестах применение UFFD позволило сократить время загрузки уровней в игре "Streets of Rage 4" с 6-8 секунд до 1.5-2 секунд, что соответствует показателям запуска на платформе Windows.
Задействованы номера системных вызовов NT, идентичные последним версиям Windows, что необходимо для поддержки приложений, использующих жёстко прописанные номера системных вызовов.
На системах ARM64 реализована возможность симуляции страниц памяти размером 4K в окружениях с ядрами Linux, использующими более крупные страницы памяти (16K или 64K). Симуляция позволяет запускать простые приложения, а для более сложных программ рекомендуется использовать ядра Linux с 4-килобайтовыми страницами памяти.
Графическая подсистема
На системах X11 (winex11) для OpenGL по умолчанию задействован бэкенд отрисовки, использующий EGL. Бэкенд GLX объявлен устаревшим, но пока остаётся доступен в качестве запасного и используется при отсутствии EGL.
Добавлена начальная поддержка объектов D3DKMT, предоставляющих низкоуровневый доступ к графическим устройствам из пространства пользователя. Реализованы Vulkan-расширения VK_KHR_external_memory_win32, VK_KHR_external_semaphore_win32, VK_KHR_external_fence_win32 и VK_KHR_win32_keyed_mutex.
В режиме WoW64 (64-bit Windows-on-Windows) реализована поддержка маппинга памяти для OpenGL при помощи API Vulkan, позволяющего ускорить работу 32-битных OpenGL-приложений в Wine.
Реализована эмуляция буфера отображения (front buffer) для OpenGL на платформах без его встроенной поддержки.
В драйвер для графического API Vulkan добавлена поддержка спецификации Vulkan 1.4.335.
В наборе библиотек WindowsCodecs расширена поддержка метаданных в файлах с изображениями, а также реализована поддержка преобразования между целочисленными форматами представления цвета и форматами с плавающей запятой.
Убрана зависимость от библиотеки OSMesa (Off-screen Mesa). Реализована возможность отрисовки битовых карт через OpenGL с использованием аппаратного ускоренного OpenGL runtime.
Интеграция с рабочим столом
В драйвере winewayland.drv, позволяющем использовать Wine в окружениях на базе протокола Wayland без применения XWayland и компонентов X11, реализована поддержка буфера обмена, методов ввода, непрямоугольных окон и прозрачности.
Улучшена интеграция с X11: обеспечена отправка оконному менеджеру запросов активации окон и задействован протокол EWMH для согласования состояния активных окон X11 и Win32.
Реализована поддержка эксклюзивного полноэкранного режима. Улучшена поддержка полноэкранного режима в D3D и улучшена работа старых игр на базе DDraw.
Повышена производительность некоторых функций работы с окнами. Для взаимодействия между процессами задействована разделяемая память.
Direct3D
В Direct3D 11 добавлена поддержка аппаратного ускорения декодирования видео в формате H.264, реализованная при помощи графического API Vulkan.
В Direct3D 11 реализована поддержка minmax-фильтрации текстур, используя OpenGL-расширение GL_ARB_texture_filter_minmax или Vulkan-расширение VK_EXT_sampler_filter_minmax.
В Direct3D 11 реализованы функции загрузки текстур.
Реализована большая порция возможностей Direct3D при отрисовке через Vulkan, таких как смешивание вершин, плоское затенение, пользовательские плоскости отсечения и различные форматы ресурсов.
Во встроенной копии vkd3d-shader улучшена поддержка 1, 2 и 3 моделей шейдеров.
В методе D3DXSaveSurfaceToFileInMemory реализована поддержка изображений PNG, JPEG и BMP.
Direct3D 10 и 11 реализована поддержка сжатия и распаковки форматов BC4 и BC5, а также генерации MIP-уровней (MipMap) при загрузке текстур.
Реализованы методы ID3DXEffect::SetRawValue() и ID3DXSkinInfo::UpdateSkinnedMesh().
Устройства ввода
Улучшена совместимость с джойстиками, благодаря использованию бэкенда hidraw.
Улучшена поддержка эффекта виброотклика (Force feedback) при использовании игровых рулей и джойстиков.
Улучшена поддержка геймпадов в API Windows.Gaming.Input и при использовании бэкенда evdev.
В апплет управления игровыми контроллерами добавлена вкладка для настройки API Windows.Gaming.Input.
Повышена совместимость DirectInput со старыми играми.
Bluetooth
В драйвере для Bluetooth добавлена возможность сканирования, настройки обнаружения и сопряжения устройств.
Добавлена поддержка сервисов Bluetooth Low Energy.
Приложениям предоставлена возможность создавать низкоуровневые RFCOMM-соединения c внешними устройствами, используя API Winsock.
Поддержка сканеров
Реализована поддержка API TWAIN 2.0, позволяющего обращаться к сканерами из 64-разрядных приложений.
Реализована поддержка компонента DAT_IMAGENATIVEXFER для передачи изображения от сканера в приложение.
Обеспечено сохранение в реестре выбранного сканера и настроек сканера.
Добавлена поддержка многостраничного сканирования и автоподатчи документов.
Прекращена блокировка приложения во время вызова интерфейса сканирования.
Добавлена поддержка загрузки родных Windows-драйверов к сканерам.
Интернационализация
Обеспечена генерация БД локалей в формате locale.nls из БД Unicode CLDR (Unicode Common Locale Data Repository) версии 48. Добавлена поддержка дополнительных локалей bua-RU, bqi-IR, cop-EG, ht-HT, kek-GT, lzz-TR, mww-Hmnp-US, oka-CA, pi-Latn-GB, pms-IT, sgs-LT, suz-Deva-NP и suz-Sunu-NP.
Таблицы символов Unicode обновлены до версии стандарта 17.0.0. Обновлена база часовых поясов.
Сетевые возможности
В движке MSHTML в режиме соответствия стандартам обеспечена работы с атрибутами элементов как с полноценными узлами DOM. Реализованы объекты DOMParser, XDomainRequest и msCrypto.
В JavaScript добавлена поддержка типизированных массивов.
Для ICMPv6 реализована команда ping.
БД
В библиотеку MSADO (ActiveX Data Objects) добавлена поддержка записи изменений в БД. Реализовано большинство функций объекта
Recordset.
В библиотеке odbc32 улучшена поддержка ANSI win32-драйверов, не рассчитанных на работу с Unicode. Реализованы функции SQLDriverConnectA(), SQLSpecialColumnsW(), SQLGetInfoW(), SQLGetInfoW(), SQLStatisticsW() и QLColumnsW().
Встроенные приложения
В WineCfg добавлена вкладка для настройки MIDI-устройства по умолчанию.
В утилите cmd реализовано автодополнение ввода имён файлов в интерактивном режиме работы, добавлена поддержка сложных инструкций и реализована команда "mklink /j" для создания Reparse Point.
В утилиту conhost (Console Hosting) добавлена поддержка получения истории нажатием клавиш F1 и F3.
Реализованы команды timeout, runas и subst.
В утилиту find добавлены опции "/c" для показа числа совпадений и /i для сопоставлений без учёта регистра.
В утилите whoami появилась возможность настройки формата вывода.
Разное
В реализации языка описания интерфейса WIDL (Wine Interface Definition Language) появилась поддержка генерации метаданных Windows Runtime (WinRT). Обеспечена генерация и установка файлов WinMD (Windows Metadata) для API WinRT (Windows Runtime).
В утилиту winedump добавлена поддержка дампа ресурсов MUI, номеров системных вызовов, встроенных NE-модулей и больших файлов PDB (> 4 ГБ).
Проведён рефакторинг реализации Common Control, библиотека COMCTL32 разделена на отдельные модули для версий 5 и 6.
В BCrypt добавлена поддержка стандарта формирования ключа PBKDF2
Добавлена поддержка каталогов UserProgramFiles, AccountPictures и Screenshots.
В состав интегрированы библиотеки LLVM Compiler-RT 8.0.1 и TomCrypt 1.18.2. Для определения CPU на платформе FreeBSD задействована библиотека HwLoc.
Обновлены до новых версий компоненты Vkd3d 1.18, Faudio 25.12, FluidSynth 2.4.2, LCMS2 2.17, LibMPG123 1.33.0, Libpng 1.6.51, LibTiff 4.7.1, LibXml2 2.12.10, LibXslt 1.1.43.
Добавлена поддержка спецификации Freedesktop.org XDG Base Directory и возможность использования каталога "~/.config/mozilla" для хранения профилей, дополнений, настроек и внутренних БД. Поддержка размещения данных в старом каталоге "~/.mozilla" сохранена в качестве опции, активируемой при запуске с переменной окружения "MOZ_LEGACY_HOME=1".
Добавлена поддержка механизма "Compression Dictionary Transport" (RFC 9842), позволяющего сократить размер данных, передаваемых между клиентом и сервером, за счёт использования алгоритмов сжатия Zstandard (Content-Encoding: dcz) и Brotli (Content-Encoding: dcb) в сочетании со сжатием типовых конструкций с использованием словарей. Доступно два сценария использования Compression Dictionary Transport - сжатие контента по предварительно переданным сервером словарям и использование ранее переданного контента в качестве словаря для сжатия его новой версии (дельта-сжатие, при котором передаются только изменения по сравнению с имеющейся версией).
Например, при запросе "GET /index.html" сервер может передать сведения о наличии словаря, вернув путь к нему в заголовке 'Link: <.../dict>; rel="compression-dictionary"'. При загрузке клиентом словаря ".../dict" сервер выдаст информацию об его применении к HTML-файлам, выставив заголовок 'Use-As-Dictionary: match="/*html"'. При следующем запросе html-ресурса, например, "GET /index2.html", клиент укажет сведения о наличии у него словаря через заголовок 'Available-Dictionary: хэш_словаря"'. Если сервер имеет на своей стороне словарь с данным хэшем, то вернёт содержимое index2.html, сжатое с использованием данного словаря.
Для дельта-сжатия разных версий JavaSсript-файлов в ответ на запрос "GET /app.v1.js" сервер может выставить заголовок 'Use-As-Dictionary: match="/app*js"', информирующий что возвращённый контент в дальнейшем можно использовать в качестве словаря для путей "/app*js". При последующем запросе файла, соответствующего данной маске, например, "GET /app.v2.js", клиент передаст хэш имеющегося словаря через заголовок "Available-Dictionary:", а сервер вернёт лишь изменения между файлами app.v1.js и app.v2.js.
Добавлена страница about:keyboard для настройки комбинаций клавиш и переопределения имеющихся горячих клавиш, например, для задания более привычных для себя вариантов или исключения конфликтов с другими программами.
Оптимизировано воспроизведение видео с использованием аппаратного ускорения декодирования на GPU AMD. На системах с GPU AMD аппаратно декодированное видео теперь воспроизводится без дополнительного копирования данных (режим zero-copy), как это ранее было реализовано для систем с GPU Intel и NVIDIA.
Для версии 5 обновлена реализация протокола Safe Browsing, применяемого для проверки URL на предмет наличия в списках небезопасных ресурсов (фишинговые сайты, страницы с вредоносным ПО и т.п.), предоставляемых Google. Новая версия протокола позволяет загружать списки блокировки для использования на локальной системе (БД с префиксами хэшей SHA256 проблемных URL), которые теперь применяются в Firefox.
Добавлена опция для автоматического продолжения воспроизведения видео в режиме "картинка в картинке" в случае переключения вкладки.
В режиме усиленной защиты от отслеживания перемещений (ETP, Enhanced Tracking Protection => Strict) включено по умолчанию применение спецификации LNA (Local Network Access) для ограничения обращений к локальной системе (loopback, 127.0.0.0/8) или внутренней сети (192.168.0.0/16, 10.0.0.0/8 и т.п.) при взаимодействии с публичными сайтами. Обращение к внутренним ресурсам используются злоумышленниками для осуществления CSRF-атак на маршрутизаторы, точки доступа, принтеры, корпоративные web-интерфейсы и другие устройства и сервисы, принимающие запросы только из локальной сети. Кроме того, сканирование внутренних ресурсов может использоваться для косвенной идентификации или сбору сведений о локальной сети.
На Linuх-системах с GNOME и композитным сервером Mutter решена проблема с нечётким отображением контента при использовании дробного уровня масштабирования.
На компьютерах Apple с чипами Apple Silicon и ОС macOS включена поддержка API WebGPU.
Выставляемые в HTTP-заголовке Accept-Language приоритеты выбора языка (q-параметры) синхронизированы со значениями, выставляемыми другими браузерами, что решило некоторые проблемы с переносимостью. Например, для второго языка теперь выставляется приоритет q=0.9 вместо q=0.5, а для каждого последующего языка приоритет уменьшается на 0.1.
Библиотека ICU обновлена до версии 78 с поддержкой Unicode 17 и обновлением данных локалей.
В Service Worker-ах разрешено использование JavaScript-модулей ESM (ECMAScript Module), импортируемых и экспортируемых через выражения
import и export.
Добавлена поддержка спецификации CSS Module Scripts, позволяющей использовать систему модулей JavaScript для импорта CSS-ресурсов. Например:
import styles from "./styles.css" with { type: "css" };
В псевдо-элементе "::marker", позволяющем настроить параметры чисел и точек для перечислений в блоках <ul> и <ol>, разрешено использовать CSS-свойства "counter-*" и "quotes".
В API CompressionStream и DecompressionStream добавлена поддержка формата сжатия Brotli.
В API View Transitions, применяемом для создания анимационных эффектов при переключении между разными состояниями DOM, добавлено свойство "type", содержащее массив с типами переходов. Также добавлен соответствующий CSS-селектор ":active-view-transition-type" и свойство document.activeViewTransition, возвращающее экземпляр активного для документа объекта ViewTransition.
Включён набор CSS-свойств для управления показом элементов, привязанных к местоположению других элементов (CSS Anchor Positioning), без использования JavaScript, например, для прикрепления к элементам всплывающих окон (popover), появляющихся по аналогии со всплывающими подсказками.
Реализована спецификация "Storage Access Headers", определяющая заголовок запроса "Sec-Fetch-Storage-Access" и заголовок ответа "Activate-Storage-Access" для получения доступа к сторонним Cookie без вызова метода document.requestStorageAccess(). Сервер может запросить доступ к Cookie через заголовок "Activate-Storage-Access" и он будет отправлен клиентом, если ранее пользователь подтверждал предоставление доступа к хранилищу Cookie через API Storage Access.
В CSS-свойство "root-font-relative" добавлена поддержка относительных единиц измерения rcap, rch, rex и ric.
Реализован API Navigation, позволяющий web-приложениям перехватывать операции навигации в окне, инициировать переход и анализировать историю действий с приложением. API предоставляет альтернативу свойствам window.history и window.location, оптимизированную для одностраничных web-приложений.
В инструментах для web-разработчиков в панели с правилами CSS реализована поддержка редактирования и добавления селекторов псевдоэлементов. В интерфейс для просмотра данных в формате JSON добавлена кнопка для импорта ресурса в систему профилирования (Firefox Profiler) для определения информации о его размере.
В панелях инспектирования HTML-элементов и анимации обеспечено отображение псевдоэлементов View Transitions. В панели с правилами CSS реализовано отображение правил @position-try, применяемых для управления показом элементов, привязанных к местоположению других элементов (CSS Anchor Positioning).
В версии Firefox для Android добавлена защита от атак по сторонним каналам, таким как Spectre, применяемым для обхода изоляции между сайтами. Ранее подобная защита была доступа только в сборках для десктоп-систем.
Кроме новшеств и исправления ошибок в Firefox 147 устранено 23 уязвимости. 10 уязвимостей вызваны проблемами работы с памятью, такими как переполнения буферов и обращение к уже освобождённым областям памяти. Потенциально данные проблемы способны привести к выполнению кода злоумышленника при открытии специально оформленных страниц. 3 уязвимости позволяют обойти sandbox-изоляцию из-за некорректной проверки границ и целочисленного переполнения в компоненте для работы с графикой.
Давид Хейнемейер Ханссон (David Heinemeier Hansson), автогонщик и автор веб-фреймворка Ruby on Rails, опубликовал дистрибутив Omarchy 3.3, отражающий его представление об идеальном Linux-окружении. Дистрибутив развивается в соответствии с принципом "Omakase Computing", предполагающим, что большинство пользователей в начале своего пути не знают, чего именно они хотят, и для них будет лучше не терзать себя попытками выбора, а воспользоваться набором инструментов, подготовленным тем, чьей компетентности и вкусу они доверяют. Наработки проекта распространяются под лицензией MIT. Размер ISO-образа 7.2 ГБ.
Дистрибутив основан на пакетной базе Arch Linux и предлагает пользовательское окружение на основе композитного менеджера Hyprland с мозаичной компоновкой окон. Отмечается, что проект не просто предлагает набор предустановленных пакетов, а пытается предложить среду из сочетающихся между собой приложений, подобранных с учётом эстетики и эффективности решения задач.
По мнению Давида, для высокой производительности труда важна мотивация и частью такой мотивации является красивое и эстетичное окружение. В состав Omarchy не входит ничего лишнего и предлагаются только приложения, повседневно используемые Давидом - от Neovim, Chromium и LibreOffice до Spotify, Typora, Ghostty и Zoom.
Omarchy не пытается быть похожим на Windows или macOS, угодить большинству или показаться привычным пользователям, а лишь стремиться быть лучше. Предложенное окружение, работа с кодом в Neovim, активное использование терминала и мозаичная компоновка окнами многим покажется непривычной, но те кто решиться выйти из зоны комфорта и освоить для себя что-то новое сможет повысить эффективность своей работы.
Некоторые особенности:
Консольный инсталлятор и ориентация на установку на отдельный диск с применением полнодискового шифрования
Возможность управления всеми действиями в графическом окружении при помощи клавиатуры, что позволяет заметно ускорить выполнение типовых действий по сравнению с применением мыши. Например, для вызова списка приложений можно использовать комбинацию "Super + Space", для показа меню "Super + Alt + Space", запуска терминала - "Super + Return", запуска браузера - "Super + Shift + B".
На выбор предложено 14 тем оформления, которые можно сменить через секцию "Style > Theme" в основном меню.
Использование комбинаций клавиш Super + C, Super + X и Super + V для копирования и вставки из буфера обмена. Наличие интерфейса (Super + Ctrl + V) для просмотра и поиска по истории помещения данных в буфер обмена.
Автоматическое создание снапшотов системы после обновления с возможностью отката изменений в случае возникновении проблем. Ручное создание снапшотов командой "omarchy-snapshot create".
Активация по умолчанию межсетевого экрана с блокировкой всех входящих соединений на порты, кроме 22 (ssh) и 53317 (LocalSend).
По умолчанию использование штатных репозиториев Arch Linux core, extra, multilib, а также своего репозитория Omarchy Package Repository. Опционально возможно включение установки из AUR.
Наличие AI-инструментов: OpenCode (агент для обращения к AI-сервисам и большим языковым моделям), Voxtype (система голосового ввода), LM Studio и Ollama (для локального запуска AI-моделей). Наличие провайдеров для Claude Code, Gemini CLI, OpenAI Codex и GitHub Copilot.
Использование по умолчанию редактора кода NeoVim с возможность его замены на VSCode, Cursor, Zed, Sublime Text и Helix.
Наличие Docker, GitHub CLI и средств для установки преднастроенных окружений для разработки, например, для использования Ruby on Rails,
Node.js, Bun, Deno, Laravel, Symfony, .NET, OCamal, Zig и Elixir. Для установки нескольких разных версий одного языка программирования или фреймворка задействован Mise.
Поставка консольного интерфейса lazygit для работы с Git, а также Lazydocker для работы с Dоcker.
Использование консольного интерфейса Impala для настройки Wi-Fi и BlueTUI для подключения Bluetooth-устройств.
Наличие графических приложений: системы ведения заметок Obsidian, редактора изображений Pinta, системы для обмена файлами с другими устройствами LocalSend, офисного пакета LibreOffice, мессенджера Signal, мультимедийного проигрывателя mpv, системы потокового вещания OBS Studio, редактора видео Kdenlive.
Предоставлена возможность быстрой установки проприетарных приложений: менеджера паролей 1Password, markdown-редактора Typora, системы синхронизации файлов Dropbox, VPN Tailscale, музыкального сервиса Spotify.
Устанавливаемые web-приложения: почтовый клиент и календарь-планировщик HEY (альтернатива Gmail, Outlook и Apple Mail), система управления проектами Basecamp, Google Maps, ChatGPT, WhatsApp, X/Twitter, YouTube, Zoom.
Для любителей игр поставляются Steam, RetroArch, Minecraft, Xbox Controllers.
В меню имеется опция "Install > Windows" для быстрой установки Windows 11 Pro (без активации) в виртуальной машине Docker.
Наличие расширенных утилит для работы в командной строке, таких как fzf (расширенный поиск файлов), Zoxide (замена команды cd с ведением истории операций), ripgrep (расширенный аналог grep для поиска содержимого), eza (замена ls, показывающая больше информации),
fd (замена find), try (создание каталогов для экспериментов).
Предоставление shell-функций для типовых задач, таких как compress/decompress, iso2sd, format-drive, img2jpg, img2jpg-small и img2png.
Организация Buddies Of Budgie опубликовала отчёт о развитии среды рабочего стола Budgie, в котором отмечены достижения за 2025 год и раскрыты планы на 2026 год. После формирования выпуска Budgie 10.10, переведённого на Wayland, всё внимание переключилось на разработку ветки Budgie 11.
Вместо GTK для организации вывода в Budgie 11 будет задействован Qt6 и вспомогательные библиотеки из набора KDE Frameworks. Миграция уже опробовала в приложении Budgie Display Configurator, при разработке которого использованы Qt6 и фреймворк построения интерфейса Kirigami (надстройка над Qt Quick Controls).
В Budgie 11 будет произведён переход на модульную архитектуру, подразумевающую разделение на два слоя: "Budgie Core" и "Budgie Desktop". Модульная архитектура позволит адаптировать проект для новых формфакторов, устройств ввода и рабочих процессов. Например, Budgie сможет использоваться не только на ПК и ноутбуках, но и на планшетах, телевизорах, устройствах виртуальной реальности и смартфонах.
Слой Budgie Core содержит базовые библиотеки, применяемые для всех устройств, отвечает за запуск компонентов в зависимости от типа устройства, и предоставляет библиотеки для организации вывода информации, поддержки языков и локалей, управления энергопотреблением, взаимодействием с устройствами ввода и конфигурирования.
Слой Budgie Desktop реализован поверх Budgie Core и предоставляет функциональность графической оболочки. Слой отвечает за такие операции, как компоновка окон, управление рабочими столами и приложениями, построение интерфейса пользователя. Из возможностей Budgie 11 также заявлена поддержка кроссплатформенных тем оформления и возможность замены компонентов и расширений, таких как композитный сервер, система вывода уведомлений и панели.
Представлен первый выпуск проекта Gixy-Next, развивающего статический анализатор для файлов конфигурации Nginx, позволяющий выявлять проблемные настройки, негативно влияющие на безопасность и производительность. Проект развивает Джошуа Роджерс (Joshua Rogers), несколько лет назад выявивший 55 уязвимостей в прокси-сервере Squid. Gixy-Next создан как форк проекта Gixy-ng, продолжавшего развитие инструментария Gixy, открытого компанией Yandex в 2017 году и последние два года не обновлявшегося.
В качестве причины создания нового форка называется недовольство действиями мэйнтейнера проекта Gixy-ng, злоупотребляющего использованием AI-инструментов при разработке. Форк создан после того, как в репозиторий стали добавляться автоматические сгенерированные изменения, не прошедшие должного рецензирования и приводящие к возникновению регрессий и нарушению поведения инструментария. В коде стали появляться бессмысленные артефакты от применения AI и функции, которые не делали то, что должны были. Например, вносились раздутые исправления, занимавшие тысячи строк, которые можно было заменить 10-строчным патчем. Более того, в документацию и встроенную подсказку была добавлена реклама, а сторонние pull-запросы принимались с вырезанием информации об авторах.
В Gixy-Next проведена чистка кодовой базы от мусорных изменений, созданных при помощи AI, исправлены ошибки, налажено тестирование на крупных файлах конфигурации NGINX и добавлены изменения для упрощения сопровождения кодовой базы. Из новых возможностей Gixy-Next по сравнению с оригинальным Gixy отмечается:
19 новых плагинов, проверяющих корректность настроек, связанных с управлением доступом, DNS, проксированием и регулярными выражениями, а также выявляющих настройки, приводящие к дополнительным накладным расходам и снижению производительности.
Стандартизированный и воспроизводимый вывод отчётов, пригодный для автоматизированного разбора.
Поддержка модулей map и geo.
Модернизация плагинов
origins, ssrf, http_splitting, alias_traversal и valid_referers
для снижения ложных срабатываний и более точного обнаружения проблем.
Корректная обработка дополнительных файлов конфигурации, подключаемых через директиву "include".
Улучшение проверки регулярных выражений.
Возможность сборки в виде Online-сканера, работающего в браузере.
Линус Торвальдс опубликовал новый проект AudioNoise, связанный с его увлечением гитарными педалями. AudioNoise позволяет генерировать случайные звуковые эффекты во время игры на электрогитаре. Целью проекта заявлено изучение основ цифровой обработки звука, так же, как когда-то он изучал аппаратную составляющую, экспериментируя со сборкой гитарных педалей. Основной код написан на языке Си, но в состав также входит Python-скрипт для визуализации звуковых сэмплов.
В примечании к проекту Линус упомянул, что так как он разбирается в языке Python не так хорошо, как в аналоговых фильтрах, то для генерации скрипта-визуализатора использовал вайб-кодинг в AI-среде разработки Google Antigravity. Изначально он пытался создать визуализатор традиционным путём "погуглив и воспользовавшись найденными примерами" ("monkey-see-monkey-do"), но затем убрал себя как посредника, поставил задачу AI-помощнику и получил результат.
За день до публикации скрипта-визуализатора Линус эмоционально раскритиковал продвижение в ядро патча с документацией, регламентирующей использование AI-инструментов для автоматической генерации кода для ядра. Линус указал на бессмысленность введения меток для AI-слопа, так как очевидно, что люди, создающие непроверенный код при помощи AI, не станут документировать этот факт в своих патчах, и проблему с мусорными AI-патчами не решить документацией.
По словам Линуса, документация предназначена для добросовестных разработчиков и она не должна отражать какие-то отдельные заявления про AI. В сообществе и так полно людей, придерживающихся противоположных мнений про AI - кто-то считает, что "всё рушится", а кто-то, что "наступает революция в разработке", поэтому Линус против того, чтобы документация по разработке ядра принимала какую-то одну позицию, и настаивает, чтобы AI рассматривался всего лишь как ещё один инструмент.
Итальянское управление по надзору в сфере связи (AGCOM) оштрафовало компанию Cloudflare на 14.2 млн евро за нарушение требований в отношении блокирования пиратского контента в публичном DNS-сервисе 1.1.1.1. Выставленный Cloudflare штраф стал крупнейшим взысканием за не выполнение антипиратского законодательства Италии, так как размер штрафа начисляется от общей выручки компании.
В феврале 2025 года AGCOM выдал компании Cloudflare предписание о прекращении DNS-резолвинга доменов и IP-адресов, через которые распространяется контент, нарушающий авторские права. Компания Cloudflare отказалась реализовать в DNS-сервисе 1.1.1.1 блокировку по предоставленному списку, назвав такую блокировку неоправданной и несоразмерной, а также указав на техническую невозможность реализации фильтров в сервисе 1.1.1.1, обрабатывающем 200 миллиардов запросов в день, без негативного влияния на производительность. В сервисе 1.1.1.1 изначально заявлено отсутствие какой-либо фильтрации, а для блокировки вредоносных ресурсов и сайтов только для взрослых предоставляются отдельные DNS-резолверы 1.1.1.2 и 1.1.1.3.
После отказа в AGCOM было проведено разбирательство, которое пришло к выводу, что компания Cloudflare открыто нарушила действующие в Италии правовые нормы, обязывающие провайдеров DNS и VPN блокировать пиратские сайты. В AGCOM сочли названную причину недостаточной и не согласились с доводом, что введение фильтров приведёт к снижению качества сервиса, так как компания Cloudflare не всегда является нейтральным посредником и известна своими сложными механизмами управления трафиком. По данным AGCOM у Cloudflare есть необходимый опыт и ресурсы для внедрения требуемой блокировки.
До этого, компания Cloudflare выступала с критикой действующей в Италии с 2024 года инициативы "Piracy Shield", в ходе которой под блокировку вместе с пиратскими сайтами часто попадали и легитимные ресурсы, пользующиеся теми же платформами хостинга и сетями доставки контента. Недовольство также связано с отсутствием прозрачности при наполнении списков блокировки "Piracy Shield", которые включают около 65 тысяч доменных имён и 14 тысяч IP-адресов.
Дополнение: Мэтью Принс (Matthew Prince), руководитель и сооснователь Cloudflare, заявил, что компания будет бороться c несправедливым штрафом. Помимо оспаривания штрафа рассматривается несколько вариантов реагирования на вынесенное решение: прекращение финансирования сервисов по обеспечению кибербезопасности на Зимних Олимпийских играх в Италии, прекращение оказания всех бесплатных сервисов защиты для пользователей из Италии, перенос всех своих серверов из итальянских городов, прекращение инвестирования в Италии и сворачивание планов по строительству итальянского офиса Cloudflare.
Мэтью также указал на порочность выдвигаемых AGCOM требований, предписывающих осуществлять блокировку в течение 30 минут после уведомления. За такой короткий промежуток времени невозможно полноценно верифицировать новые записи в списке блокировки, что не исключает возникновение ложных блокировок и создаёт риски превращения 1.1.1.1 в сервис для цензурирования ресурсов, неугодных европейским издателям контента, и навязывания своих условий о том, что допустимо, а что нет в интернете. Действия AGCOM также критикуются за отсутствие судебного надзора, прозрачности, формализованной процедуры и инструментов для подачи апелляций.
Опубликован выпуск среды рабочего стола Budgie 10.10, в котором полностью отказались от поддержки X11 и оставили только возможность работы в окружениях на базе протокола Wayland. Одновременно сформированы аналогичные выпуски для сопутствующих компонентов, таких как менеджер сеансов Budgie Session (форк gnome-session), рабочий стол Budgie Desktop View, интерфейс для настройки системы Budgie Control Center (форк GNOME Control Center) и набор сервисов Budgie Desktop Services. Код проекта распространяется под лицензией GPLv2.
Пакеты с Budgie 10.10 уже доступны в Fedora Rawhide и войдут в состав дистрибутивов Fedora 44 и Ubuntu Budgie 26.04.
Основу Budgie составляет панель, близкая по организации работы к классическим панелям рабочего стола. Все элементы панели являются апплетами, что позволяет гибко настраивать состав, менять размещение и заменять реализации основных элементов панели на свой вкус. Среди доступных апплетов можно отметить классическое меню приложений, систему переключения задач, область со списком открытых окон, просмотр виртуальных рабочих столов, индикатор управления питанием, апплет управления уровнем громкости, индикатор состояния системы и часы.
Выпуск Budgie 10.10 примечателен достижением паритета функциональности апплетов при использовании Wayland со старым окружением на базе X11. В качестве композитного сервера рекомендовано использовать labwc на базе библиотеки wlroots, но в ветке Budgie 11 обещают добавить поддержку Kwin и композитных серверов на базе библиотек Mir.
Среди необходимых для сборки зависимостей заявлена библиотека libxfce4windowing, реализующая не зависящий от графической системы слой с элементами управления окнами (экраны, корневые окна, виртуальные рабочие столы и т.п.). Для создания панели и компонентов рабочего стола задействована библиотека gtk-layer-shell, использующая GTK3 и Wayland-протокол Layer Shell.
В связи с переходом на Wayland заменены многие вспомогательные компоненты: Для создания скриншотов и выделения области экрана задействованы утилиты grim и slurp. Блокировка экрана, активация хранителя экрана при неактивности и управление энергопотреблением реализованы при помощи swayidle, gtklock (или swaylock) и wlopm. Для управления обоями рабочего стола задействована утилита swaybg. Для совместного доступа к экрану и записи скринкастов из приложений задействованы XDG-порталы xdg-desktop-portal-gtk и xdg-desktop-portal-wlr. Для настройки многомониторных конфигураций предложено использовать wdisplays.
Другие изменения:
Обновлены и переведены на Wayland апплеты для переключения задач, управления режимом ночной подсветки ("Night Light", меняет цветовую температуру в зависимости от времени суток), вывода уведомлений, переключения между виртуальными рабочими столами.
Панель и рабочий стол переведены на использование Wayland-протокола layer-shell. Улучшена логика позиционирования и центровки панели.
В конфигураторе (Budgie Control Center) убрана завязанная на X11 панель управления цветом; сделана опциональной панель настройки Bluetooth; настройки блокировки экрана и режима ночной подсветки перемещены в отдельные секции; добавлены опции для людей с ограниченными возможностями (например, лупа для увеличения областей экрана).
После релиза Budgie 10.10 ветка 10.x переведена в режим сопровождения, в котором допускается только исправление ошибок. В дальнейшем все ресурсы будут брошены на развитие ветки Budgie 11, примечательной отделением функциональности рабочего стола от слоя, обеспечивающего визуализацию и вывод информации. Разделение позволит абстрагировать код от конкретных графических тулкитов и библиотек.
Разработчики поисковой системы Kagi представилиальфа-выпуск web-браузера Orion для платформы Linux. Сборки Orion для Linux сформированы в формате flatpak. Ранее браузер выпускался только для платформ macOS и iOS. Браузер Orion построен на движке WebKit и примечателен блокированием по умолчанию рекламы и кода для отслеживания перемещений, отсутствием сбора и отправки телеметрии, интеграцией с поисковыми сервисами Kagi и возможностью установки дополнений от Safari, Chrome и Firefox.
Orion предлагает дополнительные возможности кастомизации интерфейса и просматриваемых страниц, не ограничивающиеся сменой тем оформления. Например, можно добавлять в панель собственные кнопки для вызова JavaScript-кода или выполнения доступных в браузере функций. Возможно изменение шрифтов, отключение непрокручиваемых заголовков, принудительное применение тёмного оформления для сайтов, а также выборочное отключение JavaScript, Cookie и внешних шрифтов.
Имеется режим быстрого удаления HTML-элементов со страниц через их выделение курсором, а также функция редактирования страницы, позволяющая изменить содержимое перед созданием скриншота или сохранением на диск.
Заявлено более эффективное освобождение памяти - в проведённом тесте после закрытия вкладок браузер занимал в 3 раза меньше памяти по сравнению с Safari, в 2.5 раза - по сравнению Chrome и в 2 раза - по сравнению Firefox. При этом протестировавшие Linux-версию Orion отмечают более высокую нагрузку на CPU по сравнению с Firefox.
Среди других возможностей: вертикальные вкладки, режим быстрого поиска, интеграция с archive.org для просмотра старых версий страниц, режим компактного отображения вкладок, автоскрытие панелей, изменение User Agent, предпросмотр ссылок, группировка вкладок, режим экономии энергии, блокировка автовоспроизведения звука и видео, отключение применяемой на некоторых сайтах блокировки копирования в буфер обмена.
В альфа-версии для Linux реализованы все базовые возможности, среди которых локальный экспорт/импорт, менеджер паролей, управление горизонтальными и вертикальными вкладками (за исключением интерфейса Tab Switcher), сохранение сеанса, автовосстановление состояния после перезапуска, закладки, группировка сохраняемых страниц по папкам, управление историей навигации. Пока не поддерживаются расширения WebKit и отсутствует инфраструктура для синхронизации между разными системами пользователя.
Издание DB-Engines обновило рейтинг популярности СУБД, отслеживающий популярность 428 систем. Методика расчёта рейтинга СУБД напоминает рейтинг языков программирования TIOBE и учитывает популярность запросов в поисковых системах, число результатов в поисковой выдаче, объём обсуждений на популярных дискуссионных площадках и социальных сетях, число вакансий в агентствах по найму персонала и упоминаний в профилях пользователей.
Как и год назад первые пять мест продолжают занимать Oracle, MySQL, Microsoft SQL Server, PostgreSQL и MongoDB. По сравнению с январём 2025 года в десятке лидеров произошли две перестановки: Elasticsearch спустился с 8 на 10 место, а Databricks поднялся с 13 на 8 место. Остальные лидеры сохранили свои позиции в рейтинге, но снижение популярности наблюдается для MySQL (-130 баллов), MS SQL Server (-92), Elasticsearch (-27), MongoDB (-25), Oracle (-21), DB2 (-10), Redis (-9). Рост популярности фиксируется для Snowflake (+53), Databricks (+53) и PostgreSQL (+3).
Если рассматривать СУБД не из десятки лидеров, то за год повысили свои позиции в рейтинге MariaDB (14 → 13), Splunk (15 → 14), Microsoft Azure SQL (16 → 15), Apache Hive (18 → 16), Apache Solr (24 → 21), PostGIS (29 → 27), OpenSearch (33 → 31), DuckDB (55 → 42), Prometheus (52 → 46), TimescaleDB (75 → 63).
В конце прошлого года во время уборки в вычислительном центре Университета Юты была обнаружена архивная магнитная лента с кодом операционной системы UNIXv4, которая была разработана в 1973 году для ЭВМ PDP-11/45 и считалась утерянной. UNIXv4 продолжал развитие выпущенной за год до этого операционной системы UNIXv3, в которой впервые был использован язык Си и неименованные каналы. Особенностью UNIXv4 стало переписывание ядра с ассемблера на язык Си. Код ядра UNIXv4 был написан Кеном Томпсоном, а драйверов - Деннисом Ритчи.
В конце декабря 2025 года
сотрудники музея истории вычислительной техники смогли найти необходимое оборудование и извлечь сохранённый на ленте архив. Для оцифровки записанного на ленту аналогового сигнала использован инструментарий readtape, а для раскодирования формата архива задействованы наработки, созданные в процессе восстановления архива с реализацией редактора Emacs от Джеймса Гослинга.
Помимо кода UNIXv4 на ленте также были найдены исходные тексты одного из первых компиляторов для языка Си и интерпретатора языка SNOBOL. Позднее код UNIXv4 был приведён в порядок и опубликован на GitHub в форме, пригодной для сборки и запуска в симуляторе PDP-11. Код
UNIXv4 включает 61 тысячу строк, из которых 27 тысяч на языке Си, 33 тысячи на ассемблере для PDP-11 и около тысячи - заголовочные файлы.
Один из исследователей безопасности обратил внимание на утилиту "su", поставлявшуюся в UNIXv4. Данная утилита включала менее 50 строк кода, устанавливалась с флагом setuid-root и позволяла запустить /bin/sh с правами root при вводе правильного пароля. Код содержал уязвимость, приводящую к переполнению буфера из-за копирования вводимого пользователем пароля в фиксированный 100-символьный массив без проверки размера вводимых данных.
Выявленную проблему прокомментировал 93-летний Дуглас Макилрой (Douglas McIlroy), входивший в команду изначальных разработчиков Unix в Bell Labs, предложивший концепцию неименованных каналов и создавший такие утилиты, как echo, spell, diff, sort, join и tr. По словам Дугласа, до появления червя Морриса в 1988 году мало кто обращал внимание на переполнения буферов. Добавление проверок размера вводимых вручную данных рассматривалось как добавление лишнего кода, а аварийное завершение при переполнении воспринималось как неуклюжая форма реагирования на некорректные входные данные. Со временем переполнения, возникающие при обработке автоматически генерируемых строк, стали исправлять, но для ручного ввода логика была на уровне "кому может понадобиться вручную вводить слишком длинные строки".
Разработчики дистрибутива Gentoo Linux опубликовали отчёт с обзором основных событий и финансовых показателей за 2025 год. Среди отмеченных достижений:
Доход организации Gentoo Foundation за 2025 финансовый год составил 12066 долларов, из которых 80% передано в форме индивидуальных пожертвований. Дополнительно $8471 индивидуальных пожертвований получено через организацию SPI. Для сравнению в 2024 году проект получил $20800, что на $263 больше, чем в 2025 году.
Затраты составили $21036 (год назад $21200), из которых $8332 потрачено на хостинг и прочие сервисы, $1724 на управленческие расходы и ведение бухгалтерии, $905 на сбор средств (fundraising) и $10075 на амортизационные расходы. Баланс на банковском счёте: $104831 (год назад 105 тысяч долларов).
Продолжен перевод управления активами, решения юридических вопросов и организации сбора пожертвований в организацию SPI (Software in the Public Interest).
В основной репозиторий за 2025 год внесено 112927 изменений, что на 9% меньше, чем в 2024 году (123942). Число коммитов от сторонних разработчиков сократилось на 27%, с 12812 до 9396. Число уникальных сторонних участников сократилось на 10.5%, с 421 до 377.
В поддерживаемый пользователями репозиторий GURU внесено 5813 изменений от 264 участников (в 2024 году было 7517 изменений от 241 участника).
В систему отслеживания ошибок за год добавлено 20763 отчётов. За год решено 22395 проблем (в 2024 году было 26123 отчётов и 25946 решённых проблем, в 2023 - 24795 отчётов и 22779 решённых проблем).
Проектом поддерживается 31663 ebuild-сценариев, охватывающих 19174 разных пакетов. Размер бинарных пакетов для архитектуры x86-64 составляет 89 ГБ.
Планируется перенос зеркал репозиторив и процесса передачи изменений с GitHub на сервис Codeberg, построенный на платформе совместной разработки Forgejo. Основная причина ухода с Github - навязывание Copilot.
Подготовлена, одобрена и добавлена в Portage спецификация EAPI 9 для ebuild. В новой версии улучшена обработка ошибок, добавлена функция edo для вывода и запуска команд, модернизировано сборочное окружение и добавлена возможность задания EAPI по умолчанию для дерева каталогов с профилями.
Предоставлены официальные загрузочные образы в формате QCOW2 для архитектур amd64, arm64 и risc-v.
Налажено еженедельное формирование сборок для установки в Windows-окружении WSL (Windows Subsystem for Linux).
Уровень поддержки архитектур hppa (PA-RISC) и sparc, для которых у проекта отсутствует оборудование, переведён из категории стабильных в тестовые.
Включена поддержка локализации окружений на базе стандартной Си-библиотеки Musl (по умолчанию включён пакет sys-apps/musl-locales).
Добавлена возможность использования альтернативных реализаций OpenPGP. Кроме GnuPG доступны FreePG (набор патчей к GnuPG), Sequoia/Chameleon.
Добавлена возможность использования zlib-ng и
minizip-ng вместо zlib.
Для Portage создан сервер запуска сборочных работ Steve.
Переработан пакет с NGINX, из которого в отдельные пакеты вынесены модули.
Добавлен инструментарий для бутстрэппинга Rust, использующий только C++ и основанный на компиляторе mrustc. Добавлена поддержка бутстрэппинга Ada и D, используя GCC.
По умолчанию задействована версия Python 3.13. Добавлена опциональная поддержка Python 3.14.
Обновлены версии KDE Gear 25.08.3, KDE Frameworks 6.20.0 и KDE Plasma 6.5.4.
Введён в строй дополнительный сборочный сервер, позволивший ускорить формирование stage-сборок, бинарных пакетов, iso- и qcow2-образов.
Опубликованы результаты исследования времени обнаружения и устранения ошибок в коде ядра Linux. Данные получены в результате анализа исправления 125 тысяч ошибок, помеченных в Git-репозитории тегом "Fixes:", ссылающимся на коммит, в котором возникла ошибка. Среднее время обнаружения ошибок в ядре составило 2,1 года. Если рассматривать только ошибки, исправленные в 2025 году, данный показатель составил 2,8 года.
30% ошибок были исправлены теми же разработчиками, что и внесли ошибки. 56,9% ошибок устраняют в течение года. 13,5% ошибок оставались незамеченными более 5 лет (если рассматривать только ошибки, исправленные в 2025 году - 19,4%). Из-за неравномерности распределения медианное время существования ошибки в коде ядра составило 8 месяцев для выборки с 2005 года и 1 год для ошибок, исправленных в 2025 году.
Наиболее долго сохранявшейся в коде ошибкой стало переполнение буфера в ethtool, устранённое спустя 20,7 года.
Динамика обнаружения ошибок заметно отличается от среднего значения для некоторых подсистем, например, в драйвере шины CAN и стеке SCTP выявление проблем в среднем занимает около 4 лет, в
IPv4-стеке - 3,6 года, USB и TTY - 3,5, Netfilter и сетевом стеке - 2,9, VM - 1,8, GPU - 1,4, BPF - 1,1 года.
Время обнаружения коррелирует с типами ошибок: среднее время обнаружения ошибок, связанных с состояниями гонки, составило 5,1 года, целочисленным переполнением - 3,9, обращением после освобождения памяти - 3,2, переполнением буфера и утечкой памяти - 3,1, подсчётом ссылок - 2,8, разыменованием нулевого указателя и взаимными блокировками - 2,2 года.
В полученной статистике также прослеживается влияние внедрения новых инструментов для автоматизированного поиска ошибок, статического анализа и тестирования кода, таких как Syzkaller, KASAN, KMSAN и KCSAN. Например, в 2010 году не было зафиксировано исправлений ошибок, найденных в течение года. В то время, как в 2014 году в течение года выявлялось 31% ошибок, 2018 году - 54%, а в 2022 году - 69% ошибок.
Полученная статистика была использована для создания модели машинного обучения VulnBERT, позволяющей предсказывать наличие уязвимостей в коммитах. При тестировании на коммитах за 2024 год точность обнаружения ошибок составила 92,2% при уровне ложных срабатываний 1,2% (для сравнения, ранее доступная модель CodeBERT выявляла 89,2% проблем при уровне ложных срабатываний 48,1%).
Проект Loss32 развивает дистрибутив Win32/Linux, сочетающий ядро Linux с графическим окружением в стиле Windows, построенным на основе Wine и пользовательских компонентов ReactOS. Дистрибутив ориентирован на воссоздание среды рабочего стола Windows и предоставление средств для бесшовного запуска Windows-приложений, но при этом поддерживает и запуск традиционных Linux-программ. Первый прототип Loss32 планируют опубликовать в этом месяце.
По своим целям проект очень близок к ReactOS и также пытается воссоздать операционную систему в стиле Windows, но отличается от него отказом от использования ядра Windows NT. По мнению создателей Loss32, основным фактором, тормозящим разработку ReactOS, является попытка создания собственного аналога ядра Windows NT, что не позволяет добиться должной поддержки оборудования, стабильности и функциональности. В Loss32 решено сосредоточить усилия на создании среды запуска Windows-приложений, используя системное окружение на основе хорошо работающих Debian 13 и Wine.
В отличие от традиционных дистрибутивов Linux, в Loss32 компоненты пространства пользователя по возможности заменены на Wine, а среда рабочего стола базируется на приложениях и библиотеках Win32, таких как explorer.exe и shell32.dll от Wine и проекта ReactOS. В качестве композитного менеджера задействован Mutter. Оформление стилизовано под классический интерфейс Windows, применяемый с конца 1990-х по начало 2010-х годов. Система позволяет загружать и запускать exe-файлы с Windows программами так, как это делается в Windows.
На сайте репозитория AOSP (Android Open Source Project), в котором размещён исходный код платформы Android, появилось предупреждение об изменении схемы публикации кода, подразумевающей открытие нового кода Android только после очередного релиза. Содержимое AOSP отныне будет обновляться только два раза в год - во втором и четвёртом кварталах. Ранее Google практиковал ежеквартальную публикацию кода.
Вместо непрерывно обновляемой ветки "aosp-main" для создания сборок и разработки изменений рекомендуется использовать новую ветку "android-latest-release", которая отождествлена с состоянием кодовой базы последнего релиза Andrоid (например, сейчас это "android16-qpr2-release"). Изменение не повлияет на публикацию патчей с устранением уязвимостей, которые продолжат раз в месяц размещаться в ветках "android-security".
В качестве причин изменения упоминается желание обеспечить стабильность платформы для экосистемы Android и привести AOSP к модели разработки trunk-stable, что позволит упростить разработку Android, избавиться от необходимости поддержания нескольких веток и предоставить сторонним разработчикам более стабильный и безопасный код. Наличие раздельных внутренних и публичных веток приводило к накоплению различий по мере разработки релиза и необходимости тратить ресурсы на синхронизацию изменений и слияние патчей между разными ветками.
В прошлом году компания Google ограничила передачу в AOSP изменений, специфичных для устройств Pixel, а также перешла к разработке релизов за закрытыми дверями без публикации в AOSP промежуточных результатов.
До этого платформа развивалась с использованием смешанной модели разработки, при которой одни компоненты Android, например, Bluetooth-стек, система сборки, движок обновлений и фреймворк виртуализации, развивались публично, а другие - вначале создавались во внутреннем репозитории и раскрывались после релиза. В соответствии с новой моделью при разработке используется только внутренняя ветка, код из которой переносится в репозиторий AOSP в привязке к релизам.
