gatoazul (gatoazul) wrote,
gatoazul
gatoazul

Category:

Почему я ненавижу "Майкрософт"

Почему я ненавижу "Майкрософт"
Глава 2

2. Не очень хорошее, плохое и ужасное


2. Не очень хорошее, плохое и ужасное

...

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

Все разработчики ПО – люди, и они время от времени делают ошибки. Но из всех фирм, торгующих программами, у «Майкрософт» самая худшая репутация, когда речь заходит о качестве продуктов в целом.

«Майкрософт» хвастается довольно широким набором продуктов, но на деле их намного меньше, чем кажется. «Майкрософт» всегда продавала и продает снова и снова практически те же самые программы, только в разных пестрых новых обертках.

Продукты от «Майкрософт» можно разделить на три категории: приложения, операционные системы и дополнительные серверные продукты. К приложениям относятся набор MS Office, Internet Explorer, Media Player, Visio, Frontpage и т. д. Операционные системы включают настольные и серверные версии Windows. На настольных системах мы можем увидеть Windows 9x/ME, NT Workstation, Windows 2000 и Windows XP, а на серверных – NT Server и разновидности Windows 2000 типа Windows 2000 Datacenter. Дополнительные серверные продукты, например Internet Information Server (IIS) и SQL Server работают поверх серверных продуктов линии Windows. Они добавляют дополнительные услуги (например, сервер Интернета или функции сервера базы данных) к базовым услугам разделения файлов, печати и аутентификации, которые предоставляются серверными платформами Windows.

Windows для настольных систем поставляется в двух разновидностях: линия продуктов Windows 9x/ME и линия Windows NT/2000/XP. Различные версии в рамках одной линии сделаны так, что выглядят немного по-разному, но различия существуют только в деталях; программы в сущности одни и те же. Windows 95, 98 и ME происходят от ДОС и Windows 3.x и содержат значительные куски старого унаследованного 16-битового кода. Эти версии Windows основываются на ДОС, но к ним добавлены 32-битовые расширения. Управление процессами и ресурсами, защита памяти и безопасность добавлены в последний момент и в лучшем случае рудиментарны. Линия продуктов Windows совершенно не подходит для приложений, в которых важны безопасность и надежность. Системы совершенно небезопасны, например могут спрашивать пароль, но пускать и без него. Пользователю или приложениям нельзя запретить получить доступ и, возможно, испортить всю систему (включая файловую систему), и каждый пользователь может изменить конфигурацию системы по ошибке или намеренно. Линия Windows 9x/ME нацелена главным образом на потребительский рынок (хотя маркетинг Windows 95 принимал во внимание и корпоративных пользователей).

Вторая линия продуктов включает Windows NT, 2000 и XP, а также серверные продукты. Это семейство Windows лучше, чем линия 9x/ME; по крайней мере эти версии используют новый (то есть написанный после ДОС) 32-битовый код. Защита памяти, управление ресурсами и безопасности немного серьезней, чем в Windows 9x/ME, есть даже какая-то поддержка ограничений на доступ и безопасной файловой системы. Это не означает, что это семейство Windows настолько безопасно и надежно, как рассказывают редмондские маркетологи, но по сравнению с Windows 9x/ME их дополнительные свойства хороши уже тем, что они есть. Но даже эта линия Windows содержит определенное количество старого 16-разрядного кода, а вся 16-разрядная подсистема прямо взята из тех дней, когда «Майкрософт» вместе с IBM писали OS/2. Короче, все 16-битовые приложения работают в одной 16-битовой подсистеме (как было в OS/2). Внутренней защиты памяти нет, поэтому одно 16-разрядное приложение может подвесить все остальные и всю 16-битовую подсистему. Это может создать неустранимую блокировку с подвисшего 16-битового кода на 32-битовые ресурсы и постепенно заставить остановиться всю систему. К счастью, теперь это уже не такая серьезная проблема, поскольку 16-битовые приложения полностью вымерли.

Конечно, за эти годы над Windows немало работали. Но на деле было улучшено лишь очень немногое. Новые свойства в новых версиях Windows демонстрируют один и тот же подход из недоделок и заплаток. При устранении каждой проблемы добавляется по меньшей мере еще одна другая (а часто и не одна).

Windows XP, например, поставляется нагруженной большим количеством приложений и свойств, чем любая другая версия. Хотя на первый взгляд это может показаться удобным, добавленные свойства далеко не так хороши, как те, что обеспечиваются внешними программами. Например, XP настаивает на поддержке DSL («широкополосного интернета»), сканнеров и другой периферии с помощью встроенного кода «Майкрософт». Для вас это заканчивается сетью DSL с неправильными настройками (и никакого удобного способа их поменять), поддержкой сканера, которая не дает использовать возможности копирования документов или интерфейсом к цифровой камере, который разрешает скачивать фотографии с камеры, но не дает использовать ее видеофункции. К тому же, приложения (напр., Internet Explorer и Outlook) интегрированы в систему еще сильнее, чем раньше, а другие бывшие отдельными продукты поставляются вместе с операционной системой.

Все версии Windows страдают от некоторых одних и тех же дефектов в структуре. Процедуры установки приложений, ошибки пользователей и сбившиеся программы могут легко разрушить операционную систему так, что ее невозможно будет восстановить, поддержка сети реализована плохо, неэффективный код приводит к производительности ниже средней, а масштабируемость и управляемость оставляют желать лучшего (см. также приложение А). На деле, NT и ее потомки (или любая другая версия Windows) не сравнимы с уровнем функциональности, надежности или производительности, к которому сообщество пользователей Юникс привыкло за десятилетия. Эти системы могут работать хорошо, а могут и не работать. На одной системе Windows будет работать без сбоев неделями, на другой – часто падать. Я посещал тренинги в авторизованном «Майкрософт» учебном центре и услышал там: «Мы сейчас будем ставить Windows на серверы. Инсталляция вероятно не получится на одной или двух системах [У них в классе было десять одинаковых систем], но так всегда и бывает – мы не знаем почему, не знает и «Майкрософт». Я повторяю, это говорили Авторизованные партнеры «Майкрософт».

Если бы этим все заканчивалось... Даже без сложностей при установке или серьезных сбоев (таких, которые требуют восстановления или перестановки) Windows работает плохо. Многие пользователи считают, что хорошо, но они как правило не пробовали работать с другими системами. На деле ненадежность Windows стала общим местом и даже частью фольклора; страшный синий экран появился в карикатурах, хранителях экрана и на футболках, его видят в аэропортах и на зданиях, и даже в фильме «Звездный путь» есть эпизод, в котором испорченный космический корабль приходится включать и выключать заново, чтобы заставить его заработать.

И даже если Windows не падает, этого еще мало для полного счастья. На достаточно серьезном настольном ПК (например, на 450-мегагерцевом Пентиуме-II с 256 мегабайтами памяти, машине, о которой несколько лет назад мы могли только мечтать) четыре или пять одновременно выполняющихся задач вполне достаточно для того, чтобы узнать границы многозадачных способностей Windows. даже если установлено много памяти. Переключение задач выполняется целую вечность, приложения перестают отвечать, потому что ожидают, пока другие приложения освободят системные ресурсы (а они могут повиснуть, так и не освободив ресурсов), или процедуры ядра или библиотек блокируются на каком-нибудь неизвестном условии. Вскоре система затормаживается полностью или работать на ней становится невозможно. Короче, управление процессами в Windows – такая же плохая шутка, как защита памяти или управление ресурсами. Операционная система, которая может целиком упасть, когда происходит ошибка в прикладной программе, не должна продаваться как серьезная многозадачная среда. Допустим, система действительно выполняет несколько процессов одновременно – но не очень хорошо. Последние версии Windows (то есть 2000 и XP) в этом отношении немного лучше, чем их предшественники, но не намного. Хотя они подмазаны, чтобы сократить влияния некоторых самых серьезных проблем, основные изъяны архитектуры системы никуда не делись; зависшее приложение (например, видеоплейер) может заблокировать систему или заставить ее внезапно и самопроизвольно перегрузиться.

Windows – вещь довольно хрупкая и испортить ее очень легко. Чаще всего это происходит во время установки пакетов обновлений, драйверов или прикладных программ, и от этой проблемы страдают все известные версии Windows. Суть проблемы коренится в том, что Windows не может (вернее, не разработана, чтобы) разделить код и настройки приложений и операционной системы. Код перемешивается, когда приложения устанавливают свои части вместе с файлами, принадлежащими операционной системе (иногда заменяя их). Настройки записываются в центральный реестр, в котором также хранятся жизненно важные настройки ОС. База данных реестра принципиально небезопасна, и настройки, важные для работы ОС или приложений, легко испортить.

К еще большим проблемам приводят ограничения подсистемы динамических библиотек Windows. Хорошая многозадачная и/или многопользовательская ОС использует принцип, называемый разделением кода. Разделение кода означает, что если приложение одновременно запускается n раз, сегмент кода, содержащий программный код (он еще называется статическим сегментом) грузится в память только один раз, а используется n различными процессами, которые являются таким образом, экземплярами одного приложения. Очевидно, в «Майкрософте» что-то слышали о разделении кода, но явно не поняли идеи и ее преимуществ, или же их это вообще не волновало. Какая бы ни была причина, но вместо этого они применили динамические библиотеки. Термин DLL расшифровывается как библиотека динамической компоновки, предполагалось, что в таких файлах будут храниться только библиотечные функции.

Windows не разделяет статический сегмент (кода) – если вы запустите 10 копий Word, основная масса его кода будет загружена в память 10 раз. Только часть кода, то есть библиотечные функции, перемещены в динамические библиотеки и могут быть разделены.

Главная проблема с поддержкой динамических библиотек в том, что ОС различает их только по именам. Системы распознавания библиотек по их подписям нет. Другими словами, Windows не видит разницы между одной библиотекой WHATIS.DLL и другой библиотекой с тем же самым именем, хотя та может содержать совершенно другой код. Как только библиотека в системном каталоге заменяется другой, назад вернуться невозможно. Кроме того, порядок, в котором запускаются приложения (и загружаются динамические библиотеки) определяет, какая библиотека будет активной и каким образом система в конце концов слетит.

Невозможно отличить различные версии одной и той же библиотеки или библиотеки самой системы и прикладных программ. Приложение во время установки может записать свою библиотеку в тот же каталог, где хранятся системные файлы, заменив библиотеки Windows своими с тем же именем.

В результате приложения могут добавлять собственные части к операционной системе. (Это одна из причин, по которым Windows требует перезагрузки после установки или изменения прикладной программы). Это означает, что процедура установки добавляет код третьих сторон (читай: непроверенный код) к операционной системе и другим приложениям, которые загружают измененную библиотеку. Более того: поскольку код системного и пользовательского уровня на самом деле не различается, код в динамических библиотеках, написанных прикладными программистами или пользователем, может быть запущен на системном уровне, то есть без всякой защиты. Это подрывает целостность операционной системы и других приложений. Довольно эффектно это продемонстрировал сам Билл Гейтс, когда на выставке «Комдекс» представлял возможности работы Plug-and-play от Windows 98 с портами USB. Он присоединил сканер к ПК и система вылетела, показав синий экран. «Теперь я знаю, почему мы еще не продаем нашу систему», - сказал Гейтс. Неплохо выкрутились, мистер Гейтс, но на деле и официальные выпуски Windows 98 и ME столь же нестабильны, а в Windows 2000 и XP добавились новые проблемы. Эти версии Windows для распознавания устройств используют версии их аппаратно зашитых внутренних программ, поэтому обновление аппаратного кода может привести к «потере» устройства системой Plug-and-Play.

Другой, менее вредный, но более раздражающий эффект от перемешивания кода – перемешивание версий программ, написанных для разных языков. Версия приложения для иностранного рынка может добавить свои сообщения к системному списку диалоговых сообщений или вообще их переписать. После этого может появиться диалоговое окно с вопросом «Вы уверены?» по-русски, а под ним две кнопки «Yes» и «No».

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

Намеренное смешивание кода ОС и приложений укладывается в маркетинговую стратегию «Майкрософт» по объединению и интеграции продуктов (см. ниже). Но результаты этого очевидны: каждая файловая операция с исполняемых кодом сулит опасность всей ОС и ее приложениям, а ошибки приложений часто превращаются в системные ошибки (и в зависания). Это приводит к смехотворным «проблемам», когда Outlook Express может подвесить Windows NT 4.0, если система версии «повышенный уровень шифрования» с текущим французским языком; ответ на письмо тогда может свалить всю систему – и причиной оказывается одна из динамических библиотек, идущих вместе с Outlook (вы еще меня слушаете?)

В хорошо спроектированной и правильно закодированной ОС такие вещи случиться не могут. Первый критерий проектирования ОС таков: система, приложения и (в многопользовательской среде) пользователи отделены и защищены друг от друга. Ни одна версия Windows не только не делает этого по умолчанию, но еще и активно препятствует вам самим это настроить. Фиаско с динамическими библиотеками – только вершина айсберга. Вы не можете поддерживать или в нужной мере восстановить целостность ОС, вы не можете добавить управление версиями, вы не можете запретить приложениям и пользователям взаимодействовать друг с другом и с системой, случайно или намеренно.

А еще в Windows отсутствует нормальный режим для ремонта или починки. Если хоть что-нибудь пойдет не так, произойдет маленькая ошибка или искажение в одном из (буквально) тысячи файлов, составляющих Windows, часто единственным выходом остается крупномасштабная операция восстановления или даже переустановка ОС. Да, вы не ослышались. Если ваша ОС вдруг перестанет нормально работать, и вы не знаете, какие файлы надо восстановить, или их заблокировала сама Windows, стандартный подход к проблеме (рекомендованный «Майкрософт») - провести полную переинсталляцию. Однопользовательский или ремонтный режим полностью отсутствуют, нет также разумных способов понять, какой файл испорчен, не говоря уже о том, чтобы его починить. (Так называемый «безопасный режим» просто меняет конфигурацию системы и не предлагает средств, необходимых для серьезного восстановления системы).

Windows часто критикуют за множество проблем, возникающих при установке ее на произвольный ПК, который может быть первоклассным брэндом или никому неизвестным клоном с любой конфигурацией. Эта критика не совсем оправдана; в конце концов практически невозможно предвидеть все возможные конфигурации оборудования, которые могут стоять на пользовательской машине. Настоящая сложность в том, что эти проблемы часто невозможно исправить, потому большая часть операционной системы Windows недоступна для настройки пользователем или администратором. Для Windows 9x/ME с этим, конечно, проще. Поскольку эти системы – в сущности досовские программы, вы можете перегрузить систему под ДОСом и в каких-то пределах починить их вручную. С Windows NT это конечно совершенно невозможно. Windows 2000 и XP поставляются вместе с отдельной ремонтной текстовой утилитой, которая позволяет вам получить доступ к файловой с системе поврежденной машины. Но это и все.

Это приводит к смехотворным ситуациям. Например, я попытался установить макйкрософтовское исправление на Windows NT, в состав которого входила динамическая библиотека, которая заменяла предыдущую версию в системном каталоге. Однако Windows держала эту библиотеку открытой и заблокированной, поэтому заменить ее при работающей системе было нельзя. Файл README, прилагавшийся к заплатке, жизнерадостно предлагал перегрузить компьютер под ДОС и вручную заменить файл, пользуясь досовскими командами. Даже оставляя в стороне тот факт, что к разделам файловой системы NTFS нельзя получить доступ из ДОС, эта неспособность выполнять свою собственную поддержку – хорошая демонстрация незрелости Windows.

Невозможность восстановления системы в некоторой степени исправлена в Windows XP. В нее входит «Системное восстановление», отслеживающее изменения ОС, так что администраторы могут «сделать откат» к предыдущему состоянию в случае возникновения проблем. Дополнительная «Проверка системных файлов» позволяет убедиться, что ни один из тысячи системных файлов не изменен после установки. Если «важный» системный файл будет заменен другой версией (например, если динамическая библиотека от Windows XP будет заменена библиотекой с тем же именем, но от Windows 95), то система восстановит оригинальную версию. (Заодно это свойство не дает вам удалить Outlook Express, Winfile.exe или Progman.exe, поскольку определение того, что считать системным файлом, довольно неряшливо).

Эти «примочки» работают как автоматические процессы и в целом находятся вне контроля пользователя. Отключение проверки системных файлов требует сложных операций, и ни одному из этих процессов нельзя запретить не вмешиваться в сознательно задуманные действия пользователия, которые они считают некорректными. Ремонтного режима по-прежнему нет. Даже это улучшение по сравнению с предыдущей ситуацией: теперь возможна кое-какая починка. С другой стороны, это иллюстрирует халтурный подход «Майкрософт» к очень серьезной проблеме: вместо изменения архитектуры системы, которые сделают невозможным ее искажение, они сохраняют базовые изъяны и пытаются как-то разобраться с ущербом, который уже нанесен. Они не чинят дыру в вашей крыше, они продают вам ведро, чтобы вы подставили его под дыру.

Неэффективность кода майкрософтовских программ катастрофична для производительности Windows. (Как вы думаете, почему систему презрительно называют «Виндозер»?) Сейчас вам нужен по меньшей мере Пентиум II 600 Мгц, чтобы под Windows XP выполнять ту же самую конторскую работу, которой вы занимались на «двойке» с 12 Мгц под ДОС... примерно за то же время. Производительность возросла совсем чуть-чуть при непомерно вздувшейся общей стоимости владения. Что вы там говорили о возврате вложенных средств?

Попытайтесь для смеха проделать следующее: запустите в NT 4.0 SP3 монитор производительности и следите за нагрузкой процессора. Теперь откройте панель управления. Не делайте ничего, просто откройте ее и оставьте... и наслаждайтесь стабильной загрузкой ЦПУ в 100% на своем сервере или рабочей станции. (Если по-честному, то так происходит не всегда. «Проблема» циклов ЦПУ, использующихся непонятно где, зависит от комбинации факторов, которые «Майкрософт» никогда не могла объяснить. Известно, что и другие приложения могут вызвать такую ошибку). В системе Windows cуществует немало других способов зря потратить процессорное время и другие ресурсы. Например, проверьте производительность своей системы до и после установки Internet Explorer 5.0 или более поздней версии. Вам не надо его запускать, не надо устанавливать его браузером по умолчанию... просто установите. И наблюдайте, как он повиснет мертвым грузом на производительности.

Всего 32 килобайтов памяти на компьютерах капсулы «Аполлоне» хватило, чтобы доставить человека на Луну. На борту космических зондов «Вояджер» стояли четырехразрядные процессоры. Процессор 80С85 со 176 килобайтами прошивки и 576 килобайтами памяти управлял марсоходом, проехавшимся по поверхности планеты и передавшем нам изобилие научных данных и полноцветные стереоскопические снимки с высоким разрешением. Сейчас у меня Пентиум II 233 Мгц с 64 мегабайтами памяти и 15 гигабайтами дискового пространства, но если я попытаюсь написать своей бабушке письмо в Офисе под Windows XP, мне понадобится целая вечность, поскольку моему компьютеру не хватает мощности! Запуск приложений на сервере или в сети проблемы не решает, главным образом потому, что Windows на деле не может разделять код. Если вы перенесете нагрузку десяти рабочих станций 450 Мгц/512 Мб на сервер приложений (используя Windows Terminal Server, Cytrix Server или другое решение на основе ASP), вам теоретически на сервере понадобится процессор со скоростью 4.5 Ггц и 5 Мб памяти, чтобы сохранить ту же самую производительностью, даже если не считать неизбежные накладные расходы, которые запросто могут достигнуть 10 и даже 20 процентов.

А еще есть огромная неэффективность и даже совершенно не нужный код в наборе файлов Windows. Возьмем для примера трехмерную игру «Пинбол» в Windows 2000 Professional и XP Professional. Эта игра (вы найдете ее в каталоге Program Files\Windows NT\Pinball) устанавливается вместе с Windows и занимает несколько мегабайтов дискового пространства. Но большинство пользователей вообще не знают, что она там есть, занимает место и не делает ничего полезного. Ее нет в меню программ или в контрольной панели, на нее не указывают ярлыки. Пользователю не задают о ней никаких вопросов во время установки. Единственная причина ее наличия, которая приходит в голову – проиллюстрировать, как в «Майкрософте» понимают слово «профессиональный». Неудивительно, что Windows с течением времени требует все больше и больше ресурсов. Несколько мегабайтов не кажутся, наверное, слишком большой цифрой, но это только потому, что мы привыкли к огромным размерам Windows и ее приложений. Кроме того, если «Майкрософт» устанавливает полную игру «Пинбалл», хотя большинство пользователей о ней ничего не знают и в ней не нуждаются, там явно не беспокоятся об экономии ресурсов (оплачиваемых сообществом пользователей). Что это может сказать об эффективности использования ресурсов другим их кодом? Разрешите небольшую подсказку: результаты, опубликованные в апреле 2002 года в «PC Magazine» показывают, что последняя версия пакета Самба превосходит по производительности Windows 2000 на сто процентов. Что же касается масштабируемости, то Юникс и Самба, не снижая производительности, могут обрабатывать в четыре раза большее количество пользователей, чем Windows 2000.

Парадоксально, но то, что продуктам «Майкрософт» для скромной работы требуется самое передовое «железо», только добавило им коммерческого успеха. Многие интеграторы и реселлеры продвигают майкрософтовские программы, потому что они дают им возможность продвигать на рынок самые последние и самые тяжелые аппаратные платформы. Юних и Netware могут показать такую же или даже большую производительность на чем-то намного более скромном. Но Windows 2000 и XP требуют больших и быстрых систем и часто несовместимы со старыми версиями аппаратуры и аппаратных прошивок (особенно с BIOS). Это плюс то, что производители аппаратуры прекращают поддержку старых устройств и BIOS заставляет пользователя покупать дорогое «железо» и не получать от этого никакой особой пользы. Это вздувает продажи аппаратного обеспечения за счет «дорогого, уважаемого клиента». Торговцы получают больше денег, когда проталкивают продукты «Майкрософт». Все очень просто.

Кроме упомянутых и (не упомянутых) выше крупных изъянов существует еще поражающее количество мелких дефектов. Фактически этих дефектов столько, что уже только их количество можно считать крупным изъяном. Короче говоря, общее качество кода всего набора майкрософтовских программ ниже всяких стандартов. Буфера без проверки, непроверенные операции ввода/вывода, ошибки синхронизации, некорректно реализованные протоколы, забывчивость при освобождении ресурсов, отсутствие проверок параметров окружения и так далее, и тому подобное. В результате отсутствия контроля за качеством продукты «Майкрософт» и в особенности Windows пронизаны буквально тысячами и тысячами ошибок и глюков. Даже большая часть сообщений об ошибке некорректна!

Часть этих промахов можно отнести к неуклюжему дизайну и не считать просто неряшливостью. Хороший пример – поддержка в Wndows длинных имен файлов. Пытаясь добавить длинные имена, «Майкрософт» намеренно испортила файловую систему файловую систему FAT. Они поместили дополнительную информацию в специально созданные пересекающиеся записи каталогов. Это, наверное, один из самых грязных хаков, какой можно себе представить. Но этого им оказалось мало. Они еще разрешили пробелы в именах файлов. Поскольку это было несовместимо с разбором командной строки в самой системе (там по-прежнему предполагалась старая нотация в духе FAT), потребовался еще один хак – пробелы надо ставить в кавычки. Это сбивает с толку (и заставляет падать) множество программ, включая немало собственных программ «Майкрософта», идущих вместе с Windows.

Другой хороший пример – видимая нечувствительность Windows к регистру. Windows делает вид, что различает в именах файлов прописные и строчные буквы, но лежащий ниже слой ПО на деле не чувствителен к регистру. Поэтому Windows только изменяет регистр имен файлов и каталогов, когда показывает их пользователю. Настоящие имена файлов и каталогов могут храниться прописными, строчными буквами, или и теми, и другими, но выводятся они строчными буквами с первой прописной. Конечно, это несоответствие не вызывает никаких проблем в чисто майкрософтовской среде. Поскольку нижележащий код не чувствителен к регистру, регистр не критичен для работы Windows. Но как только вы захотите добавить службы, основанные на Юниксе (например, веб-сервер на базе Юникса вместо IIS), вы тут же обнаружите, что Windows искажает регистр имен файлов и каталогов.

Но большинство ошибок и глюков Windows – просто результат неряшливости. Конечно, программ без ошибок вообще не бывает, но количество ошибок в Windows, мягко говоря, превышает все разумные пропорции. Например, Пакет обновления 4 для Windows NT 4.0 задуман, чтобы исправить ни много, ни мало 1200 ошибок (да, тысячу двести). Но к этому времени уже были три предыдущих пакета обновлений! «Майкрософт» без всякого стыда это признала и даже хвасталась, что NT «улучшена» в 1200 местах. Потом им пришлось выпустить за несколько месяцев еще несколько последовательных пакетов, чтобы исправить оставшиеся ошибки и, конечно, новые, добавленные самими пакетами обновлений.

Внутренняя записка, направленная разработчикам «Майкрсофт» упоминает 63000 (да, шестьдесят три тысячи) известных дефектов в первом выпуске Windows 2000. Кейт Вайт, директор «Майкрософт» по маркетингу, не отрицал существование этого документа, но заявил, что указанные там факты написаны, чтобы «мотивировать команду разработчиков Windows». Потом он заявил, что «Windows 2000 – это самая надежная Windows из всех». Да, так он и сказал. У продукта 63000 известных дефектов (обратите внимание: это только известные дефекты), а он признает, что это – лучшее, что они могут сделать. О боги!

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

Для настольных компьютере это нехорошо, но те же самые изъяны существуют и в серверных продуктах «Майкрософт». Серверы с гораздо большей вероятностью будут использоваться для критически важных приложений, поэтому ограниченная стабильность Windows и ее влияние на работу фирмы становятся главной проблемой. Время непрерывной работы типичных серверов, основанных на Windows, на которых запускаются серьезные приложения (то есть не просто службы доступа к файлам и принтерам для нескольких рабочих станций) обычно ограничено в лучшем случае несколькими неделями. Один-другой сбой сервера (читай: сбой деловых операций и потеря данных) за несколько месяцев – обычное дело. В качестве серверной ОС Windows явно не хватает надежности.

Серверные продукты Windows – на самом деле даже не серверные ОС. Их архитектура не отличается от версий для рабочих станций. Ядро NT для сервера и для рабочей станции абсолютно одинаково, а смены пары ключей в реестре хватает, чтобы убедить рабочую станцию, что она теперь сервер. Сетевые возможности по-прежнему в значительной мере основываются на равноранговом методе, который был частью Windows для рабочих групп 3.11 и который «Майкрософт» скопировала, когда он хорошо зарекомендовал себя в сетях, впервые сделанных «Эппл» и другими фирмами в середине 80-х. Конечно, кое-какой код в серверных продуктах расширен или оптимизирован для увеличения производительности, добавлена аутентификация на базе домена, но из этого еще не получается настоящая серверная платформа. Не меняет этого и тот факт, что NT Server стоит почти в три раза дороже NT Workstation. На деле речь идет вряд ли о чем-то большем, чем Windows для рабочих групп на стероидах.

В ноябре 1999 года Стивен Дж. Воэн-Николс из «Sm@rt reseller» провел сравнение стабильности Windows NT Server (на котором, очевидно, работал Internet information server) с системами на базе Линукса с открытыми исходными текстами (на которых работала Самба и Апач). Он пишет:

Общее мнение утверждает, что Линукс невероятно стабилен. Относясь к этому скептически, мы решили проверить это утверждение в течение 10 месяцев. В нашем тесте мы запускали OpenLinux фирмы «Кальдера», Red Hat Linux и Windows NT Server 4.0 с третьим пакетом обновлений на одинаковых системах Пентиум 100 МгЦ с 64 Мб памяти. С того самого дня в январе, когда мы загрузили наши системы, к каждому серверу все время посылались сетевые запросы параллельно с запросами на Интернет, доступ к файлам и принтерам. Результаты говорят сами за себя. Наш сервер NT падал в среднем каждые шесть недель. Каждый сбой требовал примерно 30 минут для починки. Это не очень плохо, если не принимать во внимание, что все линуксовские сервера работали стабильно.

Tags: программирование
Subscribe

  • Post a new comment

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your IP address will be recorded 

  • 4 comments