Пока в РФ собираются запрещать биткойны, весь мир переходит на использование технологии blockchain. Наши друзья и коллеги, разумеется, находятся в числе первых разработчиков и early adopters (это и Rusty Russell, и Jeff Garzik, и Warren Togami, и многие другие криптоэнтузиасты и математики). Но это было все на уровне частной инициативы. И вот, официально было объявлено, что Red Hat будет оказывать поддержку blockchain-разработчикам на базе платформы OpenShift.

Компания никогда не пропускает важные технологические тренды, такие, как виртуализация, облака, IoT. Так что совсем неудивительно, что она поддержала блокчейн. Можно предполагать, что будут и еще интересные анонсы. Напомним, что Red Hat входит в консорциум Hyperledger Prioject, нацеленный на стандартизацию и внедрение блокчейн-технологий. Это, разумеется, не случайность, а обдуманное решение, которое "выстрелит" через несколько лет.

На самом деле, запрет на биткойны в РФ ударит не только по биткойнам. Уже сейчас в РФ разрабатываются система электронного голосования на базе blockchain, и система идентификации клиентов банков, (которые, впрочем, могут исчезнуть из-за блокчейна), и это лишь несколько примеров технологий, которые будут ходить под запретом. Наш товарищ, участник Пиратской Партии России, практикующий адвокат, Саркис Дарбинян, изложил список технологий на базе блокчейна, внедрение которых в РФ будет затруднено из-за запрета на биткойны:

  • Прозрачные и дешевые финансовые операции.
  • Быстрая и безопасная идентификация пользователей и документов.
  • Электронная демократия без фальсификаций на выборах.
  • Умные контракты, которые сами контролируют свое исполнение, без посредников и юристов.
  • Надежная фиксация права собственности.
  • Открытые нефальсифицируемые реестры чего угодно.
  • Персонализированная налоговая система — вы будете знать, на что пошел каждый уплаченный в казну рубль компаниях.
  • Краудфандинговые компании путем выпуска собственных криптовалют.
  • Интернет вещей с возможностью арендовать любое устройство и быстро расплатиться с ним.
  • Децентрализованные бизнес-процессы в компаниях.


Заметили, как часто используются слова и синонимы слов "прозрачный", "открытый", "децентрализованный"? Вот то-то и оно. В этом-то и проблема.


Эксперт Госдумы оценивает очередное технологическое новшество

Не так давно Matthew помогал разбираться в печальной ситуации, когда rm -rf / окирпичивал UEFI-систему. Затем он подверг критике безопасность электрических лампочек, работающих по TCP (!) под управлением Android (!!!). И вот, на днях Matthew призвал временно отказаться от покупки Intel-ноутбуков на базе Skylake, т.к. Linux пока не может управлять электропитанием этого чипсета. Его заявление уже изучается коллегами-аналитиками на OpenNET.ru

За последнее время было не так много новостей о systemd, и даже выходы новой версии больше не ошеломляют. Дело в том, что самые большие новости о systemd в том, что не сделано, и чего планируют переделать. Об этом и поговорим.

Долгожданная функциональность управления пользовательскими сессиями, systemd user sessions, к сожалению, не будет использоваться. Ее запланировали полностью переработать. Ну жаль, что. Будем надеяться, что переделка не займет еще четыре года.

Под нож пошла и функциональность kdbus, которую недавно выбросили и из Rawhide. Вместо нее сейчас, особо не афишируя результаты, разрабатывается bus1.

Пока держится функционал systemd-networkd, но народ уже недовольно замечает, что архитектурно реализация отличается от всех остальных компонентов. Юниты systemd-networkd обрабатываются не на уровне systemd, а на уровне запущенного сервиса systemd-networkd, и поэтому присутствовать в графе зависимостей между остальными сервисами не могут. Это, конечно, проблема, т.к. не получается эффективно реализовать зависимости между объектами systemd-networkd и остальными юнитами.

Продолжает нарастать антагонизм между подходом Docker и systemd, о чем уже высказался Dan Walsh на прошедшем DevConf.cz. В последних релизах systemd, многое было сделано, чтобы облегчить ситуацию, а вот со стороны Docker контакта нет, и они последовательно отказываются включать в Docker патчи для совместимости с systemd (обратите внимание на обсуждения следующих пуллреквестов - раз, два, три, четыре). Поскорей бы народ от Docker отказывался в пользу более архитектурно правильно разработанных альтернатив (того же systemd-nspawn).

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

Латентные проприетарщики из FreeBSD все так же костыляют свой аналог systemd. Т.к. гордость, это плохая замена разуму, то они рассматривают три варианта, написанных с нуля (ну, с оговорками). Это, кстати, как мы знаем из истории BSD-систем, скорее всего приведет к еще трем несовместимым вариантам BSD. В паре вариантов предлагается взять launchd из проприетарной Mac OS X - так свободнее с т.з. любителей BSD. Во всех трех вариантах уже удалось реализовать функции systemd - неполностью и несовместимо, как это всегда и было у всех несовместимых даже между собой вариантах BSD. Ну пускай, чего уж там.

А пока можно подводить итоги перевода systemd на GitHub. Благодаря богатой функциональности GitHub, отсутствующей у ряда свободных (с их т.з.) хостингов, удалось легко прикрутить CI для всех пулл-реквестов. Доступна теперь и формальная статистика, по которой можно строить красивые графики и визуализировать здоровье проекта. Пока все выглядит хорошо!

И забавная новость - systemd теперь используется в электромобилях BMW. Как мы и предупреждали. В ВАЗ 2104 никакого systemd не будет, так что волноваться хейтерам не о чем - выбор всегда будет!

Мы поздравляем всех с днем космонавтики (или международным днем полета человека в космос, как его называют в ряде стран)!



Fedora и основанная на ней операционная система RHEL, это хорошо известные платформы для научных и инженерных проектов, и, разумеется, их активно используют в космической индустрии и астрономии. Присоединяйтесь и вы!

Коротко и официально. Все живые образы RFRemix теперь буду собираться на koji.russianfedora.pro.

Уже очень скоро выходит уже второе издание книги "OpenStack. Практическое знакомство с облачной операционной системой." под авторством нашего товарища и коллеги, Андрея Маркелова!



Данная книга рассчитана на ИТ-специалистов (системных и сетевых администраторов, а также администраторов систем хранения данных), желающих познакомиться с де-факто стандартом в области открытых продуктов построения облачной инфраструктуры типа “Инфраструктура как сервис” (IaaS) — OpenStack. Данный проект пользуется поддержкой более двух сотен компаний, включая практически всех лидеров ИТ-рынка.

Книга помимо теоретических знаний содержит множество практических упражнений и следуя изложению материала читатель сможет развернуть собственный стенд для тестирования возможностей облака. В четырнадцати главах читатель познакомится с основными сервисами облачной операционной системы OpenStack. Рассмотрены такие компоненты как: сервис идентификации пользователей, сервисы построения объектного хранилища (Swift), блочного (Glance), хранилища образов. В главе посвященной сетевым службам рассматриваются концепции программно-определяемой сети, работа с OpenStack Neutron и Open vSwitch. Также рассматриваются cервис мониторинга Ceilometer, cервис оркестрации Heat и принципы обеспечения высокой доступности облака. Кроме того, одна из глав просвещенна интеграции OpenStack и системы управления контейнерами Docker.


Что нового во втором издании?

Текст книги обновлен, чтобы соответствовать актуальным версиям рассматриваемых проектов и компонент OpenStack по состоянию на начало 2016 года (версия Liberty), а объем книги увеличен более чем на треть. Некоторые изменения второго издания:

  • Исправлен ряд неточностей и опечаток первого издания вышедшего в июне 2015 года.
  • Добавлена глава, посвященная программно-определяемой системе хранения данных Ceph и использованию Ceph совместно с OpenStack.
  • Расширен и переработан материал по работе с виртуальными машинами и сетью (агрегация узлов, зоны доступности, живая миграция, создание образов виртуальных машин, работа с сетью и многое другое). С целью лучшей структуризации материал разбит на две отдельные главы.
  • При описании настройки тестового окружения разделены управляющий, сетевой и вычислительный узлы, что позволяет нагляднее познакомиться с типичными ролями серверов при развертывании OpenStack.
  • Значительно переработан материал по работе сети в OpenStack.
  • Вопросы производительности и отказоустойчивости сервисов OpenStack выделены в отдельную главу.
  • Добавлено более пятнадцати новых иллюстраций и снимков с экрана.


    Книгу уже можно заказать на сайте издательства. Так что достаем свои бисерные кошелечки, и в магазин!

    Объявлено место проведения ежегодной конференции LibreOffice 2016 - Брно!

    Конференция состоится с 7 по 9 сентября 2016 года, так что начинайте планировать. Выбор места не удивил нисколечко. Брно, это высокотехнологичный центр Восточной Европы, каким могло бы стать Сколково, да не стало. Тут серьезный айти-кластер, базирующийся на нескольких технических ВУЗах, и большое и активное OSS-сообщество с экспатами со всего света. Наших соотечественников тут полно, а за последний год стало еще больше, и продолжает прибывать, так что не заскучаете.

    В эпоху все возрастающего цензурирования нашего интернета различными силовыми структурами разных стран мира, использование Tor становится актуальным. Вот, теперь и DNF постепенно учится работать через Tor. А пакетный менеджер вашего дистрибутива позволяет безопасно устанавливать пакеты через Tor?

    Из других новостей - приняли RFC с кодом ответа "451".

    Составлен список организаций-участников GSoC 2016. Снова полно дружественных нам проектов и организаций, так что выбирайте организацию и присоединяйтесь!

    DNF уже довольно зрелое приложение, и можно полагать, что его архитектура проверена в действии. Теперь стоит заняться и оптимизацией, в рамках чего его части будут переписаны с Python на C, а некоторые библиотеки сольются в одну общую. Новость уже обсуждается коллегами-аналитиками на OpenNET.ru и Linux.org.ru. Хочется лишь добавить, что скоро к команде разработчиков RPM и DNF присоединится один наш соотечественник, участник коммьюнити Russian Fedora. Ждите анонсов!

    Страницы