Russian Fedora

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

Выборы в Fedora Council

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

С 18го по 26 ноября будут проведены выборы в Fedora Council, и мы призываем всех участников проекта Fedora прийти и проголосовать. На два места претендуют пять человек, и их уже проинтервьюировали:

Все на выборы!

Добавление Linux-специфичного API в Glibc

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

Когда речь идет про low level API, то как правило говорят про Glibc. Но на самом деле библиотека просто отдает наверх то, что выдается ей ядром системы. Есть такой механизм, syscalls, и Glibc оборачивает функции ядра просто вызовом syscall, например, чтобы реализовать функцию ssize_t read(int fd, void* buf, size_t len) это делается примерно вот так: `` nread = syscall(SYS_read, fd, buf, len);`` Вместо использования оберток Glibc можно дергать эти функции самому напрямую из ядра с помощью syscall, хотя почти всегда это нецелесообразно - ведь Glibc не просто оборачивает их, но и выполняет много других проверок (корректность аргументов, 32/64-битность и прочее). Но порой приходится, т.к. обертки в Glibc просто нет. Ядро Linux предоставляет огромное количество функций, и далеко не все из них имеют аналоги в API Glibc. Возникает вопрос, а почему какие-то функции экспортированы, а какие-то нет? Раньше, когда Glibc управлял Ulrich "Stop Reopening" Drepper, он и решал - эту функцию включаем, а эту нет. После его ухода из Red Hat на заработки к финансовым спекулянтам в Goldman Sachs, когда процесс разработки Glibc упорядочился и оздоровился, народ начал обсуждать, а каковы могут быть формальные критерии для создания обертки для функции из ядра? Одной из проблем является мало кому нужная кроссплатформенность Glibc.

Дело в том, что несмотря на то, что в несовместимых между собой операционных системах семейства BSD, проприетарных Unix-системах, и т.п. используется свой аналог Libc, разработчики Glibc с непонятным упорством пытаются обеспечить кроссплатформенность библиотеки - спроса на это практически никакого, но работа ведется. Практика показывает, что кроссплатформенный аналог всегда проигрывает нативному, т.к. вынужден опираться на общее подмножество функционала всех систем, на которых он работает. Поэтому в коде будет полно кусков, облепленных ifdef, в которых по каждой ветке будут неисправленные ошибки, уже давно отсутствующие в других ветках. Хочется добавлять интересный Linux-функционал, но это сразу будет уводить Glibc от его сборок для альтернативных ядер. И даже когда функционал добавляется, его не используют в userspace, т.к. люди боятся обидеть шумных представителей меньшинств с нетрадиционными системами, которые запросто могут начать собирать на киллера. Поэтому Linux-специфичный API повисает мертвым грузом с одним или двумя пользователями, потому что любители юниксвэя закричат любую попытку его использования в популярных приложениях.

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

Обсуждая невостребованную кроссплатформенность Glibc и аналоги в несовместимых между собой вариантах BSD нельзя не упомянуть религиозную суть вопроса. Мы ее не будем раскрывать, т.к. боимся ненависти со стороны фанатиков, и просто предложим подумать, о том, насколько может быть конструктивна техническая дискуссия с людьми, приписывающими везде GNU к названию ядра дистрибутива и ходящими босиком, или с людьми, переписывающими утилиты ls и cp, т.к. им показалось, что лицензия недостаточно открытая.

Так или иначе, но несмотря на все проблемы, интересный Linux-специфичный функционал в Glibc продолжал появляться все время, и обсуждение того, как бы формализовать его появление тоже шло. Все сдвинулось с мертвой точки в конце 2012 - начале 2013 года, когда гентушник Mike Frysinger выписал доводы за и против включения дополнительного API ядра в Glibc.

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

Недавнее включение (обновление) поддержки futex в Glibc вновь плавно привело к идее формального описания критериев для добавления Linux-специфичного API.

На этот раз дело дошло до документации.

В целом народ согласен с документом - пора бы начать добавлять API из Linux без оглядки на совместимость с каким-нибудь TruOpenUnixWorks. Из забавного, появление и обсуждение этого RFC затормозило включение в Glibc функционала для поддержки kdbus.

Поддержка STEM-отрасли в РФ в новостях за ноябрь

Ну, в общем, пока ничего не меняется.

Нас уже не очень волнует и удивляет, что в РФ арестовывают за покупку 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. Его закрыть у Единой России получится лишь физически изолировав рунет от интернета, что им будет реализовать непросто, хотя и возможно.

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

Новости systemd

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

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, это уже не будущая, а нынешняя горячая тема.

Опять про bundled libs

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

Сегодня, больше 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!

Сервис 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

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

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

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

Firefox в Fedora и рекламный контент

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

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

Для тех, кто интересуется, что конкретно так возмутило некоторых наших коллег, есть скриншот (обратите внимание на рекламу Booking.com в верхнем ряду плиток):

https://i.imgur.com/byR9jZF.png

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

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

http://ic.pics.livejournal.com/lattona/24142880/48759/48759_original.jpg

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

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

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

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