Russian Fedora

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

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

Процесс включения kdbus в ядро

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

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

Одной из болевых точек является отношение kdbus и Binder, который по описанию является полным аналогом D-Bus, но от Google. К сожалению, архитектурно он сильно отличается. Но еще более удивительно то, что несмотря на то, что вся система Android построена на базе Binder, его разработка заброшена, хотя в нем есть известные проблемы с безопасностью.

Изначально Greg KH был негативно настроен по поводу Binder, и небеспричинно, надо отметить. Внезапно его отношение не то, чтобы принципиально поменялось, но значительно изменилось. Он неожиданно решил включить его в основное дерево (сейчас оно тоже там, но в staging/). Причем аргументировал это тем, что хотя и Binder плохо спроектирован, но он широко используется (во всех Android-устройствах), и поэтому давайте тащить этот субоптимальный код в основные драйверы. Вполне предсказуемо, что реакция была от сдержанно негативной до негативной.

Непонятно, зачем Грегу сейчас срочно понадобилось тащить его в ядро, когда даже инженеры Google планируют переписать юзерспейсную библиотеку libbinder под вот-вот появляющийся в ядре kdbus.

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

Первым вопросом, породившим обсуждение, стала концепция "credentials", неких параметров доступа, прикреплявшихся к сообщению. С помощью них планируется обеспечить безопасность. Но когда их прикреплять? При открытии соединения или при посылке каждого сообщения? Eric Biederman настроен отрицательно по отношению к проверке прав доступа в момент соединения, т.к. ранее подобный подход в других случаях и в других частях ядра вызывал проблемы. Однако и присоединение credentials в момент отсылки сообщения вызывает проблемы - не получится присоединиться, получить некий security-токен для некоей операции, и сбросить права доступа, сохранив право на ту операцию.

Выбор того или другого варианта обусловливается практическими вариантами применения kdbus, а пока из потребителей этой шины есть лишь systemd (ну и Google, как перейдет на него).

Необходимо обсудить и то, какая информация должна быть послана в credentials.

Обязательно ли, например, включать командную строку приложения? Вызвала дискуссию и ситуация с именами для регистрации. Глобально видимые имена, и их использование в контейнерах приведет к тому, что придется ввести иерархическую структуру, хотя в самих именах нет ничего иерархического (приложение foo никак не соотносится к приложению bar, запущенному в том же или другом контейнере). Одновременно хочется, чтоб приложения могли регистрироваться, но не могли регистрировать на себя "чужие" имена. От этих решений зависит и организация узлов в /dev - будет ли она иерархической, или организованной неким иным образом.

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

Вообще, можно начинать уже переписывать ПО под использование D-Bus, что будет хорошим вариантом. К сожалению, помимо вполне верных утверждений о неторопливости D-Bus по сравнению с альтернативными вариантами шин, про нее еще и рассказывают, что она переусложненная. Нужно сказать, что несмотря на кажущуюся простоту, задача создания шины данных непростая.

Но на самом деле, сложность D-Bus не распространяется на API разработчика-пользователя. Lennart Poettering попытался упрощенно рассказать о том, как устроен API D-Bus с т.з. программиста на ANSI C. Будем надеяться, что это поможет разобраться в D-Bus начинающим. Конечно, использование современных языков, а не дореволюционного ANSI C, заметно упрощает использование шины, так что выбирайте правильные языки и тулкиты! image0Разработчики systemd закончили с kdbus и планируют дальнейшую экспансию

Дело Align Technology против ClearCorrect

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

Удивительным образом очередное дело в американском суде о патентах может отразиться на всех нас. Калифорнийская стоматологическая компания Align Technology еще в 2012 году подала в суд на своего пакистанского конкурента ClearCorrect, у которого было отделение в Техасе.

Ситуация обычная - якобы нарушались патенты на то или на это, и все продвигалось по известному сценарию. Но внезапно дело приняло интересный оборот, когда к нему подключилась американская комиссия по международной торговле. Они сообщили, что с их точки зрения произошел импорт товаров, которым они считают передачу по интернету неких технических документов из Пакистана в США, и поэтому это дело находится в их зоне ответственности. Как результат ITC потребовало от ClearCorrect прекратить **импорт** этих **товаров** в США.

Уточним еще раз - речь идет о файлах, переданных из Пакистана в США по интернету. Почувствовав опасность, пакистанцы подали протест, но суд вынес компромиссное решение - дело не находится в ведении ITC, но и импорт товаров, в виде скачки файлов по интернету, нужно прекратить.

Тут уже почувствовали надвигающуюся угрозу, в виде появления очень неприятного нового надзорного органа, представители Internet Association, которые поспешно выпустили **amicus brief** с изложением в нескольких пунктах своего видения ситуации:

  • Указанные промышленные патенты вообще неприменимы к передаче данных по сети интернет.
  • Если они применимы, то ITC не может связывать нарушение патентов и передачу данных, т.к. нарушение произошло после передачи данных. Сначала надо было скачать, а потом нарушать, а ITC пытается регулировать именно скачку. Можно ведь скачать и не нарушать, или нарушать, но потом. Т.е. Internet Association попытались разделить события скачки и последующего нарушения, не связывая одно с другим.
  • Даже если это единое событие, имеющее причинно-следственную связь (раз скачал, значит имел умысел нарушить), то получение документов не нарушает патент, т.к. патент на метод, это не патент на товар, которым скачанный документ является. Иначе говоря, импортированный в США документ может нарушить лишь патент на собственно документ, а не патент на товар, описанный в документе.
  • Товары, которые может запрещать ITC, и которые были запрещены в многочисленных подобных инцидентах, всегда были реальными (tangible) объектами. Т.е. Internet Association тут попытались апеллировать к ранним прецедентам, мол такого никогда еще не было. Слабенько, но засчитаем.
  • И наконец, самое сильное утверждение, это то, что ITC вообще не имеет полномочий запрета документов в сети интернет. Все, чем наделили ITC, это возможность указывать таможенникам США, что данный товар не может быть переправлен в США, а не возможность указывать зарубежным лицам и организациям, какие электросигналы могут быть излучены в сторону США.

Мы будем внимательно следить за исходом дела, т.к. если оно закончится негативно для пакистанцев, то у ITC будет возможность накладывать подобные ограничения (требовать запрета "импорта файлов в США"), например, на репозитории. К сожалению, американское законодательство сейчас распространяется на весь мир, а несогласным отключают счета в банках, или даже подбамбливают понемножку, поэтому пока ни одна обычная компания или обычное частное лицо, т.е. не политик, не политическая организация, не осмеливались неисполнять требования американских госструктур.

Как Collabora зарабатывает деньги и помогает opensource community?

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

Дружественная нам компания Collabora, это хороший пример того, как можно зарабатывать на открытом ПО, и не быть размером с Red Hat. О секрете (не так уж и секретном) своего успеха они рассказали на Bern LibreOffice Conference 2014:

В systemd добавили поддержку PPPoE

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

Продолжает развиваться сетевой стэк systemd. Не так давно присоединившийся к Red Hat участник Arch Linux, Tom Gundersen, добавил поддержку PPPoE в systemd-networkd.

Автор предупреждает, что до полноценного использования еще довольно далеко, но можно предполагать, что к версии 218 будет на что посмотреть.

У systemd-networkd уже появились пользователи, так что при переходе на Fedora 21 можно будет попробовать.

К сожалению, в Fedora 20 networkd не будет.

Начался OpenStack Summit в Париже

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

Начался OpenStack Summit November 2014 Paris. Народу в этот раз там навалом, и коллеги-аналитики передают, что в Wi-Fi сетке мероприятия /16 закончились айпишники. Вероятно многие посетители принесли с собой свои OpenStack-кластеры. Ну и отдельно хочется упомянуть про поддержку IPv6 в нем.

В твиттере начали выкладывать фотки - следите по хэштегу #OpenStackSummit.

Например, выложили фотку типичной системы под правлением OpenStack: image0 Поддерживает ли она systemd?

Слайды с выступления Павла Емельянова на Devops Moscow Meetup

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

Pavel Emelyanov из Parallels выложил слайды со своего выступления на недавно прошедшем Devops Moscow meetup про Docker и контейнеры.

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

`Teach your dockers to use CRanes <//www.slideshare.net/PavelEmelyanov2/teach-your-dockers-to-use-cranes>`__ from `Pavel Emelyanov <//www.slideshare.net/PavelEmelyanov2>`__