Участником Fedora и работником Red Hat Kushal Das было официально объявлено о введении в строй Darkserver, специального сервиса, для онлайн-хранения полной информации о сборке приложения. На этом сервисе по так называемому build-id будут доступны ссылки на логи сборки, debug-информацию и собранные RPM-пакеты в Koji.

Наверное все знают или догадываются, что в Open Source одной из важнейших ситуаций в общении между разработчиками и пользователями, является исправление ошибок. В идеальном мире пользователь, столкнувшись с ошибкой, изучает ситуацию, при которой она возникла, запускает дебаггер, проводит пошаговую отладку, находит ошибку, тратит некоторое время на пересборки и подготовку патча с исправлением, регистрируется на feature/issue-трекере (если уже не зарегистрирован), подробно сообщает об ошибке и условиях, при которой она возникает, и прилагает исправление. Разработчики дружелюбно приветствуют его, успешно воспроизводят ошибку по описанию и с радостью принимают его исправление. В этой-же реальности все намного сложнее, болезненнее и менее захватывающе.

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

Для решения этих и некоторых других задач, у Fedora было уже довольно много сделано. Были сделаны репозитории, хранящие дополнительную отладочную информацию (debuginfo пакеты), был сделан метод автоматического уведомления мэйнтейнеров об ошибках (программа abrt), была реализована "фича" по добавлению BuildID в приложения, чтоб автоматически сопоставлять coredump, версию пакета и debuginfo. Теперь добавлен еще один элемент - сервис, с которого, с помощью API, можно получить информацию о приложении, имея лишь coredump, оперируя с backtrace или производя манипуляции с самим приложением. С помощью этой информации, можно указать на информацию в Koji, о пакете, в который входит приложение, создавшее coredump.

К сожалению, этого еще мало, хотя уже очень много по сравнению с куцыми возможностями работы над ошибками в проприетарных системах. Несмотря на то, что все кирпичики уже есть, полноценной распределенной системы анализа ошибок еще нет. Пользователь до сих пор нуждается в скачивании debuginfo пакетов - например, если он желает разбираться с ошибкой лично, а не отправлять логи падения на сервер (в которых, так как это моментальный снимок "внутренностей" программы, может содержаться его личная информация). Для преодоления этой сложности ранее были предложены некоторые решения, например специальная файловая система на базе FUSE - DebuginfoFS, но они так и не были доведены до конца. Кстати, это хорошая тема для студента-участника GSoC!

Вообще, проблема принятия пользовательских отчетов об ошибках и реакции на них, это то, что отличает серьезное коммьюнити от кучки тинейджеров форкающих форк форка форка. Например, понятно, что для успешного исправления ошибки, хорошо бы чтоб разработчик смог ее воспроизвести. Это значит, что у разработчика должна быть точно такая же среда, как и у пользователя. А как этого добиться, если у пользователя туча "USE-флагов", "система настроена под себя", "система оптимизирована пересборкой с -O99 под мою архитектуру" и т.п.? Можно, конечно, исправить проблему и в этом случае, но каков тогда будет КПД исправления? В дистрибутивах с повторяющимися результатами, с идентичными бинарными сборками, исправление сразу затронет всех пользователей продукта, а в системах "настроенных под себя" - может быть ограничено лишь некоторой группой пользователей. Опять-же, чем многочисленнее и/или технически грамотнее количество пользователей, тем более точно будет описана проблема, тем четче будут ответы на вопросы разработчика, что может значительно ускорить исправление. А как быть, если мэйнтейнер приложения в твоем дистрибутиве никогда им сам не пользовался, не знает, как оно устроено, и просто добился того, что оно как-то собралось? В некоторых дистрибутивах есть мэйнтейнеры, которые на добровольных началах управляют сотнями пакетов приложений (порой они еще и по своей наивности гордятся этим). А ведь в общем случае, это значит, что в целом ими производится некачественная работа над ошибками. Еще надо отметить, что некоторые, ставшие популярными среди начинающих, "простые" дистрибутивы в явном виде сообщают, что сообщения об ошибках надо посылать сразу в upstream, т.е. полностью отстраняются от участия в исправлении. Удивительно, но их фанбои порой громко кричат о "безглючности" их "простого" и "передового" дистрибутива "с самым свежим софтом". Конечно, если закрыть глаза на проблему, то она сразу-же исчезнет.

Photo of Beefy Miracle Сообщество Fedora не стоит на месте и уже потихоньку начинает подготовку к Fedora 18. Традиционно первым шагом является выбор кодового названия релиза. О том, как это происходит, я уже писала в предверии Fedora 15 (см. пост).

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

Интересно посмотреть, кто будет соревноваться с Beefy Miracle :)
Ну а историю названий Fedora можно посмотреть здесь.

UPD. Названия можно будет добавлять до 27 марта включительно.

На прошедшем сегодня собрании FESCo начали принимать "фичи" для Fedora 18. Среди принятых:
  • Одно из больших планирующихся изменений, это ARM будет основной архитектурой. Ошибка сборки пакета на ней теперь будет блокировать включение его в Fedora (как это обстояло с PPC и PPC64 архитектурами раньше).
  • Обновление pcre до версии 8.30. С этой версии в pcre доступна поддержка UTF-16.
  • Поддержка режима HotSpot в Networkmanager.
  • Реорганизация метаданных для yum. Сейчас они хранятся в виде одного большого comps-файла, что невыгодно в ряде случаев.
  • Обновление RPM до версии 4.10. Это, в основном, исправления ошибок и оптимизации, так-что обычные пользователи скорее всего ничего и не заметят.
  • Перемещение мандата kerberos из /tmp в /run/user/$USERNAME
  • .
И наконец, наверное наиболее важная новость, это то, что единогласно (8 голосов против, 0 за) было принято решение отказаться от перехода на Journald. В свете последних улучшений в системе журналирования событий, те нововведения, которые привносит этот компонент, уже не так актуальны. Отказ касается только включения этой "фичи" в Fedora 18, и возможно ее предложат в измененном виде, учтя критику, в Fedora 19 или позже.

Только что анонсировали утвержденный список проектов, которые приняты в качестве организаций в Google Summer of Code 2012. В этот раз участвует 70 организаций, среди которых и Fedora. Дружный коллектив Russian Fedora всячески рекомендует начинающим и не очень разработчикам, которые на этот сезон еще учатся, и которым уже есть 18 лет, попробовать поучаствовать в этом проекте. Если вашу заявку примут, и если вы добьетесь успеха, то вы получите не только 5000 долларов, но и уникальный опыт разработки в темпе, близком к вашему (но чуть-чуть ускоренном вашим ментором), при участии опытных старших товарищей.

Для тех, кто еще не слышал, формат вашего участия таков. Сначала, вы выбираете проект, в котором вы можете принять участие. Не бойтесь того, что из опыта у вас за плечами только желание этот опыт получить - необязательно досконально во всем разбираться. Ключевой момент GSoC, это обучение, а не платная разработка, так что не бойтесь, что вы вчера узнали, что такое Apache, PHP и GCC, а уже хотите начать переписывать весь интернет. Еще не бойтесь, что вы так и не узнали, что такое GCC - в рамках проекта нужны не только системные программисты, но, например, web-разработчики. Еще такой момент - лучше выбрать проект, который вы лично используете, так как гораздо больше мотивации исправлять то, с чем лично сталкиваешься, чем выполнять какую-то абстрактную задачу.

Итак, вы выбрали проект. Теперь немедленно регистрируйтесь на сайте Google Summer of Code и срочно ищите "менторов" с помощью средств коммуникаций, принятых в выбранном проекте (список рассылки, джаббер-конференция, ирка). Менторы, это те, кто будет подталкивать вас, когда у вас кончится эйфория и вдохновение, и кто будет оценивать вашу работу. Они же будут помогать вам своими советами и учить вас взаимодействию в среде opensource разработчиков. Практика показывает, что по ряду причин, именно этого "инжиниринга" процесса разработки и не хватает русскоязычным разработчикам, так что это очень и очень ценно. Выйдя на контакт с потенциальными менторами вы сообщаете им о своем желании и рассказываете о своей идее, как можно улучшить их проект. Они соглашаются с вами, соглашаются с оговорками или полностью разбивают вашу идею (предлагая какие-то свои). Здесь есть момент произвола и сильное влияние человеческого фактора, что неизбежно.

Предположим, переговоры прошли нормально, и вы договорились c потенциальным ментором об идее, которую будете реализовывать. На проект Google выделяет несколько "слотов" (в зависимости от неких непубличных оценок значимости проектов внутри Google), и теперь вы конкурируете с другими студентами за слоты. Вас и вашего ментора будут интервьюировать другие представители выбранного проекта, чтоб затем открыто и публично решить, какие-же предложения выглядят более привлекательными для участия в GSoC. Ваша заявка может выглядеть техничнее прочих, но, например, у других представителей проекта может по разным причинам сложиться впечатление, что вы и ваш ментор не сумеете закончить ее в срок. Невыполненные в срок заявки серьезно понижают шансы проекта попасть в следующий GSoC, так что тут "ничего личного". У разных проектов есть свои варианты оценки предложения - от реальных тестовых заданий, которые выбираются из числа "janitorial" задач, до простого общения через feature/issue-tracker.

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

Все очень просто - проще, чем, например, устроиться на работу в Яндекс, VKontakte, Facebook или Google. Для участия крайне желательно уметь письменно общаться на английском, хотя-бы с акцентом, так как общение, это очень важный фактор в разработке, а общаться придется на английском. Есть проекты, где традиционно есть русскоязычные менторы, но тем не менее, очень поможет знание международного языка. Насчет русскоязычных менторов, мы советуем обратиться к нам, в Fedora, к Alexandre Prokoudine и LinuxGraphics, к коллективу GIS-Lab. Напоследок, прочитайте подробный отчет от участника GSoC о том, с чем ему пришлось столкнуться.

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

Начиная с сегодняшнего дня команда Fedora проводит тестирования GNOME Shell и дополнений к GNOME.
  • Официальная страница тестового дня
  • Live-образы:
    • i686 - контрольная сумма SHA256SUM
      5a0f70bd863f95e016c93e01556c058e4faea63c04dc1a3e56ec25ecd7cecbd1
    • x86_64 - контрольная сумма SHA256SUM
      4ee9523cf832043fe73cd57743dacb82f5ae4240d98016a4ccd12314724dfd30
Российские локализаторы просят сообщать о багах непосредственно в русскоязычную рассылку команды GNOME или вносить их в вики-таблицу (регистрация не требуется).
Тестировать предлагается работоспособность всех задействованных в Fedora 17 возможностей оболочки GNOME 3, а так же доступных дополнений. К тестированию приглашаются пользователи GNOME независимо от используемого дистрибутива - проект Fedora передаёт все исправления в upstream, поэтому выявленные в рамках мероприятия ошибки, позволят дополнительно стабилизировать готовящийся релиз GNOME 3.4.

Сегодня, в рассылке Fedora-Devel было объявлено, что оригинальный JSON парсер для Java будет удален из репозитория. От него больше не зависит ни один пакет, и удаление пройдет безболезненно для подавляющего большинства пользователей.

К сожалению, причина удаления в этот раз нетехническая. Разработчики библиотеки сменили лицензию, со свободной на несвободную, добавив к Apache Software License следующее условие - "The software shall be used for good, not evil". Несмотря на хихихи и мимими, выполнение этого условия совершенно недоказуемо в суде, так что простые и коммерческие пользователи продукта, содержащего подобную библиотеку, рискуют подставиться под удар от юридического тролля (например, конкуренты могут анонимно нанять юридическую или правозащитную контору, представители которой потребуют в суде выполнения этого условия лицензионного соглашения). Участники Fedora-Legal пытались вести переговоры с представителями проекта, но безуспешно. Похоже, что те просто не поняли, в чем проблема, несмотря на пояснения от юристов Red Hat.

Ну, конечно, не стоит забывать, что Fedora используется в том числе и в военных целях (как инструмент для разработки внутри структур НАТОвской военщины и американских спецслужб), что вряд-ли может быть названо "good, not evil". Многие не знают, но внутри коммьюнити Fedora (и среди работников Red Hat) немало представителей структур типа ЦРУ, НАТО, ФБР и прочих. Там есть и "бывшие", о которых мы знаем, и действующие сотрудники, о которых нас, само собой, не информируют. Все они работают и на наше благо, так как продукт-то открытый, но в первую очередь выполняют задачи, интересные им. Это может показаться удивительным для российских силовиков, но их американские коллеги не городят за закрытыми дверьми кривоватые "национальные" велосипеды силами нанятых за копейки студентов, основным стимулом которых порой служит отсрочка от призыва в армию после выпуска, а открыто и гласно ведут разработки, передавая результаты своих трудов обществу. Это и есть конверсия.

Ещё один важный для русскоязычных пользователей тестовый день, в котором может принять участие каждый: тестируются методы ввода, переключение раскладок и поддержка различных языков в приложениях.
  • Инструкция по участию
  • Live-образ для тестирования
  • Список тестовых случаев

Приглашаем всех желающих принять участие в тестировании поддержки стандарта USB 3.0 в Fedora 17.

USB3.0 - порт синего цвета Для тестирования вам потребуются:

  • порт с поддержкой USB 3.0 - можно опознать по синему цвету (см. картинку)
  • флешка с поддержкой USB 3.0
  • Live-образ с текущей сборкой Fedora 17 (скачать)

Участвовать в тестовом дне можно и после его окончания. Статистика результатов подсчитывается обычно спустя 5-7 дней.

Как обычно все вопросы по участию в тестировании вы можете задать непосредственно организаторам тестового дня на IRC-канале #fedora-test-day (сервер freenode), либо на Jabber-канале русскоязычной поддержки [email protected].

Недавно вышедший RERemix 6.2 включал Live-образы, размер которых был больше 700 Мб. Подобную практику мы переносим и на RFRemix для образов с GNOME и KDE. К сожалению постоянно приходится очень долго возиться и чем-то жертвовать, а то и вычищать даже нужные пакеты, чтобы только уместиться в эти злосчастные 703 чистых мегабайта.

Проблема скорее всего скажется на различных старых компьютерах и ноутбуках, у которых нет DVD ридера и не поддерживается загрузка с USB. Для таких машин останется возможность загрузки по сети, а также живые образы с XFCE и LXDE, которые мы будем держать в рамках 700 Мб.

Одна из популярных ошибок у начинающих пользователей Fedora, это отключение SELinux. Действительно, некоторые "наколеночные" дистрибутивы Linux вообще не используют эту подсистему, т.к. их мэйнтейнеры либо уже неспособны справиться с ее настройкой так, чтоб она работала у пользователя из коробки (эта настройка требует довольно долгого наблюдения за тем, как же работают программы, какие ресурсы они требуют, как взаимодействуют с пользователем, с системой и с другими программами), либо еще не доросли до осознания предметной области, в которой лежат задачи, которые решает SELinux. Опять-же, значительная часть проприетарного ПО содержит годами неисправляемые ошибки (что не является чем-то из ряда вон выходящим для проприетарного ПО) типа утечек системных ресурсов, которые блокируются SELinux, но необязательно вызывают видимые пользователем проблемы при отключенном SELinux. Все это создает у пользователей ошибочное мнение, что эта система не так уж и важна и/или даже мешает работе. Как всегда, если пользователь чего-то не понимает, то он считает, что злые разработчики Red Hat зачем-то сознательно вредят ему.

Участник проекта Fedora, опытный программист, нашедший и закрывший благодаря своей работе над SELinux несчетную тучу ошибок в открытом ПО, Dan Walsh продолжает серию статей, рассказывающих о том, как SELinux помогает выявлять дефекты в ПО. В этот раз он написал статью о том, как SELinux блокирует утечку файлового дескриптора в случае порождения дочернего процесса, и что делать программисту, который допустил эту ошибку, чтоб исправить ее.

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

Страницы