понедельник, 21 сентября 2009 г.

Самая большая в мире open-source компания? Google

World's biggest open-source company? Google
by Matt Asay

Как правило, лидером индустрии программного обеспечения с открытым исходным кодом признается Red Hat, но такое утверждение некорректно и не имеет под собой основы. Оно, как правило, основывается на измерении доходов Red Hat, которые прямо зависят от открытого ПО, его разработки и распространения, в то время как другие компании, такие как Sun, IBM и Google на самом деле пишут и предоставляют не в пример больше открытого кода. Пришло время прекратить говорить о компаниях, строящих свой бизнес на открытых технологиях, и вернуться назад к важности самого кода.

Открытое ПО все больше и больше становится неотъемлемой частью инфраструктуры, от которой зависят поставщики программного обеспечения и компании, строящие свой бизнес в Web. Во вторник MySpace стала предметом обсуждения сообщества, после того как она открыла исходный код Qizmt - фреймворка распределенных вычислений (вопреки всему работающий на Windows Server), который на данный момент обеспечивает работоспособность функции MySpace "People you may know". Но MySpace, как заметил VentureBeat, просто последовала примеру Facebook, которая недавно открыла Tornado.

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


Наряду с этим это путь для улучшения качества программного обеспечения. Беря открытые проекты как фундамент для инфраструктуры, компании затем осознают все преимущества данной модели ведения разработки и распространяют ее на свое ПО. Качество же открытого кода, которое пишется в условиях сотрудничества, внушает уважение и одновременно с этим непрерывно растет, как говорится в сообщении Accenture Kit Plummer.

Теперь после освещения вопросов личного интереса и качества ПО, ясно, почему открытый код стал основой инфраструктуры, фактически, для всего коммерческого ПО, и почему Red Hat и другие игроки рынка истинного открытого кода больше не являются центром вселенной открытого ПО.

Исходный код ядра Linux включает в себя 11.5 миллионов строк кода, из которых приблизительно 12% код Red Hat (тут подразумевается весь код, в котором было принято участие). Даже если мы добавим сюда JBoss Application Server (еще около 2 миллионов строк кода или около того) и другие проекты Red Hat, то мы увидим, что Red Hat предоставил сообществу намного меньше открытого кода, чем другие.

Возьмем, к примеру, Sun. Это ведущий разработчик, стоящий за Java (более чем 6.5 миллионов строк кода), Solaris (свыше 2 миллионов строк кода), OpenOffice (приблизительно 10 миллионов строк кода) и другими проектами с открытым исходным кодом.

Или IBM с 12.5 миллионов строк кода, которые она внесла в Eclipse, не упоминая уже Linux (6.3% от общего количества строк кода), Geronimo, и другие самые разнообразные проекты с открытым кодом.

Как бы то ни было, Google - это самая интересная компания из всех, так как она, по сути, не software компания. Я спросил Крис Ди Бона, менеджера по стратегии развития открытого ПО и связям с сообществом компании Google, о вкладе компании в открытый исходный код. Он ответил:
"Мы внесли приблизительно около 14 миллионов строк кода. Код системы Android занимает здесь свыше 10 миллионов строк кода, Chrome - 2 миллиона строк кода, GWT - 300000 строк кода, наряду с этим есть код ряда других проектов, выпускаемых каждую неделю на протяжении последних пяти лет. Также мы должны упомянуть несколько тысяч патчей, которые предоставляются нашими сотрудниками в течение каждых месяцев и недель".

В то время как Ди Бона намекнул о том, что Google не претендует на корону самого выдающегося поставщика открытого кода ("Мы предпочитаем говорить, что мы среди числа самых активных контрибьюторов"), это почти точно, что Google - самый активный контрибьютор открытого кода, особенно, когда рассматриваются ее другие open source активы. Сюда стоит включить хостинг наверно самого большого в мире репозитария проектов с открытым кодом, сейчас там представлено более 250000 различных проектов, не менее в 40000 из которых было принято активное участие, не упоминая уже инициативу Summer of Code. Тем не менее, понятно, число строк кода - это не обязательно самый весомый показатель значения участия в разработке открытого кода.

Патрик Финч из Mozilla Foundation предполагает, что Google, как самый активный поставщик открытого кода, может вообще не быть связан с написанием нового кода:
"Самое значимый результат участия Google в разработке открытого кода - это вероятно не сам код, но демонстрация того, что теперь вы можете использовать Linux на своем компьютере".

Это основная мысль делает акцент на отличии open source компании от каких-либо других. Google не называет себя open source компанией, и это действительно правильно. Открытый код - это просто часть ее стратегии в распространении ПО, которое помогает продавать больше рекламы.

Sun попыталась переквалифицироваться в open source компанию, но Oracle предотвратила это своей недавней сделкой. Oracle, конечно, не даст себе такое звание, не потому что это плохо, но потому что это просто не имеет выгоды.

Теперь мы все в том или ином понимании open source компании, что также одновременно означает, что никто из нас таковыми не являются. Открытый код - это просто путь, который дает некоторые новые возможности в ведении бизнеса, и без разницы, кто будет использовать их Red Hat ли, Microsoft ли, Google или Facebook.

Рассматривая утверждение, данное выше, только относительно Web компаний, таких как Google, видно, что необходимость в коммерционализации открытого кода просто отпадает. Действительно, мы можем видеть, как много открытого кода отдано такими Web компаниями, которые мы не называем и не думаю, что назовем в будущем традиционными "компаниями-разработчиками открытого кода", например как Red Hat, MySQL или Pentaho.

Мэт Асей - вице-президент направления бизнес разработки Alfresco
Читать дальше...

пятница, 11 сентября 2009 г.

Проблемы с распространением программ в системе Linux и пути их решения

Уже много людей из сообщества говорили о том, что текущее положение дел с установкой программ в системе Linux необходимо менять. Кто-то же говорил обратное, что все хорошо и ничего менять не надо. Действительно, на данный момент времени с распространением программ и их обновлением все замечательно, но до тех пор, пока у вас есть постоянная и стабильная связь с интернетом. В случае же, когда доступ к сети либо отсутствует, либо сильно ограничен, необходимо прилагать достаточно серьезные усилия в установке программ, которые для подготовленного человека не вызывают особых затруднений, но для новичка это может стать препятствием на пути полноценного использования операционной системы. И не надо говорить, что интернет настолько дешев, что он есть практически везде, это большое заблуждение. Конечно, как решение можно предложить использовать срезы репозитариев дистрибутивов на DVD-дисках. Но появление новых программ и исправление ошибок в старых происходят каждый день, поэтому такие срезы я не считаю панацеей, но только лишь обезболивающим, которое теряет свои целебные свойства месяц за месяцем.

Существует большое количество разновидностей пакетных менеджеров, и каждый из них решает свои задачи очень хорошо. Но в каждом отсутствует возможность формирования метапакетов (ранее я уже рассказывал об этой идее здесь), которые очень просто можно развернуть на другой системе с той же самой версией дистрибутива. Что же такое метапакет? В данном контексте под метапакетом я буду подразумевать следующее. Как известно, в массовых дистрибутивах, таких как Ubuntu, Fedora, OpenSuSE, ключевые библиотеки: графические тулкиты, системные библиотеки, – кардинально меняются лишь от версии к версии (мягко обойдем стороной рабочие станции техноманьяков). Что и понятно, разработчики дистрибутивов стремятся поддерживать стабильным программный интерфейс, так как разработчики программ доверяют им и точно знают, что после очередного обновления пакетов текущей версии дистрибутива, их программа будет работать без проблем. То есть, во всех стабильных и популярных дистрибутивах есть некий фундамент, состоящие из различных библиотек, которые предоставляют один и тот же API на каждой из установленных машин. Теперь задача установки одной программы, скажем на десяти машинах с однотипными дистрибутивами, никак не связанных между собой и не имеющих доступ в сеть, может быть решена распространением среди пользователей этих машин метапакетов, которые включают в себя пакеты программы и пакеты с необходимыми зависимостями, а также некие сценарии установки, которые решают задачи такого рода, как порядок установки пакетов, разрешение циклических зависимостей и т.п. То есть, когда пакетный менеджер устанавливает программу из такого пакета, он не скачивает из сети пакеты, от которых зависит программа, а при необходимости берет их из этого же самого метапакета, при этом пользователь избавляется от рутины и ненужных действий: не надо думать о том, в каком порядке и как надо установить эту кучу пакетов, чтобы приложение заработало. Таким образом, эта система метапакетов может быть интегрирована в архитектуру пакетных менеджеров, сохраняя преимущества и принципы пакетной дистрибьюции программ.

На сегодня существуют другие пути решения проблемы, например, недавно я публиковал новость о системе распространения программ с помощью Application Bundle, но это не выход из сложившейся ситуации. Связано это с тем, что она стоит особняком от зарекомендовавшей архитектуры пакетной дистрибьюции. То что подобные системы используют статическую линковку всех используемых библиотек, то есть все библиотеки, которые используется программой, скомпилированы непосредственно в исполняемый файл, это тоже минус. Статическая линковка – это лишняя избыточность, которая приводит к нерациональному использованию оперативной памяти и пространства на жестком диске.

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


Автор: Александр Мышов (Google+)
Читать дальше...

четверг, 10 сентября 2009 г.

Проброс портов (Port Forwarding) в Virtualbox с помощью VboxManage

Введение

Virtualbox - это бесплатная, мощная и гибкая программа виртуализации, которая доступна для операционных систем Linux, Mac OS X, Windows, она может создавать виртуальные машины для множества различных операционных систем. VirtualBox был изначально разработан Innotek, но затем был куплен Sun и переименован в Sun xVM VirtualBox. Есть несколько версий программы: свободная и бесплатная с закрытым исходным кодом, я использую бесплатную несвободную версию, потому что она предоставляет больше функций, чем VirtualBox OSE.

Для гостевых ОС VirtualBox доступно несколько сетевых механизмов, чтобы подключится к сети Интернет, но я буду ссылаться здесь только на NAT (Network Address Translation).

В руководстве VirtualBox есть описание преимуществ и недостатков механизма NAT:

"Network Address Translation (NAT) - это самый простой путь дать доступ в интернет виртуальной машине, он не требует каких-либо конфигураций сети хоста и гостевой системы. По этой причине NAT в VitualBox является сетеовй моделью по умолчанию.

Виртуальная машина с NAT подобно тому, как реальный компьютер соединяется с сетью через маршрутизатор. "Маршрутизатор" в этом случае это сетевой движок VirtualBox, который передает трафик из и в виртуальную машину прозрачно. Недостаток NAT в том, что точно так же как и с использованием частных сетей за маршрутизатором, виртуальная машина невидима и недоступна из интернет, поэтому вам нельзя полноценно использовать различные сервер и сервисы, пока вы не настроите проброс портов (описано ниже)."


Таким образом вы очень просто можете дать доступ к сети вашей виртуальной машине, но она будет невидима для других устройств в вашей сети. Это небольшая проблема, но до тех пор, пока вы не захотите запустить ssh сервер на виртуальной машин или организовать доступ к другим сервисам машины (таким как вебсервер) без конфигурации проброса портов.

Проброс портов в VirtualBox

Проброс портов может быть осуществлен с помощью мощной и гибкой утилиты командной строки VBoxManage. У VBoxManage есть множество опций, но мы для настройки будем использовать только setextradata.

Команды, которые будут описаны далее, позволят вам осуществить доступ к виртуальной машине через ssh. Прежде чем вы возьмемся за дело, я представлю несколько утверждений о гостевой системе:
  • Ваша виртуальная машина не запущена, но уже была создана и сохранена
  • На ваша гостевой операционной системе установлен и корректно сконфигурирован ssh сервер
  • Ваша гостевая система была настроена со стандартным виртуальным сетевым оборудованием (PCNET III)
  • Sshd принимает входящие подключения на стандартном порту (порт 22)
  • Ваша гостевая ОС названа "VM Name Here", хотя могу поспорить, что у вас она называется по-другому.

Если Вы не знаете имя своей виртуальной машины самый легкий путь узнать имя -запустить VirtualBox и просмотреть имена машин перечисленных в главном окне. Промотав экран вниз к детальной информации вы сможете увидеть другую информацию, например какой виртуальный сетевой адаптер используется.

Следующие команды позволят перенаправить трафик, который идет с порта 2222 вашей основной системы на порт 22 гостевой ОС:

$ VBoxManage setextradata "VM Name Here" \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP

$ VBoxManage setextradata "VM Name Here" \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22

$ VBoxManage setextradata "VM Name Here" \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222


Обратите внимание на двойные кавычки в имени виртуальной машины. Если вы назвали виртуальную машину одним словом, например, "VMNameHere", то вы можете двойные кавычки опустить:

$ VBoxManage setextradata VMNameHere \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP

$ VBoxManage setextradata VMNameHere \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22

$ VBoxManage setextradata VMNameHere \
"VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222


Но нет вреда и в том, если кавычки останутся здесь: поступайте так как вам нравится.

Есть также некоторые ограничения проброса портов через NAT, я перечислю их здесь, эту информацию также можно найти в руководстве по VirtualBox:
"Есть четыре ограничения использования NAT, с которыми пользователь должен быть знаком:
  1. Ограничения протокола ICMP.
  2. Получение широковещательных пакетов UDP не надежно
  3. Такие протколы как GRE не поддерживаются
  4. Проброс для портов, номер которых ниже 1024 невозможен"
Эти ограничения обычно не сказываются на стандартном использовании сети. Но существуют нюансы использования NAT с протоколами, которые VirtualBox хорошо поддерживает. К примеру, часто сервер может быть сконфигурирован так, что он не позволяет принимать запросы с непривилегированных портов (с номерами, которые ниже 1024).

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

Росс Ларсон

оригинал статьи (англ.)
Читать дальше...