Russian Fedora

cообщество русскоязычных участников
международного проекта Fedora

Материалы с GNU Tools Cauldron 2017

AAC кодек включают в Fedora

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

Включена будет модифицированная версия известной библиотеки - Fraunhofer FDK AAC в версии для Android, которая, что интересно, в немодифицированном виде участниками Fedora рассматривается, как несвободное, хотя и открытое ПО. Учитывая, что и про конкретные поддерживаемые возможности модифицированной библиотеки явно ничего сказано не было, видимо изменить пришлось много. Также сразу будет включен плагин для GStreamer.

Когда время перезагрузки имеет значение или почему IBM использует CRIU на мейнфреймах

Как вы уже слышали, в CRIU включили поддержку архитектур IBM. Наши друзья из компании Parallels решили объяснить, зачем это нужно IBM вообще.

Когда время перезагрузки имеет значение или почему IBM использует CRIU на мейнфреймах

В современном мире, когда светлое будущее прочат микросервисам, кажется странным заниматься технологиями, которые помогают обновлять код без перезагрузки. Ведь микросервисы и контейнеры куда проще «убить» и создать заново. Тем не менее, мы продолжаем работу над системой живой миграции CRIU, и нам в этом активно помогают ребята из IBM. Почему? Попробуем объяснить.

/images/criu-ibm-1.jpg

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

Для всех очевидно, что системы, которые долго запускаются и разогреваются, не должны перезагружаться слишком часто, а лучше всего – чтобы они и вовсе никогда не перезагружались. И чем мощнее система, и чем больше от неё зависит микросервисов, тем менее выгодной выглядит остановка ее работы с целью перезагрузки. Одним из примеров решения подобной задачи является технология ReadyKernel, которая позволяет устанавливать обновления хостовой ОС Linux, на которой работает множество виртуальных машин и контейнеров, без ее перезарузки. Другое решение для снижения простоев различных сервисов предлагает наш проект CRIU.

CRIU становится стандартом

Несмотря на те сомнения, которые встретили CRIU на этапе становления этого OpenSource инструмента (впрочем, впервые выступившего с планшетом Гейтса тоже подняли на смех), сегодня CRIU интегрирован в контейнеры OpenVZ, Docker, LXC, CoreOS; входит в дистрибутивы Linux Ubuntu, Debian, OpenSUSE, Altlinux и ряд других, а также поддерживается разработчиками из разных компаний, включая IBM. Кстати, любопытно, что именно «Голубой гигант» сделал один из самых масштабных вкладов в CRIU – сегодня инструмент работает сразу на нескольких платформах: x86_64, ARM, aarch64, PPC64 и s390. И две из них – PowerPC64 и s390 – являются детищами IBM. О поддержке инструмента на последней был объявлено буквально летом 2017 года.

/images/criu-ibm-2.jpg

Для того, чтобы объяснить, почему крупнейшей компании в области разработки аппаратных платформ и ПО требуются такие инструменты, нужно немного вникнуть в суть самого проекта. CRIU позволяет «заморозить» приложение, чтобы запустить его потом на другом хосте или в другом контейнере. При правильном применении этого инструмента, приложение не должно даже догадываться о том, что его переместили, продолжая работать, как ни в чем не бывало. Как уже говорилось, это совершенно не нужно микросервисам, но оказывается очень полезно для тех задач, которые решают в том числе на мейнфреймах.

/images/criu-ibm-3.jpg

Микропроцессорная архитектура для высокопроизводительных серверов s390 является уникальной, IBM развивает ее в своей линейке мейнфреймов. Многопроцессорные и многопоточные системы позволяют работать с огромными массивами данных, что накладывает свои особенности на архитектуру ОС и приложений. Летом 2017 года в CRIU пришли патчи от разработчиков из IBM, которые делают возможным использовании CRIU на s390. Дело в том, что CRIU представляет собой низкоуровневый инструмент, его код близок к коду ядра, и поэтому требуется его адаптация к каждой новой архитектуре. Чтобы CRIU начал работать, нужно было реализовать поддержку платформенно-специфических функций. От простого к сложному разработчики IBM обеспечили поддержку системных вызовов, собственных типов данных, описателей виртуального адресного пространства процессов, добавили нужные настройки компилятора, образы для регистров, нужные трамплины для паразитного кода, который мы внедряем в процесс для его «заморозки», а также архитектурную специфику типа TLS/GOT. Познакомиться с содержанием проделанной работы можно здесь:

     #include "common/asm/linkage.h"
     .section .head.text, "ax"
     /*
     * Entry point for parasite_service()
     *
     * Addresses of symbols are exported in auto-generated criu/pie/parasite-blob.h
     *
     * Function is called via parasite_run(). The command for parasite_service()
     * is stored in global variable __export_parasite_cmd.
     *
     * Load parameters for parasite_service(unsigned int cmd, void *args):
     *
     * - Parameter 1 (cmd) : %r2 = *(uint32 *)(__export_parasite_cmd + pc)
     * - Parameter 2 (args): %r3 = __export_parasite_args + pc
     */
     ENTRY(__export_parasite_head_start)
     larl %r14,__export_parasite_cmd
     llgf %r2,0(%r14)
     larl %r3,__export_parasite_args
     brasl %r14,parasite_service
     .long 0x00010001 /* S390_BREAKPOINT_U16: Generates SIGTRAP */
     __export_parasite_cmd:
     .long 0
     END(__export_parasite_head_start)

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

И это касается не только мейнфреймов. Участие IBM в проекте CRIU не ограничивается архитектурой s390. Несколько лет назад мы получили от IBM патчи для поддержки PPC64. Эти решения IBM предназначены для рабочих станций и серверов «попроще» — не мейнфреймов. Но самый интересный вклад, который разработчики IBM внесли в проект CRIU – это технология «ленивой миграции».

/images/criu-ibm-4.jpg

Происходит это следующим образом: контейнер перемещается с одного хоста на другой без содержимого своей памяти. Такой подход позволяет на порядок сократить размер образов, и он очень эффективен для тех приложений, которые держат в памяти огромные массивы данных. Например, если мы говорим о JVM, её полный образ может занимать десятки мегабайт (и это без учёта той памяти, которую выделит себе работающая в ней программа), в то время как его размер без содержимого памяти составит несколько десятков килобайт. Благодаря этому миграция происходит в разы быстрее, снижая паузу в работе. Суть того, что делают дополнения от IBM заключается в возможности обеспечить удаленный доступ к памяти и ее асинхронную миграцию при необходимости.

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

Заключение

Расширенная поддержка проекта CRIU позволяет говорить о том, что сегодня каждый разработчик может использовать возможность «заморозки» и «живой миграции» приложений уже на 5 различных архитектурах. Вклад IBM в развитие проекта позволил не только использовать возможности CRIU на мейфреймах и серверах PPC64, но применять механизмы «ленивой миграции» на других платформах.

Более того, происходящие изменения сподвигли нас на создание отдельной библиотеки Compel, которая позволяет заражать процессы паразитным кодом, заставляя выполнять определенные инструкции. Сегодня Compel используется в проекте CRIU, а также в новой системе живого патчинга приложений. О ней и о самой библиотеке Compel мы расскажем в следующем посте.

Новая обучалка по SELinux

На Fedora Magazine опубликовали очередную обучалочку по SELinux. В целом ничего особенно нового, но основные случаи покрываются. Напомним, обычно проблемы с SELinux вызывают проприетарные компоненты, такие как Skype или запущенные в Wine программы для Windows. Штатное ПО из основных репозиториев, как правило, проблем не вызывает, хотя бывает по-всякому.

Насчет проприетарного - у нас опять проблема с закрытыми видеодрайверами NVIDIA и ядром 4.13. Хорошо, что никто ими не пользуется!

Книга по PulseAudio

Если вы, в отличие от анонимных аналитиков, пока еще не разбираетесь в архитектуре и принципах работы PulseAudio, но очень хотели бы, то для вас есть хорошие новости! Наш соотечественник, Victor Gaydov, опубликовал многостраничный документ - PulseAudio under the hood, в котором попробовал рассказать о внутреннем устройстве PulseAudio. В отличие от большого количества подробных или не очень хаутушек, Victor изложил свои мысли в формате книги, учебника.

Если вы работаете с мультимедиа-приложениями, или просто интересуетесь устройством подсистем линукса, то ознакомьтесь. Книга - хороший кандидат на настольную.

Новая мультимедийная подсистема - PipeWire

Наш коллега, Christian Schaller, официально объявил о выходе новой мультимедийной подсистемы, PipeWire. Это будет аудио/видеосервер, который в будущем заменит Pulseaudio, расширив его возможности на видеопотоки (и вообще произвольные мультимедиа-потоки).

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

Сервер будет доступен в Fedora 27, но пока в параллель с Pulseaudio.

Новые патентные обязательства от Red Hat

Как вы знаете, в США и Южной Корее возможно патентовать алгоритмы, абстрактные идеи, и бизнес-процессы. Сообщество открытого ПО всячески борется с этой токсичной и вредной для гражданского общества коррупционной технологией, но, будучи прагматиками, мы понимаем, что пока закон не удалось сменить, то надо ему подчиняться.

В любой софтверной компании, работающей в США, рано или поздно появляется патентный пул, в котором находятся документально подтвержденные свидетельства о приоритете в додумывании той или иной абстрактной идеи, зачастую не имеющей реализации (например, недавно в США выдали патент на телепорт в/через параллельные миры, и теперь те, кто придумают телепорт, по законам США будут вынуждены платить дань некоему коррупционеру). Этот патентный пул, как правило используется исключительно в целях юридической защиты компании от судебных исков других компаний. Если на тебя нападает конкурент, например, с помощью патента на защелку в деревенском сортире (изобретение Apple), то ему можно предложить обменяться патентами из патентных пулов, и отказаться от иска. Если у тебя нечего предложить, то будь добр плати рэкетиру за крышу, как это делают почти все производители Android-телефонов, выплачивая значительные суммы Microsoft, лишь чтобы не ставить Windows Mobile на свои телефоны вместо Android.

Red Hat, разумеется, обладает своим патентным пулом, и также регулярно выступает на стороне своих клиентов в патентных побоищах в США. Но Red Hat в 2002 году пообещала не использовать патенты из своего пула против свободного ПО, и, таким образом, позволила реализовывать запатентованные идеи. Пункт "свободное ПО" был неоднозначен, и в самых строгих трактовках, включал чуть ли не только ПО, выпускаемое под GPL. И вот, компания официально объявила, что значительно расширяет защитный зонтик своей патентной системы ПРО.

Hовое публичное обещание покрывает все открытое ПО, лицензированное под одной из лицензий, одобренных FSF или OSI. Указав явно критерии, компания расширила зону покрытия с примерно 35% до 99% всего открытого ПО, подтверждая свою приверженность развитию открытого ПО и технологий, и идеалам открытого общества.

Новости Java

В последнее время все отдают свои Java-проекты в Eclipse Foundation. Сначала Red Hat передала им свой Ceylon, затем в Oracle решили отдать их Java EE туда же, и вот теперь еще и IBM тоже передали их самодельный JVM под названием OpenJ9 в Eclipse. Положительная динамика!

Простая перезаливка исходников не решит проблем с управлением разработкой, которые обязательно существуют в старом корпоративном проекте, и даже тут есть улучшения! Было предложено полностью изменить процесс выпуска новых версий в пользу более частых релизов, как это сейчас модно. Учитывая, что недавно достигли консенсуса по поводу модуляризации в Java 9, по поводу которой долго спорили, то можно ожидать заметного улучшения и оздоровления в развитии языка и его экосистемы.

Правда вот на Phoronix уже потестировали дар от IBM, и пока что-то не впечатляет. Не особо получился подарочек.