Сначала мы должны определиться, что же подразумевается под "быть готовым для применения в настольных ". Для некоторых из нас это понятие связано с наличием графического интерфейса, в котором приложения имеют иконки, и могут быть запущены интуитивно, без ввода множества различных команд. Даже Commodore 64 под управлением Geos будет "готов для применения в настольных ", если следовать этому определению. Однако, факт в том, что, когда мы читаем "готов для применения в настольных ", мы понимаем "готов заменить Microsoft Windows".
<br /><br />
Перевод: Олег Шимчик aka The Wanderer<br />
Оригинал статьи доступен <a href=http://www.osnews.com/story.php?news_id=7813></a>
<hr>

Вступление

Но одного этого определения не достаточно. Большинство людей и средств массовой информации понимают, что заменить Windows не значит всего лишь загрузить что-то вместо операционной системы от Microsoft. Это связано так же с такими понятиями, как техническая поддержка, совместимость документации, наличие офисного пакета и других основных приложений.
Кроме того, операционная система, стремящаяся заменить продукт Microsoft, должна быть готова выполнять, как минимум, те же обязательства перед конечным пользователем, которые выполняет Windows. Это может выглядеть не слишком убедительно сегодня, во время огромного количества дыр в программном обеспечении, но я поясню свое высказывание чуть позже. Мы все согласны с тем, что можем научить наших родителей путешествовать по сети или создать документ "Word" в Linux, или, что еще лучше, использовать Windows-тему, которая может обмануть при первом взгляде многих ветеранов Windows. Но смысл, однако, не в этом. Говоря "готова для применения в настольных ", мы имеем в виду систему, которая может быть использована кем-либо без помощи родственников или специализированого журнала. Более того, мы хотим, чтобы Linux предустанавливаась большинством крупных производителей компьютерной техники. Мы хотим, чтобы самые новейшие игры и оборудование были совместимы с Linux. Мы хотим пользоваться драйверами, написанными в той компании, которая производит оборудование, а не сделанными студентами, которые занимаются этим в свое свободное время.

Мы знаем, что значит "готов для применения в настольных ", но чем является Linux?

Ядром. Повторяйте за мной, ядром. Нет, это не Suse и не RedHat. Но это различные “типы” Linux, не так ли? Нет, это продукты, которые используют специфические версии ядра Linux. Это значит, что приложение, скомпилированно с одним ядром, может не работать с другим. К примеру, в данный момент некоторые дистрибутивы используют ядра семейства 2.4.x, в то время, как другие - линейку 2.6.x. Приложения, ориентирующиеся на Suse Linux не обязательно совместимы с RedHat Linux, несмотря на то, что имя и того и другого продукта содержит слово “Linux”. Каждый дистрибьютор компилирует и объединяет в пакеты основные приложения для своей реализации.

Правда состоит в том, что не существует Oracle или Java для "Linux". Они существуют для некоторых "сертифицированн" дистрибутивов, в сущности, идейно "различных соперников Windows". Таким образом, на сегодняшний день "Linux-приложения" - это исходный код, которые вы можете надеятся скомпилировать на большинстве дистрибутивов. И не факт, что имея в распоряжении только ядро и компилятор, вы сможете сделать это. Скорее всего, для компиляции понадобиться определенная оболочка и конкретный набор утилит для нее. Нередко мы узнаем, что компилирующий скрипт вызывает какую-нибудь утилиту оболочки, которую не посчитали нужным включить в наш дистрибутив. Когда мы говорим про “приложения Windows", мы подразумеваем, что ожидаем запустить их на любой версии "Windows" (если это не какое-либо специализированое программное обеспечение, которое нуждается в специфических возможностях ядер серии NT, к примеру, некоторые серверные приложения). Если у меня есть CD-ROM с энциклопедией для Windows, я могу ожидать, что она без проблем будет работать на Windows 95, 98, ME, XP, 2000 и т.д. Если же у меня есть такой же продукт для Linux, то он будет совместим с очень ограниченным кругом дистрибутивов, а если он вдобавок ко всему еще и в бинарной форме, то, возможно, не сможет запуститься уже спустя несколько лет после покупки, потому что все мы знаем, что долголетие откомпилированнх приложений в Linux не гарантируется. Я не говорю о формате ELF, я говорю в общем смысле, имея в виду то, что скомпилированны приложения зависят от слишком большого количества динамических библиотек, которые зачастую относятся к определенном релизу ядра. Linux-приложения, как правило, не работают сразу. Они часто ругаются об отсутствии динамических библиотек или, что еще хуже, glibc.

KDE и Gnome

Вопрос в данном случае не кто лучше. По этому поводу существует огромное количество статей и дисскусий. Проблема в том, что у нас есть и тот и другой. Пожалуйста, давайте не будем говорить о персональных предпочтениях и свободе выбора. Давайте лучше поговорим о несоответствии, несовместимостии усилиях разработчиков. Должны ли водители автомобиля выбирать где быть педали газа: справа или слева? Нет, они могут захотеть, чтобы сидения были другого цвета. Мы ожидаем, что те уроки, что мы изучили, когда получали водительские права, позволят нам водить любой автомобиль. Можем ли мы сказать то же самое о Linux? Будут ли наши личные занятия с родителями полезны, когда они получат компьютер с Suse или Mandrake? Если ваш старый родственник звонит вам, находясь за тысячу километров, и жалуется, что он использует Linux и не может попасть в Интернет, можете ли вы дать ему четкие инструкции вроде "Нажмите Пуск, выберите Запуск..., наберите cmd и затем ipconfig"? Нет, потому что нет определенного способа запустить консоль с рабочего стола. Простейшая вещь, иконка для запуска консоли, меняет свое местонахождениев зависимости от оконного менеджера. Нажатие немного странной комбинации Alt+Ctrl, чтобы перейти в режим консоли - не вариант: многие LCD мониторы вообще не поддерживают такой текстовый режим, особенно если это не стандартный 80x25.
Прилагаются громадные усилия, чтобы интегрировать оба эти оконных менеджера, чтобы заставить приложения для Gnome выглядеть, как приложения для KDE, и наоборот. Это хорошее начало, но если мы намереваемся заставить обе оболочки выглядеть одинаково, то зачем нам два разных графических API? Должен существовать один "" оконный менеджер для конечного пользователя. А остающиеся в таком случае наборы утилит не обязательно должны погибнуть, они все еще смогут быть использованы для академических целей или как предмет чьего-то хобби.

индекс статьи
страница 1 - текущая : страница без заголовка
страница 2 : страница без заголовка
страница 3 : страница без заголовка