Размышления Марка Шаттлворта об Ubuntu, Canonical и внедрении свободного программного обеспечения
Те, кто регулярно читает opennet.ru, наверняка обратили внимание на горячее обсуждение письма Марка Шаттлворта о вкладе Canonical и Ubuntu в свободное ПО в целом. Почитав это письмо, я нашел в нем достаточно интересных мыслей, что сподвигло меня на перевод этого текста. Думаю, что мой перевод позволит словам Марка достичь гораздо большей аудитории.
Краткое резюме для тех, кто не хочет читать:
1. Свободное ПО - это огромная область, работы на которой хватит всем. Поэтому и надо заниматься работой, а не считать кто и сколько сделал.
2. Свободное ПО, как алмаз, который нуждается в правильной огранке, чтоб достичть своего пользователя. В истории IT есть много случаев, когда становились популярными не самые лучшие с точки зрения качества и надежности работы продукты. Поэтому, для популяризации свободного ПО нужно учитывать реальные потребности пользователей и подстраиваться под них.
Критика в адрес Canonical по поводу ее вклада в разработку ядра Linux и GNOME заставила меня задуматься: доволен ли я тем, чем занимаюсь каждый день моей жизни. Насколько для меня важно чувствовать, что результаты моей работы служат другим людям и делают мир лучше. Явлется ли мое участие в проекте Ubuntu тем делом, возможность заниматься которым можно посчитать за счастье.
За последний месяц у меня было два случая, позволяющих положительно ответить на данный вопрос. Первый - письмо с благодарностью из Новой Зеландии, от человека, который отметил, что Ubuntu 10.04 внесла реальные изменения в жизнь его семьи. Для них этот проект, предоставляющий целостное, интегрированное окружение для работы и существующий благодаря труду тысяч людей, похож на маленькое чудо человеческой щедрости. Второй случай - контракт на поддержку десятков тысяч рабочих станций, работающих на Ubuntu 10.04. Общее между этими двумя случаями - два столпа, на которых зиждутся проекты Ubuntu и Canonical: предоставлять всему миру результаты труда огромного сообщества свободного программного обеспечения как подарок, бесплатно, свободно, без ограничений и делать это на постоянной основе.
Первая история из Новой Зеландии о тех, кто учит детей пользоваться компьютером с раннего возраста и наблюдает насколько больше они могут получить знаний от Ubuntu, чем от Windows, и насколько доступнее делать это с Ubuntu. Для них то, что Ubuntu приносит им весь мир свободного программного обеспечения как единое целое - это здорово, это - прорыв, и они очень благодарны за это.
Это история, повторение которой я надеюсь увидеть 100 миллионов раз. И она делает честь и приносит удовольствие не только мне, не только тем, кто отдает Ubuntu свою любовь и энергию, но и всем тем, кто участвует в разработке свободного ПО в целом. Ubuntu в отдельности не заслуживает всеобщего признания, это часть большой и сложной экосистемы, но без Ubuntu продвижение свободного программного обеспечения просто не достигло бы таких масштабов.
Мы все понимаем, что тело свободного ПО состоит из многих органов, многих клеток, каждая из которых имеет свои собственные приоритеты, интересы и назначение. Тело может существовать только благодаря их совместной работе. Мы лишь небольшая часть целого, это честь для нас - взять на себя ответственность в создании своего дистрибутива. Мы несем ответственность за выбор Ubuntu теми, кто только начинает свое путешествие в мир свободного ПО, и мы упорно работаем над тем, чтобы быть уверенными, что все ее компоненты хорошо складываются вместе.
Ubuntu и то, что она делает, не могло бы произойти без усилий прекрасного Linux-сообщества, которое, в свою очередь, не могло бы существовать без сообщества GNU, которое также не смогло бы подняться на сколь-нибудь значимое место без усилий таких компаний, как IBM и Red Hat. И может быть все пошло бы совсем не так, если бы не участники проектов Mozilla и Netscape, GNOME, KDE, Google и всех остальных, кто использовал свободное ПО для разных задач, что делало его только лучше. Есть десятки тысяч людей, которые никак не связаны с Ubuntu и которые сделали эту историю - реальностью. Многие из них работали более десятка лет - и прошло много времени прежде, чем пришел неожиданный успех, в то время как Ubuntu на сцене только лишь 6 лет. Именно поэтому Ubuntu не может признаваться единственной и неповторимой лишь только для красного словца и чтобы порадовать своих поклонников :).
Тем не менее проект Ubuntu делает кое-что уникальное, специфичное и важное для свободного ПО: создает у конечных пользователей устойчивый образ того, что со свободным ПО могут работать все, как с экономической точки зрения, так по легкости использования и готовности решать проблемы, возникающие то там, то здесь. И я считаю, что это подарок тем людям, которые собирают каждый из пакетов Ubuntu. Если мы сможем предложить свободное ПО аудитории в 10 раз большей чем сейчас, мы десятикратно усиливаем вашу щедрость, что делает каждый час нашей с вами жизни (который мы проводим исправляя ошибки или улучшая что-либо) в 10 раз ценнее. Я очень горжусь тем, что трачу время и силы на Ubuntu. Да, я мог бы делать множество других вещей, но я не могу себе представить что-то еще, что имело бы аналогичное влияние на мир.
Я готов признать, что не каждый может видеть картину моими глазами. Передача результатов своей работы аудитории в 10 раз большей без учета усилий, затрачиваемых на двустороннюю связь с конечными пользователями и работу над новыми возможностями, может выглядеть со стороны просто как рост скачиваний или увеличение потока отчетов об ошибках в 10 раз. Другими словами, если upstream не видит ничего кроме «кода», то он и не сможет увидеть ничего кроме кода. Я действительно не знаю, что с этим делать: Ubuntu - не средство для доставки конечным пользователями всего многообразия написанного кода, мне кажется это не то, в чем нуждается мир. А нуждается он в средстве, которое позволяло бы брать этот код и следило за тем, чтобы тот код, который уже есть, оставался в состоянии высокого качества и надежности. Все, что нужно для рабочих станций уже есть и даже код соответствует ожиданиям, не было только возможности вынести область его использования за пределы серверов, чтобы представить широкой публике уже готовое решение.
Второе письмо я не могу процитировать. Оно предполагает контракт на оказание услуг Canonical в оказании помощи по миграции более чем 20 000 настольных компьютеров с Windows на Ubuntu. В последнее время в этой области много предложений, их темп ускоряется по мере укрепления доверия к Ubuntu. Хоть Linux уже давно зарекомендовал себя прекрасным рабочим столом для вдохновленного и целеустремленного разработчика, существует разрыв между его потребностями и потребностям крупных организаций. Другой такой компании, которая была бы настолько же привержена идее свободного ПО для настольных систем в том же масштабе, как Canonical, нет и поэтому я очень горд тем, какую роль мы играем в этой экосистеме. Для меня было бы очень печально, если б все усилия, которые сообщество свободного ПО затрачивает на разработку приложений для рабочих станций, были потрачены впустую.
В настольных компьютерах, которые Canonical поддерживает в крупных организациях, нет чего-то секретного или закрытого. Подлинным чудом для меня является то, что и в истории из Новой Зеландии, и в истории с миграцией компьютеров фигурирует один и тот же код. Для меня это истинное назначение свободного ПО. Когда я сам участвовал в проектах с открытым кодом, я всегда был рад, когда результаты моей работы могли служить не только моим потребностям, но и оказаться полезными многим другим.
Ubuntu лишь малая часть огромной экосистемы, но я горжусь тем, как мы подошли к решению этих задач.
Canonical использует различные подходы для взаимодействия с другими компаниями, которые работают с Linux, и не занимается скрытой критикой конкурентов просто потому, что у нас есть свои принципы. Сила свободного ПО именно в наличии огромного количества разных компаний, совместно работающих над различными целями.
В последние несколько недель неоднократно заявлялось, что Canonical преследует какие-то свои собственные интересы и действует отнюдь не в интересах сообщества, занимающегося открытыми исходными кодами. Это все лживые заявления, потому что большинство из нас наоборот мотивировано делать все, что мы только сможем, чтобы способствовать делу свободного ПО как в интересах конечных пользователей, так и сообщества, которое его делает, и мы убеждены, что существование Ubuntu и Canonical это лучший способ для достижения этой цели. И этот пост показывает результаты размышлений над этими вопросами: это моя собственная позиция показывающая, что именно я делаю и почему я испытываю чувство гордости от тех усилий, которые затрачиваю каждый день.
Что мы вместе делаем для свободного ПО? И что же я сам могу сделать для него?
Во-первых, мы занимаемся доставкой его конечным пользователям. Мы снижаем влияние потребительской инерции и тех факторов, которые мешают людям попробовать бесплатное ПО и решить для себя, нравится ли оно им в той мере, чтобы начать им пользоваться. Сотни из тех, кто сейчас участвует в свободном ПО (разработчиков, переводчиков, дизайнеров, пропагандистов) получили возможность стать частью нашего движения, поскольку для них не стало проблемой слегка намочить ноги в воде. И это совсем не легко. Просто посмотрите на результаты нашей многолетней работы над упрощением инсталлятора Linux, что стало возможно только благодаря труду многих групп людей и было бы просто невозможно без участия Canonical и Ubuntu.
Есть тысячи людей, которые довольствуются сборкой свободного ПО для себя, и это не преступление. Но желание облечь его в такую форму, чтобы другие могли его попробовать, изучить и затем удобно использовать, нужно тоже приветствовать. И именно этому в сообществе Ubuntu придается огромное значение: если вы почитаете planet.ubuntu.com, вы станете свидетелем радости многих людей, использующих свободное ПО. Как сообщество мы глубоко удовлетворены тем, чтобы люди использовали его для решения каких-то задач в своей жизни. Это радует гораздо больше, чем истории о том, как мы «сделали это быстрее» или «добавили новую функцию». Мы, конечно, работаем и над тем и над другим, но сообщество больше ценит влияние на мир, а не на код. Люди очень ценят свое время и опыт. Я горжусь тем, что Ubuntu привлекает людей, вносящих свой щедрый вклад в общее дело. Поэтому мы благодарим и Kubuntu, и Xubuntu, и Puppy, и Linux Mint. Они не висят у нас на хвосте, они стоят на наших плечах, так же, как мы стоим на плечах гигантов. И это здорово. Наша работа будет более значимой и ценной, потому что их работа достигает тех пользователей, которых не достигли мы.
Что еще?
Посмотрите на проект Papercut, основанный на том положении, что все невероятные технологии и усилия, направленные на какой-то сложный проект (например, такой как ядро Linux) имеют нулевую ценность, если средний пользователь не может с ним работать. И, наоборот, проект ценен тогда, когда он просто работает. Сотни пожеланий пользователей были учтены во многих различных приложениях, пользу от чего получает не только Ubuntu, но и любые другие дистрибутивы, их использующие. Если вы думаете, что это легко, попробуйте оценить усилия, затрачиваемые на сортировку и рассмотрение каждого из тысяч предложений, координацию исправлений и их дальнейшее распространение. Результаты неустанного труда большой команды видны невооруженным взглядом.
Другой пример: сохранить миллионам пользователей 1 час в неделю - это экономия энергии, которую можно получить, используя свободное ПО. Хоть команда дизайнеров Canonical играет ведущую роль в создании проекта Papercuts, настоящие звезды представлены здесь - http://www.omgubuntu.co.uk/2010/06/maverick-papercut-hunting-season-opens.html . Каждый может внести предложение, как для версии Desktop http://ubuntuserver.wordpress.com/2010/01/20/ubuntu-server-papercuts-project/, так и для Server.
Лично я положил много на руководство и управление проектом и создание структуры сообщества. Когда мы только начинали Ubuntu, я потратил много времени на анализ существующих сообществ, на то как в них разрешаются неизбежные трения и разногласия, возникающие, когда у вас есть много умных и талантливых людей, взаимодействующих между собой. Для решения этого вопроса мы составили кодекс поведения, который будет гарантировать, что наша страсть к технологии и/или работе не подавит основную цель - собрать разных людей вместе, чтобы совместно работать над общей платформой. Я очень рад, что эта идея распространилась и на другие проекты: у нас нет цели тайно вынашивать идеи, проекты и мысли, которые шли бы вразрез с нашим назначением.
Мы создали простейшую структуру: технический совет (technical board) и совет сообщества (community council). Такой подход в настоящее время широко распространена и во многих других проектах. Поскольку проект Ubuntu вырос, управление претерпело изменения, в настоящее время есть несколько управляющих команд для таких групп, как Kubuntu, форумы и IRC, которые дают советы и руководят такими группами, как LoCo, модераторы, оперативный отдел, разработчики, которые, в свою очередь, стремяться к техническому совершенству и умению работать с людьми, как часть огромного мирового сообщества. Это удивительно и прекрасно. Когда люди начинают участвовать в Ubuntu, как правило, они мотивированы не только желанием быть частью замечательного сообщества, но и исправлением конкретной проблемы или внесением какой-либо идеи по улучшению. С течением времени некоторые из этих людей сознают, что они могут помочь людям быть более креативными, разрешать разногласия, организовывать работу группы так, чтобы результат был гораздо лучше, чем сможет сделать один человек. Наша структура управления проектом создает все возможности для таких людей: они составляют основу и структуру, которая делает это сообщество легко масштабируемым, производительным и довольным.
Такой проект, как Ubuntu, нуждается в постоянном уходе, чтобы защищать свои ценности. Когда вы малы и поднимаете плакат с надписью «мы делаем вот это» вы, как правило, привлекаете только тех людей, которых это интересует. Когда проект перерастает в нечто мощное и заметное, вы, как правило, начинаете привлекать ВСЕХ, потому что люди хотят быть там, где что-то происходит. И значимость проекта может легко пойти вниз. Так, я по-прежнему трачу много энергии на работу с советом сообщества Ubuntu и командой Canonical по взаимодействию с сообществом, и они оба являются талантливыми и трудолюбивыми, потому что эта часть моей работы приносит мне огромное удовольствие. Совет сообщества Ubuntu относится к своим обязанностям хранителя ценностей проектов сообщества очень серьезно. Он в основном состоит из людей, которые не связаны с Canonical, но которые тем не менее считают, что проект Ubuntu важен для свободного программного обеспечения в целом. И бесподобный Jono Bacon, восхитительный Daniel Holbach, и невозмутимый Jorge Castro - профессионалы, которые понимают, как сделать работу сообщества продуктивной и успешной.
Нечто столь же большое как сообщество Ubuntu не может быть только моей или чьей-то еше заслугой, но я горжусь той ролью, которую сыграл и буду продолжать играть по возможности.
В последние годы я стараюсь обращать больше внимания на соревнование за наилучшее оформление в свободном ПО. Я считаю, что свободное ПО обладает лучшим качеством, но думаю, нам нужно точно знать, что мы хотим создать для наших пользователей, будь то рабочая станция, нетбук или сервер. Поэтому я трачу так много моего времени на вдохновление различных сообществ - и Ubuntu, и upstream - чтобы приглашать в них тех, кто видит ПО глазами обычного пользователя, а не опытного хакера. Это фундаментально изменит ценность открытого ПО, и я не могу надеяться, что такую задачу можно осилить в одиночку, но я тем не менее горжусь тем, что являюсь чемпионом этого подхода и рад, что все предложенное неуклонно принимается.
В свободном ПО уже были дизайнеры и до того, как мы это предложили. Я надеюсь, они чувствуют, что внимание Canonical в области концепции лидирующей роли дизайна сделало их жизнь легче, и сообщество в целом больше ценит их усилия и восприимчиво к их идеям. И все-таки, если вы действительно заботитесь о внешнем виде свободного ПО, команда по дизайну Canonical (Canonical design team) ждет вас.
Я делаю некоторую часть работы по оформлению сам и участвую в разработке дизайна Unity - интерфейса для Ubuntu Netbook Edition 10.10. Это следующее поколение старого интерфейса UNR. Самое главное в нем - это утверждение, что рабочие станции Linux не должны быть застревать в 90-х, мы можем и будем пытаться построить новые и эффективные способы взаимодействия с компьютерами. Я был в восторге от скорости, с которой некоторые объекты Unity были приняты сотнями проектов, их цель сделать использование Linux гораздо более простым и прекрасным для всех, так как скорость этой адаптации является мерой того, насколько быстро пользователи смогут лучше адаптироваться к новым способам использования своих компьютеров.
Дизайн сам по себе ставит нас в положение, удобное для обвинения в желании свалить работу по его внедрению на других, так что я горжусь нашей замечательной командой, которая занята реализацией некоторых из этих основных компонентов. В частности, dbusmenu оказалось полезным для организации согласованности внешнего вида приложений GNOME и KDE, работающих под Unity, и я очень надеюсь, что оно будет принято в другие проекты, которые нуждаются в тех интерфейсах, которые оно предоставляет. Я полностью доверяю нашей инженерной команде, нацеленной на качество готового продукта, которая предоставит разработчикам простой и ясный API и руководство о том, как его использовать. Если вы использовали полный набор индикаторов в 10.10, то вы в курсе той работы, которая была сделана без лишнего шума и вобрала в себя результаты многих различных проектов и превратившей панель в нечто прекрасное и эффективное. Utouch также приближается к своему первому релизу и будет продолжать развиваться, так что и Ubuntu, и GNOME, и KDE получат простой способ реализации поддержки жестов Multi-Touch.
Помимо этого, я также занимаюсь финансовой поддержкой различных проектов. Целесообразность вклада денег в свободное ПО должна определяться ответом на следующий вопрос: может ли результат вложения денег в другой проект, помочь большему количеству людей? Есть много способов помогать людям: на $100 000 можно отправить многих в школу, одеть и накормить их. Поэтому я действительно должен быть уверен, что этими деньгами я привношу реальное воздействие на жизнь людей. Благодарственные письма, которые я получаю каждую неделю, помогают мне сохранить уверенность в этом. Более того, мои собственные наблюдения того каталитического эффекта, который Ubuntu дает всей экосистеме ПО с открытым исходным кодом, с точки зрения привлечения новых разработчиков, создания новых платформ, создания нового бизнеса, признания новых участников, придают мне уверенность, что обеспечиваемое мной финансирование оказывает значимые последствия.
Когда мы только задумывали Ubuntu, экосистема Linux была в некотором смысле полностью сформирована. У нас уже было ядро. У нас уже были GNOME и KDE. У нас были X, libc и GCC и все остальные хорошо знакомые инструменты. Естественно, что в них были ошибки, недостатки, были планы по их устранению. Но кое-чего не хватало: иногда это «кое-что» формулируется как «маркетинг», а иногда как «все для конечного пользователя». Я помню, как подумал «вот то, что я могу сделать». Именно поэтому Ubuntu и Canonical не прикладывают усилия к тому, что и так хорошо работает, вместо этого мы сосредотачиваем свое внимание на новых идеях, новых инструментах и новых компонентах. Я считаю это живительным взаимодействием со всей экостистемой открытого ПО, и я слышу от многих людей, что они воспринимают его точно так же. Те, кто говорят «Canonical не участвует в разработке X», правы, но упускают из вида все, что мы делаем с нуля. Конечно, есть мало того, что мы делаем в одиночку, и мало чего из того, что мы делаем, не смог бы сделать кто-то другой, но я думаю, что энергия сообщества Ubuntu и энтузиазм ее пользователей отражает тот факт, что в проекте есть кое-что отличное от других. Это «кое-что» заставляет нас торжествовать, гордиться своим трудом, и мотивирует нас продолжать.
Свободное ПО больше, чем любой из проектов. Оно больше, чем ядро Linux, чем GNU, чем GNOME и KDE, чем Ubuntu, Fedora и Debian. Каждый из этих проектов играет свою собственную роль, но это все в целом реально меняет мир. Поэтому, когда мы начинаем спорить друг с другом о том, какая часть свободного ПО перспективнее, мы рискуем упустить картину в целом. Это немного похоже на аутоиммунные заболевания, когда организм начинает атаковать сам себя. Тот, кто напряженно работает в течение всего дня, чтобы донести свободное ПО до более широкой аудитории, играет на той же стороне, что и я, если уж мы применяем такую терминологию. Я восхищаюсь и уважаю всех тех, кто вкладывает свою энергию в продвижение свободного программного обеспечения, даже если он делает это по-другому.
De vuelta por wordpress.com
Strategy is mighty!
This is a follow up to my friend Jos' post about strategy.
I love strategy! (Strategy was one of my major subjects at university and a research focus of the chair I worked and taught over four years.) So I might be biased. Nevertheless I want to
Why do we invest time into that valuable strategy discussion?
There are several studies about the success of organizations. The strategy is in most cases playing an important part. I explain why:
What is the benefit of a strategy?
A good strategy should
1. show your major future challenges and provide an answer to those challenges,
2. point into a direction where the team wants to move and
3. unite the team.
Challenges
"Prediction is very difficult, especially about the future. " (Niels Bohr) But you have to try to anticipate the challenges. Otherwise you have no chance to act. You could only re-act and that is not an advantage. It is always easier to change things when you are in the driving seat. These challenges include the development of customer needs as well as of the competitors. Business tools (like them or not) can help to see some things clearer.
Direction
A good strategy gives a direction where the herd is aiming at. In an environment with no strong top down control (like in communities), having the same targets and values are essential. This direction - called the vision or mission - summarizes the common goals in one sentence. This goal is far enough away that you have to move yourself and close enough that it is possible to reach.
Uniting
A strategy can help a community to glue together, to find the things they have in common and to define (together) the way they want to go (together). In business many strategies are defined by the top management and fail because they are not wholeheartedly supported by the employees. The best strategy is worth nothing if it is not filled with life. Therefore, the perhaps most important part of a good strategy is the process how this strategy was created. Who was involved? How were the opinions collected and summarized? Is the process open enough? Is the communication and the flow of information transparent? How many people outside of the organization were involved? Etc. [This would fill a whole blogpost of it's own.]
Strategy is for communities!
Most strategy projects at university I did with NPO (non profit organization). We worked with kindergartens, with schools, with the youth welfare office etc. I can assure you: those projects were a blast. I am convinced that it works for communities as well!
Strategy is mighty!
A brilliant strategy, developed in an open environment by the community and external persons can take your open source project to the next level of success. Focus on the processes not (only) the content. Don't write down a strategy just to have one. Make it move your world!
Another openSUSE kernel git repo
The mirror of the openSUSE kernel-source repository has been around for several months already, now there is something new: A repository that is actually usable :-). The current kernel-source repository is a series of patches managed in git, which has some upsides, like the ability to easily cherry-pick a patch and port it to a different branch or send it upstream. But it is quite painful if you want to work with the code itself and not with patch files. A task as simple as determining if drivers/…/foo.c in openSUSE-11.3 has or does not have a certain change requires checking out the branch and running the sequence-patch script to be able to look at the file. If you need to know when was the file changed, you have to run ‘quilt patches <file>’ to find out what patches touched the file and then ask git about the history of these patches. Neither convenient nor efficient. That’s why we have a second repository, that contains the mainline tree with all the suse patches applied. It’s located at http://gitorious.org/opensuse/kernel, the clone url is git://gitorious.org/opensuse/kernel.git. If you already have a clone of the mainline tree, then you can download just the differences with
git remote add suse git://gitorious.org/opensuse/kernel.git git remote update suse git checkout suse/master
The above task is then solved by opening the required file in an editor or typing ‘git show branch:file’. And you don’t even need to clone the tree to quickly check something in the source, just use the web viewer. Also, bisecting is much easier, because you avoid the sequence-patch step now. There are some gotchas though:
- Not every commit to the kernel-source repository results in a change in the kernel repository. For instance updating config files in the kernel-source repository results in a commit that has no text changes. The gitorious viewer is confused by this and tells you that you are viewing the initial commit. In a local clone, you can exclude such commits with ‘git log .’ (note the dot).
- When the patch series does not apply, there isn’t much to show in the kernel repository. In such case, the commit only adds a ‘BROKEN’ file to the toplevel directory and uses the tree from the previous commit. When using a bisect script, you can skip such commits with e.g. ‘test -e BROKEN && exit 125’.
- When patches such as xen are temporarily disabled while updating to newer upstream versions and later enabled, it generates huge diffs back and forth. That’s usually not a problem unless you are bisecting something xen-related.
Anyway, I’m sure this will be useful for anyone who needs to debug something in the openSUSE kernel.
Introduction
I have been running GNU/Linux distributions for almost 8 years now. My first experience was with Mandrake (today Mandriva) Linux - downloading 6 CD's on dialup was fun - and after some distro hopping I soon found a home with SuSE 9.2. Since then I've stuck with openSUSE as my main distro while also running the *buntu's and others on testing machines. My preference has always been for KDE - which is why I've never been a fan of Ubuntu - but every so often I'll fire up Gnome, Xfce, LXDE to see what progress has been made. I'm just as happy hacking away from a console.
Over the years I've picked up a fair few scripting and coding skills. Given a bit of time to remember the syntax, I can generally get what I want done in most common languages - bash, awk, sed, perl, C/C++.
My main contributions to the FOSS software environment are RPM packaging/maintenance (made super easy by the OpenSUSE Build Service), and C++/Qt/KDE application maintenance and patching. One of the first projects I became directly involved in is the SynCE project, where I ported some simple KDE3 applications to KDE4. Since then I've been active on the openSUSE mailing lists and occasionally on the forums.
My openSUSE Build Service home project is accessible here.
Version Tolerant Serialization with Mono
(Zoot Woman - Lonely By Your Syde)
During the last months I've kept working {with|on} Mono, but not working for Novell anymore.
Today I'm proud to blog about a bit of work I've done on Mono towards a better Binary Serialization experience:
-
mono-api-info command now can output ABI instead of API if you append the flag --abi. It has been useful for us in LindenLab while working on binary serialization compatibility between versions (already upstream!, so will be available in Mono v2.8, even with a new man page).
If you ever wondered why your .NET code is no longer capable of deserializing some old binary object you had in your servers, instead of fixing the problem in a case-by-case basis, you can now see the whole picture by just diffing the output of mono-api-info --abi from your current and old codebase! A small TODO that I haven't completed yet is to deal with automatic properties (because we still don't use them) so that would be an exercise for the reader! - Fix for upstream Mono to act as .NET in regards to Version Tolerant Serialization, a patch to which I have just added a lot more unit tests (soon to be pushed hopefully).
You can see the patch of this quite old mono bug here. Disclaimer: to be honest you will only need the previous --abi tool if you use a Mono version prior this fix, because from my testing VTS in MS.NET works as if every new field had an [OptionalField] attached! (At least the BinaryFormatter, the TODO here for the reader is to test the SoapFormatter ;) )
On a totally unrelated note: kudos to the MonoDevelop team for making such a great releases lately (and fixing the bugs I report so promptly). I've been testing it the last months on Windows and I can say it's a great experience to see your favorite IDE working cross-platform and making you not depend on VS anymore if you need to work on Windows from time to time (I know the Express versions are free, and are great! but they do not support plugins :( ). BTW, I've been lately experimenting with the C language support in this IDE, and have had some problems, but the real culprit seems to lay behind some wierd behaviour of my gdb in opensuse. Taking advantage that I'm in opensuse planet, can I do a couple of lazyweb requests?:
a) If you're quite familiar with gdb, can you take a look at these 2 bugs in case it rings any bell for you? BNC#588175, BNC#459274
b) Can you try to reproduce those bugs in openSUSE 11.3? (I haven't migrated yet from 11.2 because I fear about the HALlessness of it :) )
PS: Wondered why the video on the top? Well, I like the trend that some people have about posting random photos in their blog posts even when they may be completely unrelated, but in my case I love music so I figured this would suit better. Of course I would rather embed a WebM video or, even better, something that can preview a song (without video) in a "normally-lower-quality-than-what-you-can-buy" way, so if you have any hints, those are welcome! I especially mention the latter in this case because the Album version of the song above is much much better (synth pop FTW!).
UPDATE 28-AUG-2012: Found a video-less alternative to youtube for embedding songs! It is GoEar.
Hello Planet SUSE
The openSUSE strategy discussion has scratched my itch and I started to contribute more to openSUSE.
What could you expect?
Don't expect much code from me. My experiences are more in the area of strategy, marketing and promotion. Perhaps I could also share some results from my researches during the last years about open source communities.
So be curios and stay tuned.
I am happy to join the openSUSE community and I am looking forward to know more of you.
Let's have a lot of fun!
Cheers,
Thomas
Recompiling wxRuby
Who uses Ruby might be interested to try this interesting multiplatform library that allows the development of GUI (Graphic User Interface) with a considerable visual impact and compatible with the three most popular Operating Systems: Linux (via GTK) Windows (with Native controls) and OSX (via Aqua). (This article is also available for italian users)
Usually need install the wxGTK libraries and the gem wxruby (or wxruby-ruby19 if using ruby 1.9) and start creating your own scripts.
$ sudo zypper in wxGTK wxGTK-gl
$ sudo gem install wxruby
But sometimes we could find an Error for a wrong compatibilty between the installed version of the wxGTK libraries and the wrapper library included in the gem.
/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so:
symbol _ZN13wxAuiNotebook14ShowWindowMenuEv, version WXU_2.8.5 not defined in file libwx_gtk2u_aui-2.8.so.0 with link time reference -
/usr/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-linux/lib/wxruby2.so
When an error like this appear, the unique solution is recompile the gem.
What we need:
- rubygems: Tool for manage the ruby’s gems;
- rake: the Ruby’s version of the popular make, will help us to compile wxRuby;
- wxGTK, wxGTK-gl, wxGTK-devel: Library and headers needed for run our scripts and produce the object’s file;
- SWIG: Build the wrapper classes in Ruby from the C++ sources, wxRuby 2.0.1 need the version 1.3.8;
- gcc-c++: The C++ compiler used for build the wrapper library;
- wxRuby: We have to download the source’s package directly from Rubyforge.
Added the repository which contains the Ruby extensions (warning to the portion of the address that refers the version of openSUSE), we can proceed with the installation confirming the request of the dependent packages:
$ sudo zypper ar http://download.opensuse.org/repositories/devel:/languages:/ruby:/extensions/openSUSE_11.3/ RubyExtensions
$ sudo zypper ref
$ sudo zypper install rubygems rubygem-rake gcc-c++ wxGTK-devel rubygem-ffi-swig-generator make
It’s time to download the sources of SWIG version 1.3.38 from sourceforge, then uncompress and install it:
tar -xvf swig-1.3.38.tar.gz
cd swig-1.3.38
./configure && make
sudo make install
All the packages are ready, we have to set some environment variables before continue:
export SWIG_CMD=/usr/local/bin/swig
export WXRUBY_EXCLUDED=GLCanvas
export WXRUBY_VERSION=2.0.1
The second instruction is important for ignore all the references to the openGL library, which are not availables in unicode version.
The next step is download the wxRuby’s source from Rubyforge and start to compile
tar -xvf wxruby-2.0.1.tar.gz
cd wxruby-2.0.1
rake
After this procedure end you can remove the old gem and build & install the new:
rake gem
sudo gem install wxruby-2.0.1-x86-linux.gem
Personally, I needed recompile wxRuby in openSUSE 11.2; with the new version (11.3) standard packages work fine, anyway i wished share my experience for someone could meet the same trouble in the future :))
Система инициализации Systemd. Часть II
Собираем все вместе - systemd
- service/сервис: наиболее очевидный тип модуля: это демоны, которые могут быть запущены, остановлены, перезапущены или перезагружены. Для совместимости с SysV в systemd помимо собственных файлов конфигурации для различных сервисов имеется возможность чтения классических скриптов инициализации SysV, а также она умеет разбирать заголовок LSB, если он существует. /etc/init.d является, следовательно, не более, чем просто еще одним источником конфигурации.
- socket/сокет: данный модуль реализует сокет, расположенный в файловой системе или в Интернете. В настоящее время поддерживаются сокеты AF_INET, AF_INET6, AF_UNIX типов stream, datagram и последовательных пакетов (sequential packet). Также поддерживаются классические буферы FIFO. Каждый модуль типа «сокет» имеет соответствующий ему модуль «сервис», который запускается при попытке установки соединения с сокетом или буфером FIFO. Пример: nscd.socket при установке соединения запускает nscd.service.
- device/устройство: этот модуль реализует устройство в дереве устройств Linux. Если устройство описано через правила udev, оно будет представлено в systemd как модуль устройство. Набор параметров устройства, установленный udev, будет использоваться systemd как исходный в определении зависимостей для этого типа модулей.
- mount/точка монтирования: модуль реализует точку монтирования в файловой системе. systemd контролирует все точки монтирования (их подключение и отключение), а также может быть использована для монтирования и размонтирования отдельных файловых систем. Файл /etc/fstab используется как дополнительный источник конфигурации для них, подобно тому, как сценарии инициализации SysV могут быть использованы в качестве дополнительного источника конфигурации для модулей service.
- automount/точка монтирования с автоматическим подключением: модуль реализует точку монтирования с автоматическим подключением файловой системы. Каждый такой модуль имеет соответствующий ему модуль типа mount, который запускается (т.е. подключается), как только монтируемая файловая система становится доступной.
- target/указатель: данный тип модулей используется для логической группировки других модулей: на самом деле сам по себе он ничего не делает, он просто указывает на другие модули, которыми таким способом можно управлять вместе. В качестве примера можно привести модули multi-user.target, который играет роль 5-го уровня запуска в классической схеме SysV, и bluetooth.target, активируемый, как только становится доступен Bluetooth-адаптер, и запускающий сервисы, имеющие отношение к Bluetooth (которые обычно не запущены - bluetoothd и obexd) (т. е. по сути это придет на смену традиционным уровням запуска SysV - прим. перев.).
- snapshot/снимок: подобно предыдущему типу модулей снимки также ничего не делают сами, и их единственное преданзначение заключается в ссылке на другие модули. Снимки могут быть использованы для сохранения состояния и возможности отката назад состояния всех служб и модулей системы инициализации. Он, главным образом, предназначен для двух случаев. Первый, чтобы позволить пользователю временно перевести систему в какое-то специфичное состояние, например, однопользовательский режим с остановкой всех работающих сервисов, а затем легко вернуться в предыдущее состояние с одновременным запуском тех сервисов, которые были перед этим запущены. Второй вариант его использования - поддержка режима suspend: достаточно много сервисов не могут корректно работать с этой системой, и зачастую их лучше остановить перед засыпанием, а потом просто запустить.
- Для каждого порожденного процесса вы можете контролировать: среду исполнения, ограничения ресурсов, рабочую и корневую директории, umask, настройки OOM killer, параметр nice, класс и приоритет операций ввода-вывода, политику и приоритеты использования процессора, привязку к процессору, таймер, идентификаторы пользователя, основной и дополнительных групп, списки директорий, доступных для чтения/записи, список директорий, доступ к которым запрещен, флаги монтирования, биты безопасности, параметры, относящиеся к планировщику процессора CPU, области видимости /tmp, привязку к cgroup для различных подсистем. Также можно присоединить stdin/stdout/stderr сервисов к syslog, /dev/kmsg, произвольным TTY. Если вы присоединяете TTY ко входу systemd - удостоверьтесь в том, что процесс получает эксклюзивный доступ.
- Каждый запущенный процесс получает собственную cgroup (в текущем состоянии разработки по умолчанию они создаются в подсистеме debug, поскольку она все равно не используется). С помощью systemd также легко помещать отдельные сервисы в различные cgroups, причем, это можно сделать из пользовательского пространства, например, посредством утилит libcgroups.
- Файлы конфигурации systemd имеют синтаксис, аналогичный используемому в файлах .desktop, который прекрасно разбирается (parse) многими имеющимися утилитами и имеет все необходимое для интернационализации. Поэтому администраторам и разработчикам не нужно учить новый синтаксис.
- Как упоминалось выше, мы (Здесь и далее под "мы" понимаются разработчики и сама systemd, надо смотреть по контексту. Обычно это нормально, когда автор осознает свое единство со своим творением :). Список основных разработчиков приведен в конце этой статьи. Прим. перев.) обеспечиваем совместимость со скриптами SysV, дополнительно к этому обрабатываются заголовки LSB и утилиты chkconfig RedHat. Если их нет, просто используется любая доступная информация (такая, как приоритеты запуска сервисов) из /etc/rc.d. Поскольку эти скрипты начинают просто читать другой источник конфигурации, обновиться с SysV на systemd достаточно легко. Дополнительно мы можем читать классические PID-файлы сервисов, чтобы определить PID главного демона. Также мы можем использовать информацию о зависимостях из LSB-заголовка скрипта и транслировать ее в «родной» формат описания зависимостей для systemd. Важное замечание: Upstart не может использовать эту информацию. Во время запуска Upstart, в отличие от systemd, не распараллеливает запуск большей части скриптов LSB и/или SysV. Фактически, для Upstart все скрипты SysV - это одно исполняемое задание (Тут опять автор немного лукавит. В Upstart просто оставлен слой совместимости со скриптами SysV, который действительно работает, как описано. Но это именно что слой совместимости с теми службами, управляющие скрипты которых по каким-то причинам пока не отконвертированы в "родной" формат для Upstart, а не "злостная недоработка" разработчиков Upstart. Прим. перев.).
- Аналогичным образом, существующий файл /etc/fstab читается и используется как еще один источник конфигурации. А с использованием опции comment= fstab вы даже можете отметить отдельные записи в этом файле, чтобы передать их под контроль systemd (для обеспечения работы функционала автоматического монтирования).
- Если для одного сервиса существует несколько файлов конфигурации (например, есть два файла /etc/systemd/system/avahi.service и /etc/init.d/avahi), тогда "родной" формат файлов имеет преимущество. Устаревший формат файлов игнорируется, позволяя легко провести обновление.
- Мы также поддерживаем механизм использования шаблонов. Например, вместо того, чтобы иметь шесть одинаковых конфигурационных файлов для шести getty, у нас есть только один файл getty@.service, который используется сервисом getty@tty2.service и аналогичными ему. Интерфейсная часть также может наследоваться выражениями, описывающими зависимости, т. е. легко понять, что сервис dhcpcd@eth0.service запускается сервисом avahi-autoipd@eth0.service.
- Для активации сервисов посредством сокетов, мы поддерживаем полную совместимость с традиционной моделью inetd, а также простой режим, имитирующий работу launchd, который рекомендуется к использованию для вновь создаваемых сервисов. Режим совместимости с inetd позволяет передавать запускаемому демону только один сокет, в то время как "родной" режим работы позволяет передавать произвольное количество дескрипторов файлов. Мы поддерживаем как режим с одним экземпляром сервиса на одно соединение, так и с одним экземпляром на все соединения. Например: sshd.socket может запускать сервис sshd@192.168.0.1-4711-192.168.0.2-22.service с cgroup sshd@.service/192.168.0.1-4711-192.168.0.2-22 (т. е. IP-адрес и номера портов используются в качестве имен). Для сокетов AF_UNIX, используется PID и идентификатор пользователя присоединяющегося клиента. Это предоставляет администратору прекрасный инструмент для определения различных экземпляров одного и того же демона и контроля за ним. «Родной режим» передачи сокета легко реализовать в приложениях: переменная $LISTEN_FDS, если она установлена, содержит количество передаваемых сокетов, и демон может найти их в файле .service, начиная с файлового дескриптора 3 (хорошо написанный демон также может использовать fstat() и getsockname() для идентификации сокетов в случае, если их больше одного). В дополнение мы устанавливаем переменную $LISTEN_PID, содержащую PID главного демона, который получает сокеты, потому что переменные среды обычно наследуются дочерними процессами, что может несколько запутать процессы, находящиеся далее в цепочке. Поскольку логика передачи сокетов очень проста, мы предоставляем примерную реализацию этого процесса под лицензией BSD. Также мы портировали множество существующих демонов на эту схему.
- Мы предоставляем совместимость с интерфейсом /dev/initctl. Эта совместимость фактически реализована с помощью сервиса, активируемого посредством FIFO, который просто транслирует устаревшие запросы в запросы D-Bus. На практике это означает, что старые команды shutdown , poweroff и аналогичные им из Upstart и sysvinit будут работать с systemd.
- Мы предоставляем совместимость с utmp и wtmp. Код, который это делает, выглядит гораздо более жизнеспособным, чем эти файлы :).
- systemd поддерживает несколько типов зависимостей между модулями. After/Before могут использоваться для определения последовательности запуска. Requires/Wants определяет статус зависимости, является она обязательной или опциональной. И наконец, Conflicts определяет отрицательный характер зависимости (т. е. две и более службы, у которых в зависимостях указана Conflicts, не смогут быть запущены одновременно - прим. перев.). Есть также еще три, менее часто используемые типы-зависимостей.
- systemd построена как система с минимумом транзакций. Это означает: если модуль запросил запуск или остановку, мы добавляем его и все его зависимости во временную транзакцию. Затем проверяем целостность этой транзакции, т.е. последовательности обработки зависимостей After/Before для всех модулей на возможность появления циклических зависимостей. Если они есть, systemd пытается исправить ситуацию путем удаления из транзакции «несущественных» (non-essential) заданий. Также systemd пытается убрать из транзакции такие из «несущественных» заданий, которые могут остановить какой-либо другой сервис (не имеющий отношение к останавливаемому модулю). «Несущественными» являются такие задания, которые не относятся к оригинальному запросу, но при этом помещены в очередь на основе зависимостей Wants. В заключение проверяется, могут ли задания в транзакции противоречить заданиям, которые уже находятся в очереди и, если возникла такая ситуация, транзакция отменяется. Если все сработало корректно, транзакция целостна и минимизирована по количеству операций, она ставится в очередь на исполнение. В сухом остатке это означает, что перед запуском запрошенной операции мы проверяем, имеет ли смысл ее вообще выполнять, если возможно, исправляем возникшие ошибки, и затем ничего не делаем, если операцию выполнить невозможно.
- Мы записываем время запуска/остановки, PID и статус завершения для каждого из порождаемых и/или контроллируемых процессов. Эти данные позволяют увязать демоны с их данными в abrtd, auditd и syslog и создать интерфейс, который выделял бы упавшие демоны и предоставлял бы всю необходимую о них информацию.
- Мы также реализовали самостоятельный перезапуск процесса init в любое время по требованию. Состояние демона замораживается перед этим и размораживается после. Таким образом мы упрощаем онлайнового обновления с SysV init на systemd, а также передачу полномочий от остановленного к перезапущенному демону. Запросы к открытым сокетам и точкам монтирования autofs, как уже отмечалось выше, будут корректно упорядочены и поставлены в очередь ядром, поэтому клиенты даже не почувствуют, что что-то вообще произошло. Поскольку большая часть информации о состоянии обслуживаемых systemd процессов хранится в виртуальной файловой системе cgroup, это позволяет нам не прерывать их исполнения из-за невозможности доступа к данным init. Код, реализующий перечитывание конфигурации init, является общим с кодом его перезапуска.
- Избавляясь от shell-скриптов в процессе запуска системы, мы переписали основную их часть на C и поместили непосредственно в systemd. В частности, это код таких операций как монтирование виртуальных файловых систем /proc, /sys and /dev и установка имени хоста.
- Состояние сервиса доступно и может контроллироваться через D-Bus (за это Upstart не пинал только самый ленивый - прим. перев.). Правда, эта возможность пока не реализована и находится в стадии активной разработки.
- Мы придаем особое значение активации сервисов посредством сокетов либо через D-Bus (и, следовательно, поддерживаем обработку соответсвующих зависимостей). В то же время мы поддерживаем традиционные зависимости только между сервисами. Также поддерживается несколько способов, которыми сервис может сообщить о своей готовности: путем вызова fork() и завершением родительского процесса (традиционное поведение daemonize()) и посредством публикации своего имени на D-Bus.
- Существует интерактивный режим, который запрашивает подтверждения для каждого из процессов, порождаемого systemd. Вы можете включить это, передав параметр systemd.confirm_spawn=1 в строке параметров ядра.
- С помощью параметра systemd.default= в строке параметров ядра вы можете указывать, какой из модулей systemd нужно запускать при загрузке системы. Обычно здесь находится что-то вроде multi-user.target, но можно указать и какой-то один сервис вместо модулей типа «указатель», к примеру, «из коробки» мы поставляем сервис emergency.service, который по своему назначению подобен параметру init=/bin/bash, но по сравнению с ним имеет то преимущество, что можно запустить полнофункциональную систему прямо из оболочки восстановления от сбоев (emergency shell).
- Также есть минимальный пользовательский интерфейс, позволяющий запускать/останавливать сервисы и наблюдать за ними. Правда, он еще далек от завершения, но вполне может использоваться как утилита для поиска ошибок. Он написан на Vala и называется systemadm.
Состояние разработки
Предполагаемые направления развития
Вы хотите увидеть systemd в действии?
Написание демонов
- Мы просим разработчиков не вызывать fork () (или даже двойной fork()) в своих процессах, используя цикл событий основного процесса, который systemd вызывает для вас. Также не вызывайте setsid().
- Не стоит сбрасывать привилегии (имеется в виду, когда демон не должен быть запущен с root-привилегиями, прим. перев.) с помощью самого демона, предоставьте сделать это systemd и настраивайте это в ее конфигурационных файлах (Тут есть несколько исключений. К примеру, для некоторых демонов нужно сбрасывать привилегии только посредством самого демона после стадии инициализации, которая требует повышенных полномочий).
- Не надо создавать PID-файлы.
- Имя демона следует получать с D-Bus.
- Если вы хотите использовать возможности systemd для ведения логов, сбрасывайте все, что нужно включить в логи, на stderr.
- Предоставьте systemd создать и обслуживать сокет для вас, благодаря чему будет работать активация посредством сокетов. Для этого нужно использовать $LISTEN_FDS и $LISTEN_PID как описывалось выше.
- Используйте SIGTERM для остановки своего демона.
Часто задаваемые вопросы
- Кто основные разработчики?
- Большая часть кодовой базы - моя собственная работа, Lennart Poettering (Red Hat). Однако, общий дизайн и его отдельные детали - это результат моего взаимодействия с Kay Sievers (Novell). Также в проекте участвуют Harald Hoyer (Red Hat), Dhaval Giani (бывший сотрудник IBM), и многие другие из таких компаний как Intel, SUSE and Nokia.
- Это проект Red Hat?
- Нет, это мой персональный проект. И позвольте мне подчеркнуть: мнение, отраженное в данной статье - это только мое мнение. Это ни мнение моего работодателя, ни Рональда МакДональда, ни кого бы то ни было еще.
- Увидим ли мы это в Fedora?
- Если наши эксперименты покажут что наши подходы работают, если сообщество Fedora выскажется в поддержку, тогда да, мы увидим systemd в Fedora.
- Увидим ли мы это в OpenSUSE?
- Этим занимается Kay, но думаю, что все будет также же, как и в Fedora.
- Увидим ли мы это в Debian/Gentoo/Mandriva/MeeGo/Ubuntu/[Моем_любимом_дистрибутиве]?
- Это вопрос к их разработчикам. Мы можем только приветствовать их интерес и помочь с интеграцией.
- Почему бы не добавить все вышеперечисленное в Upstart, зачем было изобретать что-то новое?
- Недостатки Upstart приведены выше, так же было показано, что ее основной дизайн, по нашему мнению, ущербен. Этот проект выглядит, как имеющий кучу недостатков в своей основе. Однако, имейте в виду, что это не помешало нам найти много идей для вдохновения в кодовой базе Upstart.
- Если вам так нравится launchd, почему было бы просто не адаптировать ее?
- launchd - прекрасное изобретение, но я не уверен, что она хорошо впишется в Linux, более того, она вообще никак не вяжется по своему дизайну ни с его (Linux) масштабируемостью, ни с его гибкостью.
- Это проект NIH?
- (Тонкий укол, намекающий на то, что разработчики пошли по собственному пути только по причине того, чтобы начать свой собственный проект. Проект ради проекта. Прим. перев.)
- Я надеюсь, что ясно пояснил текстом выше, почему мы пошли по своему собственному пути, вместо того, чтобы использовать как основу Upstart или launchd. Мы начали разработку по техническим, а не политическим причинам. И не забывайте, что это Upstart, а не systemd, включает библиотеку NIH (которая является, своего рода, новой релизацией glib).
- Будет ли systemd работать на [моей_любимой_операционной_системе_отличной_от_ Linux]?
- Маловероятно. Выше мы отметили systemd использует много специфичных для Linux API (таких как as epoll, signalfd, libudev, cgroups и т.п.), поэтому портирование его на другую операционную систему выглядит (по нашему мнению), как не стоящий своих затрат. Мы, разработчики проекта, не заинтересованы в работе, предполагающей портирование на другие платформы. Для тех, кто заинтересован в этом, мы можем только сказать, что git хорошо поддерживает концепцию ветвей (branches).
- Скажу больше, портируемость ограничивается не только окружением, в котором работает systemd: нам нужны самые последние версии ядра Linux, glibc, libcgroup и libudev.
- Если кто-либо хочет сделать нечто подобное для других операционных систем, можем предложить приемлемый режим взаимодействия: мы поможем вам определить какие интерфейсы являются общими с вашей системой, сделаем немножко легче жизнь тех, кто будет писать демоны для systemd и ее аналога. Мы можем помочь идеями, но не кодом.
- Я слышал, что [система загрузки Gentoo, initng, Solaris SMF, runit, uxlaunch, что-то еще] - это реально классная система инициализации, которая также позволяет параллелизовать запуск, почему бы не использовать ее как основу?
- Прежде чем начать разрабатывать systemd мы изучили имеющиеся системы и ни одна из них не зацепила нас (естественно, за исключением launchd). Если вы этого никак не можете заметить - прочтите приведенный выше текст еще раз.
Помощь проекту
Сообщество
Система инициализации Systemd. Часть I
Каждая Unix-система имеет процесс со своим специальным идентификатором, равным 1. Этот процесс запускается ядром прежде всех остальных и является родительским процессом для всех процессов, которые не имеют собственного родителя. Благодаря этому он может делать много чего такого, что не могут остальные процессы. Например отвечает за такие вещи, как инициализация и поддержка работы пользовательского пространства в процессе загрузки системы.
- Запустить минимум необходимого.
- Попытаться запустить параллельно всё остальное.
Динамическое изменение аппаратного и программного обеспечения
Параллелизация запуска сервисов, зависящих от сокетов (socket service)
Такого рода синхронизация запуска служб приводит к тому, что значительная часть запуска системы проводится последовательно. Правда было бы здорово избавится от описанных требований такой синхронизации? На самом деле, нет ничего невозможного! Для этого мы должны понять, что именно демоны требуют друг от друга и почему их запуск откладывается. Что касается традиционных демонов Unix, на этот вопрос есть только один ответ: они ждут, пока сокет другого демона станет доступен для соединения. Обычно это сокет AF_UNIX в файловой системе либо это может быть AF_INET [6]. К примеру, клиенты D-Bus ждут возможности подключения к /var/run/dbus/system_bus_socket, клиенты syslog - /dev/log, клиенты CUPS - /var/run/cups/cups.sock, NFS-клиенты ожидают /var/run/rpcbind.sock и открытия порта portmapper и т. д. Только подумайте - это единственное, чего они ждут.
Параллелизация запуска служб, зависящих от D-Bus (d-bus services)
Современные демоны на Linux, как правило, предоставляют услуги посредством D-Bus, а не простого сокета AF_UNIX. Таким образом, появляется вопрос - а можем ли мы применить для них ту же логику распараллеливания запуска сервисов, что и для для традиционных сокетов? Да можем! В D-Bus уже есть все необходимое для этого: с помощью активации посредством D-Bus служба может быть запущена при первом же обращении к ней. Такой способ запуска дает нам минимальную возможность синхронизации на запрос, которая нам нужна для одновременного запуска служб-потребителей и служб-поставщиков: если мы хотим запустить Avahi одновременно с CUPS (CUPS использует Avahi для поиска mDNS/DNS-SD принтеров), то так и следует сделать, и если CUPS запустится раньше, то с помощью логики активации сервисов посредством шины мы заставляем D-Bus создать очередь запросов, пока Avahi запускается.
Параллелизация заданий, имеющих отношение к файловой системе
Если вы посмотрите на графики визуализации загрузочного процесса текущих дистрибутивов, то увидите множество точек, требующих синхронных операций: самое важное - это задания, связанные с файловыми системами. Обычно при загрузке системы много времени тратится на ожидание инициализации всех устройств, перечисленных в файле /etc/fstab, затем на проверку файловых систем, инициализацию квот. Только после того как это все закончится, мы сможем продолжить процесс загрузки.


