Fedora Rawhide (будущая версия 24) переходит на недавно анонсированный RPM 4.13.0!

Из заметных изменений в RPM 4.13.0 можно отметить File Triggers, вариант скриптлетов, выполняемых, если пакет содержит файл, удовлетворяющий некоторым признакам. С их помощью можно будет, например, попробовать заменить %pre, %post, %postun скриптлеты во всех пакетах, содержащих загружаемые C/C++-библиотеки.

Вторая новинка новой версии RPM, это логические зависимости между зависимостями. Например, Requires: sysklog OR syslog-ng OR rsyslog. Более интересный вариант, это установка дополнительных компонентов, если установлен некоторый пакет. Например, Requires: opensips-oracle IF oracle-instantclient. Логические выражения над зависимостями, это очень экспериментальная функциональность, и ее поддержка в библиотеках высокого уровня пока неполная. Синтаксис тоже в процессе обсуждения.

Наш коллега, Jiří Eischmann, собрал интересную статистику по количеству пакетов в релизах Fedora:



Кто-то полагает, что рост числа пакетов замедляется, и может быть даже выходит на плато (хотя, как считают некоторые коллеги-аналитики, оснований для вывода о стабилизации на некоем уровне пока нет). Сам Jiří тоже полагает, что количество пакетов стабилизировалось, и причиной этому считает рост популярности Copr, о котором мы рассказывали, аналога неоднозначно зарекомендовавшего себя PPA из Ubuntu. Действительно, вроде бы количество пакетов в Copr растет.

Тут хотелось бы кое-что добавить. Во-1 не стоит пока говорить о выходе на плато. Подождем еще годик-полтора, чтобы вывод базировался не на одной точке. Во-2 замедление добавления пакетов в Fedora обуславливается еще и объективно существующей тенденцией - мы, в отличие от многих других дистрибутивов, порой выбрасываем устаревшие, давно не собиравшиеся пакеты. Гордиться, как другие, поросшим лопухами, но формально большим репозиторием, мы не желаем. Ну и в-3, Copr оценивают не только положительно.

Напомним, Copr появился в рамках работы по реализации идеи о рзделении Fedora на кольца, но моментально стал использоваться для сборки и выкладывания пакетов, в обход все больше устаревающего и устаревающего процесса сборки пакетов в Fedora. Jiří надеется, что в будущем соответствие к предъявляемым Fedora требованиям таких пакетов вырастет, и они начнут конвертироваться в пакеты Fedora.

К сожалению, нужно сказать, что инфраструктура Fedora, хотя и заметно улучшилась, продолжает выглядеть очень архаичной. Дело в общем подходе, не изменившемся с 1990х годов (ориентация на тарбол с исходниками, выложенный на университетском FTP, как тогда было принято). Современный рабочий процесс ориентирован на CI, на тестирование, на Git с его тэгами и бранчами, и автор этих строк не устает удивляться тому, как сильно различаются эти два подхода. Немного чисел - манипуляции с новой сборкой пакета (из тарболла и кучки патчей) в Fedora обычно занимают около часа. Иногда гораздо больше, но порядок величины такой. А вот тот же результат, но достигаемый с помощью Buildbot и Git, требует уже около 5 минут (опять же, когда больше, когда меньше, но порядок величины примерно такой). С таким настроением ты слона не продашь, как говорится. Если раньше мы еще могли зазывать новых мэйнтейнеров, то сейчас он(а) приходит, брезгливо смотрит на существующие инструменты и уходит обратно, отряхивая налипший линукс со своего макбука. Нужна радикальная переработка всего процесса.

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

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

Дел много, но будем смотреть позитивно - это еще и море возможностей. И как раз, недавно у нас появилась вакансия в Fedora Engineering Team. Присоединяйтесь!

Bitcoin Picnic Moscow 2015

Большая биткойн-тусовка на открытом воздухе в Парке Горького!

Лето в самом разгаре. Скоро уже середина. Нужно, чтобы лето запомнилось чем-то приятным именно в мире биткойна, местным, московским! Мы проводим пикник/тусовку для биткойнеров и всех, кто заинтересован темой цифровых валют и технологией блокчейн. Собраемся на траве у набережной в Парке Горького в субботу 1 августа 2015 в 12:00

С собой приносить и приводить:

  • хорошее настроение
  • хороших друзей и подруг
  • бумбокс; флэшки с хорошей музыкой!
  • фрисби
  • волейбольный мяч
  • бадминтон
  • прочие всякоспортивные лонгборды
  • пледы, чтобы было на чем сидеть / лежать / уткнуться в wifi
  • напитки, снэки (по-русски закуски всякие)
  • все, что сами пожелаете!


Хорошее настроение, интересное общение и много позитива. Bitcoin Picnic собирёт как профессиональных биткойнеров, так и новичков. Майнеры, трейдеры, разработчики и журналисты, инвесторы и бизнесмены, новаторы и консерваторы – всем кому интересна тема биткойн. Участие, конечно же, бесплатное.

Вся информация о мероприятии в ВК.

Точка встречи: https://maps.yandex.ru/-/CVcSa4mc. В случае дождя - мероприятие переместится в ближайшее кафе (оно в 50 метрах от точки встречи).

Искренне Ваш, Bitcoin Embassy Moscow.

#BitcoinPicnic

Наши коллеги из Red Hat опять нашли дыру в Qemu, которая теоретически позволит исполнить код в хостовой машине с правами процесса Qemu. Ну бывает, что. Вон, в VMware недавно нашли дыру в системе принтеров, подключенных через COM-порт.

Инженеры Red Hat уже предложили патчи для исправления ошибки.

Наш коллега, Jon Masters, в последнее время приуныл. В AArch64 / ARM64 все уже стандартизировано, и осталось только запугать последних ленивых производителей, чтоб те включали свой код в апстрим, т.к. больше никаких форкнутых ядер 2.6.17.4 не будет - продаваться будут лишь те платформы, на которых основные дистрибутивы будут вставать без дополнительных телодвижений. Под основными дистрибутивами Jon имеет в виду только Fedora, но другие подтянутся - они, как обычно, отстают.

Image and video hosting by TinyPic


И вот, неожиданно, Jon анонсировал в своей ленте Google+ новое начинание. Он призвал всех, кто занимается разработкой когерентными ускорителями, написать ему, т.к. начата интересная инициативная работа по кросс-платформенной стандартизации этой технологии. Вообще-то для Coherent Accelerator Processor Interface (CAPI) уже есть платформозависимый API для платформы POWER / OpenPOWER, и наверное можно его расширить за пределы решений IBM, но вполне может быть, что все гораздо сложнее. Интересно, что несколько дней назад Jeff Scheel, Chief Architect в IBM, внезапно заинтересовался достижениями Jon Masters по стандартизации AArch64 и решил пригласить его в коммьюнити OpenPOWER.

Только что отгремел OpenStack Summit Vancouver, а наши друзья и коллеги начали готовиться к OpenStack Summit Tokyo. И им требуется ваша помощь! Заявок на выступления там традиционно больше, чем свободных слотов, и то, кто будет выступать, определяют на 146% честными выборами. Среди поданных заявок на выступление есть и от наших соотечественников, инженеров Mirantis - Aleksandra Fedorova и Igor Belikov. От вас требуется лишь зарегистрироваться и проголосовать за доклад.

Продолжим тему научно-популярной и учебной литературы. Наши друзья в Mirantis выложили первые три главы книги "Git in Practice", о чем объявили в своей ленте Google+. Книга написана инженером GitHub, Mike McQuaid , и посвящена не только тому, как работать непосредственно с Git, но и тому, как использовать GitHub.

Кстати, если покопаться в BTDigg.com, то легко находится PDF с похожим названием, но что в нем внутри мы не знаем.

А та идея-то жива-живехонька! Наш коллега, Karel Zak, недавно потихоньку добавил вывод в формате JSON в библиотеку libsmartcols, о которой вы уже слышали, и началось. После добавления в lsblk, findmnt, lslocks, и losetup, он быстро добавил подержку JSON в sfdisk/libfdisk, и планирует добавлять поддержку в другие старые утилиты. А на днях он написал новую утилиту, lsipc, в которой уже изначально была поддержка JSON.

Эта новая утилита, lsipc, идет на замену устаревшей и малофункциональной ipcs, и предназначена для вывода информации о SysV IPC. Конечно, с появлением systemd и kdbus, эта система межпроцессного взаимодействия однозначно устарела, но ее еще используют некоторые малоизвестные приложения - от базы данных Oracle, до браузера Firefox, поэтому приходится ее использовать.

У нашего коллеги, создателя Fedora Electronic Lab, Shakthi Kannan, вышла актуальная книга!



Иногда нам задают довольно странные вопросы, наподобие такого - "я люблю опенсорс, но не знаю, что делать, чтоб ему помочь". Честно говоря, порой сложно ответить что-то определенное, т.к. практика показывает, что самый хороший результат получается, когда человек чем-либо заинтересован - любимая игра глючит, что-то недопереведено, на работе платят за допиливание открытого ПО, и т.п. Но фишка в том, что во всех этих случаях, человек уже и так знает, что надо делать. Т.е. вопрос на самом деле такой - "я люблю опенсорс, скажите, что мне в нем будет интересно?"

Теперь мы знаем, какую книгу посоветовать купить и прочитать!

Если кто не доехал до OpenStack Summit 2015, прошедшего в канадском Ванкувере, то теперь можно посмотреть видеозаписи выступлений.

Интересных видео довольно много, но есть и совсем бомбы. Вот, например, помните историю про то, как PayPal отказывается от любимого интеграторами VMware? Ну так вот, посмотрите это видео (для нетерпеливых - промотайте на 07:15):


100% of PayPal runs in production on #OpenStack. If you have concerns about #OpenStack scale, don’t.

Страницы