Не будем наивными: OS/2 с открытым кодом мы никогда не увидим. Тем же, кто очень хочет сегодня познакомиться с ней, можно разве что посоветовать eComStation 2.0 RC4 компании Serenity System, которая ближе всего напоминает старую добрую OS/2. А вот одна из лучших функций этой ОС под названием SOM (System Object Model — модель системных объектов) пользователям Linux вполне доступна.
Хорошо осведомленные разработчики рассказали мне, что IBM все еще держит в своих запасниках исходный текст SOM, права на который полностью принадлежат ей. А вот об OS/2 в целом этого не скажешь, поскольку солидная ее часть находится во владении Microsoft. Так что о раскрытии кодов OS/2 можно и не мечтать.
Естественно, многие могут спросить: “Что это за SOM такая?”. Отвечу. Это — совместно используемая объектно-ориентированная библиотека на базе CORBA. Но такое определение, пожалуй, поймут только программисты, остальные же лишь недоуменно пожмут плечами. Для них объясню проще: эта универсальная и простая в использовании библиотека программирования позволяет разработчикам DKE и GNOME создавать программы, пригодные для любой среды настольных систем Linux.
Лучшей демонстрацией возможностей SOM может служить Workplace Shell, интерфейс настольных систем OS/2. Здесь наглядно проявляется главное достоинство SOM — предельная простота заказной настройки настольной системы и ее приложений. С помощью этой технологии ничего не стоит облечь любое приложение в формы KDE, GNOME или какой-нибудь другой внешней программы для настольных систем. Разработчику не нужно колдовать со множеством интерфейсов прикладного программирования (API). Чтобы перенести приложение, скажем, с Ubuntu GNOME на OpenSUSE KDE, ему достаточно с помощью одного-единственного WinReplaceObjectClass API сменить класс KDE на класс GNOME.
Такой способ намного облегчает создание приложений по принципу, действующему в мире Java: “Один раз написал — и пользуйся где угодно”. Вот только Java-аплеты требуют еще и установки интерпретатора Java (что, в общем-то, и задерживает их широкое распространение), тогда как приложения и настольные среды на базе SOM этого тормоза лишены.
С технической точки зрения работа в средах GNOME и KDE обеспечивается за счет связок gtk и qt с одной общей библиотекой. Другими словами, сегодняшним разработчикам приложений для настольных систем даже не придется изучать никаких новых методов привязки программ к этой новой среде. Для эффективного использования SOM вполне достаточно знания объектно-ориентированного программирования. Но даже если его придется осваивать, это будет куда проще, чем обращаться к нынешним способам переноса приложений из одной среды настольной системы в другую.
Но SOM хороша не только этим — ее можно успешно использовать и с другими языками программирования. Любой язык с поддержкой этой технологии — будь то Java, PHP, Python, Ruby или какой другой — вполне сможет побороться с Mono и Microsoft .Net не только за Linux-платформы, но и за саму Windows.
Еще одно достоинство подзабытой технологии тесно связано с тем, что объектно-ориентированное программирование обеспечивает стабильность и гибкость даже начальной версии приложений. Самыми яркими примерами тому могут служить сегодня приложения Cocoa и Carbon из разработанной Apple операционной системы Mac OS. Какое из них лучше, — спор об этом может растянуться до бесконечности (ветераны старой школы Unix и Linux, скажем, до сих пор ломают копья, сравнивая vi с EMACS), но одно совершенно ясно. Оба эти приложения Mac OS очень стабильны и всегда работают одинаково.
Что же касается Linux, то даже несмотря на применение объектно-ориентированных языков наподобие С++ здесь до сих пор нет универсальной объектно-ориентированной библиотеки. А ведь с помощью SOM эта ОС не только избежала бы грядущих ссор по поводу своих Carbon и Cocoa, но и — не побоюсь сказать — стала был лучшей средой программирования для настольных систем.
Следующий плюс SOM связан с тем, что IBM создавала эту модель для работы с любой архитектурой от мэйнфреймов до ПК. К тому же она уже перенесена в AIX — реализацию Unix в исполнении IBM. Если сопоставить эти факты, становится ясно, что перенос SOM в Linux никакого труда не составляет.
Но если всё так великолепно, то почему же, спрашивается, Linux не обзавелась собственной объектно-ориентированной системой? Что ж, попробую ответить и на этот вопрос. Такие попытки предпринимались, и самая известная из них — Bonobo для GNOME. Но дело не очень-то пошло. И вовсе не потому, что идея была неверна. Здесь-то как раз все наоборот, ведь Bonobo, как и SOM, создавалась на базе CORBA. А вот подготовка объектно-ориентированной инфраструктуры оказалась делом невероятно долгим и трудным. Библиотеками пользоваться легко, когда под рукой уже имеется нужная инфраструктура, однако стоимость ее разработки способна похоронить даже самую хорошую идею. Но с SOM подобной проблемы не возникает, поскольку такая работа уже выполнена.
Чтобы вписаться в Linux, конечно, SOM должна иметь открытый код, но с этим особых сложностей не предвидится. В конце концов IBM этой своей разработкой давным-давно не пользуется. А если она только собирает виртуальную пыль, то почему бы владельцу не открыть ее код? Более того, корпорации даже не придется возиться с публикацией или чисткой инструментария разработки, поскольку для Linux таких средств — хоть пруд пруди. Так что IBM будет достаточно открыть код SOM и, может быть, подготовить несколько демонстрационных программок для него.
Будет ли результат похож на OS/2? Ни в коем случае! Но зато разработчики Linux получат отличную объектно-ориентированную инфраструктуру, способную сделать настольный вариант этой ОС гораздо более привлекательным для независимых поставщиков ПО. В результате должна появиться масса новых приложений, которые, в свою очередь, стимулируют интерес пользователей настольных систем к Linux.
Да, и еще одно. Ничего не стоит превратить SOM в сетевую DSOM распределенного типа, а это значит, что корпоративные пользователи смогут легко и просто интегрировать настольные системы Linux (в первую очередь — компьютеры под управлением AIX и z/OS) с межплатформным ПО IBM для запуска не серверах IBM. Нужно ли что-то еще добавлять к этому?
