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

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

В результате простой переход на базу с SQL-языком резко ускорил процесс:

# Было
$ time grep -E ^tex /var/cache/dnf/available.cache
real    0m0.112s
user    0m0.017s
sys    0m0.043s

# Стало
$ time sqlite3 packages.db "select pkg from available WHERE pkg LIKE \"tex%\";"
real    0m0.018s
user    0m0.008s
sys    0m0.010s

Теперь автодополнение при установке пакетов просто летает!

Исправил и это (раз и два), что тоже привело к заметному ускорению. Разработчик схватил идею на лету, и оставшиеся проблемы исправил уже сам.

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

Новость чуть не прошла мимо, хотя ее уже озвучили на всех ведущих Linux-сайтах. Любители systemd создали обучающий видеоролик о нем.

Коллеги-аналитики уже справедливо критикуют реализацию идеи за технические и организационные огрехи, но мы тут руководствуемся мудрым принципом "Сперва добейся!"

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

Наш коллега, Nick Clifton, обратил наше внимание, что спустя год после анонса начала работы, в GCC появился offloading.

Функционально, это реализовано так - фрагменты программы при сборке GCC транслируются в промежуточное представление и передаются дальше, на (до)сборку некоторому другому компилятору или компиляторам. Полученное потом встраивается в итоговый бинарник, который при запуске и исполнении передаст инородный кусок кода на некий другой доступный вычислительный узел (например, программа начнет выполняться на CPU, а часть передаст на выполнение на GPU). Пока поддерживается offloading для архитектуры Intel MIC, но уже можно предсказывать появление других вариантов.

Что особенно приятно, так это то, что работа проведена соотечественниками из российского филиала Intel - Michael V. Zolotukhin (ныне инженер Apple), Ilya Verbin, Kirill Yukhin и еще некоторые стесняшки, не имеющие публичных профилей в популярных среди разработчиков социальных сетях Google+, LinkedIn и GitHub. Молодцы, соотечественники! Интересно, что до появления LLVM, без упоминания которого сейчас уже невозможно рассказать о, наверное, самой популярной гибридной вычислительной модели - нативный код + OpenCL, манипуляции и прямой доступ к промежуточному представлению GCC не поощрялись. Конечно, добраться до внутренностей GCC было можно, что и сделали в том же проекте GCC-XML, но это было непросто, и помощи от сообщества вряд ли стоило ожидать. Мы стараемся сторониться политических тем, пока эти темы нас не затрагивают, но мы слышали, что дело было именно в политике. В народе говорят, что некоторые разработчики и идеологи проекта GNU всерьез опасались, что если сделать промежуточное представление GCC доступным к использованию, то embedded-вендоры перестанут открывать спецификации на свои архитектуры, предпочитая вместо этого предоставлять клиентам проприетарные модули для использования совместно с GCC. Году в 2002 эти рассуждения, наверное, выглядели вполне обоснованно, но с тех пор прошло много времени, и производители микропроцессоров теперь начинают с того, что пишут поддержку своей архитектуры в GCC. Хотя, конечно, может такая их открытость сегодня и является следствием пугливых решений проекта GCC того времени, теперь уж и не узнаешь.

На 20 ноября запланирован тестовый день Fedora Atomic. В его рамках будет проведено тестирование самых наипоследнейших Linux-технологий - Project Atomic и Kubernetes.

К сожалению, тестирование потребует наличия развернутой облачной системы (мы рекомендуем OpenStack, но подойдут и конкурирующие решения), что, конечно, отсекает от участия в тестирования некоторых добровольцев. Но если у вас есть поблизости облачная система, то можете начинать готовиться, чем уже занят наш коллега, Joe Brockmeier.

Кстати, это последний из запланированных тестовых дней.

Объявлено место проведения конференции Flock 2015.

В отличие от Flock 2014, эта конференция будет проведена не в Европе, а в США, в Rochester Institute of Technology.

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

На этот раз мы немного запоздали с Beta версией. Почти на две недели позже. Но ничего страшного. На этот раз Beta версия уже почти совсем похожа на релиз. GNOME так вообще вылечился от детских проблем. Перестал крашится на двухмониторных конфигурациях и стал вполне себе стабильным.

Также как и Chromium.

Итак. RFRemix включает GNOME 3.14(.2), KDE 4.14(.3), Firefox 33.1, ядро 3.17, LibreOffice 4.3.2.2.

Что нового

1. Пакеты, в которых изменено брендирование на RFRemix, вынесены в отдельный репозиторий branding.

   В fixes остались лишь пакеты с багфиксами различными патчами (например fontconfig и freetype). Поэтому для обновления 20-й версии через команду yum --releasever=21 distro-sync необходимо сперва установить пакет russianfedora-branding-release (#1385);

2. Исправлена проблема с нелокализованным дисплейным менеджером sddm (сборка KDE);

3. Исправлено имя продукта, чтобы можно было отправлять ошибки в Bugzilla через abrt;

4. Установочного образа DVD больше нет, есть только образ с сетевой установкой.

Загрузка

• Установочные диски [ i686 ] [ x86_64 ]
• Образы Live [ i386 ] [ x86_64 ]
• Торренты [ i386 ] [ x86_64 ]

Релиз намечен на конец года. Ошибки можете сообщать в багтрекер redmine.russianfedora.pro или jabber-конференцию fedora@conference.jabber.ru.

На следующей неделе будет также выпущен RFRemix 20.1.

Подведены итоги очередного опроса пользователей OpenStack.

Как и в предыдущем опросе полугодовой давности интересных фактов очень много, и остановимся лишь на самых важных.

Начнем с того, на базе какого дистрибутива строятся решения:

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

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

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

Любители юниксвэя изгоняют из Debian очередного участника

Интересно, но даже Windows обогнал Debian. Несмотря на юридическую опасность использования Windows в облаках, когда без консультации профессионального юриста совершенно непонятно, что же в результате можно, а что нельзя делать с вендой, на ней реализуют проекты в значительных количествах.

Увы, но в список не попали новые игроки на рынке - CoreOS, OSv и прочие. Видимо пока народ опасается экспериментировать очень уж по-серьезному. Ну посмотрим - идея тонкой системы для контейнеров довольно популярна.

Интересна разбивка по странам, в которую впервые заскочила и наша Россия:

Мы пока уступаем таким развитым технологическим державам, как Бразилия и Голландия, но в целом, учитывая количество специалистов, можно ожидать продолжения подъема России в рейтинге. Если, конечно, не примут какого-нибудь очередного деструктивного для айти-отрасли закона. Но тогда мы, как обычно, просто переведем облачные ресурсы в страны с положительным отношением к айти - Прибалтика, Голландия. Конечно, в США было бы интереснее, но порой надо учитывать латентность каналов.

Переходим к виртуализационным решениям:

Ничего необычного - доминирует Qemu/KVM. Вторым, что интересно, идет VMware, и обратите внимание на лесенку экспериментируем-тестируем-продакшен. Это либо разочарование в гипервизоре, либо рост интереса - следующий опрос покажет точнее. А вот что уже видно, так это крушение интереса к платформе Xen. Мы все ждем обещанного нам в приватной беседе, ухода с Xen одного из больших пользователей. Видимо у него слишком большая инфраструктура, чтоб переход случился быстро.

Далее хранилища.

С прошлого опроса LVM сильно сдал в пользу Ceph и даже GlusterFS. Пока не сбывается предсказание, что *"any distributed filesystem like GlusterFS or Ceph that tries to preserve the POSIX API will go the way of the dodo bird"*.

Сетевая подсистема, в отличие от блочных устройств, радует разнообразием вариантов:

Способов развертывания тоже много:

Опять непонятно, что выбирать - Chef или Puppet. Понятно, что развертывание облачной системы, это как раз проще заменяемая штука, чем, например, блочное устройство, и тут экспериментирует народ смелее.

В результатах опроса еще много чего интересного - сходите по ссылке и посмотрите. Да, опрос будет постоянно открыт, и его итоги опять подведут в следующем году, весной, так что поучаствуйте сами.

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

Гентушник и бывший инженер Collabora, Arun Raghavan в своем блоге подводит итоги PulseAudio Mini Summit 2014, прошедшего недавно в Дюссельдорфе. На миниконфе обсуждали разные вопросы - скорый выход версии 6.0, более тесная интеграция с systemd, переход на kdbus + memfd и отказ от rtkit, Hi-Fi-режим (без ресэмплера), более качественный ресэмплер, и многие другие.

Инженер Collabora, Michael Meeks, в своем блоге рассказывает о поддержке OpenGL в LibreOffice версии 4.4.

Надо отметить, что до недавних пор с OpenGL в линуксе было не очень хорошо, но в последние несколько лет начало улучшаться. Например, недавно добавили поддержку OpenGL в GTK.

Модернизация с помощью перехода на современные технологии, такие, как systemd, и отказа от устаревшего груза в виде поддержки игрушечных ядер, вдохнула свежие силы в давно позабывшее, что такое инновации, коммюнити Debian. Matthias Klumpp, участник проектов Debian и GNOME, предложил еще один вариант кросс-дистрибутивного инсталлятора пакетов, Limba.

Напоминание для коммьюнити Debian И напоследок еще одна новость - разработка golang переводится на Git и перемещается на GitHub.

Напомним, что недавно на Git перешел Emacs, так что ждем и других. Коллеги-аналитики уже обсуждают новость на OpenNET.ru и Linux.org.ru, и задают вопросы, мол почему на Git, и почему на GitHub. Последний вопрос нас удивил - неужели кто-то еще не в курсе, что Code.google.com скоро закрывают?

Lennart Poettering выложил очередную статью из серии "systemd для администраторов". В этот раз она посвящена запуску приложений в контейнерах, и управлению контейнерами из systemd. К сожалению, строгое следование принципам Unix-way разработчиками systemd не позволило включить им туда еще и управление устройствами хранения, и создания rootfs, и пока тут мы проигрываем по функциональности Docker.

Приложения в изолированных контейнерах ведут себя хорошо!

Red Hat анонсировал выход RHEL 7 Atomic Host. Как правильно отметили коллеги-аналитики на OpenNET.ru, это ответ на растущий запрос на тонкую платформу для запуска контейнеров в облаках. Т.е. мы запускаем Atomic Host в облаке, а уж в нем запускаем контейнеры. CoreOS напрягся.

Paolo Bonzini опубликовал статью по мотивам выступления (слайды и видеозапись) Andrew Honig на KVM Forum 2014, с обзором текущей ситуации с безопасностью KVM, и ведущимися работами по ее улучшению. Статья пока за paywall.

Анонсировали новое средство мониторинга контейнеров, BoxSpy, уже традиционно написанное на Go. Не будем по существу комментировать необходимость в еще одном средстве мониторинга на рынке, но кое-что скажем. Уже видно, что продвижение контейнеров (т.е. Docker) "сверху", со стороны "frontend-разработчиков на Ubuntu", привело к тому, что многих вещей либо вообще нет, либо о том, зачем и как их делать, популяризаторы и евангелисты Docker просто не знают. Так что мы еще увидим довольно много решений, аналоги которых в мире "бэкенда" существуют уже давно.

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

Интересно, что появление контейнеров (и, в частности, их популяризация через использование Docker) привело к возврату интереса к предложениям bare-metal платформ, необлачных, о чем пишет в своем блоге инженер eBay, Subbu Allamaraju. Если вкратце, то возможности Docker привели к тому, что облачные решения, предоставляющие VM и ничего больше (generic VM orchestration, load-balancing, monitoring etc), чувствуют или скоро почувствуют серьезное снижение интереса. Дело в том, что решение сложных задач, как правило, само по себе сложное, и generic-предложения по балансировке нагрузки на уровне машин не лишают пользователей этой сложности (просто разброс по машинам не дает business value - его приходится реализовывать самостоятельно).

А пользователи уже требуют решения по балансировке не снизу, со стороны оборудования, что предоставляется в уже известной облачной парадигме "pets vs cattle", а сверху, со стороны бизнес-логики, от "frontend-разработчиков на Ubuntu". Это раскладывается в совершенно другие архитектурные схемы, которые иначально не гомогенны, а гетерогенны. Облачная среда с тысячами VM, плавающими по блэйд-серверам внутри датацентров в моменты изменения нагрузки, как нарисована на слайдах во множестве презентаций, разбивается о саму физическую структуру современных датацентров, где до сих пор есть выделенные стойки с хранилищами, вычислительными узлами нескольких типов (дешевые и дорогие, как минимум), разбитые по изолированным кластерам сообразно с различными нетехническими бизнес-соображениями, с проприетарными системами управления трафиком и т.п. Контейнерные приложения, изначально гетерогенные плохо кладутся на подобную систему. Хотя сейчас облачные системы позволяют вам легко вводить в строй узлы инфраструктуры, но пользователи, как считает Subbu, требуют больше - им нужна платформа для создания новых бизнес-паттернов управления нагрузкой и ресурсами, Методология-as-a-Service. Что интересно, это говорит инженер компании, с не самым последним на рынке размером парка оборудования. В общем, прочитайте сами, и походите по ссылкам из/на его пост.

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

Довольно давно список поддерживаемых видеочипов в открытом драйвере freedreno, практически в одиночку разрабатываемым нашим коллегой, участник Fedora ARM SIG, Rob Clark, ограничивался семейством Adreno A2xx/A3xx. Как и обычно, информация добывалась с помощью реверс-инжиниринга, изучения MMIO-трейсов проприетарных видеодрайверов и так далее. Чипы A2xx и A3xx имели много общего, и работа шла быстро, но когда появился A4xx Rob обнаружил, что он сильно отличается от предыдущих поколений.

Было решено, что необходимо сфокусироваться на предыдущих широко используемых семействах чипов, а с A4xx заняться, когда будет время.

Прошел год, времени так и не находилось, как вдруг в рассылку разработчиков прилетело несколько патчей для поддержки A4xx в драйвере freedreno из Qualcomm.

Мы все были шокированы, ведь обычно embedded-компании и производители бытовой техники не очень охотно идут на контакт с opensource-коммьюнити.

Потом прилетело еще несколько патчей от Qualcomm. В коммьюнити пока особо не комментируют это, т.к. боятся спугнуть удачу, но в целом это позитивный знак.

После этих новостей, Rob сумел запустить OpenGL-демо на A4xx: Интересно, что кот выводился на экран в неправильном цвете, т.к. Rob ошибся где-то. Но быстро написанный им же скрин-граббер тоже содержал ошибку в цветопередаче при записи BMP, поэтому цвет на скриншоте стал правильным. Минус на минус дает плюс!