Russian Fedora

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

Content (108 страница со старыми записями)

Red Hat теперь участник Node.js и другие новости

Red Hat стал платиновым корпоративным спонсором коммьюнити Node.js, присоединившись к хорошему коллективу из Microsoft, IBM, PayPal и прочих. Теперь под контроль наших коллег попадает и одна из самых популярных JS-платформ. Для стандартизации, это лишь в плюс. Ну, наверное, это связано с покупкой FeedHenry.

Вообще, насчет Microsoft как-то неудобно получается. Недавно наши коллеги запустили процесс удаления предложенных Microsoft расширений для стандарта C11 (об этом уже писали на OpenNET.ru), а тут придется с ними сотрудничать. Но, кстати, удалять собрались уже четвертый неправильный способ работы со строками, так что его никому особо жалко не будет.

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

Продолжается эпопея с поддержкой архитектуры POWER8 в Ocaml. В апстриме был бэкенд для 32-битного PowerPC, а вот для 64-битных процессоров всегда была какая-то проблема (ну с этой архитектурой из-за снобизма их вендоров по-другому и быть не могло). Наш коллега, David Woodhouse давным давно написал бэкенд для ppc64, который, к сожалению, выкинули, т.к. железо от Apple медленно умирало (в смысле физически), затем Sony залочило Playstation 3, а другого доступного железа в продаже и не было никогда (см. "снобизм вендоров"). В прошлом году появился новый (третий) бэкенд для ppc64le от IBM, но тоже в формате out-of-tree патчей. И вот, наконец-то, базируясь на разработках Red Hat и IBM в апстриме написали свой, четвертый бэкенд для архитектур ppc / ppc64 / ppc64le. Понятно, что унифицированный бэкенд гораздо лучше, чем разномастные сторонние патчи, поэтому наш коллега, Rich WM Jones, объявил, что Ocaml-пакеты в Fedora теперь будут собираться с помощью upstream-бэкенда.

Кстати, насчет доступных и надежных дистрибутивов для альтернативных платформ - CentOS уже появился для i686, и скоро появится для ppc64 / ppc64le. Работа по сборке CentOS под armv7hl также почти закончена.

Новости systemd

Сформирована программа первого systemd.conf 2015. Подтянулись и спонсоры, так что будет интересно.

Интересно, что еще продолжают биться об стену создатели альтернативных init-систем. Совсем недавно появилась еще пара - beginning и govisor (про него даже написали на OpenNET.ru). Одно время программисты писали десятки если не сотни window-менеджеров, потом медиаплейеры, а вот теперь стали писать init-системы. Ну что сказать, уровень растет!

С ростом интереса к базовым компонентам, появился спрос на исторические материалы. Мы неоднократно говорили, что SysVinit был признан устаревшим 10-15 лет назад, вот, например, обратите внимание на инициативу GNOME-разработчика Seth Nickell (опять эти гномеры!). В этой связи интересно посмотреть на хронологию событий, приведших к появлению нынешнего лидера.

Вышедший не так давно systemd 226 (новость на OpenNET.ru) интересен тем, что он не очень интересен. Кроме изменений в systemd-networkd там унифицирована работа демона D-Bus и современного kdbus. Требуется самый последний dbus 1.10, которого нет даже в Fedora 22, и мы видим четкий эволюционный путь - через работу с dbus 1.10 к kdbus в следующем релизе (получается, что уже 24).

К самому D-Bus стали присматриваться пристальнее. Как раз, когда решили менять - вот вовремя то! Ну, конечно, лучше поздно, чем никогда. Так или иначе, народ уже увидел, что в dbus содержится пересекающаяся функциональность с init-системой, и это плохо. Где же вы раньше были?

К сожалению, вновь появившиеся тесты производительности dbus vs. sd-bus vs. kdbus + sd-bus противоречат результатам синтетических тестов чистого kdbus полуторагодичной давности. Впечатление такое, что Poettering и его команда что-то такое в sd-bus наворотили, и там теперь серьезный затык. Пока переходить на kdbus пожалуй не стоит. Будем надеяться, что это, все-таки, проблема в sd-bus, и инженеры Google не столкнутся с такими проблемами, прежде чем начнут перевод Android на kdbus.

И из других новостей - вышел PulseAudio 7.0. Теперь с socket activation по TCP!

ScyllaDB

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

Наши друзья из OSv представили еще один проект в букете своих технологий - ScyllaDB. Это реализация Cassandra на языке C++, что традиционно для OSv. Как говорят авторы, получилось в 10 раз быстрее, и им удалось добиться миллиона транзакций в секунду на одной ноде.

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

image0По нашему мнению, различий от оригинальной Cassandra не так и много

Для сборки ядра теперь потребуется openssl-devel

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

Известный хулиган и матершинник, Linus Torvalds, одобрил включение в ядро пары патчей, благодаря которым для сборки ядра с цифровыми подписями модулей теперь потребуется openssl-devel. Т.к. Linus использует Fedora, то он проверял лишь с openssl-devel, а в Debian и Ubuntu надо использовать libssl-dev или что-то типа того. Конечно, туда современные ядра добавят с традиционной задержкой, так что волноваться не о чем.

Поздравляем с днем знаний!

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

Наше дружное сообщество поздравляет учащихся с началом учебного года! Помните, что ученье - свет, а неученье - чуть свет, на работу.

image0

Слияния и объединения

VMware уже просто кричит о контейнерах в своем продукте. Популярность OpenStack пошла им на пользу, как мы видим.

Если честно, немного страшновато - откроешь какой-нибудь ZDNet или TheRegister, и там в каждой статье контейнер на контейнере, и экcперты, прославляющие этот величайший технологический прорыв Человечества со времен электричества. Мы-то знаем, что "контейнер", это обычный процесс, к которому в таблице процессов добавлены метки "namespace" и "control groups", которые учитываются при его работе, но люди, принимающие решения, похоже этого не знают, и всерьез сравнивают с виртуализацией и кластерами "дооблачных" времен. Есть растущее ощущение, что ушедший в ультразвук энтузиазм по поводу контейнеров обернется ужасающим разочарованием. Но пока этого не произошло, давайте наслаждаться открывшимися возможностями.

Так вот, VMware теперь рекламирует не виртуализацию, а контейнеры. Нам это нравится, т.к. это благоприятно сказывается на блудном сыне VMware, компании Pivotal, которая и помогает VMware создавать новую платформу (благо у них уже есть открытая платформа - Cloud Foundry).

Для нас Pivotal, конечно, это прежде всего люди, разрабатывающие нашу любимую шину сообщений - RabbitMQ. На базе нее построен обмен сообщениями в OpenStack, и хотя есть попытки использовать конкурирующие AMQP-решения (Qpid), RabbitMQ с места просто так не сдвинуть. Он написан на Erlang, что заведомо повышает качество кода и надежность системы. Нужно отметить, что рядом лиц затрачиваются огромные усилия по включению варианта на базе ZeroMQ, но есть основания предполагать, что это не взлетит никогда. Если кто не в курсе, то у ZeroMQ помимо ряда социально-организационных проблем, есть серьезные недостатки и ограничения, которые следует учитывать. Наши друзья и коллеги, в т.ч. и участники Moscow Erlang User Group, как-то скинулись и переписали ряд особо гадких особенностей ZeroMQ. Получилось внушительно.

http://s00.yaplakal.com/pics/pics_original/3/0/0/612003.jpg

Коллеги узнали, что ты решил использовать ZeroMQ

Конечно, с RabbitMQ есть нюансы использования, все-таки CAP-теорему так просто не объехать, но все ведущие компании-разработчики OpenStack сейчас нанимают Erlang-разработчиков, и можно ожидать, что в ближайшее время ситуация улучшится. Сейчас RabbitMQ рассматривается ими как загадочная шкатулка с музыкой, и даже в Red Hat проблемы с ним решаются извне, не трогая код продукта, а привычно перенастраивая окружение от ядра до Glibc.

Интересно, что VMware, похоже понимает, что главное в "контейнерах", это не сами "контейнеры", а их обвязка - средства управления, живой миграции, failover, развертывание, сетевые возможности (SDN) и многое другое. Недаром она привлекает других именно этими возможностями своих проприетарных продуктов. Тем не менее, не только они тут играются. Mirantis в последнее время дружит со всеми - Mirantis и CoreOS, Mirantis и Intel, и даже Mirantis и Goldman Sachs (Голдманы, как и все финансисты, очень любят открытое, даже оборудование).

Некоторые даже всерьез используют термин OpenStack Wars (как Unix Wars, только про OpenStack), но в мире OSS воевать непросто да и бессмысленно - лучше сотрудничать.

Наконец-то открыли Kinetic Storage Platform

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

Seagate, традиционный участник RICON, сдержал свое обещание открыть исходный код Kinetic Storage Platform (они пообещали сделать это на прошедшем OpenStack Summit, о чем вы уже могли слышать). В рамках проекта будет развиваться платформа распределенного хранилища данных (Software-defined Storage. К проекту уже присоединились Cisco, Cleversafe, Dell, Digital Sense, Huawei, NetApp, Open vStorage, Red Hat, Scality, Seagate, SwiftStack, Toshiba, Western Digital.

Хранилище сразу спроектировали не на базе устаревшего и неподходящего для распределенных систем стандарта POSIX (о его недостатках мы регулярно рассказываем), а как KV-хранилище с незамысловатым протоколом, использующим protocol buffers. Добавление поддержки в WIreshark будет сравнительно несложным делом.

Ну пока еще этот Kinetic взлетит, а до тех пор народ будет использовать традиционные хранилища, и их разработчикам еще работы будет много. Если вы из "Ceph vs. Gluster" выбрали последний, то наверное уже слышали, чтоб в конце весны вышла версия GlusterFS 3.7.0 (новость уже обсуждалась на OpenNET.ru). Из особо понравившихся фич можно выделить "bitrot detection", поддержка NFSv4 и pNFS, и шардинг, но новинок там гораздо больше.

Встреча разработчиков Linux-контейнеров в Москве

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

Приглашаем на встречу разработчиков Linux-контейнеров — мероприятие сообщества OpenVZ, которое пройдёт 19 сентября в московском офисе Яндекса. Оно пригодится всем, кто интересуется применением контейнеров и контейнерной виртуализацией.
На встрече вы узнаете про плюсы и минусы живой миграции контейнеров, библиотеку LibCT, новый менеджер памяти в OpenVZ.
Докладчики расскажут о решении проблемы фрагментации виртуальных дисков, применении контейнерных технологий в DevOps-процессах и особенностях использования OpenVZ в инфраструктуре крупного хостинг-провайдера.
Участие во встрече бесплатное, однако нужно зарегистрироваться.
Программа:
  • 11:00 Регистрация

  • 11:30 Живая миграция контейнеров: плюсы, минусы, подводные камни.

    Павел Емельянов, Odin

  • 12:00 Управление памятью контейнеров в проекте OpenVZ. Владимир Давыдов, Odin

  • 12:30 Перерыв

  • 12:40 LibCT и контейнеры на уровне приложений. Андрей Вагин, Odin

  • 13:10 Использование контейнерных технологий в DevOps. Дмитрий Лазаренко, Jelastic

  • 13:40 Перерыв

  • 14:30 Опыт использования виртуальных контейнеров в работе сервис-провайдера. Константин Анисимов, Русоникс

  • 15:00 CRIU: ускорение запуска PHP в CloudLinux OS. Руслан Куприев, CloudLinux

  • 15:30 Перерыв

  • 15:40 Развёртывание приложений Docker в контейнерах Virtuozzo.

    Павел Тихомиров, Odin

  • 16:10 Проблема фрагментации виртуальных дисков и способы её решения. Дмитрий Монахов, Odin

  • 16:40 Закрытие

Росийские госструктуры выбирают Red Hat!

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

Наиболее популярной ОС с открытым исходным кодом является продукт американской компании Red Hat. На его базе функционирует оборудование 25 ФГИС. Доли других ОС приведены в таблице.

Разновидности Linux, используемые в ФГИС

  Число ФГИС
Red Hat 25
Debian 15
CentOS 15
Ubuntu 11
Fedora 8
Mandriva 7
SUSE 5
МСВС 2
Alt Linux 1
Oracle Enterprise Linux 1

Данные: аналитический центр TAdviser Report, август 2015

Самым популярным дистрибутивом Unix, согласно исследованию, является FreeBSD. Доли остальных разновидностей приведены в таблице.

Разновидности Unix, используемые в ФГИС

  Число ФГИС
FreeBSD 13
Oracle Solaris 8
IBM AIX 7
HP-UX 2
Циркон 1

Данные: аналитический центр TAdviser Report, август 2015

На базе российских дистрибутивов Linux - МСВС и Alt Linux - работают серверы только трех ФГИС.