Опубликовано 23.10.2014 10:24 пользователем Peter Lemenkov
Выложили видеозаписи всех выступлений с ежегодного мероприятия Gstreamer Conference, которое проводится с 2010 года. Enjoy!

Опубликовано 22.10.2014 23:45 пользователем Peter Lemenkov
Приближается еще одно мероприятие - OpenStack Summit November 2014 Paris. Оно состоится в Париже, с 3го по 5е ноября (2го начинается регистрация, а 6го и 7го тусовочные дни). Расписание очень плотное, и наших коллег там будет прилично. Ожидается заезд наших соотечественников из компании Mirantis, от которой будет представительная программа, как и положено одному из лидеров разработки OpenStack.

Присоединяйтесь!

Опубликовано 21.10.2014 17:58 пользователем Peter Lemenkov
Только что анонсировали очередной митап DevOps Moscow коммьюнити:

После летнего перерыва возвращаемся к DevOps митапам. В этот раз эксперимент - будем проводить митап в будний день. К нам приедет Jérôme Petazzoni из компании Docker и расскажет нам о Docker из первых рук. Программа мероприятия будет позже. Ждите обновлений.


Мероприятие состоится 29 октября, с 18.00 по 22.00 в офисе Badoo, БЦ "Легенды Цветного", сразу напротив метро Трубная. Цветной бульвар, 2, стр. 1 Зарегистрируйтесь, чтобы получать обновления.

Опубликовано 21.10.2014 14:12 пользователем Peter Lemenkov
Вслед за списком пожеланий от разработчиков systemd, у разработчиков GNOME появился свой GNOME Kernel Wishlist.

Опубликовано 20.10.2014 15:29 пользователем Peter Lemenkov
Появилось дополнение к новости о выходе версии 1.2 утилиты для сборки RPM, mock. Michael Šimáček решил поподробнее рассказать о нововведениях в этой версии. которых больше, чем было анонсировано. И действительно, список новинок довольно значителен:

  • Уже упомянутый плугин для LVM. Это изменения для больших билд-ферм, которое будет использовать фичи LVM по созданию снапшотов. Общая пакетная база, из которой собираются rootfs для сборки, как правило, довольно значительна. Поэтому LVM должен сильно экономить время на перегенерацию roots при его использовании. Раньше мы использовали тарболы, которые распаковывались в chroot.
  • Улучшение производительности с помощью nosync при перегенерации Yum DB при сборке rootfs. В случае создания rootfs особая надежность на случай аварии не нужна, поэтому нет нужды вызывать большое количество раз fsync (man 2 fsync), что ускорит сборку пакетов.
  • Поддержка dnf. Мы уже используем dnf в быту - работает надежно, хотя порой иначе, чем yum, что замечали и наши коллеги. Пока фича считается экпериментальной.
  • Улучшенный режим журналирования. Теперь mock печатает в консоли и вывод Yum/DNF и rpmbuild.
  • Меньшее количество блокирующих операций. Некоторые операции над rootfs теперь поддерживают множественный доступ, например shell-доступ к ней, прямо в процессе сборки.
  • Теперь mock может выполнять дополнительные команды Yum/DNF, например mock --pm-cmd clean metadata-expire.
  • В процессе сборки rootfs можно выполнять команды --enablerepo и --disablerepo пакетного менеджера.
  • Долгожданная команда short-circuit, позволяющая проходить заново обвалившиеся стадии без запуска с самого начала.
  • Возможность передачи дополнительных аргументов в rpmbuild. Например для выбора алгоритма сжатия в финальном пакете.
  • Теперь можно задавать свои пути к утилитам rpm, rpmbuild, yum, yum-builddep, dnf. Таким образом можно легко подменять их своими версиями, без необходимости изменять system-wide копии.
  • Автоматическая инициализация и улучшенная очистка после завершения.
  • Поддержка Python 3.
  • Малоизвестная фича --unique-ext. Она позволяет запускать в параллель несколько сборок одного и того же пакета, с тем же названием. Напрямую это сделать нельзя, т.к. сборки будут использовать одну и ту же директорию для chroot, а благодаря этому ключу к названию добавится указанный суффикс, и конфликта не будет.


Конечно, пока наша инфраструктура неидеальна, но судя по таким новостям, мы потихоньку движемся в верном направлении!

Опубликовано 20.10.2014 13:15 пользователем Peter Lemenkov
Мы всегда говорим, что киборги-админы локалхоста, читающие логи "глазами" (например, раз, два, три), и проклинающие "бинарные логи", просто не знакомы с задачами, которые возникают, когда надо не только читать /var/log/messages, но и осмысливать прочитанное. И вот, в новых вакансиях Яндекса, мы с интересом увидели практические примеры задач на анализ логов:

Эксперт по нагрузочному тестированию
...
Продемонстрируйте свои знания
...
Вопрос 4

Перед вами пример части access-лога web-сервера, на котором работает сервис Яндекс.Погода.

[10/Jul/2010:00:13:18 +0400] pogoda.yandex.ru 2.2.2.2 "GET /chernigov HTTP/1.1" 200 "http://www.yandex.ua/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0)" 113
[10/Jul/2010:00:13:19 +0400] pogoda.yandex.ru 3.3.3.3 "GET /russia HTTP/1.1" 200 "http://pogoda.yandex.ru/27612/choose/" "Opera/9.52 (Windows NT 6.0; U; MRA 5.5 (build 02842); ru)" 119
[10/Jul/2010:00:13:20 +0400] pogoda.yandex.ru 5.5.5.6 "GET / HTTP/1.1" 302 "http://www.yandex.ru/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; InfoPath.2)" 203

Любым удобным для вас способом определите, пожалуйста, для полного лога из нескольких миллионов строк:

1) топ-3 рефереров, с которых перешли на главную страницу сервиса (/) или на страницу с прогнозом погоды в Москве (/moscow), и число таких переходов;
2) в какое время уложилось 95% запросов (время ответа в мс указано в последнем столбце каждой строки) для страниц с прогнозом погоды в Киеве (/kiev).

Из ответа мы хотели бы понять почему вы подошли к решению задачи именно таким способом и увидеть пример конкретной реализации.


и еще одна вакансия:

Стажёр-тестировщик
...
Продемонстрируйте свои знания
...
Вопрос 11

Перед вами часть access-лога веб-сервера, на котором работает Яндекс.Погода.

[10/Oct/2012:00:15:32 +0400] pogoda.yandex.by 178.122.164.78 "GET / HTTP/1.1" 302 "-" "Opera/9.80 (Windows NT 5.1; U; Edition Yx 01; ru) Presto/2.10.229 Version/11.60" "-" 0.008 - 1170
[10/Oct/2012:00:15:35 +0400] pogoda.yandex.ru 212.193.232.183 "GET / HTTP/1.0" 302 "-" "-" "-" 0.011 - 1237
[10/Oct/2012:00:15:37 +0400] pogoda.yandex.ru 78.46.121.182 "GET /kemerovo/details HTTP/1.1" 200 "http://pogoda.yandex.ru" "Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)" "-" 0.314 - 93275
[10/Oct/2012:00:15:38 +0400] pogoda.yandex.ru 93.158.129.212 "GET /astrahan/ HTTP/1.1" 200 "-" "Python-urllib/2.5" "-" 0.183 - 37160

Любым удобным для вас способом определите для полного лога из нескольких миллионов строк:

1) количество запросов для каждой секунды суток;
2) число 5хх HTTP-кодов ответа.

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


Те наши читатели, которые хоть немного знакомы с SQL, уже могли заметить, что вопросы довольно характерные. Мы бы хотели задать дополнительные вопросы соискателям:

  1. Почему хранение журнала в текстовом файле будет нерационально для решения подобных задач?
  2. Какие есть практические варианты для ведения журнала событий, которые бы позволили эффективно получать ответы на подобные запросы?

Опубликовано 19.10.2014 19:23 пользователем Peter Lemenkov

Roll up your sleeves, we may need to fork Debian

.

Опубликовано 19.10.2014 19:16 пользователем Peter Lemenkov
На прошедшем Blackhat нашли возможность получать информацию из Android-приложений, нелегально подсоединившись к Binder (23-страничная статья доступна онлайн). На первый взгляд, это какая-то сомнительная возможность, ведь присоединиться к системной шине, да еще и под произвольным именем, это само по себе непросто - "съесть-то он съест, да кто ж ему даст?". Но есть нюанс! Оказалось (увы, но внутренности Android задокументированы не очень хорошо), что даже внутри приложения Android коммуникации между различными составными частями программы происходят по шине. Поэтому добившись такого подключения, можно заглядывать внутрь приложения, вытаскивая данные. которые само приложение наружу отправлять не будет, обходя таким образом систему безопасности.

Если кто забыл, то Binder, это аналог D-Bus от Google, который уже работает в ядре. Прямо сейчас между Binder и D-Bus / kdbus есть серьезные архитектурные различия, обуславливаемые разными целями обоих решений, о которых с т.з. разработчика вы уже могли слышать. С точки зрения пользователя, существенное различие между двумя системами, это паттерны использования - в Linux обращения к шине D-Bus нечасты (можно подсоединиться утилитой dbus-monitor и оценить порядок величины), а вот Android, как показали исследователи, основывается на message passing, активно используя обмен сообщениями по шине даже внутри приложений (см. выше). Поэтому тема производительности D-Bus до недавних пор была малоинтересной разработчикам (не было особого спроса), а вот производительность в Binder была главной целью, и ради нее был принесен в жертву кое-какой функционал. Сейчас ситуация меняется. Активное использование message passing против традиционной архитектуры (shared libs + приложения, сующие друг другу разное в пайпы и сокеты), это то светлое будущее, к которому мы ведем Linux, невзирая на очаги бессмысленного сопротивления любителей заняться в одиночку юниксвэем. Именно поэтому уже началась работа по осовремениванию D-Bus, и разработчики уже добились успехов. И теперь, несмотря на более современную архитектуру Android по сравнению с "обычным" линуксом, в целом различия между ними уже не выглядят неустранимыми, и работа по реализации Binder поверх kdbus тоже идет.

Но каково текущее положение с kdbus? Наш коллега, известный борец с Linux-сепаратистами, Jon Masters, в своей заметке о ядре 3.17 и текущей разработке, посвятил несколько абзацев и состоянию kdbus:

...
Готовимся к kdbus

Результаты подготовительной работы в рамках реализации kdbus, ядерной реализации D-Bus, уже включены в версию 3.17. D-Bus, это система IPC (Inter-Process Communicaton), изначально разработанная в коммьюнити FreeDesktop и GNOME (сейчас также используется в KDE и Qt4). D-Bus позволяет системным сервисам регистрироваться в некоем глобальном пространстве имен, и затем отправлять и получать сообщения. Сервисы могут быть запущены в ответ на поступающие в их адрес сообщения, как уже работают многие десктопные службы современного Linux. В обычной конфигурации D-Bus запускается, чтобы предоставлять системную шину, по которой общаются системные сервисы, и по шине на каждый пользовательский логин для пользователей. Обычно D-Bus предоставляется демоном dbus-daemon, но ведется работа по переносу части его функций в пожирающий весь системный функционал systemd. И как часть проекта по переносу, идет работа по улучшению его производительность используя ядерный механизм.

Модуль ядра, kdbus, предназначен для уменьшения количества взаимодействий, необходимых для того, чтобы один сервис послал сообщение другому, используя механизм D-Bus. Будучи полностью userspace-решением, от существующих сервисов требуется системный вызов для посылки сообщения, который потом будет обработан (легковесным, но тем не менее) демоном dbus-daemon, и наконец получен требуемым адресатом сообщения после еще нескольких пересылов внутри и наружу ядра. Чтобы не требовать большого числа переключений контекстов между процессами (известных, как "задачи" внутри ядра, kdbus устраняет необходимость в специализированном демоне во многих случаях. Вместо этого сообщения могут быть напрямую посланы и получены по кратчайшему маршруту. В некоторых случаях, однако, может понадобиться более серьезная обработка, так что системный сервис останется, особенно для legacy-приложений.

Для того, чтобы kdbus функционировал, в ядро нужно добавить некоторые изменения (кроме того, что туда надо включить сам kdbus. Эти изменения включают memfd (не так давно добавленный), механизм, которые предоставляет zero-copy разделяемую память между процессами с использованием файловых дескрипторов, как используются традиционные файлы. Рука об руку с этим механизмом идет система file sealing ("запечатывание регионов памяти" для предотвращения их изменений), т.к. необходимо добиться того, чтобы посланное см помощью memfd сообщение можно было разобрать в принимающем процессе без риска того, что посылающий процесс модифицирует сообщение после посылки, прямо в доступной ему области памяти. Как только memfd "запечатан", содержимое не может быть изменено посылающим процессом. Типичная схема посылки сообщения с помощью kdbus происходит следующим образом - отправитель выделяет память получая ее memfd, создает в этой памяти сообщение, запечатывает memfd и отсылает его в kdbus. Т.к. kdbus, это ядерный механизм, то передача будет производиться легко, "zero-copy". Ядро будет использовать несколько классических трюков управления памятью, чтобы напрямую передать массив данных по memfd.
...


Ну это вкратце, как kdbus устроен. Но без потребителей, это будет лишь сложная и забавная погремушка. Первым потребителем kdbus видимо станет systemd, а затем на него может перейти Android. Но уже сейчас у GNOME появились планы по использованию kdbus. Конечно, переход GNOME на kdbus вызовет дополнительные проблемы у устаревших операционок, которые уже еле-еле справляются (несовместимые между собой форки BSD, непопулярные дистрибутивы, неперешедшие до сих пор на systemd). Действительно, некоторые наши коллеги сначала обещали, что GNOME будет поддерживать совместимость с устаревшими системами, без systemd, но сейчас это становится все сложнее и сложнее, и через несколько релизов мы перестанем ее поддерживать.

Опубликовано 17.10.2014 17:35 пользователем Peter Lemenkov
Оказывается, в США есть закон, запрещающий свободный экспорт криптографических технологий в другие страны (не тем нескольким бедолагам, что всем известны, а вообще во все страны), и Intel под него попал. Их наказали на 750 тысяч долларов (штраф мог быть гораздо больше, но Intel пошел на сотрудничество со следствием) за неавторизованный экспорт криптографии их дочерней компанией, Wind River Systems, государственным организациям Китая, Гонконга, России, Израилю, ЮАР и Южной Кореи. Ну мы, конечно, все понимаем, но остается вопрос - а Израиль то за что?

Мы, в Fedora Project, тоже вынуждены соблюдать законы США, и их экспортные ограничения, так что внимательней читайте наши документы. Например, пункт "C":

By downloading Fedora software, you acknowledge that you understand all of the following: Fedora software and technical information may be subject to the U.S. Export Administration Regulations (the “EAR”) and other U.S. and foreign laws and may not be exported, re-exported or transferred (a) to any country listed in Country Group E:1 in Supplement No. 1 to part 740 of the EAR (currently, Cuba, Iran, North Korea, Sudan & Syria); (b) to any prohibited destination or to any end user who has been prohibited from participating in U.S. export transactions by any federal agency of the U.S. government; or (c) for use in connection with the design, development or production of nuclear, chemical or biological weapons, or rocket systems, space launch vehicles, or sounding rockets, or unmanned air vehicle systems. You may not download Fedora software or technical information if you are located in one of these countries or otherwise subject to these restrictions. You may not provide Fedora software or technical information to individuals or entities located in one of these countries or otherwise subject to these restrictions. You are also responsible for compliance with foreign law requirements applicable to the import, export and use of Fedora software and technical information.


Мы не знаем, является ли скачивание с сайта https://fedoraproject.org/en/get-fedora экспортом, ре-экспортом или передачей, и уж тем более непонятно, скачивание с зеркала внутри страны это экспорт или нет, но если вы с помощью нашего дистрибутива мастерите беспилотники или, как Jeff Garzik, планируете запускать спутники в космос, то немедленно проконсультируйтесь с адвокатами.

Все это сильно разочаровывает нас. Тускнеет миф о Благословенном Валиноре, Стране Всеобщей Свободы, и, к сожалению, такие новости еще и подталкивают репрессивные правительства к дальнейшим запретительным шагам.

Но есть и хорошие новости! GitHub значительно переработал свою политику по отношению к DMCA-запросам. В последнее время на компанию подвалило запросов на удаление различного ПО с сайта, и хотя они публикуют их в репозитории, прозрачности и справедливости не хватало. Теперь пользователю дается 24 часа на реакцию, и теперь форки не будут автоматически удаляться - только если жалобщик потребует. В целом это гораздо лучше, чем было, и новость уже получила одобрительные отзывы на профильных сайтах, например на TorrentFreak.com.

Опубликовано 17.10.2014 14:51 пользователем Peter Lemenkov
Наконец-то вышел OpenStack 2014.2 Juno (новость уже обсуждается на OpenNET.ru). Интересно сравнить участие компаний по сравнению с предыдущим 2014.1 Icehouse.

Было
Стало


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

В новшествах OpenStack 2014.2 довольно много всего, но особо бы хотелось отметить сетевую подсистему. По списку новых плугинов видно, что движение в сторону SDN очень серьезное. Мы не раз уже говорили, и повторимся, что SDN, это следующая (или уже нынешняя) горячая тема.

Недавно Linux Foundation объявило о создании открытой платформы для виртуализации компонентов сетей, Open Platform for NFV Project (OPNFV). Платформа будет построена на базе уже готовых компонентов, таких, как Linux, OpenStack, OpenDaylight, и т.п., о чем с гордостью сообщил в корпоративном блоге известный вам Neela Jacques.

Red Hat, разумеется, собирается играть активную роль в этом проекте, и обладает собственным видением ситуации (и многочисленными разработчиками и неофициальным влиянием на другие коммьюнити опенсорс-разработчиков. Ознакомьтесь с выступлением Chris Wright на Collaboration Summit 2014:



...и комментариями нашего коллеги, Mark McLoughlin, на эту тему. Можно полагать, что если будет реализована хотя бы часть задуманного в рамках создания открытой виртуализированной распределенной архитектуры, то проприетарные системы уже никогда не догонят открытые. Не поэтому ли некоторые проприетарные вендоры присоединяются к OpenStack? Ну, может не только потому, но в т.ч. и потому.

На самом деле у проприетарных вендоров будет в руках сильное оружие (и хороший источник дохода) - патенты. Т.к. законы США распространяются на весь мир, то не учитывать роль патентных троллей нельзя. Open Invention Network недавно предупредило честных людей, что у коммьюнити OpenStack нет никаких возможностей защищать своих пользователей и разработчиков от патентных троллей. Сейчас OIN расширяет свой защитный экран на OpenStack, и уже прикрывается 33 Python-пакета. Сейчас к OIN начали активно подключаться новые пользователи. Проняло даже стартапы и азиатские компании, которые, как и некоторые отечественные игроки рынка, раньше не верили, что законы США распространяются и на них. Неудивительно, т.к. ущерб от американских патентных троллей стабильно растет.

И напоследок о хорошем. Вышел Docker 1.3.

Страницы

Get Fedora! Скачать RFRemix 21!
Slax Linux

Обменная кнопка проекта:

Хостинг для проекта предоставлен компанией FastVPS

Сайт поддерживается российским сообществом Fedora, Red Hat не несет ответственности за его содержимое.
Обратная связь |Благодарности |Правовые положения Fedora | Торговые марки Fedora