Сколько платят молодым ит-специалистам

• Х выплат на строительство (приобретение) жилья гражданам, проживающим в сельской местности, 833.17kb.
• Словарь-справочник, 262.79kb.
• Программа дисциплины "информатика" Для направления, 92.88kb.
• Сочинение. Суровая правда войны, 73.1kb.
• Задачи : Изучение нормативных документов. Помощь молодым специалистам в подготовке, 1271.11kb.
• Доклад Финансирование школы осуществляется из нескольких бюджетов, 29.53kb.
• Гильдия рекламистов при Торгово-промышленной палате, 261.32kb.
• А. С. Обручников 10 мая 2011г. Положение, 125.09kb.
• Анализ работы методиста по биологии Клименко Е. А. в 2008-2009 учебном год, 331.14kb.
• I международная заочная научно-практическая конференция "Маркетинг, реклама и pr как, 50.74kb.

Подглядывая за будущим Илья Щуров Voyager Опубликовано 17 августа 2006 года Конференция разработчиков свободного программного обеспечения "На Протве" проходит уже в третий раз. Два года назад я про нее не знал, год назад не смог приехать, а этим летом звезды наконец "выстроились в ряд", и я все-таки выбрался на три дня в Обнинск, дабы вдоволь пообщаться с представителями российского open source-сообщества. За недостатком места и обилием обсуждаемых тем (тезисы докладов можно найти ссылка скрыта, а вот тут выложены ссылка скрыта) мне придется закончить на этом лирическое вступление и перейти к делу. Точнее, к бизнесу. Бизнес Неоднократно отмечалось, что разработка свободного ПО и научные исследования - вещи очень близкие, порой переходящие друг в друга. В обоих случаях результатом инвестиций и трудовой деятельности является не товар, легко обмениваемый обратно на деньги в рамках классической марксистской формулы, а знания, требующие иных бизнес-моделей и методов зарабатывания на жизнь. Впрочем, проникновение свободного софта из академической в бизнес-среду дает о себе знать, и риторические вопросы на тему "где бы найти финансирование для open source?" на конференции раздавались редко. Программисты, участвующие в разработке открытых продуктов, находят работу в самых разных ИТ-компаниях, так или иначе использующих ресурс свободного ПО - а таковых становится все больше и больше. О своем видении взаимодействия открытой и проприетарной моделей разработки и ведения дел рассказал Александр Давыдов из Naumen. Эта компания как раз находится "меж двух миров": занимается разработкой проприетарных решений, но на основе открытых продуктов и технологий. В данный момент она постепенно открывает часть своих собственных наработок - в основном для усиления мотивации сотрудников-программистов. По мнению Давыдова, свободное ПО сейчас становится основной универсальной платформой для интеграции программ, вытесняя проприетарный софт на "периферию". Еще один интересный доклад "про бизнес" сделал Георгий Курячий (ALT Linux), рассказавший о том, как обычно происходит миграция ИТ-инфраструктуры компаний с пиратского софта - и как она должна происходить при правильной организации. Зачастую, столкнувшись с претензиями правообладателей по поводу использования нелицензионного ПО, руководство компании решает срочно перевести весь свой компьютерный парк на open source. Сносится Windows, ставится Linux… и корпоративная жизнь замирает на несколько недель. Бизнес-процессы рушатся, сотрудники жалуются на непривычные программы и отказываются работать в таких ужасных условиях, а сисадмины днюют и ночуют в офисе, безуспешно пытаясь исправить ситуацию. Итог, как можно догадаться, плачевен. Но дело здесь, конечно, не в Linux и не в свободном софте, а в неграмотной миграции. Задача эта нетривиальна, и решаться она должна по всем правилам внедренческой науки: с обязательным исследованием сформировавшихся в компании бизнес-процессов и шаблонов поведения пользователей, составлением проектного и технического заданий, постепенным внедрением нового ПО, написанием соответствующей документации и т. д. При этом полный переход на свободный софт не всегда оправдан: во многих случаях лучше все же купить лицензии на какие-то программы, которые сейчас невозможно заменить. (К слову, отсутствие Linux-версии не является непреодолимым препятствием: написанные в соответствии со стандартом Windows API программы, как правило, работают под Wine, а многие специфические для российского рынка продукты (скажем, разработки компании "1С") - под модифицированной версией Wine@Etersoft.) Власть От бизнеса перейдем к другой насущной проблеме: не всегда простым отношениям технологий с государством. Наш постоянный автор Федор Зуев поделился своим анализом черновика лицензии GPLv3 на предмет его совместимости с российским законодательством об авторском праве. Будучи плодом ума американских граждан, лицензия не всегда учитывает специфические тонкости европейского гражданского права, а тем более – российских законов. Например, в нашей стране авторский договор, по которому передаются имущественные авторские права, должен содержать ряд "существенных условий" (в частности, о размере авторского вознаграждения, территории, сроке действия и т. д.). В лицензии сейчас прямо упомянуты не все из них. Вторая черновая версия, опубликованная уже по завершении конференции, смягчает некоторые несовместимости, но не снимает их полностью. С другой стороны, по словам Зуева, они не являются столь критичными, чтобы использование GPLv3 в России стало действительно опасным. К тому же рассматриваемый текст все-таки не окончателен, и в данный момент ведется работа над поправками, которые, в случае их принятия, смогут устранить большинство нестыковок. Впрочем, грозящие нам изменения в самом российском законодательстве об авторском праве (пресловутая "Четвертая часть Гражданского кодекса") могут породить гораздо более серьезные проблемы - так что следите за новостями. Еще одна область, где технологии сталкиваются с государством: использование криптографии. Необходимую в ряде случаев сертификацию могут получить только разработки, реализующие национальные криптографические стандарты, - в частности, речь идет о признаваемой государством цифровой подписи и защищенных каналах связи. Естественно, в существующих свободных программах они пока не реализованы, но ситуация здесь уже сдвинулась с мертвой точки: Виктор Вагнер ("Криптоком") рассказал об опыте встраивания российской криптографии в библиотеку OpenSSL. Задача оказалась непростой: несмотря на наличие механизма подгружаемых к OpenSSL модулей (engines) и стандартного API, призванного сделать взаимодействие с библиотекой не зависящим от реализованного метода шифрования, многие программы используют недокументированные функции, привязанные к конкретному алгоритму RSA. Таким образом, изменения приходится вносить не только в саму библиотеку, но и в сторонние программы, ее использующие. Однако ничего невозможного в этом нет, и хочется верить, что в скором времени пользователи Linux и FreeBSD смогут взять на вооружение признаваемые государством криптографические средства. Последняя тема, которую мне хотелось бы затронуть в этом разделе, посвящена регулированию информационных технологий, применяемых в самом государственном управлении. Этот вопрос, не относящийся к теме конференции напрямую, был вынесен на отдельный семинар, и сейчас я коснусь его очень кратко. Необходимость формулирования специальных требований к технологиям, применяемым в госсекторе (и покупаемым или разрабатываемым за государственный счет), уже более или менее очевидна. Например, использование закрытых и недокументированных форматов данных может привести к зависимости от конкретного поставщика не только какое-то отдельное ведомство, но и целые сегменты общества - недавняя история с введением ЕГАИС в очередной раз подтвердила этот тезис. О мерах, предпринимаемых на этом фронте в рамках программы "Электронная Россия", мы надеемся рассказать в одном из следующих номеров. Технологии Вернемся к основной теме конференции: свободному софту и связанным с ним технологиям. Среди последних особенно выделялись два не очень новых, но ставших весьма модными именно сейчас слова: вики и виртуализация. Первому из них было посвящено сразу несколько докладов. Александр Сигачев, активный участник сообщества русскоязычной Википедии, рассказал о текущих достижениях и проблемах проекта. Надо отметить, что свободная энциклопедия уникальна не только своими "внешними" характеристиками (такими, как количество статей и скорость реакции на появление новых тем), но и внутренним устройством. Тогда как в большинстве сетевых проектов царит что-то вроде просвещенного (в лучшем случае) абсолютизма, региональные вики-сообщества (в том числе и русскоязычное) развиваются по принципам самоуправления и в чем-то напоминают настоящие свободные государства: со своими законами-правилами, полицией-администраторами и даже судебными органами. Впрочем, социальный феномен Википедии еще ждет своих исследователей, а на конференции больше внимания уделялось технической стороне - в частности, использованию вики-движков в целях, далеких от написания энциклопедии. Несмотря на достаточно широкие возможности и легкость освоения, у вики имеются и определенные недостатки. Например, различные движки используют несовместимые друг с другом и к тому же никак не формализованные языки разметки, что значительно усложняет автоматизированную обработку документов (скажем, перевод с одного "диалекта" на другой). Тем не менее, по словам исследовавшего этот вопрос Кирилла Маслинского (ALT Linux), и здесь все не так плохо: попытки выработки единого формата вики-разметки уже начались. Второе модное слово - "виртуализация" (то есть возможность запуска нескольких "виртуальных компьютеров" на одном реальном) - в последнее время все чаще звучит из уст как разработчиков процессоров, так и специалистов по операционным системам. Практические возможности эта технология предоставляет немалые: тут и изоляция разных приложений с целью увеличения общей безопасности системы, и очевидные удобства для разработчиков и тестировщиков ПО, и многие другие "вкусности". Существует несколько подходов к виртуализации - как полная эмуляция железа программными средствами, позволяющая "обманывать" любую операционную систему, так и паравиртуализация, для которой необходимо вносить изменения в код "гостевых" ОС. Участники проекта OpenVZ рассказали еще об одном подходе, называемом "виртуализацией на уровне ядра". Идея состоит в том, что запускается одно (модифицированное) ядро операционной системы, которое изолирует наборы программ друг от друга и распределяет между ними ресурсы. Таким образом можно, например, одновременно запустить несколько разных дистрибутивов Linux на одном компьютере, но нельзя запустить Linux и Windows. Зато производительность системы будет заведомо выше, чем при полной эмуляции. Как и многие другие сюжеты в этом кратком обзоре, рассказ о виртуализации хочется закончить словами: "и вот, уже совсем скоро…" Подобная незавершенность естественна: большинство решений, о которых шла речь на конференции, пока не доведены до массового использования. И именно этим, на мой взгляд, интересен открытый процесс разработки: наблюдая за такими проектами, можно заглянуть в будущее и почувствовать живое дыхание прогресса. Из журнала "Компьютерра" Виртуализация сегодня: задачи, проблемы, технологии, решения ссылка скрыта > ссылка скрыта > ссылка скрыта 18 августа, 2006 АЛЕКСАНДР ТОРМАСОВ, АНДРЕЙ НИКОЛАЕВ В последнее время мы наблюдаем живой интерес участников рынка к виртуализационным технологиям. Недавнее объявление о том, что аппаратная поддержка виртуализации в ближайшем будущем станет ключевым направлением деятельности таких компаний, как Intel и AMD, заставляет обратить пристальное внимание на актуальные задачи, существующие наработки и реализованные решения в этой области. Уже сейчас без преувеличения можно сказать, что шаг в “виртуализацию” будет как минимум настолько же значимым и всеобъемлющим, как и шаг, сделанный в конце 80-х — начале 90-х, когда в архитектуре x86 появился защищенный режим исполнения приложений. Возможно, последствия здесь будут столь же далеко идущими, как и после появления персональных компьютеров, существенно изменивших практически всю отрасль. Задачи и проблемы виртуализационного ПО Виртуализационным ПО (ВПО) мы будем называть программный комплекс, обеспечивающий запуск и функционирование модифицированной или не модифицированной гостевой операционной системы на физическом компьютере таким образом, что она не “замечает” наличие ВПО, напрямую или опосредованно пользуется устройствами компьютера, может быть остановлена и сохранена в любой момент цикла своей работы, а потом перезапущена с этого момента и способна как к клонированию на этом же компьютере, так и к переносу на другой ПК, обладающий тем же комплексом ВПО. Практически ВПО так или иначе инкапсулирует ОС в некоем своем “виртуальном мире”, представляющем собой объект, с которым оперирует ВПО и который далее мы будем называть его виртуальной машиной (ВМ). На первый взгляд это кажется чем-то искусственным, фантастическим и далеким от реальных приложений. Однако если вспомнить о существовании целого ряда уже апробированных технологий, порой никак не связанных с виртуализацией, таких как гибернирование (hibernation), программы-эмуляторы и интерпретаторы бинарного кода на процессорах с другими системами команд, кроссплатформенные средства разработки и отладки ПО или виртуальная Java-машина, то становится понятно, что виртуализационные технологии появились не вдруг и не сразу, а прошли долгий, подчас мучительный путь становления и уже имеют весьма богатую историю. Сегодня мы просто подошли к этапу, на котором виртуализация из отдельной технологии для каких-то частных конкретных целей превращается в повсеместную и вездесущую деталь компьютерных систем**. Оказавшись перед таким серьезным порогом, стоит задуматься над перспективами и понять, что принесет нам этот переход, какие выгоды можно получить от него, а чего лучше попытаться избежать. Выигрыш может быть очень существенным, ведь использование операций клонирования, переноса, резервного копирования и восстановления гостевой ОС (вместе с запущенными в ней приложениями) по сути приведет к манипуляциям с файлами, содержащими образы ВМ в нужном состоянии. Естественно, что при таком упрощении важных и трудоемких задач значительно уменьшится самая большая статья расходов современных ИТ-подразделений — стоимость управления информационной инфраструктурой. В то же время даже незначительная подвижка в стандартах ВПО и поддерживающей их аппаратуры, не обеспечивающая обратной совместимости или совместимости различных брендов, может обернуться существенными затратами в случае, например, перехода от одного стандарта к другому при унификации систем двух ранее независимых организаций или при внедрении следующего поколения ВПО. С другой стороны, стоимость одновременного применения нескольких современных стандартов в корпоративных центрах данных может быть снижена за счет аппаратной поддержки виртуализации (об этом см. ниже). Виртуализация в архитектуре Intel x86 Технически реализация ВПО в архитектурах семейства x86 — весьма непростая задача, так как при изначальном проектировании Intel не предусматривала подобных режимов работы. Например, часть команд, которые могут выполнять обычные универсальные ОС, не должны быть разрешены к исполнению внутри ВМ. Самым простым способом решения этой проблемы была бы возможность получать так называемые прерывания или исключения при попытке выполнения этих команд в ВМ с тем, чтобы обрабатывать их внутри ВПО. Но проблема заключается в том, что простого способа вызвать это исключение для некоторого класса команд нет. Они отработают внутри ВПО, дав при этом не тот результат, которого ожидали разработчики, не предвидевшие, что ОС может оказаться “в гостях”. Причем иногда выполнение подобной небезопасной команды может вызвать сбой в основной ОС или даже зависание всей компьютерной системы. Например, в архитектуре Intel Pentium имеется 26 таких инструкций, и перед их выполнением в коде ядра ОС необходимо либо принять специальные меры, обеспечивающие безопасность операции с точки зрения связки “гостевая система — основная система”, либо вообще заблокировать их исполнение. В любом случае все эти меры приведут к значительным накладным расходам по производительности, если сравнивать гостевую ОС, запущенную под ВПО, и установленную как обычно. Для решения данных проблем разработчики эмуляторов обычно применяют разные подходы — от простой пошаговой эмуляции каждой инструкции, выполняемой ВПО для кода ВМ, до сложной оптимизации, в частности бинарной трансляции исполняемого кода перед его реальным исполнением. Другим вариантом решения задачи “неконтролируемых” инструкций является модификация кода ядра для гостевых ОС, которая применяется в ряде решений, объединяемых термином “паравиртуализация”. В этом случае вместо прямого исполнения “плохих” команд ядро гостевой системы для выполнения соответствующих операций вызывает некоторые функции основной системы (прямо или опосредованно), т. е. в момент инсталляции оно просто не содержит “плохих” команд. Однако и в случае создания полной ВМ, и в случае “паравиртуализации” необходимо средство для контроля за “виртуальными мирами” гостевых ОС. Такое средство в различной литературе называется гипервизором или монитором виртуальных машин (МВМ, или, в английской терминологии, Virtual Machine Monitor). Сейчас разные варианты названия стали применять для несколько различающихся модификаций управления. Так, МВМ обычно существует “параллельно” с основной ОС, имеет практически одинаковые с ней полномочия и не обладает специальными планировщиками процессора и другими ресурсами. А у гипервизора чаще есть выделенные только для него возможности по контролю оборудования и распределению некоторых ресурсов, и даже основная система осуществляет свои функции посредством использования ресурсов гипервизора, а не прямым обращением к аппаратуре (хотя и здесь могут быть свои исключения). Основные игроки рынка микропроцессоров — компании Intel и AMD — уже объявили о создании аппаратной поддержки для решения типовых задач МВМ, которая со временем войдет практически во все новые серии процессоров — как для серверов, так и для рабочих станций и ноутбуков. Главной целью введения аппаратной поддержки является облегчение создания новых версий ВПО и уменьшение накладных расходов при применении технологий виртуализации. Решение от Intel: Vitrualization Technology — Vanderpool В 2004 г. на осеннем форуме Intel для разработчиков (Intel Developer Forum) была анонсирована Virtualization Technology (VT), известная ранее под кодовым названием Vanderool. В апреле 2005-го появились ее общедоступные спецификации для архитектуры IA-32 (см, например,ссылка скрыта). Суть VT-решения заключается во введении нового режима функционирования процессора — VMX, предназначенного для поддержки виртуализации. В этом режиме команды процессора могут работать в двух новых режимах (рис. 1): VMX-root (обычный режим) и VMX-nonroot (режим исполнения виртуальной машины). По сути, эти режимы изменяют поведение некоторых команд. Переключения от VMX-root к VMX-nonroot называются входами в режим исполнения виртуальной машины (VM-entry), а обратные переключения — выходами из режима исполнения виртуальной машины (VM-exit). Сами переключения в терминологии Intel называются VMX-переходами (VMX-transition). Рис. 1. VMX-режим позволяет исполнять код как VMX-root т как VMX-nonroot (Ring — уровень привилегий) Поведение процессора в режиме VMX-root почти такое же, как и вовне режима VMX, за исключением случаев, когда имеется дополнительный набор VMX-команд или ограничения на значения, загружаемые в некоторые управляющие регистры (CR0, CR4). Поведение процессора для режима VMX-nonroot изменено таким образом, чтобы осуществить работу ВПО. Вместо того чтобы исполняться, некоторые инструкции (включая новую инструкцию вызова МВМ — VMCALL, которая уменьшает накладные расходы таких обращений), попав в CPU и пытаясь быть исполненными в режиме VMX-nonroot, будут приводить к исключению — выходу из режима исполнения ВМ и передаче управления МВМ. Эти переходы остаются невидимыми для гостевого VMX-nonroot-кода, существенно ограничивая его прямой доступ к физическому оборудованию и позволяя МВМ полностью контролировать ресурсы компьютера. Теоретически для режима VMX-nonroot нет никаких прямых возможностей определить, что логический процессор работает с ним в одном режиме. Это позволяет предотвратить распознавание кодом внутри ВМ наличия гостевой ОС и ее ПО. Хотя на практике косвенные пути для определения этого факта скорее всего будут найдены. Поскольку VMX-режим для VMX-nonroot-кода вносит ограничения даже для нулевого уровня привилегий (ядро ОС), гостевая ОС и ее ПО без каких-либо модификаций могут функционировать в ВМ именно так, как рассчитывали разработчики при ее проектировании. Жизненный цикл МВМ выглядит следующим образом (рис. 2). Программа командой VMXON переводит процессор в VMX-режим. Теперь МВМ может передавать управление только из гостевых ОС в каждый момент времени с помощью команд VMLAUNCH и VMRESUME (входы в ВМ). Обратно он получает управление при выходе из ВМ — в этом случае управление будет передано на заранее установленную точку в коде МВМ. Затем МВМ определяет причину выхода из ВМ, производит соответствующие действия и может снова передать управление гостевой ОС через входы в ВМ. В какой-то момент времени МВМ может решить покинуть режим VMX, для чего реализуется команда VMXOFF, глобально отключающая поддержку выполнения виртуальных машин. Рис. 2. Жизненный цикл монитора BM