Unix и Windows -- cиамские близнецы

2 февраль, 2004 - 00:00Андрей Зубинский
Если уж говорить о "неправильностях" в распространенных системах, то, вероятнее всего, сегодня слишком поздно начинать разговор о несовершенствах реализаций их "деталей". Поздно потому, что даже несовершенные системы в настоящее время "обросли" столь мощным слоем самого ценного -- прикладного ПО, что нужно быть уж совсем ярым фанатиком какой-либо "светлой идеи", чтобы допустить хотя бы в мыслях "развитие" системного программного обеспечения по принципу "до основанья, а затем..." только ради исправления "деталей". Именно поэтому под "неправильностями" разумнее понимать сложившееся или в силу обстоятельств, или в силу каких-либо стратегических принципов очевидное положение вещей. Очевидное для многих, например для Линуса Торвальдса, четко определившего в беседе с журналисткой Кейт Макензи (интервью журналу Australian IT, 16 января 2004 г.) сроки готовности самой популярной наследницы неувядающей ОС Unix -- Linux -- к "массовому" применению (Торвальдс выразился даже жестче -- до момента, когда "нормальные пользователи" обратят внимание на Linux как на "настольную" систему). По его мнению, от пяти до десяти лет отделяют современную Linux от вехи, исключительно важной в судьбе претендующего на массовое применение продукта любой технологии. Фактически же -- от сегодняшнего состояния другой, действительно самой массовой системы -- естественно, Microsoft Windows. И такое очевидное положение вещей является вполне очевидной "неправильностью" практически всех наследниц Unix (Mac OS X, несмотря на рекламные ухищрения, все-таки настолько радикально отличается от оригинальных Unix-систем, что ее просто не будем учитывать). Равно как и очевидной "неправильностью" можно было назвать крайне слабую (или вообще -- отсутствующую) способность самой массовой Windows без дорогостоящих "довесков", например, вести себя как подобает приличной операционной системе в разнородном окружении. К очевидным "неправильностям" Windows отнесем и справедливо критиковавшуюся скудость инструментальных средств в базовой поставке, впрочем, слово "скудость" здесь не совсем уместно -- по сравнению с любым клоном той же ОС Unix в базовой поставке Windows инструментов почти нет (речь идет именно об инструментальных средствах, а не о пользовательских приложениях). Вот и получается, что подобные "неправильности", что бы и как бы яростно ни утверждали приверженцы двух платформ, мешают в любом "мире" -- в мире Unix-подобных ОС нет ни требуемой от пользовательской среды "дружественной когерентности", ни такого обилия прикладных пользовательских программ (тем более такого класса), как в мире Windows, в последнем же нет такого обилия одновременно почти элементарно простых, доступных и надежных инструментальных средств, объединенных элегантной концепцией.

Unix и Windows -- cиамские близнецы
В мире Windows запущен Acrobat -- еще до момента запуска консоли SFU. В мире Unix PID этого процесса -- 1340
Естественно, всему вышесказанному можно возразить, ведь давно существуют разнообразные программные средства, позволяющие эти "неправильности" устранить. В Unix-подобных системах возможно исполнять Windows-приложения с помощью программных эмуляторов различного уровня, в Windows -- использовать "Unix-удовольствия" благодаря аналогичным решениям. Оно, конечно, все так... Но вот сами программы-эмуляторы слишком далеки от даже не совершенства, а "удобоваримости". Они или ненадежны (увы, увы... "эмулирующие надстройки" -- это более "инструменты приключений", чем пригодные к ежедневному интенсивному применению изделия), или очень ресурсоемки (бесспорный недостаток "эмуляторов архитектур", программно имитирующих чуть ли не все, начиная с центрального процессора), но не это главное. Главное то, что они "чужеродны". Это свойство проявляется в слабости интеграции исполняемых эмулятором программ с "окружающей эмулятор средой" и массой вытекающих отсюда ограничений.

Последний контраргумент, с которым можно и нужно согласиться, -- факт существования полноценных "систем в системах", пусть даже слишком дорогих и специфичных. Но сегодня соглашаться с ним все-таки нужно с одной оговоркой -- вторую часть контраргумента пора оставить в прошлом. Потому как после практически одновременных радикальных изменений в версии 3.5 и приобретения статуса freeware "система в системе" Microsoft Windows Services for Unix, по-своему уникальная (причем не только с технической точки зрения... много вы видели продуктов компании Microsoft, получивших награду выставки LinuxWorld Expo, причем не просто награду, а оценку "лучший в классе приложений"?) и, без сомнения, красивая разработка, стала доступна всем желающим.


"Об'Unix'сим Windows"

Unix и Windows -- cиамские близнецы
Отправляем сигнал -9 из одного мира в другой -- и процесс завершен...
Итак, мы будем говорить о SFU 3.5 (Microsoft Windows Services for Unix) -- легально бесплатном продукте, который можно загрузить с сайта корпорации Microsoft; тех, кто использует dial-up-соединения, сразу следует предупредить -- размер дистрибутива SFU составляет, ни много ни мало, почти 230 MB (автор надеется, что в результате дальнейшей беседы этот размер не покажется таким уж страшным).

Давайте сразу отметем попытки возможных сравнений с, так сказать, "аналогами", на самом деле аналогичными только в части высокоуровневой функциональности. SFU, в отличие от хорошо известных "имитаторов" типа Cygwin и U/WIN, не является программой пользовательского уровня (иначе говоря -- надстройкой над доступным пользовательским программам API Windows). Это нечто совершенно иное. Собственно "иности" SFU и обязан своим появлением этот краткий обзор.

Если использовать грубую аналогию, то ближайший аналог SFU -- упомянутая выше Mac OS X. И действительно, одновременно настолько далекая в архитектуре и реализации пользовательского уровня от канонической Unix Mac OS X весьма схожа именно с SFU. В обеих системах хорошо просматривается концепция "микроядра" (кавычки здесь потому, что на самом деле "микроядра" обеих систем астрономически далеки от канонического понятия микроядра), в них присутствует заимствованное из мира BSD Unix "пользовательское пространство" (user-space), и наконец, в них не обошлось как без сугубо коммерческого ПО, так и без его главного "врага" -- ПО с лицензией GNU. Впрочем, судите сами: Mac OS X, по сути, -- заимствованная из FreeBSD надстройка (одновременно системного уровня и user-space) над "микроядром" Mach (кто пытался "побродить" по исходным текстам этого самого "микро-", поймет значение кавычек), SFU также является системной и user-space-надстройкой непосредственно над ядром основанных на архитектуре Windows NT ОС. Причем если попробовать заглянуть в бинарный код практически любой утилиты SFU, в нем можно обнаружить весьма примечательные строчки: "The Regents of the University of California. All rights reserved. Copyright (c)..." -- хотя это излишнее подтверждение не скрываемого производителем факта: user-space-утилиты действительно происходят из кода BSD-систем (согласно слухам, конкретный источник -- система OpenBSD, известная щепетильностью своих разработчиков в вопросах контроля качества кода). От GNU обе системы заимствовали, естественно, то, чем проект GNU знаменит, -- средства разработки (поборники "чистоты" соблюдения лицензий, можете не волноваться -- все, что взято из проекта GNU, в SFU представлено как в пригодном к исполнению бинарном виде, так и на уровне исходных текстов, причем начиная с процедуры инсталляции вам будут об этом напоминать регулярно). "Коммерческая составляющая" SFU -- доработанные командой Unix-специалистов Microsoft коды компании Interix. Обе системы абсолютно "естественны" в своем окружении, но здесь SFU вырывается далеко вперед -- если Mac OS X, собственно, и есть "окружение" для самой себя, то SFU существует в действительно чужеродной среде. При этом, опять же, использованное выражение "существует" настолько далеко от истины, насколько возможно. Подводя итоги этого краткого знакомства с методом аналогии, заметим, что SFU является совершенно полноценной POSIX-совместимой операционной системой, способной "на равных" сосуществовать с "законной владелицей" компьютера -- ОС Windows.

О полноценности SFU свидетельствуют хотя бы весьма "нескромный" размер дистрибутива и следующие данные: в состав SFU входит все необходимое для практически идеального соответствия стандартам IEEE 1003.2-1992 (более 350 классических Unix-утилит) и IEEE 1003.1-1990 (почти 2 тысячи программных интерфейсов, включающих как стандартную библиотеку языка С, так и клиентские части системы X Window для максимальной совместимости сразу двух версий, а также стандартную библиотеку графических примитивов пользовательских интерфейсов Motif), комплект сетевых сервисов Unix с расширенной функциональностью, исчерпывающая документация в форматах двух "миров" -- традиционные man-страницы и иерархически организованное руководство по всем аспектам использования SFU в формате chm. В базовой поставке SFU включает в себя средства разработки (как собственный С-транслятор, так и привычный по клоновым бесплатным системам GNU-комплект из компилятора GCC версии 3.3 и отладчика GDB), но при инсталляции системы с настройками по умолчанию средства разработки не устанавливаются (так как инсталляционная программа SFU -- совершенно обычная для мира Windows, достаточно в ней выбрать способ установки "Custom" и сформировать собственную конфигурацию SFU).

Теперь настало время поговорить о главном отличительном свойстве SFU -- ее интеграции с ОС Windows. Сразу после установки системы проявления этого свойства буквально поражают, даже в мелочах. Например, классическая Unix-утилита ps с опцией --a показывает действительно все процессы в системе, назначая им PID (идентификатор процесса), с которым можно обращаться именно так, как вы это привыкли делать в ОС Unix. Например -- послать Unix-сигнал Windows-процессу, запущенному в Windows-среде, естественно, не имеющей и отдаленного представления о сигналах ОС Unix. И все сработает именно так, как ожидается в полноценной ОС Unix... Можно запускать из Windows-среды Unix-процессы и сервисы, можно поступать наоборот. Но это все, как говорится, "цветочки". "Ягодки" начинаются с тонкостей интеграции системных функций и сетевых сервисов. Так, с версии 3.5 (доступной на сегодняшний день) в системе тщательно и удачно "пролечена" идеология отображения файловых систем Windows на, скажем так, представление о них ОС Unix. Выражается это, например, в новом представлении путей -- теперь Windows-файл My_data.xls, расположенный на диске D: в каталоге \User_Files\, доступен в Unix-подсистеме по полному пути и имени так: /dev/fs/D/User_Files/My_data.xls (наконец-то можно забыть о "ни рыба, ни мясо" представлении путей в Cygwin), что для имеющего опыт работы в Unix пользователя говорит само за себя. Также разработчики SFU потрудились над тщательным и однозначным отображением прав доступа к каталогам и файлам обеих систем (в подробности вдаваться не будем, -- детальные описания этого момента есть в отличной сопутствующей продукту документации, стоит только отметить, что подобная задача более чем далека от тривиальности). Кроме интеграции уровня представления файловых систем, в SFU, например, реализованы механизмы однозначного отображения имен пользователей (что означает -- для работы в двух системах фактически достаточно войти только в одну из них) и автоматического согласования паролей Windows<->Unix (изменение одного пароля ведет к прозрачному изменению другого). Шлюзование разделяемых системой NFS (Network File System) каталогов и файлов с соответственно разделяемыми Windows обеспечивает их единое представление для пользователя. При этом NFS-подсистема существенно модифицирована по сравнению с предыдущей версией SFU, к слову, и без того бывшей одной из лучших реализаций NFS для ОС Windows. Стандартная для Unix система удаленного сетевого конфигурирования NIS (Network Information Service) теперь может прозрачно управляться контроллером домена Active Directory. Административные средства SFU, естественно, интегрированы в единую консоль управления Windows (MMC, Management Console Center), что не исключает возможности решения административных задач традиционным для Unix способом. Но особенности сетевой интеграции, разумеется, более интересны системным администраторам, чем конечным пользователям SFU. Зато возможность трансформации Unix-утилит командной строки в COM-компоненты Windows (!) с последующим использованием их в обычных Windows-приложениях, без сомнения, заинтересует многих. Причем, что самое интересное, в гибридном "POSIX-Windows COM" приложении бинарные Unix-утилиты никоим образом не "трансформируются", не модифицируются, не перекомпилируются и исполняются в родной для них Unix-среде. Созданные же в Windows-мире примитивные "интегрирующие облатки" в виде динамически загружаемых библиотек отвечают за отображение стандартных потоков ввода/вывода из POSIX-мира на COM-интерфейсы.

Короче говоря, если прибегнуть к немного нечестному журналистскому приему и добавить эмоций, то сказать, во что превращается после установки SFU 3.5 Windows-машина через несколько дней усиленного изучения и эксплуатации подсистемы, трудно -- это не похоже ни на что, с чем прежде доводилось иметь дело. Недельный опыт эксплуатации выявил, что портирование Unix-программ в SFU-среду -- занятие совершенно тривиальное (тем более детально и тщательно документированное, так что за вечер скомпилировать и собрать такого монстра, как OpenMotif, вполне реально), и никакой разницы между получившимися "гибридами" и их транслированными, например, на машине под управлением FreeBSD 5.2 бинарными аналогами, не существует (разве что SFU-код одних и тех же программ, без сомнения, выигрывает у Linux- и *BSD-кода работой с файловой системой NTFS). Поставляемые с системой командные интерпретаторы -- стандартные в "мире BSD" cshell и в "мире Sys V" Korn Shell -- ведут себя именно так, как они должны себя вести, редактор vi делает именно то, что ему предписано -- и так до тонких нюансов и деталей. Благодаря введенной в версии 3.5 поддержке POSIX "нитей" (pthreads) и глубинным модификациям стандартной С-библиотеки, обеспечивающим полную безопасность использования С-вызовов в "нитевидных" программах, устранен главный недостаток предшественницы системы, и она фактически стала полноценным заменителем рабочей станции Unix для разработчиков POSIX-совместимого ПО. Причем threads-модификации, естественно, затронули не только пользовательский уровень SFU, но и глубинные системные компоненты -- по заверениям разработчиков, в новой версии существенно улучшена поддержка многопроцессорных архитектур и обеспечивается 30%-ный прирост производительности потоковых Unix-программ на системах с числом процессоров до восьми ("подлавливать" команду разработчиков на справедливости этого утверждения автор не собирался, и потому никаких "многопроцессорных тестирований" не производилось).

Осталось, в принципе, сказать о совсем немногом. Точнее, попытаться придумать ответы на последний очевидный вопрос: кому в наших реалиях и зачем может понадобиться SFU? К слову, вопрос далеко не простой... Первая потенциальная категория желающих полноценно "об'Unix'сить Windows" очевидна и крайне немногочисленна -- это привыкшие к ряду возможностей ОС Unix пользователи, не закрывающие глаза на упомянутые в начале статьи "неправильности" обоих систем. Вторая категория, несомненно, программисты, разрабатывающие как Windows-, так и POSIX-программы. И наконец, естественно, корпоративные пользователи масштабных гетерогенных систем, не желающие или не имеющие возможности идти по пути "дорогостоящего стремления к гомогенности". Система потенциально весьма интересна для применения в образовательных целях -- например, в вузах (здесь, конечно, необходимо детально просчитать финансовые стороны длительной эксплуатации, например, конкурирующей ОС Lindows и комбинации Windows + SFU, но по крайней мере по критерию богатства предложенного качественного прикладного ПО второй вариант безоговорочно выигрывает).