Tue, Sep 21, 2010

Почему нам не нужен третий дистрибутив Linux

Это мой перевод еще одной статьи из блога Novell о том, нужен ли рынку решений дистрибутив Linux от Oracle. Статья мне показалась интересной, хотя бы своим тоном по отношению к недавнему покупателю Sun. Ссылка на оригинал - в конце статьи.



Майкл Аппельбаум, директор по Linux-решениям
Хорошо известно, что Novell и Red Hat по-прежнему задают тон, когда речь идет о Linux для промышленных решений, но Oracle пытается прорекламировать новое решение на Linux, которым она надеется улучшить свое состояние на этом рынке. Изменят ли эти последние новости отношение этого рынка к Oracle? Эксперты с этим не согласны.
Лучше всего задаться таким вопросом: а нужен ли корпоративному рынку еще один дистрибутив Linux?

Когда дело доходит до корпоративных решений на Linux, Novell и Red Hat по-прежнему доминируют на рынке. В последних результатах, представленных IDC, Novell и Red Hat совместно получают 95% доходов от Linux, причем в прошлом году эта доля была 94%. Oracle же не достигла даже 1% о доходов рынка Linux. Несмотря на заявления Oracle о наличии тысяч клиентов по Linux-направлению, аналитикам еще предстоит увидеть ее хоть сколь-нибудь заметное влияние на рынок. Между тем, доля Novell здесь продолжает расти, увеличившись за последний год на 5 процентов с аналогичным снижением доли Red Hat.
Так почему только эти два дистрибутива Linux из многих существующих сегодня удерживают более 90% коммерческого рынка? Причем, они завоевали множество сегментов рынка и имеют среди своих приверженцев много состоятельных компаний.
Почему же есть только два успешных коммерческих поставщика Linux? Во-первых, для создания и поддержки Linux-дистрибутива корпоративного класса необходимо наличие хорошей инфраструктуры. Не так легко получить право на поддержку сертифицированных приложений, причем тут есть определенный элемент проблемы «курица-яйцо». Только Novell и Red Hat имеют каталог приложений, которые исчисляются тысячами, причем Novell опережает Red Hat по этому показателю в два раза и предлагает более 500 сертифицированных приложений Oracle. Предоставление поддержки корпоративного класса - сложное и дорогое занятие, хоть это и не препятствие для Oracle. И, чтобы сделать такие инструменты как SUSE Studio для развертывания приложений для облачных вычислений, требуются инновационное мышление и ресурсы. Другими словами, для входа на этот рынок есть реальные барьеры, даже если это рынок, которые может кое-кому показаться коммодитизированным (Это термин, который я решил не переводить. Самое нормальное объяснение ему я нашел здесь. Вот цитата оттуда: «Коммодитизация — то, что случается с продуктами, которые становятся достаточно дешёвыми в массовом производстве, и вместо одного уникального товара возникает море из торговых марок. Различий в потребительских качествах между разными брендами не остаётся, так что прежние звёзды теряют при этом свою уникальность. «Компьютер станет также распространён, как микроволновая печь» — это коммодитизация.». - Прим. перев.).
Давайте с вами рассмотрим - имеется ли на рынке потребность в третьем дистрибутиве Linux? Давайте посмотрим на эту ситуацию глазами клиента, купившего поддержку Linux от Oracle:
Будет ли это поставщик решений с бОльшим опытом, чем Novell и Red Hat? Нет. 
Будет ли это поставщик, который будет привержен идее Linux-инноваций для всех физических, виртуальных и облачных платформ, которые могут понадобиться клиентам? Нет. В центре интересов Oracle находится только сам Oracle. Если вам потом понадобится купить решение VMware или для мэйнфреймов, что ж надо было думать раньше.
Будет ли это поставщик, заинтересованный в развитии Linux как стратегической платформы и уделяющий особое внимание ее разработке? Опять нет. (Просто попросите кого-нибудь из Oracle объяснить сегменты рынка и указать рекомендуемые области использования Solaris и Oracle Linux, а затем смотрите, как они будут выкручиваться).
В конечном счете, все дело в том, что рынку просто не нужен третий дистрибутив Linux. Наличие двух сильных игроков - Novell и Red Hat - делает рынок достаточно конкурентным, и наши команды по R&D совместно с талантливыми людьми из сообщества ПО с открытым исходным кодом рождают исключительные инновации в таких областях как виртуализация, облачные вычисления, кластеры и HA-решения, управление предприятиями. Хотя, безусловно, в интересах Oracle быть на рынке решений Linux, ведь их доля на рынке отстает.
Конечно, нужно признать историческую роль Oracle в качестве сильного партнера экосистемы Linux, включая Novell, с такими инициативами, как OCFS и тесты баз данных Oracle на разных дистрибутивах Linux, включая SUSE Linux Enterprise Server. Это ключевые элементы, которые делают нынешний Linux таким ярким.
Вопрос: нужен ли клиентам третий дистрибутив Linux? Пока по крайней мере, другого ответа, кроме «нет» найти нельзя.

Sun, Sep 19, 2010

Кто покупает Novell? Делайте ваши ставки!

Мой перевод статьи-размышления от Joe Brockmeier о том, кому может достаться Linux-бизнес Novell


Прошел слух, что Novell достигла предварительного соглашения о продаже, что расколет ее бизнес на две части и продаст ее Linux-отделение "неназванному стратегическому покупателю". Предполагая, что сделка все-таки состоится, кто же этот покупатель, и что это будет означать для SUSE и проекта OpenSUSE ?

Краткая отмазка: Novell мой бывший работодатель. Я ушел из компании в конце января, и, насколько я знаю, предложение в 2 млрд. долларов от Elliott Associates тогда еще даже не обсуждалось. Во всяком случае у меня нет какой-либо внутренней информации (позвони же мне, Ян...), так что написанное ниже - всего лишь мои размышления. У меня нет никакой заинтересованности в каком-то определенном покупателе. Я только надеюсь, что мои бывшие коллеги будут работать в компании, которая будет относиться с уважением к ним и проекту OpenSUSE.


Давайте рассмотрим потенциальных покупателей. Novell недавно заключила несколько стратегических соглашений с VMware, и имеет давние партнерские отношения с IBM и SAP. Oracle сейчас также находится в режиме постоянных приобретений, и, вполне возможно, захочет закусить бизнесом SUSE Linux после своей покупки Sun. Но зачем было разрушать нарождающееся сообщество открытого исходного кода (OpenSolaris), когда можно иметь два (OpenSUSE)?

Давайте начнем с Oracle. Oracle имеет свою собственную платформу Oracle VM, имеющую в основе Xen и Red Hat Enterprise Linux(RHEL). Ну хорошо, RHEL с логотипами Oracle. Oracle Unbreakable Linux полностью бинарно совместим с RHEL безо всяких излишних затрат на развитие, которые Red Hat фактически вкладывает свой дистрибутив.

Правда, есть одна маленькая проблема, в грядущем релизе Red Hat просто выкинет Xen в окно, предпочитая ему KVM. Oracle должен будет либо последовать ее примеру и инвестировать в такой переход, или ей придется нарушить совместимость с RHEL после релиза RHEL 6. Если Oracle останется на Xen, ей придется подумать о переходе на другой дистрибутив. Novell по-прежнему до сих пор не вкладывает свои деньги ни в одну платформу, предпочитая стратегию «и нашим и вашим», то есть поддерживая все платформы виртуализации.

Возможно, я излишне оптимистичен, но я считаю маловероятным то, что Oracle собирается поглотить бизнес SUSE. Если это произойдет, я не верю в будущее проекта OpenSUSE. Даже если Oracle все же решит поддерживать его, стиль работы Oracle с сообществом отвратителен. Покупка Oracle сильно затормозит тот прогресс, на который взял курс этот проект, и, кажется, весьма вероятно, что компания увидит «утечку мозгов» подобно той, что произошла после покупки Sun.

IBM - другой претендент. IBM поддерживает партнерские отношения со всеми крупными Linux-компаниями: SUSE, затем Novell, Red Hat и Canonical. Покупка одного из трех и создание своего собственного дистрибутива выглядит не слишком хорошо. Это может даже сделать Red Hat одним из конкурентов IBM, чего никто не хочет. Но IBM и Novell сильно завязаны друг на друге в бизнесе мэйнфреймов, поэтому IBM может решить, что иметь в своем портфеле SUSE будет очень хорошо. Если IBM серьезно относится к форку OpenOffice.org - Symphony, то она также может захотеть заполучить кого-то из разработчиков Novell, участвующих в Go-OO.org. Хотя это, вероятно, подтолкнет HP, Dell и других к Red Hat или другим дистрибутивам. IBM может быть хорошим управленцем для сообщества OpenSUSE; безусловно, гораздо более лучшим, чем Oracle.

Еще один из вариантов - SAP. У нее много стратегических соглашений с Novell/SUSE и много крупных клиентов на SUSE Linux. Но SAP использует также другие продукты Novell, что входит в противоречие со слухом, что компания покупает только Linux-отделение, а все остальное достанется инвестиционным фирмам. Если SAP собиралась бы купить Novell, кажется, более вероятно, что она бы просто купила компанию целиком без лишней суеты.

Все это подводит меня к наиболее вероятному выбору: VMware. VMware в последнее время уже покупала другие решения с открытым исходным (Zimbra, SpringSource), поэтому не будет преувеличением сказать, что эта компания, возможно, захочет добавить SUSE Linux в свой портфель. VMware также может захотеть иметь свой собственный дистрибутив Linux, чтобы помочь своим клиентам и партнерам построить больше готовых решений, которые будут работать на продуктах VMware для виртуализации. И для этого на рынке нет лучшего решения, чем SUSE Studio. Мне кажется, что SUSE Studio - это действительно хорошее дополнение к VMware Appliance Marketplace. Red Hat сейчас только на пути построения своего собственного решения для виртуализации, так что это также помогло бы конкурировать VMware с поставщиком Linux номер один.

Как это отразится на проекте OpenSUSE и SUSE Linux в целом? Думаю, что все будет по крайней мере также, если не лучше, по сравнению с тем периодом, когда у руля стояла Novell. Скорее даже лучше, потому что Novell временами впадает в кризис самоидентификации, когда она пытается разобраться, как все ее бизнес-единицы сочетаются друг с другом. SUSE же идеально впишется в стратегию компании VMware - по крайней мере, на взгляд со стороны.

И в завершение совсем кратко - а что же Microsoft? Вот это точно вряд ли. Мне трудно представить себе, как она собирается действовать, оставаясь в рамках антимонопольного законодательства.

Так кто же скрывается под неизвестным «стратегическим покупателем»?

Я ставлю все, что у меня есть, на VMware, но я вполне могу оказаться неправ. Это могут быть IBM, SAP, или (только не это!) Oracle. Или это кто-то другой, о котором я не подумал. Есть варианты? 

Оригинал статьи


От переводчика. 
Что не удалось Novell?  
Первое: никакой маркетинг. Novell имеет прекрасный набор продуктов для полноценного построения инфраструктуры предприятия любого масштаба - eDirectory, ZenWorks, все сервисы OES. Причем, каждый из этих продуктов пока не имеет конкурентов по полноте охвата всех имеющихся платформ и по своему функционалу.
Второе: слабая работа с сообществом. Пример такой работы следовало бы брать с конкурента номер 1. Novell участвует во многих открытых проектах, но мало кому известны масштабы этого участия.
У Novell реально классные продукты. У нас на курсах многие администраторы с теплом в глазах вспоминали Netware, надежность которой осталась непревзойденной до сих пор. И очень жаль что эта операционная система оказалась вытесненной продуктом гораздо худшего качества. 

Sat, Sep 18, 2010

«Веб-лицо» проекта openSUSE. Новая русскоязычная Wiki.

Не секрет, что в наше время визитной карточкой любого проекта или компании является его или её веб-сайт, тем более для проекта из сферы информационных технологий.
Именно поэтому, чтобы соответствовать передовым технологиям, одновременно с выходом новой версии openSUSE обновились и все интернет-порталы проекта. Изменился дизайн, структура, появились модные в эпоху «веб 2.0» округлые элементы, добавились новые сервисы...
Казалось бы, чего ещё желать? А желать есть чего. Дело в том, что эти изменения коснулись преимущественно «стандартных» англоязычных версий порталов, в то время как локализованные версии остались в своем прежнем исполнении и уже не вписываются в единую структуру opensuse.org
За примерами далеко ходить не надо - достаточно сравнить английскую и русскую версии Wiki.





Как видно из скриншотов английская версия выполнена в едином стиле с той же Планетой, например, а русская Wiki выглядит не как часть портала, а как отдельный ресурс.
Но, как гласит известная поговорка: «Будет и на нашей улице праздник!» Совсем недавно специально для локализованных версий Вики был запущен портал languages.opensuse.org
Благодаря активности нашей Wiki-team русскоязычный раздел появился там первым.
Сейчас сайт выглядит вот так:



Видно, что по сути - это создание мультиязычной версии Wiki почти с нуля. Именно поэтому сейчас команде Wiki очень необходима помощь всего сообщества. Объём работ предстоит колоссальный! От своего лица и от лица команды вики призываю всех, кто хочет помочь, и у кого есть свободное время, принять активное участие в наполнении новой Wiki качественным содержимым. Это может быть перевод статей из английской версии, перенос и обновление статей из прежней вики, а также создание новых статей по ещё не освещённым темам.

Из новых сервисов хочу отметить официальную соц-сеть сообщества openSUSE - connect.opensuse.org На текущий момент сервис работает в бета (альфа ?) режиме - пробуются разные движки, меняется набор функций и пр. Но зайти под тестовым аккаунтам иувидеть всё своими глазами можно уже сейчас.

В разговорах на IRC канале я заметил, что не все пользователи знают, какие ресурсы доступны на opensuse.org, поэтому ниже приведу список известных мне сервисов с кратким описанием, если что-то упущу - добавляйте в комментах.

Список ресурсов домена opensuse.org:
Ну и в заключении хочу сообщить, что я таки раскошелился на личный домен, и теперь этот блог доступен по новому адресу blog.linux-oid.ru.

Fri, Sep 17, 2010

Другой путь к свободе


Предлагаю вниманию читателей блога интересные размышления о свободе и свободном ПО, автор которых Jos Poortvliet - нынешний лидер сообщества openSUSE.
Дисклеймер: политические взгляды переводчика могут не совпадать с мнением автора статьи

Jos Poortvliet
В конце прошлой недели Нью-Йорк Таймс поместила историю о том, как правительство России использует вопросы лицензирования программного обеспечения для борьбы с протестами и митингами несогласных. В статье объясняется, что русская милиция изымает их компьютеры под предлогом использования пиратского программного обеспечения. В результате данные, полученные из этих компьютеров, помогают органам изучить планы активистов, что в дальнейшем приводит к их арестам.

И хотя Microsoft отреагировала на эту ситуацию выдачей разрешительных лицензий для таких организаций, читая статью я подумал, что есть другой, гораздо лучший способ помешать органам использовать тему лицензирования ПО как повод для арестов. Хоть этот способ не остановит авторитарные правительства от борьбы с инакомыслящими, использование свободного и открытого программного обеспечения может затруднить органам узаконить этот тип действий.
Во-первых, философия свободы пронизывает все существо тех мужчин и женщин в сообществе, разрабатывающем программное обеспечение с открытым исходным кодом, что приводит ко многим нововведениям, препятствующим ограничениям свобод. Например, это такие вещи, как шифрование с помощью GPG и технология TOR, которые делают возможным использование анонимных коммуникаций для миллионов пользователей в таких странах, как Китай и Иран. Не говоря уже о том, что в мире открытого ПО у нас есть сильный акцент на безопасность и защиту от таких угроз, как вирусы или "бекдоры", помещаемые в коммерческое ПО путем давления со стороны правительств.
Во-вторых, сообщество открытого ПО делает акцент на устранении существующих ограничений для людей - будь-то физические ограничения, как у инвалидов, или для тех, кто нуждается в том, чтобы защитить себя от любопытных глаз цензуры в своей стране. Мы создаем для таких людей инновационные и зачастую просто выдающиеся продукты, которые при незначительных или вообще нулевых затратах за использование дают им возможность получить преимущества в условиях развивающейся экономики. Чтобы свободно использовать, чтобы изучать и чтобы строить свой бизнес вокруг свободного ПО. Открытое программное обеспечение предлагает реальную альтернативу тем, кто нуждается в экономичных и социально-значимых вычислительных решениях.
И да, это РЕАЛЬНО лучший продукт, чем может предложить мир проприетарного ПО - несмотря на то, что он «другой» по своей сути. Свободное ПО не совершенно — например, как Нидерланды, где я живу, совсем не совершенны. В самом деле, чтобы нормально жить в моей стране, скажем, жителю Северной Кореи, нужен какой-то срок на адаптацию, примерно также, как и пользователю Windows нужно привыкнуть к использованию openSUSE. Но в Нидерландах и с открытым ПО реально лучше, потому что они более свободны.
Да, мы создаем сильные и убедительные альтернативы проприетарному ПО. Но НЕ достаточно просто иметь лучший продукт - свобода это также его неотъемлемое качество. Работающий TOR-сервер - даже если вы живете в демократической стране и вам нечего скрывать - помогает жителям других стран, имеющих репрессивные правительства, потому что вы даете им возможность использовать ваше интернет-соединение - для сокрытия от любопытных глаз своего правительства. Свободное ПО воплощает ожидания и убеждения для деятельности, связанной со свободой и организацией сообществ, например, таких групп активистов, как Baikal Wave. Любому лицу, группе или организации, которые желают действовать на основе того, во что верят, следует рассмотреть возможность использования свободного программного обеспечения как способ жить и работать без ущерба для своих убеждений.
Я не скажу, что свободное и открытое ПО делает мир совершенным - но это шаг в нужном направлении. В конце концов, «в мире, где общение речь зависит от ПО, свобода слова зависит от свободного ПО»! (D.B. Martin)

Другой путь к свободе


Предлагаю вниманию читателей блога интересные размышления о свободе и свободном ПО, автор которых Jos Poortvliet - нынешний лидер сообщества openSUSE.
Дисклеймер: политические взгляды переводчика могут не совпадать с мнением автора статьи

Jos Poortvliet
В конце прошлой недели Нью-Йорк Таймс поместила историю о том, как правительство России использует вопросы лицензирования программного обеспечения для борьбы с протестами и митингами несогласных. В статье объясняется, что русская милиция изымает их компьютеры под предлогом использования пиратского программного обеспечения. В результате данные, полученные из этих компьютеров, помогают органам изучить планы активистов, что в дальнейшем приводит к их арестам.

И хотя Microsoft отреагировала на эту ситуацию выдачей разрешительных лицензий для таких организаций, читая статью я подумал, что есть другой, гораздо лучший способ помешать органам использовать тему лицензирования ПО как повод для арестов. Хоть этот способ не остановит авторитарные правительства от борьбы с инакомыслящими, использование свободного и открытого программного обеспечения может затруднить органам узаконить этот тип действий.
Во-первых, философия свободы пронизывает все существо тех мужчин и женщин в сообществе, разрабатывающем программное обеспечение с открытым исходным кодом, что приводит ко многим нововведениям, препятствующим ограничениям свобод. Например, это такие вещи, как шифрование с помощью GPG и технология TOR, которые делают возможным использование анонимных коммуникаций для миллионов пользователей в таких странах, как Китай и Иран. Не говоря уже о том, что в мире открытого ПО у нас есть сильный акцент на безопасность и защиту от таких угроз, как вирусы или "бекдоры", помещаемые в коммерческое ПО путем давления со стороны правительств.
Во-вторых, сообщество открытого ПО делает акцент на устранении существующих ограничений для людей - будь-то физические ограничения, как у инвалидов, или для тех, кто нуждается в том, чтобы защитить себя от любопытных глаз цензуры в своей стране. Мы создаем для таких людей инновационные и зачастую просто выдающиеся продукты, которые при незначительных или вообще нулевых затратах за использование дают им возможность получить преимущества в условиях развивающейся экономики. Чтобы свободно использовать, чтобы изучать и чтобы строить свой бизнес вокруг свободного ПО. Открытое программное обеспечение предлагает реальную альтернативу тем, кто нуждается в экономичных и социально-значимых вычислительных решениях.
И да, это РЕАЛЬНО лучший продукт, чем может предложить мир проприетарного ПО - несмотря на то, что он «другой» по своей сути. Свободное ПО не совершенно — например, как Нидерланды, где я живу, совсем не совершенны. В самом деле, чтобы нормально жить в моей стране, скажем, жителю Северной Кореи, нужен какой-то срок на адаптацию, примерно также, как и пользователю Windows нужно привыкнуть к использованию openSUSE. Но в Нидерландах и с открытым ПО реально лучше, потому что они более свободны.
Да, мы создаем сильные и убедительные альтернативы проприетарному ПО. Но НЕ достаточно просто иметь лучший продукт - свобода это также его неотъемлемое качество. Работающий TOR-сервер - даже если вы живете в демократической стране и вам нечего скрывать - помогает жителям других стран, имеющих репрессивные правительства, потому что вы даете им возможность использовать ваше интернет-соединение - для сокрытия от любопытных глаз своего правительства. Свободное ПО воплощает ожидания и убеждения для деятельности, связанной со свободой и организацией сообществ, например, таких групп активистов, как Baikal Wave. Любому лицу, группе или организации, которые желают действовать на основе того, во что верят, следует рассмотреть возможность использования свободного программного обеспечения как способ жить и работать без ущерба для своих убеждений.
Я не скажу, что свободное и открытое ПО делает мир совершенным - но это шаг в нужном направлении. В конце концов, «в мире, где общение речь зависит от ПО, свобода слова зависит от свободного ПО»! (D.B. Martin)

Wed, Sep 15, 2010

Размышления Марка Шаттлворта об 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. Каждый из этих проектов играет свою собственную роль, но это все в целом реально меняет мир. Поэтому, когда мы начинаем спорить друг с другом о том, какая часть свободного ПО перспективнее, мы рискуем упустить картину в целом. Это немного похоже на аутоиммунные заболевания, когда организм начинает атаковать сам себя. Тот, кто напряженно работает в течение всего дня, чтобы донести свободное ПО до более широкой аудитории, играет на той же стороне, что и я, если уж мы применяем такую терминологию. Я восхищаюсь и уважаю всех тех, кто вкладывает свою энергию в продвижение свободного программного обеспечения, даже если он делает это по-другому.

Fri, Sep 03, 2010

Система инициализации Systemd. Часть II

Это продолжение начатого тут.




Собираем все вместе - systemd


Выше я объяснил, что должен делать хороший процесс с PID 1 и как работают существующие системы инициализации. Перед тем как перейти к самому главному, давайте сделаем еще паузу. Сходите налейте себе еще кружечку кофе. Это того стоит.

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

Поскольку systemd запускает и контролирует всю систему, отсюда и ее название. Она реализует все возможности, указанные выше, и еще кое-что. Система построена на концепции модулей (units). Модули имеют имя и тип. Поскольку их конфигурация обычно загружается из файловой системы - названия модулей на самом деле представляют собой имена файлов. Например: модуль avahi.service считывается из конфигурационного файла с тем же именем и естественно, что он реализует работу с демоном Avahi. Существует несколько видов модулей: 
  • 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: достаточно много сервисов не могут корректно работать с этой системой, и зачастую их лучше остановить перед засыпанием, а потом просто запустить.

Приведенные модули могут иметь зависимости друг от друга (как положительные, так и отрицательные, т. е. бывает, что одни без других не могут обойтись, а другие, наоборот, не могут терпеть друг друга): например, модуль устройство может зависеть от какого-то модуля сервис, т.е. как только устройство становится доступным - запускается определенный сервис. Модули mount имеют неявную зависимость от устройства, которое они пытаются смонтировать. Также они наследуют неявные зависимости от префиксов путей к точкам монтирования (например, модуль, подключающий /home/lennart, неявно зависит от модуля, подключающего /home)и так далее.

Краткий перечень остальных функциональных возможностей:
  1. Для каждого порожденного процесса вы можете контролировать: среду исполнения, ограничения ресурсов, рабочую и корневую директории, umask, настройки OOM killer, параметр nice, класс и приоритет операций ввода-вывода, политику и приоритеты использования процессора, привязку к процессору, таймер, идентификаторы пользователя, основной и дополнительных групп, списки директорий, доступных для чтения/записи, список директорий, доступ к которым запрещен, флаги монтирования, биты безопасности, параметры, относящиеся к планировщику процессора CPU, области видимости /tmp, привязку к cgroup для различных подсистем. Также можно присоединить stdin/stdout/stderr сервисов к syslog, /dev/kmsg, произвольным TTY. Если вы присоединяете TTY ко входу systemd - удостоверьтесь в том, что процесс получает эксклюзивный доступ. 
  2. Каждый запущенный процесс получает собственную cgroup (в текущем состоянии разработки по умолчанию они создаются в подсистеме debug, поскольку она все равно не используется). С помощью systemd также легко помещать отдельные сервисы в различные cgroups, причем, это можно сделать из пользовательского пространства, например, посредством утилит libcgroups. 
  3. Файлы конфигурации systemd имеют синтаксис, аналогичный используемому в файлах .desktop, который прекрасно разбирается (parse) многими имеющимися утилитами и имеет все необходимое для интернационализации. Поэтому администраторам и разработчикам не нужно учить новый синтаксис. 
  4. Как упоминалось выше, мы (Здесь и далее под "мы" понимаются разработчики и сама 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. Прим. перев.).
  5. Аналогичным образом, существующий файл /etc/fstab читается и используется как еще один источник конфигурации. А с использованием опции comment= fstab вы даже можете отметить отдельные записи в этом файле, чтобы передать их под контроль systemd (для обеспечения работы функционала автоматического монтирования). 
  6. Если для одного сервиса существует несколько файлов конфигурации (например, есть два файла /etc/systemd/system/avahi.service и /etc/init.d/avahi), тогда "родной" формат файлов имеет преимущество. Устаревший формат файлов игнорируется, позволяя легко провести обновление. 
  7. Мы также поддерживаем механизм использования шаблонов. Например, вместо того, чтобы иметь шесть одинаковых конфигурационных файлов для шести getty, у нас есть только один файл getty@.service, который используется сервисом getty@tty2.service и аналогичными ему. Интерфейсная часть также может наследоваться выражениями, описывающими зависимости, т. е. легко понять, что сервис dhcpcd@eth0.service запускается сервисом avahi-autoipd@eth0.service. 
  8. Для активации сервисов посредством сокетов, мы поддерживаем полную совместимость с традиционной моделью 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. Также мы портировали множество существующих демонов на эту схему. 
  9. Мы предоставляем совместимость с интерфейсом /dev/initctl. Эта совместимость фактически реализована с помощью сервиса, активируемого посредством FIFO, который просто транслирует устаревшие запросы в запросы D-Bus. На практике это означает, что старые команды shutdown , poweroff и аналогичные им из Upstart и sysvinit будут работать с systemd. 
  10. Мы предоставляем совместимость с utmp и wtmp. Код, который это делает, выглядит гораздо более жизнеспособным, чем эти файлы :).
  11. systemd поддерживает несколько типов зависимостей между модулями. After/Before могут использоваться для определения последовательности запуска. Requires/Wants определяет статус зависимости, является она обязательной или опциональной. И наконец, Conflicts определяет отрицательный характер зависимости (т. е. две и более службы, у которых в зависимостях указана Conflicts, не смогут быть запущены одновременно - прим. перев.). Есть также еще три, менее часто используемые типы-зависимостей. 
  12. systemd построена как система с минимумом транзакций. Это означает: если модуль запросил запуск или остановку, мы добавляем его и все его зависимости во временную транзакцию. Затем проверяем целостность этой транзакции, т.е. последовательности обработки зависимостей After/Before для всех модулей на возможность появления циклических зависимостей. Если они есть, systemd пытается исправить ситуацию путем удаления из транзакции «несущественных» (non-essential) заданий. Также systemd пытается убрать из транзакции такие из «несущественных» заданий, которые могут остановить какой-либо другой сервис (не имеющий отношение к останавливаемому модулю). «Несущественными» являются такие задания, которые не относятся к оригинальному запросу, но при этом помещены в очередь на основе зависимостей Wants. В заключение проверяется, могут ли задания в транзакции противоречить заданиям, которые уже находятся в очереди и, если возникла такая ситуация, транзакция отменяется. Если все сработало корректно, транзакция целостна и минимизирована по количеству операций, она ставится в очередь на исполнение. В сухом остатке это означает, что перед запуском запрошенной операции мы проверяем, имеет ли смысл ее вообще выполнять, если возможно, исправляем возникшие ошибки, и затем ничего не делаем, если операцию выполнить невозможно. 
  13. Мы записываем время запуска/остановки, PID и статус завершения для каждого из порождаемых и/или контроллируемых процессов. Эти данные позволяют увязать демоны с их данными в abrtd, auditd и syslog и создать интерфейс, который выделял бы упавшие демоны и предоставлял бы всю необходимую о них информацию.
  14. Мы также реализовали самостоятельный перезапуск процесса init в любое время по требованию. Состояние демона замораживается перед этим и размораживается после. Таким образом мы упрощаем онлайнового обновления с SysV init на systemd, а также передачу полномочий от остановленного к перезапущенному демону. Запросы к открытым сокетам и точкам монтирования autofs, как уже отмечалось выше, будут корректно упорядочены и поставлены в очередь ядром, поэтому клиенты даже не почувствуют, что что-то вообще произошло. Поскольку большая часть информации о состоянии обслуживаемых systemd процессов хранится в виртуальной файловой системе cgroup, это позволяет нам не прерывать их исполнения из-за невозможности доступа к данным init. Код, реализующий перечитывание конфигурации init, является общим с кодом его перезапуска. 
  15. Избавляясь от shell-скриптов в процессе запуска системы, мы переписали основную их часть на C и поместили непосредственно в systemd. В частности, это код таких операций как монтирование виртуальных файловых систем /proc, /sys and /dev и установка имени хоста. 
  16. Состояние сервиса доступно и может контроллироваться через D-Bus (за это Upstart не пинал только самый ленивый - прим. перев.). Правда, эта возможность пока не реализована и находится в стадии активной разработки. 
  17. Мы придаем особое значение активации сервисов посредством сокетов либо через D-Bus (и, следовательно, поддерживаем обработку соответсвующих зависимостей). В то же время мы поддерживаем традиционные зависимости только между сервисами. Также поддерживается несколько способов, которыми сервис может сообщить о своей готовности: путем вызова fork() и завершением родительского процесса (традиционное поведение daemonize()) и посредством публикации своего имени на D-Bus.
  18. Существует интерактивный режим, который запрашивает подтверждения для каждого из процессов, порождаемого systemd. Вы можете включить это, передав параметр systemd.confirm_spawn=1 в строке параметров ядра.
  19. С помощью параметра systemd.default= в строке параметров ядра вы можете указывать, какой из модулей systemd нужно запускать при загрузке системы. Обычно здесь находится что-то вроде multi-user.target, но можно указать и какой-то один сервис вместо модулей типа «указатель», к примеру, «из коробки» мы поставляем сервис emergency.service, который по своему назначению подобен параметру init=/bin/bash, но по сравнению с ним имеет то преимущество, что можно запустить полнофункциональную систему прямо из оболочки восстановления от сбоев (emergency shell). 
  20. Также есть минимальный пользовательский интерфейс, позволяющий запускать/останавливать сервисы и наблюдать за ними. Правда, он еще далек от завершения, но вполне может использоваться как утилита для поиска ошибок. Он написан на Vala и называется systemadm.

Следует также заметить, что systemd использует много специфичных для Linux возможностей, не ограничиваясь стандартами POSIX. Это позволяет использовать огромное количество возможностей Linux, разработанных для портируемости, которые остальные системы не предоставляют.

Состояние разработки


Значительная часть перечисленных выше возможности уже реализована. В настоящее время systemd уже может использоваться как полноценная замена для Upstart и sysvinit (по крайней мере, пока не все сервисы еще отконвертированы в формат Upstart, за что спасибо разработчикам основных дистрибутивов).

Однако объем тестирования systemd минимальный, поэтому номер версии, которую мы имеем на сегодняшний день - это абсолютный и великолепный НОЛЬ. Так что, если решитесь использовать ее в таком виде, как она есть, ждите появления некоторого количества неожиданных проблем (автор намекает на необходимость обязательного наличия бубна при использовании systemd на рабочих машинах - прим. перев.). Другими словами, все должно работать почти стабильно. Кое-кто из нас был настолько смел, что загружал наши рабочие машины с помощью systemd (не только виртуальные, но и те, которые мы обычно используем для разработки). В общем, тут как повезет, особенно если пробовать systemd на дистрибутивах, которые мы - разработчики - не используем.

Предполагаемые направления развития


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

Мы хотим добавить, по крайней мере, два типа модулей. Первый - это swap, который будет контролировать разделы подкачки теми же способами, которыми мы контролируем точки монтирования, т. е. автоматическое разрешение зависимостей для тех устройств, на которых они расположены. Второй - это timer, обеспечивающий функционал, подобный cron, т. е. возможность запускать сервисы по определенным временным событиям, используя как обычные временные интервалы, так и календарные даты (т. е. «запустить через 5 часов после последнего запуска» и «запускать каждый понедельник в 5 часов»).

Более важно часть наших планов - это не только экспериментировать с systemd для оптимизации времени запуска, но также сделать из него полноценный и идеальный менеджер сессий, чтобы заменить (или, по крайней мере, попытаться) gnome-session, kdeinit и подобные демоны. Набор проблем и задач, которые надо решить для менеджера сессий и системы инициализации по большому счету один и тот же: максимально быстрый запуск жизненно важных частей и выполнение функций няньки по отношению к запущенным процессам. Для этого можно использовать тот же код. В Apple для этого похожим образом используется launchd. Поэтому мы хотим использовать описанные выше способы активации сервисов через сокеты и D-Bus и максимальную параллелизацию запуска процессов и для менеджера сессий и для системных сервисов.

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

Однако есть некоторые вещи, которые мы должны предварительно исправить в ядре и в пользовательском пространстве, прежде чем закончить работу над systemd: нам нужны извещения об изменениях состояния подкачки, способом подобным тому, как сейчас работает с монтирование файловых систем; мы также хотим реализовать извещения когда CLOCK_REALTIME перескакивает на CLOCK_MONOTONIC; мы хотим позволить обычным процессам получить часть возможностей init; нам нужно хорошо документированное и общепризнанное место, куда нам нужно положить сокеты. Ничего из этого не является жизненно необходимым для systemd, но может здорово ее улучшить.

Вы хотите увидеть systemd в действии?


Мы пока еще не выпускали релизов, поэтому у нас нет готовых тарболов. Но если вам очень хочется, вы всегда можете сделать снимок с нашего текущего репозитория (git). В дополнение, чтобы вы вообще могли что либо запустить, здесь можно скачать тарбол с конфигурационными файлами для модулей, которые позволяют немодифицированной Fedora13 работать с systemd. У нас пока нет готовых RPM, чтобы их предложить вам.
Самый легкий путь - это скачать этот образ Fedora 13 для qemu, который специально приготовлен для systemd. В меню grub вы сможете выбрать - будете ли вы грузиться с помощью Upstart или с помощью systemd. Эта система имеет минимальный набор модификаций. Информация о сервисах читается исключительно из существующих скриптов SysV. «Благодаря» этому мы не получаем всех преимуществ от активации сервисов посредством сокетов и D-Bus. Но особенности systemd позволяют параллелизовать запуск сервисов только на основе чтения заголовков LSB и уже только это позволяет нам грузиться быстрее, чем через Upstart. Образ сконфигурирован таким образом, чтобы выдавать информацию для отладки на последовательную консоль и в буфер ядра для ведения логов (просматриваемый с помощью dmesg). Поэтому необходимо сконфигурировать для qemu поддержку виртуального последовательного терминала. В качестве всех паролей установлен systemd.

Еще более простой путь - это посмотреть на эти прекрасные скриншоты. На первом приведен интерфейс утилиты systemadm:



Здесь показан список загруженных модулей и вывод детальной информации об одном из экземпляров getty.



Это вывод команды ps xaf -eo pid,user,args,cgroup, показывающей насколько аккуратно все процессы отсортированы по своим cgroupsто показывает четвертая колонка с префиксом debug: такой префикс используется по той причине, что мы пока используем специальный контроллер cgroup для отладки. Это описывалось выше.)

К сожалению, у нас пока еще нет графиков загрузки или еще каких-то данных по времени запуска системы. Мы их опубликуем, как только сможем полностью параллелизовать запуск всех сервисов, поставляемых в Fedora. В тоже время, мы приветствуем проведение ваших собственных тестов и публикацию их результатов.

У меня пока есть только две цифры, которые я могу вам привести. Но они пока не заслуживают доверия, поскольку измерялись по времени загрузки виртуальной машины (один процессор). Fedora 13 грузится с помощью Upstart 27 секунд, с помощью systemd - 24 (от grub до gdm, с одними и теми же настройками, цифры измерены один раз, один запуск следовал за другим). Следует помнить, что цифры показывают только преимущество от использования параллелизации запуска скриптов на основе информации из их LSB заголовка. Поскольку не использовалась активация сервисов посредством сокетов или D-Bus - эти цифры по сути ничего не показывают.

Написание демонов


Идеальный демон, полноценно использующий возможности systemd должен делать некоторые вещи способами, отличными от традиционного поведения. Позже, мы опубликуем подробное руководство по написанию демона для использования с systemd. Ниже приведено краткое описание того, что нужно для разработчиков демонов:
  • Мы просим разработчиков не вызывать fork () (или даже двойной fork()) в своих процессах, используя цикл событий основного процесса, который systemd вызывает для вас. Также не вызывайте setsid().
  • Не стоит сбрасывать привилегии (имеется в виду, когда демон не должен быть запущен с root-привилегиями, прим. перев.) с помощью самого демона, предоставьте сделать это systemd и настраивайте это в ее конфигурационных файлах (Тут есть несколько исключений. К примеру, для некоторых демонов нужно сбрасывать привилегии только посредством самого демона после стадии инициализации, которая требует повышенных полномочий).
  • Не надо создавать PID-файлы. 
  • Имя демона следует получать с D-Bus.
  • Если вы хотите использовать возможности systemd для ведения логов, сбрасывайте все, что нужно включить в логи, на stderr.
  • Предоставьте systemd создать и обслуживать сокет для вас, благодаря чему будет работать активация посредством сокетов. Для этого нужно использовать $LISTEN_FDS и $LISTEN_PID как описывалось выше.
  • Используйте SIGTERM для остановки своего демона.

Все что приведено выше аналогично тому, что Apple рекомендует для демонов, совместимых с launchd. В то же время демоны, поддерживающие launchd легко портировать на systemd. Заметьте, что systemd (для совместимости) поддерживает и демоны, которые не поддерживают того, что описано выше. Демоны, совместимые с inetd, для активации посредством сокетов можно использовать без каких-либо модификаций. И, конечно же, как только systemd подтвердит свою жизнеспособность в наших экспериментах и начнет адаптироваться дистрибутивами - будет необходимо портировать на нее, по крайней мере, те сервисы, которые должны быть запущены по умолчанию. Мы уже пишем концепцию патчей и тогда процесс портирования станет очень легким. Кроме того, в определенной степени, мы можем использовать ту работу, которая уже была проделана для launchd. И, более того, демон, поддерживающий активацию посредством сокетов, не становится от этого несовместимым с системами отличными от systemd.

Часто задаваемые вопросы


Кто основные разработчики?
Большая часть кодовой базы - моя собственная работа, 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). Если вы этого никак не можете заметить - прочтите приведенный выше текст еще раз.

Помощь проекту 

 

Мы очень заинтересованы в патчах и другой помощи. В этом смысле наш проект ничем не отличается от любых других проектов свободного ПО, основные преимущества которых заключаются в как можно более широком взаимодействии с сообществом. И это, действительно, большей частью правда для такой фундаментальной части системы, как система инициализации. Нам ценно взаимодействие с вам, поэтому мы не требуем передачи прав (в отличие от Canonical/Upstart!). Мы также используем git, как всеми любимую систему контроля версий!
Мы сильно заинтересованы в том, чтобы systemd заработал на других дистрибутивах, отличных от Fedora и openSUSE (Эй, кто-нибудь из Debian, Gentoo, Mandriva, MeeGo, не хотите ли заняться этим?). Ну и помимо перечисленного, нам нужны коллеги любого уровня: мы приглашаем программистов на С, майнтейнеров пакетов, заинтересованных в написании документации или разработке логотипа.

Сообщество 

 

В настоящее время, все что у нас есть - это репозиторий с исходным кодом и IRC-канал (#systemd на Freenode). Нет списков рассылки, веб-сайта или системы отслеживания ошибок. Возможно, что скоро у нас будет нечто подобное на freedesktop.org. Если у вас есть некоторые вопрос, которые вы хотите задать нам, мы приглашаем вас к нам на IRC-канал!



Wed, Sep 01, 2010

Система инициализации Systemd. Часть I

Наверное, все уже слышали о новой системе инициализации systemd, которая разрабатывается под опекой Red Hat и Novell. Я решил перевести описание работы этой системы от ее автора из его же блога. Сама статья оказалась слишком большой, поэтому выкладываю пока только ее первую часть. Вторую часть я выложу в течение пары дней. Ссылка на оригинал традиционно приведена в конце поста. Также традиционно, мои комментарии по тексту приведены курсивом.


Если вы в теме и умеете хорошо читать между строк, то уже знаете, о чем пойдет речь. Но, думаю, все равно вам будет интересна эта статья. Поэтому налейте себе чашечку кофе, садитесь и читайте о том, что грядет.
История долгая, а для тех, кто не хочет читать целиком, скажу вкратце: мы экспериментируем с новой системой инициализации, и это весело!
Здесь код. А вот сама история:


Роль процесса с PID 1

 

Каждая Unix-система имеет процесс со своим специальным идентификатором, равным 1. Этот процесс запускается ядром прежде всех остальных и является родительским процессом для всех процессов, которые не имеют собственного родителя. Благодаря этому он может делать много чего такого, что не могут остальные процессы. Например отвечает за такие вещи, как инициализация и поддержка работы пользовательского пространства в процессе загрузки системы.

Исторически на Linux в качестве такого процесса выступает старый добрый sysvinit, преклонный возраст которого сказывается все чаще и чаще. Многие пытались предложить ему замену, но реально прижился только Upstart (что интересно, один из вариантов перевода слова «upstart» - «выскочка» - прим. перев.), который уже нашел свое место во всех основных дистрибутивах.

Как уже отмечалось выше, главная обязанность init'а - максимально быстро инициализировать и сделать доступным пользовательское пространство. К сожалению, традиционная схема инициализации SysV делает это не так быстро, как хотелось бы.
Для организации быстрого и эффективного процесса загрузки системы решающее значение имеет следующее:
  • Запустить минимум необходимого.
  • Попытаться запустить параллельно всё остальное.

Что это означает на практике?
Запустить минимум необходимого означает запустить лишь самые необходимые сервисы либо отложить запуск каких-либо из них до тех пор, пока они реально не понадобятся. Иногда мы заранее знаем, какие сервисы нам понадобятся (syslog, системная шина D-Bus и т.п.), но так бывает не всегда. К примеру, демон bluetoothd не должен быть запущен то тех пор, пока не будет подключен Bluetooth-адаптер либо пока какое-то из приложений не захочет установить с ним соединение через интерфейс D-Bus. Аналогично для системы печати: если машина физически не подключена к принтеру, и/или никакие приложения не пытаются напечатать что-нибудь, то необходимости запускать демон печати, такой как CUPS, нет. Так же и для Avahi: если машина не подключена к сети, или пока никакое из приложений не захочет использовать его API, его также нет необходимости запускать. Это справедливо даже для SSH: пока кто-либо не захочет зайти на машину - в нем нет необходимости, его нужно запустить лишь тогда, когда кто-то захочет установить первое соединение (и это же относится ко многим машинам, где может быть запущен ssh, в тех случаях, когда к нему присоединяются раз месяц или реже).
Параллельный запуск всего остального означает, что если нужно что-либо запустить, то мы должны делать это не последовательно, а пытаться запустить все одновременно, чтобы максимально нагрузить имеющиеся ресурсы системы, сократив время ее запуска.

 

Динамическое изменение аппаратного и программного обеспечения


Современные системы (в частности операционные системы общего назначения) являются весьма динамичными в плане своей конфигурации и использования: они мобильны, запускают и останавливают различные приложения, к ним подключают всевозможное оборудование. Система инициализации, отвечающая за работу сервисов, должна обнаруживать изменения в аппаратном и программном обеспечении,  запускать (а иногда и останавливать) сервисы, поскольку они необходимы для запуска программ и/или для обеспечения поддержки определенного оборудования.
Большинство современных систем, которые пытаются распараллелить процесс запуска, по-прежнему пытаются синхронизировать запуск различных демонов: например, Avahi для работы требуется D-Bus, поэтому сначала запускается D-Bus и только потом - Avahi.  Аналогично для других служб: для libvirtd и X11 необходим HAL (да, я знаю, что на Fedora 13 службы игнорируют устаревший HAL), поэтому сначала запускается HAL, а уж потом libvirtd и X11. А поскольку для libvirtd нужен Avahi, он ждет еще и запуска Avahi. К тому же всем упомянутым службам нужен Syslog, они все ждут его запуска. И так далее.

 

Параллелизация запуска сервисов, зависящих от сокетов (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 и т. д. Только подумайте - это единственное, чего они ждут.
Таким образом, если причина задержки только в этом, если мы сможем добиться того, чтобы перечисленные сокеты стали доступны ранее запуска соответствующих демонов, мы сможем серьезно ускорить процесс запуска системы и запустить намного больше процессов одновременно. Как же этого добиться? На самом деле в Unix-подобных операционных системах все довольно просто: мы можем создать слушающие сокеты, задолго до реального запуска демона, а затем (когда он запустится) просто передать ему сокет посредством в exec(). Таким образом, мы можем создать все нужные нам сокеты для всех демонов на первом шаге системы инициализации, а затем на втором шаге просто запустить все демоны одновременно. Если одна служба нужна другой - ничего страшного не случится, даже если требуемая служба еще не запущена: единственное что произойдет - требуемое соединение встанет в очередь на ожидание и клиент будет ждать этого соединения (будет блокирован запросом). Но заблокирован будет только один клиент и только одним запросом. Кроме того, чтобы обеспечить необходимую параллелизацию запуска, теперь совсем не обязательно конфигурировать зависимости между службами, ведь мы запускаем все сокеты одновременно и запущенный сервис будет уверен в том, что он сможет присоединиться к нужному ему сокету.
Это ключевой момент, и без него все остальное понять будет нельзя, поэтому я попробую пояснить все то же самое, но другими словами и с примерами. Допустим, вы запускаете демон syslog и его клиенты одновременно. При этом все сообщения его клиентов будут добавлены в буфер сокета /dev/log.  Пока этот буфер не заполнится, клиентам не придется ждать, и они смогут запуститься. Как только syslog завершит процесс своего запуска, он обработает накопившуюся очередь сообщений. Другой пример: мы запускаем D-Bus и ее несколько клиентов одновременно. Если отправляется синхронный запрос (запрос, требующий мгновенного ответа) и поскольку ожидается ответ, клиент будет блокирован ожиданием, но только этот конкретный клиент и только до тех пор, пока D-Bus поймает этот запрос и обработает его.
По сути, буферы сокетов ядра работают на нас, помогая нам максимально распараллелить запуск служб, причем обработка последовательности запросов и их синхронизация выполняется ядром системы без какой-либо надобности вмешиваться в этот процесс из пользовательского пространства! И если все сокеты становятся доступными прежде реального запуска демонов, управление зависимостями также становится излишним (или, по крайней мере, вторичным): если демону нужен другой демон, он просто подключится к нему. И если целевой демон уже запущен, то первый сразу же обратится к последнему. А если нет, то обратившийся демон не будет ждать его запуска, если только он не отправил синхронного запроса. И даже если этот другой демон вообще не запущен, это может быть сделано автоматически. С точки зрения первого демона в описанных случаях нет никакой разницы, следовательно управление зависимостями становится не нужно или, по крайней мере, вторично. Процесс запуска происходит с оптимальной параллелизацией запуска демонов либо с их запуском по требованию. Кроме того, такой путь обеспечивает большую надежность, так как сокеты остаются доступны независимо от фактического состояния демона, который может иногда быть недоступным (например из-за своего падения). В самом деле, вы можете легко написать демон, который будет запускаться, останавливаться (или падать) и запускаться снова и т. п., причем клиенты не почувствуют остановок демона и ни один запрос не потеряется.
Ну что ж, теперь самое время для паузы - налейте себе еще кофе и будьте уверены, что дальше будет еще интереснее.
Только сначала давайте проясним несколько вещей: это какая-то новая идея? Нет, определенно нет. Я назову вам одну из самых известных систем, работающих как описано: это launchd от Apple - на MacOS прослушивание сокетов всех демонов осуществляется launchd. Сами сервисы могут все запускаться одновременно, и для них не надо настраивать никаких зависимостей. Это на самом деле действительно интересная идея, и именно в ней кроется причина того, почему MacOS удается обеспечить фантастическую скорость загрузки. Я настоятельно рекомендую одно видео , где разработчики launchd объясняют, как она работает. К сожалению, предложенная идея так и не получила распространения вне лагеря поклонников Apple.
Хотя она, на самом деле, даже старше, чем launchd. До нее хорошо известный почтенный inetd работал аналогичным образом: сокеты централизованно создавались демоном, который запускал необходимый сервис, передавая ему дескриптор файла сокета посредством exec(). Однако центральной идеей inetd, конечно же, были не локальные, а интернет-сервисы (хотя более поздняя реализация поддерживала и сокеты AF_UNIX). Также он не являлся инструментом для распараллеливания процесса загрузки системы или какого-либо управления зависимостями между сервисами. Для TCP-сокетов inetd, в первую очередь, использовался таким образом, что для каждого входящего соединения новый экземпляр порождался новый экземпляр демона. Это означает, что для каждого соединения порождался и инициализировался новый процесс, что не очень хорошо для высокопроизводительных серверов. Тем не менее, с самого своего рождения inetd также поддерживает и другой режим, где демон порождался первым соединением и потом тот же экземпляр принимал последующие соединения (опция wait/nowait в файле inetd.conf , которая, к сожалению, плохо документирована). Запуск демона для каждого соединения, вероятно, создал для inetd репутацию медленного сервера, что не совсем справедливо.

Параллелизация запуска служб, зависящих от 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 запускается.

Резюме: активация демонов посредством сокетов и шины D-Bus позволяет нам запустить все демоны параллельно, без какой-либо синхронизации. Это позволяет нам получить «ленивые» сервисы: если сервис используется редко, можно просто загрузить его по потребности, вместо того, чтобы запускать его во время загрузки.
И если это не круто, тогда я не знаю, что круто!


Параллелизация заданий, имеющих отношение к файловой системе

Если вы посмотрите на графики визуализации загрузочного процесса текущих дистрибутивов, то увидите множество точек, требующих синхронных операций: самое важное - это задания, связанные с файловыми системами. Обычно при загрузке системы много времени тратится на ожидание инициализации всех устройств, перечисленных в файле /etc/fstab, затем на проверку файловых систем, инициализацию квот. Только после того как это все закончится, мы сможем продолжить процесс загрузки.
Можем ли мы как-то решить эту проблему? Оказывается, можем! Harald Hoyer выдвинул идею использования для этого старой доброй autofs. Системный вызов connect() показывает, что одна служба заинтересована в другой, аналогичным образом вызов open() (или подобный ему) показывает, что служба заинтересована в конкретном файле или файловой системе. Таким образом, чтобы улучшить параллелизацию запуска, можем заставить программы ждать, пока файловая система будет готова (смонтирована). Добиваемся мы этого следующим образом - мы создаем точки монтирования autofs, а затем, когда завершатся разные проверки целостности, инициализируются квоты и т.п., мы заменим ее реальной файловой системой. Когда работает autofs, попытки обращения к ней будут поставлены в очередь ядром системы и обратившийся процесс будет заблокирован (но  - только этот демон, и только эта конкретная попытка доступа). И таким образом мы сможем начинать запускать наших демонов  задолго до того, как наши файловые системы станут доступны, без каких-либо потерь файлов и с максимальной параллелизацией.
Распараллеливание заданий, связанных с файловой системой и с запуском сервисов, не имеет смысла для корневой системы, поскольку именно там хранятся бинарники всех сервисов. Однако по отношению к файловым системам, таким как, например, /home, которые обычно намного больше, а иногда даже зашифрованы, возможно даже находятся на удаленном компьютере, такой подход может серьезно оптимизировать время загрузки системы. И уж конечно стоит отметить, что такие виртуальные файловые системы, как procfs или sysfs, никогда не должны  монтироваться с помощью autofs.
Я не удивлюсь, если кто-то из читателей может посчитать, что интеграция autofs с системой инициализации ухудшит стабильность и что это решение вообще какое-то странное, страшное и уродливое. Однако, неоднократно опробовав это решение, я могу вам сказать, что оно совершенно правильное. Использование autofs позволяет, нам создать точку монтирования без необходимости обеспечить наличие самой файловой системы. На практике это влечет за собой только задержку доступа к ФС. Если приложение пытается получить доступ к файловой системе, находящейся под опекой autofs и мы очень долго не заменяем ее реальной файловой системой, оно будет находиться в состоянии interruptible sleep. Отметим также, что в любой момент, если точка монтирования так и не становится доступной к концу запуска (например, если fsck не удалось удачно проверить файловую систему), мы можем просто попросить autofs вернуть приложению код ошибки (например ENOENT). Поэтому я полагаю, что хоть на первый взгляд включение autofs в систему инициализации может показаться чересчур смелым, наш экспериментальный код показал, что эта идея работает на удивление хорошо на практике.

Сокращение количества вызываемых во время запуска системы скриптов
 
Еще один момент, который вытекает из логики загрузки MacOS: shell-скрипты - зло.
Shell-скрипты имеют свои преимущества и недостатки. Их можно быстро писать и отлаживать, но они медленно работают. Классическая логика загрузки sysvinit построена вокруг скриптов. Будь то /bin/bash или любая другая оболочка (написанная, чтобы сделать работу скриптов быстрой), в конце концов этот подход все равно упирается в медлительность работы. В моей системе скрипты, находящиеся в /etc/init.d/, вызывают grep по крайней мере 77 раз, awk - 92 раза, cut - 23 и sed - 74. Каждый раз, когда вызываются эти команды (или какие-то другие), порождаются новые процессы, производится поиск библиотек и т.д. А затем, когда запущенный процесс выполняет какую-то простейшую операцию с текстовыми строками - он завершается. Естественно, что это все работает ужасно медленно. Ни один другой язык, кроме оболочки, не работает, как описано. Кроме того, работа скриптов сильно зависит от различных переменных среды и тому подобного, причем это все трудно контролировать.
Итак, давайте избавимся от скриптов в процессе загрузки! Прежде чем мы сможем это сделать, нам нужно выяснить, как они используются сейчас: по большому счету картина такова - большую часть времени они заняты рутинными операциями. Большинство сценариев производит элементарные операции и вызов сервисов, поэтому эти операции можно переписать на С, либо отдельные исполняемые файлы, либо сами демоны, либо сделать конкретную операцию частью системы инициализации.
Маловероятно, что мы в ближайшее время полностью сможем избавиться от скриптов при старте системы. Переписывание их на C занимает много времени, в ряде случаев игра вообще не стоит свеч, а иногда, наоборот, без скриптов вообще трудно обойтись. Но мы, безусловно, можем уменьшить их влияние на процесс загрузки.
Хороший показатель для измерения количества вызова скриптов в течение запуска системы - это PID процесса, который он получает сразу после запуска системы. Загрузитесь, войдите в систему, откройте терминал и введите echo $$. Попробуйте сделать это на вашей Linux-системе, а затем сравните результат с MacOS! (Подсказка: на Linux PID будет порядка 1823; на MacOS примерный PID - 154).

Слежение за процессами


Центральная часть системы инициализации - это выполнение обязанностей няни по отношению к сервисам: она должна следить за ними. Перезапускать их, если они завершают свою работу. Если они падают, нужно собирать всю необходимую информацию о них и сохранить ее для администратора, предоставлять ее аварийным системам сбора информации (crash dump systems) и системам ведения журнала (например syslog) и/или системе аудита.
Также она должна позволять полностью завершать сервис со всеми своими потомками. Это, наверное, проще сказать, чем сделать. Традиционно в Unix процесс, который дважды вызывает fork(), может избежать контроля своего родителя, и родитель ничего не узнает об отношении нового процесса к тому, что он запустил. Например: неправильно написанный CGI скрипт, который вызван двойным fork(), не прерывает свою работы при завершении Apache. Кроме того, вы даже не сможете выяснить его отношение к Apache, если не знаете его имя и назначение.
Итак, как же мы сможем уследить за процессами, чтобы они не убежали от нашей няни, и  контролировать их как единое целое, даже если они форкаются огромное количество раз (в оригинале gazilion times :) - прим. перев.) ?
Разные люди предлагают различные решения. Скажу вкратце, что есть подходы, основанные на использовании интерфейса ptrace или netlink (интерфейс ядра, который позволяет получить сообщение netlink каждый раз, когда любой процесс в системе вызывает fork() или exit()), которые подвергались критике за топорность, неповоротливость и плохую масштабируемость.
А что же мы можем предложить? В ядре уже достаточно долго существует такая вещь, как Control Groups (aka "cgroups"). В основном они позволяют создавать иерархию групп процессов, которая непосредственно доступна через виртуальную файловую систему. Названия групп  - это обычно названия директорий в этой файловой системе. Если процесс, принадлежащий к определенной группе, вызывает fork(), его потомок становится членом той же группы. Если он не имеет привилегированного статуса, он никак не сможет этого избежать. Первоначально cgroups были добавлены в ядро для организации контейнеров: различные подсистемы ядра могут устанавливать лимиты на ресурсы (ограничение использования процессора и/или памяти) для определенных групп. Традиционные ограничения ресурсов (как реализовано setrlimit()) устанавливаются (в основном) только для каждого процесса. cgroups, с другой стороны, позволяют устанавливать ограничение на целые группы процессов. cgroups полезны также для обеспечения соблюдения ограничений в других случаях. Вы можете использовать его, например, для ограничений общего объема памяти или ресурсов процессора для Apache и всех его дочерних процессов. Поэтому неправильный CGI-скрипт не сможет сбежать от установленных ограничений ресурсов путем вызова fork().
В дополнение к своим функциям по созданию контейнеров и использованию для ограничения ресурсов cgroups являются очень полезными как средство для слежения за демонами: членство в cgroup надежно наследуется дочерними процессами и избежать этого невозможно. Существует система уведомлений, которая ставит в известность главный процесс, когда cgroup становится пустой. Вы можете найти cgroups для процесса путем чтения файла /proc/$PID/cgroup, следовательно, это очень хороший выбор средства для отслеживания процессов.

Контроль за средой исполнения процесса

Хорошая няня должна не только следить за демонами и контролировать их, но и создавать для них хорошее и безопасное окружение. Это означает, что мы не ограничиваемся очевидными параметрами, такими как настройка ограничений ресурсов для процесса посредством setrlimit(), идентификаторы пользователя и групп. Ядро Linux дает пользователям и администраторам достаточно контроля над процессами (некоторые из них в настоящее время используются редко).
Для каждого процесса нам нужно устанавливать контроль над использованием процессора, планировщика ввода-вывода, набор функциональных ограничений, привязку к процессору и, конечно же, дополнительные ограничения посредством cgroup. Самое главное здесь - это высокоуровневый контроль, такой как, например, монтирование файловой системы в режиме только чтения при вызове mount с опцией bind. Таким образом, можно запускать отдельные демоны так, что все (или некоторые) файловые системы будут ему доступны только для чтения. Это можно использовать для контроля за тем, что делают отдельные демоны, нечто вроде бюджетного варианта SELinux (хотя это, конечно, не призвано заменить SELinux).
Наконец, ведение логов является важной составной частью запуска сервисов: в идеале каждый бит информации, выдаваемый сервисом, должен записываться в журнал.  Следовательно, система инициализации должна обеспечить процесс ведения логов для демонов, с которыми она работает, подключая стандартный вывод (stdout) и вывод ошибок (stderr) к демону syslog. А иногда даже к /dev/kmsg, который во многих случаях очень полезная замена syslog (те, кто делает встроенные системы, прислушайтесь, пожалуйста, к этому!).

Upstart, внимание, марш!

Во-первых, я бы хотел подчеркнуть, что мне на самом деле нравится код Upstart, он очень хорошо комментирован и его легко изучать. Другим проектам в этом отношении еще учиться и учиться (в том числе и моим собственным). В то же время я не могу согласится с общим подходом, который реализован в Upstart. Но сначала несколько слов о проекте.
Upstart не разделяет код с sysvinit, а его функциональные возможности перекрывают возможности sysvinit, и обеспечивает совместимость с какой-то частью хорошо известных скриптов SysV. Его основная особенность - управление сервисами на основе событий: запуск и остановка процессов связаны с "событием", которое происходит в системе, где "событием" может быть все что угодно: доступность сетевых интерфейсов, запуск какого-то ПО и т.п.
Upstart обрабатывает последовательность запуска служб посредством событий: если срабатывает событие syslog-started - оно используется как индикатор для запуска D-Bus, т. к. шина теперь сможет использовать syslog. А затем, когда срабатывает событие dbus-started, запускается NetworkManager, после чего он может использовать D-Bus, и так далее.
Можно сказать, что логическое дерево зависимостей, которое существует и хорошо понимается администратором или разработчиком, транслируется в систему событий и набор правил, описывающих реакции на события: каждое логическое «для a нужно b» становится «запустить а, когда нужно b» плюс «остановить а, когда останавливается b». Это своего рода упрощение, особенно для кода самого Upstart. Тем не менее я утверждаю, что такое упрощение на самом деле вредно. Прежде всего, система логических зависимостей никуда не девается, и тот, кто пишет файлы для Upstart, теперь должен транслировать эти правила в формате «события/действия» (два правила для каждой зависимости). Таким образом, вместо того, чтобы позволить компьютеру выяснить, что нужно делать на основе зависимостей, пользователь должен вручную перевести зависимости в простое правило «событие - реакция на него». Кроме того, поскольку информация о зависимостях не может быть декодирована, она не доступна во время работы системы, фактически это означает, что у администратора, который пытается разобраться, почему что-то произошло, нет на это никаких шансов.
Кроме того, в случае Upstart логика работы с зависимостями переворачивается с ног на голову. Вместо того чтобы свести к минимуму объем работы (что является признаком и целью хорошей системы инициализации), на самом деле происходит увеличение количества работы, выполняемой во время операций. Другими словами, вместо того, чтобы имея четко поставленную цель, проделать все необходимые шаги сразу, она делает сначала один шаг, а потом делает все остальные шаги, которые к ней ведут. Или еще проще: то, что пользователь запустил D-Bus, ни в коей мере не означает, что NetworkManager должен быть также запущен (но это то, что будет делать Upstart). А должно быть с точностью до наоборот: когда пользователь обращается к NetworkManager, это признак того, что D-Bus также должна быть запущена (это, безусловно, именно то, что ожидают большинство пользователей, не так ли?). Хорошая система инициализации должна запускать только то, что нужно, и по требованию. Либо по потребности, либо максимально параллелизуя запуск. Однако она не должна запускать больше, чем необходимо, в частности не все из установленного, для чего может понадобится этот сервис
(Честно говоря, и это только мое мнение, без претензии на истинность, что тут автор пытается притянуть за уши аргументы против Upstart. Тем более, что приведенные автором примеры относительно D-Bus и NetworkManager не соответствуют реальности. Прим. перев.).
Наконец я не вижу реальной ценности от логики, основанной на событиях. Мне кажется, что большинство событий, обрабатываемых Upstart, фактически не мгновенны, а имеют некоторую продолжительность: сервис запускается, работает и останавливается. Устройство подключается, подключено и отключается. Точка монтирования находится в состоянии монтирования, полностью смонтирована, или же она размонтирована. Кабель питания подключен, система работает от сети переменного тока, кабель питания отключен. Лишь немногие из событий системы инициализации должны обрабатываться точно в срок, большая часть из них - это старт, запуск и остановка. Информации об этом также нет в Upstart.
Мне известно, что некоторые проблемы, на которые я указал выше, в некоторой степени решаются последними изменениями в конфигурационных правилах Upstart, такими как, например, start on (local-filesystems and net-device-up IFACE=lo). Тем не менее, я считаю, что это выглядит как попытка исправить систему (автор считает, что такое решение - «костыль» - прим. перев.), основной дизайн которой является некорректной.
Кроме того, Upstart вполне подходит на роль няни для демонов, хотя что-то она делает сомнительными способами (см. выше).
Есть и другие системы инициализации, кроме sysvinit, Upstart и launchd. В большинстве из них подходы намного серьезнее, чем в Upstart или sysvinit. Наиболее интересной является Solaris SMF, которая поддерживает надлежащую обработку зависимостей между службами. Тем не менее, во многих отношениях она чрезмерно усложнена и, скажем так, несколько академична, чрезмерно использует XML и новые термины для известных вещей. Она также сильно завязана на специфичных для Solaris функциями, такими как contract system.



Бесплатный вебинар по Ubuntu

Наш учебный центр (то место, где я имею честь работать) проводит 16 сентября модный ныне бесплатный веб-семинар (или как их сокращенно называют вебинар) . Вебинар будет посвящен одному из главных событий, случившихся в нашем УЦ в этом году - партнерству с хорошо известной всем компанией Canonical.

В рамках данного вебинара планируются выступления:
  • Владимира Крюкова - менеджера Canonical по контактам с OEM-партнерами в регионе EMEA;
  • Вашего покорного слуги с информацией о том, какие вообще направления обучения предлагает Canonical;
  • И в заключение Torsten Splinder (Canonical Senior System Engineer) поведает всем присутствующим об изменениях в достаточно популярном направлении Ubuntu Enterprise Cloud. Как вы, наверное, догадываетесь, Торстен не говорит по-русски, поэтому задать ему вопросы можно будет только на английском языке :). Ну или на его родном немецком ;).

Тем, кто захочет присутствовать, желательно пройти по ссылке для регистрации на вебинар. Также по ней можно ознакомится с системными требованиями. Предвосхищая вопрос, на Linux все должно работать. Я все тестировал на последней версии Adobe Flash, теперь там нет былых проблем с русским языком.

Thu, Aug 19, 2010

Важные инновации в области ПО. Часть I

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


David A. Wheeler
Первая версия от 1 августа 2001 с дополнениями от 26 мая 2009

Введение

В последнее время слишком многие путают термин «инновации в области ПО» с другими факторами, такими как увеличение скорости работы компьютеров и сетевого оборудования. В этой статье я попытался положить конец этой путанице, выявив наиболее важные нововведения в области ПО, путем отсева тех из них, которые относятся к сфере аппаратного обеспечения (hardware), и таких программных продуктов, которые не привнесли ничего нового. Также представлены критерии оценки и определение понятия наиболее важных инноваций в ПО, источники информации, что именно привнесли эти инновации, обсуждаются патенты на ПО и почему некоторые из инноваций в ПО не упомянуты в этой статье. В заключение статьи представлены выводы.
Результаты вас могут удивить.

Критерии оценки

В этой статье приводится список наиболее важных инноваций в области ПО, поэтому в первую очередь необходимо дать точное определение каждому из этих слов:
  • Чтобы удостоиться звания наиболее важной, инновация должна заключать в себе идею, которая очень широко используется и/или имеет большое значение для той области, где применяется. То, что не получило широкого распространения, не было включено в такой список.
  • Инновация в области ПО (software) — это то, что привносит технологические новшества, которые оказывают непосредственное влияние как на процесс программирования, так и на использование компьютера.  Я намеренно не упоминаю инновации в аппаратном обеспечении (innovation in hardware), которые не связаны с инновациями в области ПО. Например, согласно судебному решению, John Vincent Atanasoff является изобретателем электронной вычислительной машины, поэтому к инновациям в ПО это изобретение не относится. По той же причине я также не включил в список другие нововведения, такие как транзисторы (1947) и интегральные микросхемы (1958), а также стандарт Ethernet, разработанный Бобом Меткалфом (Bob Metcalfe) в 1973. Я пропустил изобретения, которые не являются технологическими (например, социальные или правовые нововведения), даже если они имеют важное значение для технологии программного обеспечения и/или широко распространены. Например, концепция copyleft - это инновационный подход к лицензированию программного обеспечения, который разрешает модификацию ПО с невозможностью затем сделать его опять проприетарным. Она используется широким спектром ПО, благодаря General Public License (GPL). Первая такая лицензия (Emacs Public License) была разработана Ричардом Столлманом в 1985 году - но, поскольку copyleft это все-таки инновация в социальной и правовой сфере (а не в сфере технологий), она не включена в этот список. Кроме того, также сюда не включено изобретение смайлика ":-)". Безусловно, он широко используется повсюду, однако его существование не критично для компьютерной сферы и больше относится к социальной сфере.
  • Также тщательно нам необходимо определить само понятие инновация. Инновация - это не просто объединение двух функций в одном продукте (это интеграция, а не инновация, и требует для своей реализации только значительного объема работы). В частности, интеграция множества функций в один продукт для предотвращения использования клиентами конкурирующих продуктов - это хищничество, а не инновация. Инновация это НЕ конечный продукт, хотя, конечно же, этот продукт может содержать или воплощать какую-то революционную идею. Новая реализация существующего продукта для того, чтобы он делал то же самое, но на другом компьютере или операционной системе, также НЕ является новшеством. Инновация это новая идея. И применительно к данному документу это означает новую идею в области ПО.
В результате вы удивитесь тому количеству событий в компьютерной истории, которые НЕ входят в этот список. Большинство программных продуктов - это не инновации в ПО, поскольку они просто повторяют реализации других идей. Например, WordStar стал первым текстовым процессором для персональных компьютеров, но он не был первым - WordStar всего лишь новая реализация уже существовавшего продукта для других компьютеров. Более поздние текстовые процессоры (такие как Word или Word Perfect) также представляли собой следующие реализации аналогичных продуктов, а не инновации. Ряд значительных событий в компьютерной индустрии - это просто презентация новых продуктов или оборудования и не имеет никакого отношения к инновациям. Хотя появление IBM PC и Apple было важно для компьютерного мира, оно не представляло никаких инноваций в области ПО - это просто было очередное снижение стоимости компьютеров, с некоторым количеством ПО, написанным специально для них с использованием уже хорошо известных в то время технологий.
Иногда продукт является первой реализацией какой-либо инновации (например первая программа работы с электронными таблицами), в этом случае дата релиза продукта является датой публичного объявления какой-то идеи. Некоторые инновации порождают технологии, которые хотя и не являются явными для пользователей программного обеспечения, но они оказывают чрезвычайно важное влияние на разработку ПО (например, подпрограммы и объектно-ориентированное программирование), и тогда они включены в приведенный ниже список. В спорных случаях я привожу свои комментарии, поясняющие, почему тот или иной пункт присутствует в данном списке.
Я пытался определить дату и первую публичную презентацию идей, а не их воплощение в некоторые продукты. По возможности я пытался разделить даты первого внедрения и широкого признания инновации. "Публичность" в данном случае означает, по крайней мере, объявление для широкой аудитории. В некоторых случаях определить конкретную дату или событие трудно, и я буду рад, если кто-то укажет мне на более ранние работы. К примеру, иногда бывает трудно установить первую презентацию, поскольку с каждой последующей реализацией идея постепенно меняет форму.

Источники информации

Поскольку я не нашел никакого общепризнанного единого мнения о том, какие инновации наиболее важные, я составил данный список, проанализировав несколько источников. Я старался использовать много источников, чтобы не пропустить ничего важного. В частности, информацию об истории компьютеров IEEE (за последние 50 лет), виртуальный музей вычислительной техники, интернет-историю Гоббса, «A History of Modern Computing» Paul E. Ceruzzi и «A Brief History of the Future» John Naughton. Для описания некоторых инноваций я также использовал «Inventing the Internet» Janet Abbate, тщательно перепроверяя данные из этого источника, т.к. к сожалению Abbate иногда ошибается, что делает его использование в качестве авторитетного источника затруднительным. Например, Abbate (стр. 22) не понимает, что хотя Strachey и John McCarthy для описания своих идей использовали один и тот же термин ("timesharing" - разделение времени, см.ниже) - он обозначает разные понятия. Я также проверил ряд других источников, таких как «History-Making Components» James Durham  и «A History and Future of Computing». Стоит также отметить, что большинство источников смешивают события из области ПО аппаратного обеспечения. Другим источником является конференция “Software Pioneers” (28-29 июня 2001 года, Бонн). Также было проверено множество специализированных источников, таких как “OSI and TCP: A History” by Peter H. Salus.
Со времени первой публикации этого документа я получил ряд дополнительных сведений, которые вошли в данную статью. Я благодарю тех, кто предоставил мне эту информацию. В то же время, вполне возможно, что в ней обделены вниманием некоторые важные инновации. Поэтому, если у вас есть замечания или дополнения, пожалуйста, свяжитесь со мной (dwheeler at dwheeler.com).

Наиболее важные инновации в области ПО: 

Часть 1 (1837-1960) 

Часть 2 (1960-1970) 

Часть 3 (1970-1980) 

Часть 4 (1980-2004)

 

Патенты на ПО

Какие инновации в ПО не самые главные?

Выводы

Приложение: Инновации в ПО, которые стоит принять во внимание




Оригинальный текст: Copyright © David A. Wheeler
Перевод: Copyright © Чернышов Антон, УЦ R-Style