Russian Fedora

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

Параллельная загрузка пакетов в yum

Это архивная статья

Не прошло и десяти лет (проверьте по статистике коммитов), как yum научился одновременно скачивать больше одного пакета, о чем нам сообщил инженер чешского офиса Red Hat, Zdeněk Pavlas (напоминаем, что если вы все еще учитесь, то у вас есть возможность устроиться там на летнюю практику).

Помимо этого нововведения, yum получил один новый не смертельный, но эффектно выглядящий глюк, над устранением которого уже работает Zdeněk, и несколько изменений - измененный алгоритм выбора зеркала (при параллельной загрузке порой не очень много проку в скачивании нескольких пакетов одновременно с одного узла) и долгожданная поддержка Ctrl+C во время загрузки (раньше, из-за архитектурных ограничений было непросто "убить" yum, качающий пакеты с репозиториев, чему спустя некоторое время сумели придумать какое-то объяснение, сделав это фичей).

Выбросят ли из Phonon поддержку ALSA/OSS в пользу PulseAudio?

Это архивная статья

Участник Fedora и KDE, разработчик Phonon Trever Fischer предложил обсудить идею выбросить поддержку ALSA и OSS и полностью перейти на PulseAudio в модуле Phonon-Gstreamer. Разумеется, это изменение, даже если его примут, не затронет другие модули вывода.

Среди плюсов перехода Trever выделяет еще большую унификацию с Gnome, значительное уменьшение объема работы по поддержке и по дальнейшей разработке Phonon-Gstreamer, улушение общего качества модуля, т.к. при реализации поддержки ALSA/OSS внутри него, приходилось переделывать с ошибками то, что уже давно хорошо сделано в PulseAudio. В комментариях в целом отзывы очень хорошие, кроме традиционных жалобщиков с устаревшими Unix, которые используют Putty под Windows для работы со своими системами, и с маргинальными Linux-дистрибутивами, которые "настроили все под себя", и почему-то ожидают, что коммьюнити должно подстраиваться под их уникальную самосборную систему. Но для несогласных всегда будет вариант перейти на другой бэкенд или форкнуть. Конечно ничего еще не решено, и вы сами можете высказаться по этой теме в комментариях у Trever - он ждет вашего мнения.

Будет ли x32 архитектура в Fedora?

Это архивная статья

Недавно Canonical анонсировала, что в версии 12.10 будет поддержка архитектуры x32, о которой можно почитать здесь. Закономерно у участников Fedora возник вопрос - обсуждалась ли возможность включения этой новой архитектуры в Fedora? Незамедлительно были получены неутешительные ответы. Оказывается, что Canonical, как обычно в последнее время, не уведомила разработчиков о своих планах - Josh Boyer сообщил, что полной поддержки x32 еще нет в Glibc, и вероятно не будет до версии 2.16 (а уж только потом можно вести разговор о пересборке ПО). Также Matthew Garrett выразил сомнение, что "обычные пользователи" увидят хоть какие-то улучшения (а ухудшения они точно увидят, как всегда бывает с новой архитектурой).

Однако, если найдутся желающие, у которых будет достаточно квалификации, чтоб потянуть поддержку целой архитектуры, то это можно будет реализовать, как очередную "secondary arch".

Видеодрайвер openChrome использует EXA

Это архивная статья

С поддержкой видеокарт Via в X.org ситуация сейчас непростая - несколько конкурирующих видеодрайверов, каждый из которых поддерживает свой набор видеокарт, и находится в недописанном состоянии - chrome, написанный (вернее недописанный) участником проектов OLPC, Gentoo, Kernel и Fedora Daniel Drake, Unichrome, заброшенный основным разработчиком, бывшим инженером Novell и участником проектов X.org, Debian и Coreboot Luc Verhaegen и openChrome, форкнутый от Unichrome и разрабатываемый небольшой командой программистов, возглавляемой участником Fedora Xavier Bachelot.

Говорят, что в интернете можно найти еще два видеодрайвера - via, распространяемый на условиях "мне неинтересно мнение собак о костях, которые я им кидаю" компанией Via, и OpenVia, написанный кем-то из коммьюнити, и куски из которого то ли позже превратились в chrome, то ли ушли в openchrome, а то ли просто оказались никому не нужны. Похоже, что повторяется недавняя история с несколькими видеодрайверами для видеокарт ATI/AMD, когда одновременно существовали radeon, radeonhd и avivo, со слегка пересекающейся функциональностью и поддержкой моделей видеокарт, но в этот раз все осложняется отсутствием и следов интереса со стороны вендора, то есть Via, к OSS.

Тем не менее, некоторый прогресс наблюдается и тут. В то время, как драйверы chrome и unichrome медленно умирают, а via и openvia никто толком не видел, в openchrome заметны какие-никакие улучшения. Недавно Xavier анонсировал выход новой версии, в которой наконец-то осуществлен переход с устаревшей и удаленной из X.org системы ускорения XAA на EXA и кое-какие иные улучшения. Пока состояние драйвера далеко от совершенства, но пусть будет хоть так, чем вообще никак.

В Fedora включен пакет xorg-x11-drv-openchrome предыдущей версии, но Xavier оперативно включал в него все значительные патчи из git-репозитория, так что его состояние очень близко к текущему актуальному релизу. Полагаем, что он скоро пересоберет пакет, проапгрейдив его до последней версии.

Несовместимые изменения в API драйверов X.org

Инженер Red Hat и участник Fedora и Debian David Airlie продолжает вносить улучшения в X.org API. В своей ленте на Google+ блоге он анонсировал несовместимые изменения в API драйверов X.org, которые скорее всего поломают работу проприетарных драйверов (а может и нет - мы не в курсе планов AMD и NVIDIA относительно их проприетарного ПО). Новость опубликовали на Phoronix, и ее уже обсуждают ведущие аналитики русскоязычных интернет-ресурсов о Linux.

Мы уже скупо обрисовали неприглядную картину нынешнего состояния с открытой видеоподсистемой в Linux - X11 устарел, Wayland еще минимум полгода (оптимистичная оценка) - год (более реалистичная) - полтора (пессимистичная) будет малопригоден для "обычного пользователя" (что бы это ни значило). Фронт работ сильно растянут - от модулей ядра, до высокоуровневых кроссплатформенных библиотек, - места должно хватить всем. В этой связи нам стало очень грустно, когда до нас дошли слухи, что Canonical, с ее ограниченными трудовыми ресурсами, и лидер которой регулярно признается, что им неинтересно заниматься низкоуровневой работой (все, кроме нескучных обоев, оптимизации элементов управления на экране - слева или справа, и т.п.), обсуждают перспективу "форкнуть" Wayland, чтоб адаптировать его к проприетарным видеодрайверам. Мало того, что уже сейчас очевидна непосильность работы для них, так еще она и полностью бесполезна OSS-коммьюнити, которое делает ставку на открытые технологии (и открытые драйверы). Canonical уже собрались форкать Gnome Control Center, так зачем взваливать на себя еще и этот сизифов камень? Это, конечно, не первый раз, когда малочисленное сообщество разработчиков Ubuntu самоизолируется от основного потока разработки в upstream - так было и с Unity, которое базируется на форкнутых библиотеках GTK/GNOME, что мешает его включению куда либо, кроме Ubuntu (мы об этом не раз уже говорили).

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

Переключающаяся графика скоро в Linux!

Это архивная статья

По прошествии четырех лет инженер Red Hat и участник Fedora и Debian David Airlie и инженер AMD и участник Debian Alex Deucher представили патчи для поддержки GPU offloading для Intel, NVIDIA и ATI видеокарт с помощью технологии DMA-BUF/PRIME. Ожидается поддержка в видеодрайверах для ARM-платформ.

Расскажем немного историю вопроса и начнем с самого начала. Как вы знаете, прямо сейчас на замену старой доброй технологии из 1987 года, X11 (X Window System), разрабатывается некий Wayland (мы о его развитии периодически пишем).

Хейтеры, как и в случае с systemd, изливаются потоками ненависти, но, опять-таки, как и в случае с systemd, очень подозрительно, что признанные специалисты отрасли приветствуют изменение, а анонимные аналитики Linux-ресурсов ругают. Это, разумеется, ничего не доказывает, но дает повод для раздумий. Так вот, мало кто представляет, насколько убог и насколько уже устарел X11. А вы знаете, что в нем в принципе нет прозрачности (зато есть сетевая прозрачность!), нет OpenGL (есть с помощью расширения протокола, но это не работает по сети), нельзя создавать непрямоугольные (например, овальные) окна, нельзя поворачивать их на произвольные углы, несмотря на рассказы про сетевую ориентированность, невозможно отключиться от сессии, а потом подключиться заново - хороша "сетевая прозрачность", не учитывающая пропадания сети! А знаете ли вы, что DRI был придуман специально, чтоб бороться с сетевой моделью иксов? А вы в курсе, что еще в конце 1990x считалось, что графическая подсистема в Linux быстрее, чем в Mac OS и Windows? Вот только с тех пор конкуренты изменялись под стать изменениям оборудования и запросам пользователей, а иксы так и застряли с моделью развития из 1987 года ("хуже == лучше", "вместо реализации фичи добавь возможность пользователям приделать костыль на скорую руку" - это не шутка, это действующие руководящие принципы модели X Window System). X-server в Linux не может работать не от root, сетевая прозрачность выродилась в перекачку битмапов по сети кроссплатформенными графическими тулкитами.

Почти никогда X11 на современных компьютерах не работает, как X11 - используются различные ухищрения, такие, как SharedMemory и DRI, чтоб обойти "тру-юниксвэйные иксовые" процедуры записи пиксмапов в unix-сокет и записывать их прямо в память видеокарты, в обход юниксвэйности. API X11 (Xlib) тоже не является эталоном - мы не будем говорить об его синхронности, т.к. асинхронность в X11 критиковалась еще специалистами DEC, и, видимо, тут есть невидимые для нас, как для неспециалистов, некие проблемы в обоих подходах. Ну а вы в курсе, что в Xlib все ошибки по умолчанию фатальные и приводят к закрытию приложения? Например, использование некоторыx функций MIT-SHM в X11-приложении, запущенном по сети, очень вероятно, что закончится ошибкой и вообще не позволит вам запустить его.

В общем, с API можно что-то сделать, но, как и в случае с заменой init-системы, в живой процесс развития мертвой хваткой вцепились полумертвые монстры из прошлого (можно смело предполагать, что процесс адаптации Wayland также будет сдерживаться устаревшими Unix-системами и FUD-ом, распространяемым представителями маргинальных Linux-дистрибутивов). Более того, современные приложения используют d-bus, а он совершенно несетепрозрачный, и приложение, активно его использующее, не сможет работать правильно по сети (удивительно, но никто из пользователей KDE этого не заметил до сих пор - видимо сетевая прозрачность давно уже "не нужна"). Пора сказать открыто - архитектура иксов более не соответствует требованиям времени, и ее необходимо менять.

Процитируем Julien Danjou, участника проекта Debian, X11-разработчика и автора Awesome: It's likely impossible to fix X11 (properly). But there's no reason to keep X. ...I don't think anybody should do X specific programming nowadays anyway. People should stop writing window managers, now, seriously. If they really want to work on this kind of low-level things, yes, I think putting effort in Wayland is better, so it happens. Одной из проблем, которую практически невозможно оказалось решить в рамках действующей архитектуры X11 (понадобилось почти четыре года во времени которых было предложено несколько подходов, все, кроме одного, оказавшиеся тупиковыми путями), это то, как использовать несколько видеопроцессоров (например, SLI или CrossFire - две связанные видеокарты, работающие в параллель, либо вспомогательная видеокарта, включающаяся, когда не хватает электропитания, либо USB-видеокарта, периодически подключаемая и отключаемая). В Wayland изначально учитывается то, что и видеовыходы, и видеопроцессоры, и устройства ввода будут динамически подключаться и отключаться, а в X11 оказалось, что костыль на это не так то и просто прикрутить.

Проблему озвучил инженер Red Hat и участник Fedora и Russian Fedora (проверьте по статистике коммитов на Ohloh!) Adam Jackson еще в конце 2008 года, признав, что решение будет непростым. Прямая речь: "Getting this to work well should actually be a lot of fun, and there's lots of opportunity to sweep away old bad design and come up with something good.". Какие-то костыли для исправления ситуации с работой нескольких видеокарт в видеодрайверах были предложены спустя год-полтора. Сначала David Airlie написал в 2010 году vga_switcheroo, который позволял перезапускать иксы, выбирая видеокарту. Это решение, несмотря на его очевидную кривизну, реально использовалось в Ubuntu и Gentoo (жить ведь как-то надо), но оно не работает с проприетарным драйвером NVIDIA. Для этих карт, в т.ч. и для открытого видеодрайвера, было предложено иное решение (тоже основанное на перезагрузке иксов, но невидимое для пользователя - на более мощной видеокарте запускается свой, отдельный X-сервер, изображение с которого "проксируется" на X-сервер, постоянно запущенный на слабой видеокарте) - Bumblebee, прославившееся фееричным багом, уничтожавшим директорию /usr. Eсли б они использовали пакетный менеджер и собирали бы его в пакет в изолированном окружении, и не от root, то этот баг не отразился бы на столь огромном количестве наивных пользователей Ubuntu, которые привычно ставят не глядя самое различное ПО откуда попало, но там весь проект страдает от проблем с software engineering, как обычно в наколеночных проектах.

Вскоре к решению проблемы (написанию очередного костыля для иксов - иксы состоят из костылей, повторимся, и это полностью соответствует их философии) привлекли тяжелую артиллерию - инженеры самых разных компаний начали думать, как обойти это ограничение устаревших X11? После завершения поигрушек с vga_switcheroo David Airlie предложил proof-of-concept нового подхода, который он назвал PRIME - GPU offloading. Суть в том, что одна, например менее прожорливая электрически, видеокарта работает всегда, а иногда она будет передавать задачи на обработку более мощной видеокарте.

Это уже было что-то. Правда, из-за ограничений X11 требовалось, чтоб драйвер видеокарты знал о драйверах для других видеокарт. Процитируем Airlie: "To make this as good as Windows we need to seriously re-architect the X server + drivers..." Еще через год, в конце 2011, David Airlie успешно продемонстрировал GPU offloading на примере подключения на лету USB-видеоадаптера DisplayLink.

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

Примерно в это же время инженеры Linaro, Samsung и Texas Instruments предложили первый вариант того, что они назвали DMA-BUF, технологии для совместного доступа к памяти различных видеоустройств - V4L, X11, видеокамеры и т.п., которая позволит при обмене данными между этими устройствами вместо пересылок огромных серий байтов в ядро и обратно просто обмениваться адресами этих данных. David Airlie быстро оценил перспективность такого подхода, и следующий релиз своего PRIME уже выпустил, основанный на DMA-BUF. Темпы внедрения ощутимо ускорились, и последним куском мозаики был VGEM, представленный Adam Jackson, который позволит использовать различные DMA-BUF оптимизации устройствам, не имеющим DRM-драйвера (LLVMpipe). Все было готово - осталось лишь замотать все изолентой.

И вот, наконец, возвращаемся к первому абзацу. David Airlie и Alex Deucher собрали все куски вместе, и теперь ничего не останавливает Open Source коммьюнити от написания патчей для поддержки SLI/CrossFire или Optimus. Заметьте, как тяжело становится догонять проприетарные видеоподсистемы, нескованные цепями стандартов прошлого.

Что до Wayland, то говорить не о чем, т.к. в нем все это и так будет работать из коробки. Когда его допишут, разумеется - ждем, надеемся и верим! А пока почитайте Wayland anti-fud от того разработчика Collabora, который переносит Wayland на Android, о чем мы уже говорили.

Встречайте новый компонент системы - printerd

Это архивная статья

Tim Waugh, участник Fedora и инженер Red Hat, объявил, что он и Richard Hughes, инженер Red Hat и участник проектов Fedora, Gnome и RussianFedora, завершили работу над новым компонентом Linux-десктопа. Встречайте - printerd. Это новый spooler печати, созданный с учетом d-bus. Так как это фактически очередь объектов, отправленных на печать, то он не является заменой CUPS, а дополняет его.

Пока особо подробностей нет, но мы уверены, что они скоро последуют.

Summer Internship in Red Hat

Чешский филиал Red Hat в очередной раз приветливо открывает двери перед студентотой и школотой в летнее время. Так-что если вы считаете, что лето, солнце, море, любовь и танцы - это слишком скучно, и ваше сердце радостно трепещет от мерного гула любимого дата-центра, в котором при приятно низкой температуре романтически воют такие родные блэйд-сервера, с такими давно знакомыми отпечатками SSH-ключей, то рассмотрите вариант. Итак, вы...

  • Говорите на английском на уровне "гиды в Турции понимают меня"?
  • Считаете, что systemd - не слишком радикальное изменение, и в Линуксе надо менять больше?
  • Программируете на Bash, Perl и Java?
  • Устали пересобирать ядро локалхоста и подбирать USE-флаги и хотите пересобирать ядра Лондонской Фондовой Биржи?
  • Все еще учитесь?
  • Хотите поработать в компании матерых упырей-нердов? См. "stop reopening".

Если ответ, "да", то попробуйте присоединиться! До конца мая будут открыты следующие позиции:

  • Development Engineering (C/Python/Ruby/Ruby on Rails/Perl)
  • Quality Assurance Engineering (Python/Bash/Perl)
  • JBoss Quality Assurance Engineering (Java)
  • JBoss Engineering (Java)
  • Kernel Development Engineering (C)
  • Support Engineering (good English, admin)

Хватить сидеть в песочнице. Попробуйте по-взрослому!