ROSS 2012 Рада сообщить, что 12 апреля 2012 в Москве пройдет одно занимательное мероприятие. В этот день состоится Russian Open Source Summit, одна из секций которого будет ориентирована на сообщество и посвящена разработке СПО.

Если вы интересуетесь разработкой, передовыми технологиями и ведущими мировыми открытыми проектами, вам стоит прийти. И вот почему. В рамках секции планируется 4 доклада от 4 очень интересных людей. Про каждого из них хочется сказать отдельно.

Ян Вилдебоер
Представитель компании Red Hat и ярый сторонник open source в жизни. Ян уже много лет работает в Red Hat и является специалистом по разработке в области открытых проектов для критически важных задач на самых разных архитектурах. Неизменный участник самых ярких open source событий в Европе и по всему миру, популяризатор open source идей. И, кроме всего прочего, человек с отличным чувством юмора.

Петр Леменков
Активный участник проекта Fedora, мейнтейнер множества пакетов и крайне интересный собеседник. Петр является одним из наиболее известных в Fedora участников российского сообщества и хорошо знаком с внутренней жизнью крупных международных open source проектов.

Константин Лепихов
Координатор проекта Mozilla Россия, технический администратор. По собственному заявлению, Константин "хочет сделать Firefox самым популярным браузером в мире." И у него отлично получается двигаться в этом направлении.

Игорь Сысоев
Создатель высокопроизводительного веб-сервера nginx, пользующегося популярностью во всем мире. Число сайтов, обслуживаемых nginx, превышает 56 миллионов. А сам nginx является самым популярным веб-сервером доменной зоны .ru. Среди известных проектов его используют: Yandex, Wordpress.com, vk.com, Facebook, Rutracker.org и многие другие.

С программой Саммита можно ознакомиться на официальной странице. Секция для разработчиков начнется в 15:30 в зале "Алдан".
Для участия нужна предварительная регистрация, будьте внимательны!

Приходите! Будет интересно! :)

Разработчики systemd и dracut на DebConf

Lennart Poettering, Kay Sievers, и Harald Hoyer посетят предстоящий DebConf 2013 в Швейцарии, где 12го и 13го августа будут убеждать недоверчивых дебианщиков, что им надо переключаться на dracut и systemd. Как вы уже наверное слышали, коммьюнити Debian сейчас обсуждает на что переходить с SysV - на systemd или Upstart, и наши друзья и коллеги поедут развенчивать разные байки про загрузчики, UEFI, systemd, initrd и прочие компоненты Base OS. Не пропустите!

Официально анонсирован совершенно новый дистрибутив для быстрого создания виртуальных машин и контейнеров, CoreOS. В отличие от другие дистрибутивов, которые либо переклеивают обои, либо выкидывают компоненты, в которых не разбираются, в этом дистрибутиве есть четко поставленная цель - сделать систему пригодной для быстрого развертывания на ее базе решения в облаке, в виртуальной машине, в кластере. В числе создателей и наш товарищ, известный гентушник и дистрохоппер Greg Kroah-Hartman, уже признавший в своей ленте G+, что он напуган количеством революционных концепций в новой системе.

В качестве базовых кирпичиков используется systemd, Portage (RPM был бы лучше, но для него просто не существует средств сборки системы или части системы, а у гентушников все уже готово), Docker, и CRIU, разработка наших друзей из Parallels. В качестве языка для системных утилит используется не довоенный Perl или дореволюционный ANSI C, а Google Go. Разработчики обещают бесшовные обновления, и уже реализовали довольно много новых концепций, которые еще только запланированы в systemd. Например, замена устаревшего механизма хранения конфигурации в текстовых файлах в директории /etc на высокопроизводительное KV-хранилище с JSON RESTful API. В отличие от реестра Windows в нем предусмотрены развитые сетевые возможности по синхронизации изменений, PUBSUB.

Новости Wayland

В последние пару недель разработчики Wayland были сильно заняты, и теперь им есть что показать!

Уже известный вам участник Fedora ARM SIG Rob Clark добился полной поддержки Wayland (Weston работает стабильно) на разрабатываемом им видеодрайвере freedreno. Пока ссылки у нас нет, т.к. разработчики это плохие пиарщики (и наоборот), но Rob обещает скоро рассказать о результате.

Carlos Garnacho, инженер Lanedo, участник GNOME, непонятно почему все еще использующий Ubuntu, разработал и анонсировал Mechane, новый графический тулкит. Он начал с реализации Wayland, несмотря на то, что в Canonical теперь решили от него отказаться. Но мы, конечно, заинтересованы в его работе, и надеемся, что еще один заблудший программист присоединится к нашему коммьюнити, которое ценит разработчиков и разработку, а не бесполезный пиар.

Ситуация с видеодрайверами продолжает улучшаться! Переключающаяся графика вообще становится реальностью благодаря работе инженера Red Hat и участника Fedora и Debian David Airlie над DRM PRIME (из последнего, он добавил автоматическое отключение видеокарты в видеодрайвере, а не через юзерспейс). На базе этого независимый разработчик Axel Davy добился в Wayland рисования окна на встроенной видеокарте Intel с помощью дискретной видеокарты ATI/AMD (т.н. "GPU offloading"). Пока кода нет, но он выхожил видеоролик-демонстрашку на YouTube. Если уж заговорили про AMD - Alex Deucher объявил, что в ядре 3.11 управление питанием на видеокартах AMD можно считать стабильным. Можно, конечно, и не считать, учитывая, что открытые драйверы все еще тормозят по сравнению с закрытыми, но давайте не будем огорчать Алекса в его очередной маленькой победе. Возвращаясь к двум видеокартам - одновременная работа нескольких видеокарт в связке все еще недоступна для устаревшей архитектуры X11, так что любители юниксвэя могут радоваться - мы пока отстаем лет на 15.

И наконец, это официально - в Fedora 21 GNOME будет работать на Wayland!

С международным днем системного администратора!



На фото наш коллега, участник Fedora и сисадмин kernel.org, Konstantin Ryabitsev пытается разобраться, что же такого Линус Торвальдс "ничего не делал", после чего ничего не работает.

Поздравляем OpenStack с третьей годовщиной!

19 июля 2010 года NASA и Rackspace было объявлено о создании OpenStack. Запоздало, но поздравляем с годовщиной! День рождения, это повод подвести итоги и рассказать о новостях за недавнее время.

Начнем с того, что если вы до сих пор не понимаете, как это все работает, то Victoria Martínez de la Cruz опубликовала в своем блоге схему взаимодействия элементов OpenStack. Теперь-то все должно быть понятно.

Компания RightScale опубликовала результаты своего последнего исследования состояния облачных технологий (PDF), в котором утверждается, что единственный непобежденный конкурент у OpenStack, это Amazon, но сзади не дают расслабиться Eucaliptus, продукт наших друзей из одноименной компании, и CloudStack, разрабатываемый на кладбище opensource-проектов, Apache Software Foundation.

Вскоре, в октябре 2013, выходит следующая версия OpenStack, с кодовым именем "Havana", и наш коллега, инженер Red Hat и участник проектов Fedora и Asterisk, Russel Bryant в своем блоге рассказал о грядущих изменениях в и нововведениях.

В этом году Red Hat доработала распределенную файловую систему GlusterFS до полного соответствия требованиям OpenStack, и полностью открыла все ее компоненты. Но на самом деле, надо признать, подход GlusterFS к распределенным сетям критикуется некоторыми специалистами. Например, на прошедшей конференции RICON, организуемой разработчиками Riak (который с недавних пор доступен в Fedora из коробки), инженером Seagate, James Hughes, было сказано, что "Any distributed filesystem like GlusterFS or Ceph that tries to preserve the POSIX API will go the way of the dodo bird". Разработчик GlusterFS и CloudFS/HekaFS, инженер Red Hat и участник Fedora, Jeff Darcy несогласен как минимум полностью с утверждением о скором вымирании этих систем, хотя-бы потому, что GlusterFS поддерживает сразу несколько API для доступа к данным, и постепенно становящимся неактуальным POSIX не является исключительным механизмом для доступа к данным в GlusterFS.

Кстати, возвращаясь к конкурентам OpenStack, Jeff Darcy приводит интересные графики по IO для хранилищ у OpenStack и конкурентов. Обратите внимание, когда будете выбирать решение, - ситуация очень непростая, а цены отличаются существенно.

Уже известный вам наш коллега, участник Fedora и член технического комитета OpenStack, Mark McLoughlin, регулярно публикует отчеты с заседаний управлющих советов OpenStack - за май 2013 и за июнь 2013. По нашему мнению, это высокая степень открытости проекта, и процесса принятия решений внутри него, что выгодно отличает OpenStack от многих других организаций и компаний, занимающихся OpenSource.

Помимо организационных вопросов Mark McLoughlin публикует и статьи технического характера. Одна из последних, это его обзор различных способов асинхронного программирования в Python (на котором написано очень многое в OpenStack).

В блоге Mirantis на Habrahabr появилось еще несколько статей по OpenStack-тематике. Почитайте обязательно, если интересуетесь вопросом.

Matthew Miller, участник Fedora Cloud SIG и инженер Red Hat, выступил с предложением разделить Fedora на несколько частей - базовая часть, общая для всех, и надстройки, создаваемые в рамках рабочих групп. Базовая часть будет иметь необычное и свежее название - Fedora Core. Его предложение уже с интересом изучается русскоязычными аналитиками на OpenNET.ru

Проблема, которую пытается решить Matthew, заключается в том, что у нас, внутри проекта, есть части, движущиеся с разной скоростью. Например, Firefox и ядро обновляются быстрее всех других, и независимо от версии релиза. Получается, что внутри системы с якобы фиксированным API/ABI, есть части, разрабатываемые по принципу rolling release. Это не единственный пример - разработка приложений Cloud и Virtualization идет настолько быстро, что жесткие требования к API/ABI внутри релиза просто связывает руки мэйнтейнеру, заставляя его тратить много времени на не очень интересную и осмысленную работу по бэкпортированию патчей в старые версии. Опять же пользователи порой хотят и посидеть, и поплясать одновременно - чтоб были стабильные версии всего, кроме вот того и того, которые, как пользователю хочется, должны быть самые распоследние. Мэйнтейнерам постоянно регулярно нарушать политики по недопущению смены API внутри релиза, и Matthew хочет декриминализировать эту практику, выделив проблемные области в особенные сущности. В слайдах он приводит ряд примеров, когда существующая ориентация на пакеты (RPM) мешает, например, установка последней версии приложения из Git.

К сожалению, его небесспорное предложение прямо сейчас полностью несовместимо с существующей инфраструктурой. RPM, являясь, самой продвинутой системой управления пакетами, не имеет развитой инфраструктуры сборки и пересборки, доступной продвинутому пользователю. Не хватает многих нужных функций. Например, сервис для т.н. "chain builds" появился лишь недавно, и, к сожалению, пока непонятно каково его будущее, и какова скорость развития. Получается, что каждый дистрибутив поднимает свои системы для решения этой задачи. Просто сидя, скажем, на 17й Fedora, выбрать пакеты из Rawhide, чтоб они пересобрались для 17, кликая мышкой по чекбоксам не получится - инфраструктуры для этого пока нет. Непонятно, что делать с багзиллой, на какие компоненты открывать тикеты, в случае нахождения ошибок в таких вот пересобранных пакетах? Неясно, как в этой системе будут обеспечиваться повторяемость результатов и идентичность систем, если какие-то компоненты будут плавно изменяться со временем. Что касается сборки пакетов из VCS, то этот таг spec-файла RPM только начинает входить в оборот у мэйнтейнеров, и пока несет лишь информативную нагрузку.

Идеи, конечно, возникли не на пустом месте. Уже обсуждалось разделение EPEL на ряд слоев, обновляющихся с разной скоростью, плюс недавно Red Hat официально представила Software Collections, содержащие актуальные версии современного ПО для разработки. Некоторые аналитики даже поспешили сделать вывод, что Red Hat нужно срочно обкатать новую технологию на тестовых хомячках перед тем, как выпустить ее в продажу, но, разумеется, это беспочвенные домыслы, и низкопробная конспирология.

Так или иначе, это очень хорошо, что были очерчены некоторые негативные моменты, и создан добротный shitstorm тред в мэйллисте. Fedora Project, в отличие от некоторых других дистрибутивов, никогда не сторонилась радикальных перемен, если этого требует историческая необходимость. Например, не так давно мы вновь переосмысливали наше место в жизни, в очередной раз уточняя для кого мы, кроме нас самих, делаем дистрибутив и инфраструктуру? Раньше все было просто - ведущие разработчики OSS и активные квалифицированные (умеющие пользоваться diff и patch, как минимум) пользователи, желающие сотрудничать, это был наш контингент. Нас всегда было немного, порядка 10%, но мы всегда были людьми, которые создают почти весь Open Source, сеть Internet и все сложные индустриальные решения, и это было просто и понятно. Но в последнее время мы заметили ряд существенных изменений:

  • Взрывной рост Internet совпал с растущей популярностью Mac OS X среди разработчиков
  • GitHub создал для разработчиков социальную сеть, которую все разработчики так долго ждали, повысив связность коммьюнити. Появление GitHub полностью изменило то, как выпускается открытое ПО, одновременно сделав Git де-факто стандартом разработчика, растоптав нескольких конкурентов.
  • Появление Cloud и Virtualization технологий в датацентрах. Это радикально изменило то, как можно разворачивать, обновлять, и масштабировать системы.
  • 3D-принтеры, ARM, Maker-культура, Open Hardware
  • Слом застарелых стереотипов о том, как должен выглядеть десктоп, и каковы задачи, на нем решаемые. Появление сразу букета новых решений (спасибо, GNOME 3, ты показал пользователям, что существует много других вариантов!) и нового класса мобильного оборудования.


Все это приводит к тому, что коммьюнити Fedora Project обязано меняться, подстраиваться под разработчиков нового оборудования и его пользователей, участвовать в мероприятиях по Open Hardware, включать самое последнее ПО для виртуализации и облаков, развивать новейшие десктопные технологии, не забывая предоставлять возможность выбора, создавать механизмы для "кастомизации" дистрибутива, желательно без установки gcc и rpmbuild, идти на компромиссы при установке и обновлению ПО. Кое-что у нас получается, кое-что пока не очень (особенно по инфраструктуре, где мы всегда рады новым добровольцам), но главное - у нас никакой стабильности никакого застоя. Наоборот - градус только растет, и веселье только начинается. Присоединяйтесь к нам, т.к. во-1 сейчас у нас для начинающих очень много возможностей увековечить себя, а во-2 мы играем ключевую роль в принятии решений о том, каким будет Open Source в будущем!

Регулирование подсветки на Windows 8 compatibility устройствах побеждено

Вчера ( 21.07.2013 ) в ядро Linux были включены несколько патчей, которые решают проблему регулирования подсветки на некоторых устройствах.
Скоро Linus Torvalds выпустит Linux 3.11-rc2. В этой версии ядра уже интегрированы все патчи.
Суть проблемы заключается в следующем:
Windows 8 представила новую политику управления подсветкой, чтобы графические драйверы управляли ей.
Эта проблема проявляется у различных поставщиков:
  • Lenovo - некорректное поведение
  • Некоторые Dell - полный отказ
  • Возможно другие
Самое простое, что можно сделать - это отключить ACPI управление подсветкой, если прошивка указывает на поддержку Windows 8, но вполне возможно, что некоторые графические драйверы могу по-прежнему использовать функциональность ACPI как основную. Один из патчей легко отключает регулирование подсветкой через ACPI на машинах, совместимых с Windows 8, когда используется Intel GPU. Его можно применить для AMD, Nvidia и других видеокарт, но на данный момент мы не имеем сообщений, что там сломалось управление подсветкой.

На данный момент ( спустя более, чем полгода ) мы интегрировали в ядро 4 патча:
Первый патч от Aaron Lu экспортирует ACPICA переменную из которой можно понять, считает ли BIOS, что мы совместимы с Windows 8.
Второй патч от Matthew Garret инициализирует ACPI видео, даже если он не будет использоваться после (что необходимо для управления подсветкой на ноутбуках Thinkpad).
Третий патч реализует обходной путь для i915. Берём на себя управление подсветкой, если прошивка думает, что мы имеем дело с Windows 8. Данный патч основывается на работе нескольких разработчиков, в том числе Matthew Garrett, Chun-Yi Lee, Seth Forshee и Aaron Lu.
Последний патч от Aaron Lu заставляет нас идти вслед за Windows 8, сообщив прошивке с помощью метода _DOS, что она не должна автоматически изменять яркость так, что яркостью было бы невозможно управлять через GUI.

Наш товарищ, велосипедист и участник Fedora ARM SIG Jon Masters, опубликовал свои рекомендации разработчикам оборудования на базе AArch64. Он входит в Linaro Technical Steering Committee от Linaro Enterprise Group, поэтому можно быть уверенным, что его рекомендации вскоре будут стандартизированы.

В стандарте на AArch64 будет указываться, что оборудование должно использовать UEFI, грузиться без дополнительных загрузчиков, и использовать ACPI, а не Device Tree. В целом, это все повторяет архитектурные решения, использованные в референсной AArch64 платформе, спроектированной при его помощи. Больше не нужно будет возиться с U-Boot, а вместо этого придется возиться с UEFI. Одновременно с уходом в прошлое U-Boot, уходит и DTC (и это после того, как его только-только начали внедрять ARM-разработчики) - его даже немного жалко, т.к. это был первый существенный шаг к стандартизации ARM-оборудования. С другой стороны, это очень здорово, что уровень унификации ARM достигает уровня x86/x86_64 машин. Как сказал наш коллега, Adam Jackson, Linux, это не выбор, это жесткая стандартизация, - повторим за ним это еще раз.

К сожалению, Jon отключил комментации у себя в Google+, поэтому обсуждение его рекомендаций (высказанных в довольно приказной форме, что отметили некоторые разработчики) идет в ленте Google+ его коллеги по разработке ядра Linux, инженера Intel и участника Fedora, Arjan van de Ven.

Вы уже могли слышать, что группой заинтересованных лиц велась работа по интеграции SELinux в Android, и он там уже добавлен с версии 4.2. Но существует много устройств, на которых Android 4.2 никогда не будет доступен по официальным каналам, да и на многих устройствах с версией 4.2 он тоже не будет работать (это зависит от производителя устройства, и его туманных и противоречивых маркетинговых соображений). Поэтому очень здорово, что проект CyanogenMod официально объявил, что в проекте начат переход на SELinux. Уже отправлены на рассмотрение первые патчи. Пока SELinux работает в permissive режиме, так что устанавливайте, собирайте статистику, отправляйте в багтрекер проекта. Без тестирования пользователями тут не обойтись. Главное, не отключайте его, если какое-то кривое проприетарное приложение начнет жаловаться.

Страницы