Russian Fedora

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

Content (66 страница со старыми записями)

Важен ли Display Server?

Robert Ancell, один из немногих разработчиков в Canonical и разработчик GNOME, написал пост, в котором высказал точку зрения, что какой используется Display Server, это неважно для приложений, ведь они используют не платформо-специфичные вызовы, а тулкиты, в которых уже все сделано.

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

В этой реальности же, оказалось, что в отличие от Mir, контролирующей организации у Wayland нет, а есть широкое сообщество заинтересованных компаний и индивидуальных разработчиков, управляющее процессом по принципу меритократии и ведущее разработку публично (Mir почти год писался закрыто). Что разработчиков Wayland никто и не спрашивал о той функциональности, которая так требуется Canonical - ни один из разработчиков Mir вообще не общался с ними до самого анонса Mir. Что проприетарные драйверы в Wayldand использовать можно, и именно решение, использующееся в Wayland, было портировано в Mir. Что скорость разработки Wayland не изменилась, а вот Mir заметно сбавил скорость, несколько раз перенеся сроки выхода релиза, пригодного для широкого использования (по умолчанию его теперь планируют включить лишь в 2016 году), т.к. написать болванку проекта, даже такого, как принципиально новый дисплейный сервер - легко, а вот по достижении 80% функционала добить остальные 20 - очень тяжело. Объяснять широкой публике, почему вместо доработки Wayland надо было с нуля писать несовместимое решение, теперь у Canonical получается плохо, особенно учитывая, что Wayland уже используется в мобильных и встраиваемых устройствах, а возможностей Mir хватает лишь для сомнительных демонстрашек.

Но даже и это не то, за что зацепился глаз в заметке Роберта.

Разработчики прикладного ПО, представляющие таких игроков, как Intel и KDE почти сразу озвучили свои в озражения по существу. Ikey Doherty из Intel в своей ленте Google+ не согласился, с тем, что разработчику можно не интересоваться дисплейным сервером.

Есть заметное количество "corner case", где разработчику прикладного ПО придется спуститься на уровень ниже, чем используемый тулкит, утверждает Ikey опираясь на свой опыт. К несчастью, он привел не очень убедительный пример - GTK, к кроссплатформенности которого всегда предъявляли претензии.

Но и с Qt, очень похоже, дела обстоят не так хорошо, как утверждают в Canonical. Martin Gräßlin, у которого интересная и захватывающая история отношений с фанбоями Ubuntu, изложил свои соображения по теме.

Martin пишет следующее - он шокирован тем, что Canonical упорно продолжает не видеть тех проблем, что они создают коммьюнити. На самом деле поведение тулкита Qt на разных платформах отличается. Да, отличается по мелочам, но они есть, и лично он напоролся на несколько.

Благодаря упертости Canonical будут и другие, и их будут сотни, если не тысячи, как предполагает Martin. Это очевидным образом увеличит матрицу тестирования для разработчика прикладного ПО, увеличит сложность поддержки. С ним соглашаются и комментаторы в его посте на Google+.

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

Возможен, конечно, фантастический исход, что у Canonical впервые получится задуманное, и доля Mir начиная с 2016 года будет устойчиво расти среди мобильных устройств и десктопов, что, конечно, может повлиять на предпочтения разработчиков. Но не лучше ли забросить вредную для OSS коммьюнити попытку навязать альтернативное решение, и перейти наконец-то на то, что выбрало коммьюнити, т.е. Wayland? Ведь Canonical хватило благоразумия именно так поступить с systemd.

Ситуация начинает сказываться болезненно на обоих сторонах - на коммьюнити разработчиков Open Source, и на Canonical. Ведь не только нашим коллегам все тяжелее и тяжелее поддерживать ПО из-за нарастающих различий между стандартным дистрибутивом Linux и Ubuntu, но и Canonical все тяжелее управлять нарастающей дельтой изменений в условии отсутствия разработчиков в нужном количестве. Мы уверены, что Mir постигнет судьба всех прочих проектов Canonical, и надеемся, что здравомыслие восторжествует, но хочется, чтоб это наступило как можно скорее - это пойдет на пользу всем.

UPD статью прокомментировал и Aaron Seigo.

Унификация вывода консольных команд

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

Не так давно, в git-репозитории пакета утилит util-linux, разрабатываемого нашим коллегой Karel Zak, появился загадочный бранч с названием *scols*. Загадочным он был недолго - Karel объявил его назначение в своей ленте Google+.

Теперь, со следующего релиза util-linux, в его состав войдет библиотека libsmartcols, предназначенная для форматирования вывода консольных утилит и написанная им совместно с его коллегой по компании, Ondrej Oprala. Ее предназначение, это выводить красиво оформленные таблицы и деревья в терминале, с учетом его возможностей и соответственно с предоставляемыми текстовыми данными. Karel приглашает другие проекты переходить на нее.

Новая библиотека уже получила одобрительный отзыв от Greg Kroah-Hartman.

Наши коллеги стали лауреатами Free Software Awards!

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

FSF огласил список награжденных премией "FSF Awards" за 2013 год.

Мы с радостью сообщаем, что оба приза достались участникам проекта Fedora! Наш коллега, Matthew Garrett, бывший инженер Red Hat, ныне работающий в Nebula, получил премию в номинации Advancement of Free Software за его работу над поддержкой SecureBoot в Linux, выполненную им в Red Hat.

Также был отмечен его вклад в поддержку UEFI в Linux и его многочисленные переговоры с производителями. Не какие-то там мифические "переговоры", а вполне реальные, благодаря которым даже самосборная гентушечка может загрузиться на системе с SecureBoot после ряда телодвижений. Конечно, надо учесть, что переговорам помогало его тогдашнее положение в Red Hat.

Приз в номинации Projects of Social Benefit ушел к GNOME Foundation's Outreach Program for Women. За весь проект приз получали Karen Sandler и Marina Zhurakhinskaya.

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

image0 Гендерквир одобряет работу GNOME Foundation's Outreach Program for Women!

Язык Hack

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

С радостью сообщаем, что Bryan O'Sullivan, участник Fedora c 10-летним стажем, один из участников Fedora Haskell SIG, ныне работающий в Facebook, со своими коллегами разработал и недавно представил новый язык программирования с PHP-подобным синтаксисом, Hack. В отличие от PHP, язык поддерживает как динамическую, так и статическую типизацию (т.н. "постепенную типизацию"). Он уже применяется - в Facebook на него перевели почти все проекты. Язык уже получил положительные отзывы от ряда специалистов индустрии, и мы, зная уровень компетенции Брайана еще по его работе над языком Haskell, не сомневаемся, что будут и еще одобрительные посты.

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

Пока мы рекомендуем начать знакомство с оригинального анонса на Facebook и пары статей на русском - c OpenNET и с Цукерберг позвонит (эти хипсторы уж точно такой модной игрушки не пропустят).

ACPI это не firmware

Призыв Марка Шатлворта отказаться от проприетарного firmware, в частности от ACPI, продолжает обсуждаться в блогосфере. Ну, конечно, это типичная ситуация для вбросов от Canonical.

Уже тогда Olof Johansson заметил, что Марк путает ACPI и SMM, а сейчас это подчеркнул в своем посте инженер Linaro, Graeme Gregory. ACPI, это не firmware, а описание системы, дополненное документированным байткодом, исполняющимся ядром операционной системы. Т.е. это вполне открытый стандарт, которым с недавних пор управляет UEFI Forum, а не какой-нибудь злой вендор.

Народ почти разобрался, и начал глумиться над Марком, когда в комменты к одобрительному посту у Greg Kroah-Hartman пришел известный хулиган и матершинник Linus Torvalds, и началось:

LT: Is there a way to "-1" idiotic posts? ...anybody who claims that the
regular BIOS isn't firmware is a f*cking moron. ACPI tables and AML scripts are
firmware. Anybody who claims anything else is delusional. ...Greg
Kroah-Hartman, why are you spreading manure like this?  Is there some PR
workgroup shilling for ACPI that I'm unaware of? Is it due to the whole ARM
brouhaha vs devicetree?

GG: Linus Torvalds you fucking imbecile, see look how cool I am, I can swear
too.  What a grown up awesome dude you are, fuck off back to your cave and shut
up until you have worthwhile comments to make!

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

К сожалению, наш коллега и специалист по ACPI, Jon Masters, не участвует в последнее время в плодотворных обсуждениях, т.к. готовится к Бостонскому Марафону.

Реальное использование fedmsg в быту

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

Шина fedmsg набирает популярность. Ну, например, Fedora Java SIG использует ее, чтоб подписавшись на несколько типов сообщений своевременно проверять размер минимальной установки ряда интересных им пакетов при пересборке их зависимостей. Если они видят внезапный скачок, то значит цепочка зависимостей резко изменилась, и надо что-то делать. Но этим возможности fedmsg не исчерпываются.

Наш коллега, инженер Red Hat и участник коммьюнити Gentoo, Stanislav Ochotnicky, в своем блоге анонсировал первый релиз приложения fedwatch. Это не только приложение, но и мини-библиотека, позволяющая быстро писать скрипты, запускаемые по неким событиям от fedmsg. Например, при сборке какого-то пакета, либо при открытии заявки в багзилле. Вообще, вариантов представляется довольно много. Другой наш коллега, Miroslav Suchý, тут же подхватил разговор, быстро смастерив несложный скрипт уведомления об успешном завершении сборки в Copr.

В общем пробуйте!

Третье мероприятие из серии "Дорога в облака", и Hadoop в OpenStack

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

Hadoop в Fedora уже работает, но на одной машинке запускать его наверное смысла особо и нету -запускать его нужно на кластере. Кстати, как правильно - "на кластере" или "в кластере"? Современный кластер, это чаще всего облачная система, а облачная система, это OpenStack. И тут-то сразу возникает вопрос - как запускать Hadoop в OpenStack? Ответить на этот вопрос планируют наши друзья из компании Mirantis, которые вместе с другими заинтересованными лицами работают над проектом OpenStack Savanna, недавно переименованный в OpenStack Sahara (редкий компонент OpenStack обходится без пары переименований туда-сюда - так отсекаются не умеющие гуглить пользователи). Планируется, что работать все будет примерно вот так: image0 Надо, конечно, учитывать, что каждый прямоугольничек, это с пару дюжин демонов, но в целом все выглядит стройно и логично, и вопрос был лишь о том, когда проект будет включен в "основной" OpenStack? И вот, на днях, было единогласно решено, что проект будет включен в выходящий этой осенью OpenStack Juno.

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

Конечно, до зимы ждать незачем, и попробовать OpenStack Sahara можно прямо сейчас, но тут есть практический момент. Современнные облачные системы устанавливаются, и даже порой развертываются легко, гораздо легче, чем было раньше, однако возникают совершенно глупые вопросы - от того, как оптимально и правильно использовать полученный кластер, до того "а зачем мне это надо"? "Надо" в смысле, что как добиться чего-то такого, чего не было раньше. Для ответов на эти и другие вопросы наши друзья c OpenStack.ru планируют в ближайшее время провести мероприятие из серии "Дорога в облака" по теме Big Data в облаках.

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

image1Дорога в облака.

EPEL 7 для 32-битных архитектур

Как только команда CentOS уже начала пересборку RHEL 7 для 32-битных архитектур, выброшенных из RHEL 7, так сразу возникла проблема - EPEL для RHEL 7 существует лишь для официально поддерживаемых архитектур, и ни x86, ни armv7 нет.

Хорошо, что пересборка EPEL 7 только началась, и участники CentOS не сильно опоздали со своим предложением о запуске пересборок для 'secondary arch' для EPEL. В целом коммьюнити положительно приняло предложение, которое покрывает два потенциально интересных "use case" - миграция с устаревающих 32-битных машин и рост популярности ARM-платформ.

Параллельно с EPEL для secondary arch, группа заинтересованных лиц пока обсуждает идею создания репозитория для RHEL, но с другими правилами обновления пакетов - EPIC (Extra Packages for Infrastructure and Clouds).

Посмотрим, что из этого выйдет.

Brandon Philips рассказывает про etcd

Проект CoreOS продолжает раскрывать свои не очень секретные секреты. В еще одном интервью CTO компании CoreOS Inc, Brandon Philips, рассказывает о etcd. В совокупности с контейнерами, systemd, и fleet, это один из кирпичиков надежной кластерной системы, поэтому если вы интересуетесь вопросом, то вам стоит ознакомиться с интервью Брэндона.

Будущее tcpwrappers

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

В рассылке systemd предложили избавиться от tcpwrappers, разработка которых прекратилась в 2003 году. По ходу возникшего обсуждения, выяснилось, что из Arch Linux их выкинули года три назад, и никто даже и не заметил (правда надо учесть размер пользовательской базы, и для чего используют Arch), в Debian выбрасывать не собираются, что вполне понятно, т.к. 11 лет отсутствия разработки для них это обычное дело, и если ПО настолько древнее, то в нем все баги улетучились.

Оценив ситуацию, Lennart предложил избавиться от tcpwrappers в Fedora, изложив свои соображения. Ко всеобщему удивлению на свет стали ползти живые пользователи tcpwrappers.

image0