8 февраля

Что творится... Corel начал какое-то яростное наступление на Linux. Мало того, что появился и активно продвигается Corel Linux - объявлено о слиянии Corel и Inprise/Borland!

Результирующая компания будет называться Corel, а Borland будет полностью ей принадлежать, хотя и сохранит в рамках компании определённую самостоятельность.

Главное, впрочем, даже не это. Главное, что слияние объявлено стратегическим ходом, направленым на занятие более существенных позиций в отношении софта для Linux. Результирующая компания, как и Микрософт, будет иметь в числе продуктов операционную систему, средства разработки для неё, и продукты для конечного пользователя.

Это вызвало вопросы - будет ли компания по-прежнему выпускать продукты под чужую операционную систему, то есть Windows. Ответ положительный - никто рынок Windows бросать не намерен. Да и с чего бы вдруг успешные компании стали выкидывать в окно свои продукты с криком "никому их не продадим"...

Движение Colrel-а в сторону Linux расценивается аналитиками как, может быть, не восхитительный, но вполне удачный ход. Действительно, Микрософт вряд ли позволит себе наступить на горло собственным окнам и выпустить продукт под Linux. А продажи Linux-а, однако, вполне существенны - даже у такого молодого игрока на этом рынке, как Corel Linux. Значит - грех не воспользоваться случаем, грех не выйти на рынок, где нет и не будет главного конкурента. Одно плохо - рынок этот невелик.

Но он растёт, и, думается, именно на это делает ставку Corel. Более того, никто не уходит с рынка Windows - продукты Borland-а выпускаются под несколько платформ, а значит - яйца не лежат в одной корзине. Да и Corel Draw забывать не следует.

Вырастет ли Linux настолько, чтобы отъесть у Windows хоть 30% рынка? Никто не знает. Никто не говорит "да", но никто и "нет" не говорит. Никто не смеётся. Все внимательно следят за Corel-ом. Ситуация ясна до боли в глазах: если Corel выиграет - он выиграет много. Стать первым царём горы на новой платформе - сладкая доля. Но страшно - аж жуть.

Рыночный потенциал Линукса, впрочем, оценивается аналитиками исходя из текущей ситуации: для этой ОС нет офисного софта, а значит всё, на что она годна - это бродить по WWW. Corel же намеревается не просто выйти на рынок, но изменить его своим выходом, расширить. К апрелю (интересно, к моему дню рождения успеют?:) предполагается выпустить комплект приложений для Linux, которые в сочетании с собственной версией этой ОС станут "рынкообразующей" силой и, одновременно, силой рынкозанимающей.

Ждём весны, будем посмотреть. Но вообще-то я рад этому событию. Кто-то же должен был рискнуть, ход ведь просто напрашивался.

Местное следствие: Московское представительство Inprise теперь будет представлять Corel. Вот ведь людям выдалось - без перехода из компании в компанию сотрудники представительства поработали и в Borland, и в Inprise, и в Corel. :-)

Такая вот открытость.

From: ilya@xosoft.com Subject: Обидно, да? Здравствуйте, Дмитрий, Почитал я Ваш выпуск от 4 февраля и стало мне на душе муторно. Правду-истину Вы пишете, но не легче мне от этого. Судите сами: человек я до мозга костей UNIX'ный, профессионально пишу под ним уже лет 8. Как и положено истинному юниксоиду, презирал я все исходящее от мелко-мягких и считал (от снобизма или от наивности), что нет OS кроме UNIX, и Sun - пророк его. Но не далее как пару месяцев назад начал я заниматься разработкой некоторой файловой системы специального назначения. И вот тут-то и выяснился забавный парадокс: слухи об открытости описаний UNIX'а (а конкретно, Solaris'a) оказались сильно преувеличены. Традицинно же закрытая от посторонних глаз Windows NT оказалась на поверку куда более описанной и открытой. Проще говоря, на сегодня НЕ СУЩЕСТВУЕТ внятного описания Solaris Internals. Вся информация о ядре ограничивается книгой John R. Graham "Solaris 2.X : Internals and Architecture" образца 1995 года, да и та практически недоступна - весь тираж распродан, а допечаток нет и не предвидится. Кроме того, имеются разрозненные намеки в документации (в разделах "Writing Device Drivers", "STREAMS programming" и некоторых других). Заявленная на ноябрь 1999 года книга Jim Mauro, Richard McDougall "Solaris Internals: Architecture and Techniques Volume I: Core Kernel Components" так и не вышла. Правда, Sun обещает поставлять исходники 8 версии (с мая месяца), но информация-то мне нужна сегодня! С другой стороны, по Windows NT Internals имеется около десятка книг с примерами, а кроме того проводятся курсы и семинары. Вот такая вот странность. Я предвижу Ваши замечания о том, что информация о внутренностях OS не является предметом массового спроса - согласен. Но, с другой стороны, то, за что всю дорогу кроют Microsoft, вполне процветает и в коммерческом UNIX'е - не стоит забывать, что Solaris - наиболее открытая его версия. Про внутреннее устройство AIX, True 64 и HP-UX открытой информации еще меньше... Так что приходится мне задержать выпуск версии на Solaris'е до лета - т.е. до получения информации, а вот версия на NT, похоже, выйдет в апреле. Кто от этого выиграл? Уж наверно не Sun... -- Ilya Usvyatsky XO Soft Ltd. Senior 1 Corazin str. Software Engineer Givataim, Israel ilya@xosoft.com +972-3-5710037

Наверное. :-( Что уж и говорить - успехи Микрософта столь велики отнюдь не только потому, что им монополизирован рынок десктопных ОС. Во всяком случае, успехи на ниве систем серверного и enterprise класса. Для меня Юникс вообще перестал существовать как открытая платформа с того дня, как исчезло распространение этой системы с исходными текстами, как было со дня её создания и до момента полной коммерциализации. В шутке "Unix is a registered bell of an AT&T trademark labs" (это перефразировка задолбавшей всех "Unix is a registered trademark of an AT&T Bell Labs") есть, конечно, доля шутки, но... AT&T сумела добиться того, что исходные тексты систем стали недоступны. Оказалось (да и неудивительно), что во всех практически Юниксах есть принадлежащий AT&T код, а это давало ей право диктовать условия.

Короче говоря, я снова стал воспринимать Unix как систему только с появлением 386BSD (позже её переименовали в FreeBSD). Бесплатной и в исходниках. Это было, когда не было Linux-а, а всё что было - было коммерческим, душным и в буквальном смысле безысходным. :-)

Впрочем, не совсем так плохо - были системы, до исходников которых существовал способ добраться. Но это - через тернии... на кой такие звёзды, спрашивается.

Тошнотворные классы наносят ответный удар. :-)

From: Маркозов Дмитрий Николаевич Subject: Дерево классов, от которого тошнит. Здравствуйте, dz. "Тёзка, когда Вы говорите о том, что Вас тошнит от дерева классов, что именно Вы имеете в виду?" Конечно, я не знаю, от чего именно тошнит нашего общего тезку, но решил написать, так как меня тоже иногда... Слегка тошнит. Тошнит от того, что единственным способом выделить общие свойства у классов является порождение их от одного базового класса. Механизм, конечно, хороший и, конечно, достаточно общий, но сплошь и рядом абсолютно невыразительный. Елки-палки, я хочу упорядочивать объекты класса, для которого определены операции "больше" и "равно", а не те, у которых базовым классом является "класс_объекты_которого_можно_упорядочить". С++ не дает нормального механизма для этого. Механизм шаблонов тяжело считать нормальным. То есть он вполне выразительный, просто нужна хорошая его реализация. Та, которая не требовала бы доступа к исходному тексту, не плодила бы копии кода и одинаково понималась бы разными компиляторами. Беда не в том, что 70% времени приходится на проектирование. Беда в том, что проектирование сводится к попыткам предугадать, какие именно общие свойства классов будут использоваться и выделению для них базовых классов. Ну в самом деле, как выглядит процесс проектирования? Сначала рисуется дерево классов, которое как-то отражает взаимоотношения в моделируемом мире. Это делается легко и полученный результат понятен. Потом сверху, сбоку и внутрь внедряется немножко классов, которые служат исключительно для того, чтобы выделить общий код. Вернее, выделить места, где код, предположительно, будет общий. Затем добавляется еще немножко классов, для того, чтобы объединить классы, которые будут использоваться одинаковым образом. Потом часть классов, размножается делением на классы интерфейсов и реализации, поскольку модель классов в С++ не является объектной моделью (что бы там не говорили). Потом выясняется, что какой-то базовый класс должен иметь две разных реализации и начинается кровавый кошмар. Кровавый, потому что к тому времени получившаяся конструкция никому не понятна. Дима, это не имеет никакого отношения к классификации!!! Это просто использование механизма, предназначенного для классификации, абсолютно не по назначению. Потому что другого нет. Кстати, нетрудно заметить, что библиотеки при этом используются неОО. Я, честно говоря, вообще плохо представляю себе использование ОО библиотек (хотя бы двух) в одном проекте. Пытаюсь представить - и не могу. С уважением, Дмитрий Маркозов. PS. Да, а журнал у Вас замечательный! Читаю с огромным удовольствием. Спасибо!

Спасибо за письмо.

Во-первых, о темплейтах. Категорически согласен - механизм безобразный, причём как с точки зрения применения, так и реализации - одна из тех редких вещей, в которых плохо всё. Я бы вообще не оставил ему места в нашем счастливом будущем :-) - мне не нравится и синтаксис тоже.

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

Я вот чего не понимаю. Есть ведь множественное наследование, и, вообще говоря, свойство можно "замешать" в класс с помощью этого механизма уже после того, как всё спроектировано. Это раз. Два - мы что, говорим о случае, когда код выбивается кувалдой и зубилом на скале? Открыл исходник базового класса, и добавил в него функциональности.

Может статься, что иерархия изначально порождена неверно и границы классов не соответствуют границам свойств. Это, мне кажется, единственный момент, требующий переработки кода по локоть в крови. Только при чём тут ОО? Такое раздолбайство можно натворить на чём угодно, и ведь творят - только отвернись.

И, собственно, какую мысль мы доказываем? Что Си++ неидеален? Безусловно. Что на Си это будет сделать легче? Ни в жизнь. Что можно бы придумать ОО язык и поприличнее? А мы этим и занимаемся. :-)