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

Очередной чиновник из правительства грозится запретить GitHub в России, если те не выполнят его требования. Новость уже обсуждают коллеги-аналитики. Причин цивилизованным людям из GitHub выполнять хотелки бесноватого дикаря, недавно слезшего с нефтяной вышки, сходу не видно - не идут же они на поводу религиозных фундаменталистов из ряда стран третьего мира (но надо отметить, что на поводу у своих фундаменталистов они идут). А значит, рано или поздно российский чиновник, неважно какой, запретит GitHub, да и, наверняка, не только его. Поэтому надо готовиться.

Мы не будем касаться вопросов восстановления доступа к веб-интерфейсу GitHub. Для этого в интернете есть полно решений разной степени сложности. Например, некоторые наши коллеги, для обхода цензуры Единой России, используют комбинацию HTTP-прокси и Firefox с плагином FoxyProxy. Это же решение хорошо подходит и для работы в сети Tor. А вот каких хаутушек в интернете мало, так это как использовать Git через третий узел, находящийся под вашим контролем.

Если у вас есть IPv6, то вы уже можете воспользоваться работающим Git-SSH-прокси по адресу ikvjwd.com. Просто вместо GitHub.com используйте его домен, например:

git clone git@ikvjwd.com:RussianFedora/russianfedora-free-release.git



Необходимо отметить, что т.к. у вас лично нет причин доверять владельцам ikvjwd, то обязательно проверяйте SSH-отпечаток. Таким образом вы сумеете восстановить уничтоженный Единой Россией доступ к нужному нам всем сайту, и очень дешево. Если по каким-то причинам вам готовое решение не подходит, то разверните свой прокси на компьютере, находящемся за пределами РФ. Кстати, за основу можете взять вариант от ikvjwd, владельцы которого выложили конфиг к haproxy, которым вы можете воспользоваться. Сам haproxy доступен в репозиториях Fedora. Но, конечно, можно настроить и туннель, используя SSH. Для чего сначала нужно запустить туннель через ваш ProxyServer.example.com, на котором у вас есть SSH-аккаунт, и который находится в одной из более цивилизованных стран, например страны ЕС, Белоруссия или Украина:

ssh ProxyServer.example.com -L 3333:github.com:22 -N



Это запустит переадресацию вашего локального порта 3333 через ProxyServer.example.com на github.com:22. Затем, в другой консоли, клонируйте ваш репозиторий (или поменяйте адрес в .git/config, если уже клонировали):

git clone ssh://git@localhost:3333/RussianFedora/russianfedora-free-release.git



Если вы клонируете репозиторий по Git-протоколу, то вместо порта 22 нужно пробросить порт 9418. Строка для клонирования будет выглядеть вот так:

git clone git://localhost:3333/RussianFedora/russianfedora-free-release.git



GitHub, это один из наших основных рабочих инструментов, и когда Единая Россия его запретит, то мы обязательно поднимем на своих мощностях Git-прокси на него - таким или каким-либо иным способом. Вообще, очень печально, что такой сайт для современной модной молодежи, как GitHub, ни по IPv6 недоступен, ни в Tor не виден. А вот тот же Facebook доступен и в Tor, и по IPv6 (см. host -t aaaa facebook.com). Напоминаем, что мы-то доступны в сети Tor. Его закрыть у Единой России получится лишь физически изолировав рунет от интернета, что им будет реализовать непросто, хотя и возможно.

Но есть и хорошие новости - решили не вводить налог на программистов в пользу патриотов.

Lennart Poettering выложил слайды со своего выступления на NLUUG Najaarsconferentie 2014, где он рассказывал о фичах безопасности в systemd. Видеозапись выступления никто не сделал.

К сожалению, в RHEL 7 и пересборки включен относительно старый systemd версии 208. В нем нет ни пользовательских сессий, ни управления сетью, и много чего еще. Для тех, кто хочет воспользоваться всем этим, наш коллега Lukáš Nykrýn подготовил экспериментальную сборку самого свежего systemd, прямо из Fedora Rawhide. Конечно, никаких гарантий не предоставляется, но мы уже пробуем.

Продолжается процесс включения kdbus в ядро. Greg KH представил второй вариант патчсета. Из заметного, помимо попытки исправить недостатки, замеченные ранее, отметим появление специализированной файловой системы kdbusfs, которая будет монтироваться в /sys/fs/kdbus.

Наш коллега, Miroslav Lichvar , работает над интересным проектом - timedatex. Это сервис управления системными часами, управляемый через D-Bus, и, что самое интересное, являющийся аналогом systemd-timedated, но не требующий никаких библиотек systemd.

Flannel (ранее Rudder), еще один вариант управления сетью, использующий etcd и systemd (systemd-notify для надежного управления сервисом), наконец-то включают в Fedora. Похоже, что SDN, это уже не будущая, а нынешняя горячая тема.

Сегодня, больше 150 мэйнтейнеров Fedora получили уведомление об открытой заявке в Bugzilla. В ней описывалась дыра в безопасности в одной из популярных JavaScript-библиотек, jQuery. Из-за этой дыры, и из-за того, что jQuery приложена в виде bundled lib во множестве приложений, всем этим мэйнтейнерам придется заняться пересборкой пакетов с исправлением.

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

Неряшливый подход некоторых frontend-программистов переносится ими на системный уровень. Когда им надо использовать JS-библиотеку, то они ее бросают в исходники, и либо забывают навсегда (отчего в ней заводятся баги), либо безоглядно форкают (отчего она далеко уплывает от оригинала, патчить ее становится сложно, и в ней тоже заводятся баги). Мы попробовали было начать выносить хотя бы jQuery из пакетов, требуя использовать system-wide копию, и даже запланировали было это фичей Fedora 21, но обстоятельства оказались сильнее нас, и фичу перенесли на Fedora 22.

А так ли и надо выносить JS-модули в system-wide пакеты? Конечно, можно и не выносить, но тогда, как сейчас, вместо того, чтобы патчить один пакет силами одного мэйнтейнера, придется патчить целую кучу пакетов силами 156 мэйнтейнеров. К счастью, в апстриме уже начали исправлять проблему, например в CouchDB уже поправили.

Сервис ABRT стал доступен и пользователям CentOS, начиная с версии 7. Мы исправили довольно много ошибок, благодаря ему, хотя. конечно, далеко не все, и появление его в CentOS без всякого сомнения окажет благотворное воздействие на качество как RHEL, так и коммьюнити-пересборок.

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

Patrick Uiterwijk сообщает в своем блоге, что забрасывает свой OAuth-провайдер, FedOAuth, в пользу Ipsilon. Как и в других случаях, мы надеемся, что коммьюнити других дистрибутивов будут переходить на это решение, и помогать его развивать. Чем меньше самоделок, тем лучше!

Потихоньку развивается проект Cockpit, включение которого в Fedora объявлено фичей версии 21. Это еще один вариант для управления серверами из веб-интерфейса, и что совсем удивительно, но написан он не на Go! Тем не менее, хотя он не рекомендуется пока для широкого использования, но к нему начинают появляться обучалки. Например, появилась хаутушка по тому, как использовать D-Bus из JavaScript.

Почти сразу после выхода mock версии 1.2 вышла версия mock 1.2.1. Среди изменений - сжатие логов, полная поддержка Python 3, и т.д.

Karel Zak включил поддержку скриптов sfdisk в fdisk и cfdisk. Теперь можно сохранять разбиения дисков в файлы, и потом их загружать. Как это выглядит можно посмотреть на видео:



Раньше мы старались в рамках одного релиза не включать обновления X.org, ломающие ABI. Это, конечно, разочаровывало пользователей, которые хотели самое свежее и новое, зато сберегало нервные клетки тех из них, которые по неизвестным нам причинам предпочитают проприетарные драйверы. Ну и из общих соображений, большие многокомпонентные апдейты резко увеличивают матрицу тестирования.

Начиная с Fedora 21 мы удалили большое количество старых видеодрайверов из репозитория, и матрица тестирования резко сократилась. Это позволило вновь поднять вопрос, нужно ли выкатывать большие обновления X.org в рамках одного релиза? Пока народ склоняется к тому, что не только можно, но и нужно! Это, разумеется, принесет дополнительных проблем любителям проприетарных блобов, но они сами выбрали свой путь боли и страданий, и оглядываться на них в этом вопросе нам не стоит.

Постепенно набирает обороты обсуждение в рассылке fedora-devel нововведения от MoFo - показа рекламы на стартовой странице, с учетом истории пользователя. Горячие головы даже предлагают удалить Firefox из репозиториев, мол midori или Epiphany вполне достаточно. Для тех, кто интересуется, что конкретно так возмутило некоторых наших коллег, есть скриншот (обратите внимание на рекламу Booking.com в верхнем ряду плиток):



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


Современный интернет


Слон в лавке, которого многие предпочитают не замечать, это то, что MoFo требует от коммьюнити никак не вмешиваться в исходники Firefox без явного разрешения, угрожая изъять право распространять результат под торговой маркой Firefox. С точки зрения некоторых коллег-аналитиков, это явно делает Firefox несвободным ПО (нет свободы работать над ПО в рамках дистрибутива, хотя часть участников Fedora придерживается иной точки зрения.

Еще из интересных моментов можно отметить, что разработчики полагают, что Epiphany будет готов примерно к Fedora 23 или Fedora 25, и тогда можно будет предлагать его дефолтным браузером (разумеется, оставив Firefox в репозиториях).

В обсуждении наши коллеги пока ни до чего конструктивного не договорились, и можно предположить, что и не договорятся - замены Firefox у нас нет, править его исходники нам нельзя, а ломать все из-за одной (пока) рекламной плитки на дефолтной странице, это как-то уж слишком круто. Будем ждать развития браузеров на базе WebKit или Blink.

Снова появился повод вспомнить "бинарные логи" и любителей заняться юниксвэем.

В последнее время, к нам переходит много пользователей Debian. Это очень здорово, т.к. свежим глазом видится много того, что мы или не замечаем, или к чему давно привыкли и забыли. Недавно очередной бывший пользователь Debian недоуменно спросил - почему bash completion при установке пакетов происходит так медленно? Мы как то и не думали об этом, ну тормозит, и ладно, но после претензии от новичка наши участники решили разобраться, в чем же дело.

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

Наш коллега, Igor Gnatenko, изучив вопрос с тормозами bash completion, выяснил, что дело в том, что для поиска варианта для дополнения команды используется понятный и "читаемый глазами" текстовый файл, вместо эффективного бинарного. Ну, бывает, чего уж там. Разработчик торопился, быстро сохранил в текстовичок, и дальше, мол, грепайте в нем сколько хотите. Ну, раз нашел, в чем дело, то надо бы и исправить, ведь так? Это и было Игорем сделано в двух pull-реквестах на GitHub (раз и два). В результате простой переход на базу с 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







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

Мы никогда не устанем рассказывать, что эффективное бинарное хранение данных всегда будет гораздо выгоднее текстовичков. Например, люди даже пишут специальное ПО, чтобы преобразовывать текстовые логи Apache в базу с SQL-запросами. А казалось бы - удобно глазами читать, не нужно никаких утилит (вы же помните - любители юниксвэя, это сплошь киборги, воспринимающие информацию прямо с секторов жестких дисков). В нашем случае произошло тоже самое - переход на бинарное хранение оказал заметное ускорение. Теперь автодополнение при установке пакетов просто летает!



Попутно, Игорь, пробежавшись глазами по коду сопутствующих проектов увидел вопиющие нарушения рекомендаций Process Identifier Preservation Society. Исправил и это (раз и два), что тоже привело к заметному ускорению. Разработчик схватил идею на лету, и оставшиеся проблемы исправил уже сам.

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

Новость чуть не прошла мимо, хотя ее уже озвучили на всех ведущих 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 того времени, теперь уж и не узнаешь.

Страницы