Мнение: Почему Linux не готова для применения в настольных системах
Эрнесто Гарбарино (Ernesto Garbarino), Пятница, 06 Август 2004, 12:55
Вступление
Но одного этого определения не достаточно. Большинство людей и средств массовой информации понимают, что заменить 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? Должен существовать один "" оконный менеджер для конечного пользователя. А остающиеся в таком случае наборы утилит не обязательно должны погибнуть, они все еще смогут быть использованы для академических целей или как предмет чьего-то хобби.
Запуск одновременно Gnome и KDE хорошее решение только на определенный промежуток времени. Среда X уже достаточно тяжела, что уж говорить насчет того, что будут подгружены и все библиотеки KDE и Gnome. И это все только потому что разработчик хочет выбрать API, который ей нравиться? Мыльная опера не заканчивается на этом. Что если разработчик выбрал последнюю версию API и просит пользователя скачать и скомпилировать последний релиз KDE/Gnome? Ужас. Включение в поставку последней версии библиотеки набора утилит, даже статически скомпилированно, не обязательно плохая вещь. Конечный пользователь даже не должен знать что это такое, она всего лишь хочет скачать, нажать два раза и работать. (“она” используется в данном случае вместо “он” в целях политкорректноси – прим. переводчика)
Плохая низкоуровневая интеграция рабочего стола
Когда впервые появилась Windows 95, каждый говорил о том, что это всего лишь "" и под ней находиться обычный MS-DOS. Я тоже поддерживал этот взгляд в то время, но X намного в большей степени являются "" для основанном на командной строке дистрибутиве Linux, нежели Windows 95 для MS-DOS. Я не буду углубляться в детали и спорить насколько это все хорошо или плохо в отношении стабильности системы, но факты ясны всем: графический интерфейс для Linux медлителен и плохо интегрирован. Вызов getPixe()/putPixel() намного более ресурсоемок в Linux, чем в Windows. Поднимите руку, если вы подумали "но вы можете проектировать рабочий стол через ". 99% процентов пользователей никогда это не используют. Должны ли мы давать им в два раза более медленный рабочий стол, только чтобы оставить возможность настраивать цвет пикселя через сеть? Графический интерфейс Linux должен быть интегрирован на низком уровне так скоро, как это только возможно. Существует несколько проектов, преследующих эту цель, но половина разработчиков признают, что овчинка не стоит выделки.
Более того, интеграция с интерфейсом командной строки так же очень страдает. Если вы измените какую-либо опцию, используя командную строку, то эти изменения обычно "сами по ", и вам не следует ожидать увидеть их в графической версии утилиты. Графические утилиты конфигурировани как правило ориентированы на тех, "кто не знает, как редактировать текстовые конфигурационны ", что, по моему мнению, является ужаснейшим подходом. Вместо этого графические утилиты должны обеспечивать "дополнительный " редактирования файлов конфигурации. Как часто вы находили скрипт, который вызывает другой с комментарием, в котором говорится "Не трогать! Сгенерированно Kjoe"? Графический интерфейс Linux никогда не уйдет далеко с такими вот хаками. Правда, что часть проблемы в том, что многие утилиты, такие как sendmail, имеют настолько плохо спроектированны файлы конфигурации, что очень трудно реконструироват их, используя графический парсер, но как насчет XML? Каждое приложение должно иметь возможность быть сконфигурированым как вручную, используя текстовый редактор, так и с использованием графического интерфейса, используя ОДИН конфигурационны файл. Программисты же должны начать писать конфигурационны файлы, "дружественные к графическому ".
Основные приложения
Я не понимаю, почему большинство людей жалуются на отсутствие приложений для Linux. Это, возможно, самая сильная его сторона. Правда, что для некоторых приложений нет достойных аналогов, к примеру, Cubase (для аудио-продукции) или Photoshop, но эти приложения никогда не будут портированы на Linux, пока не будет осуществлена "чистка в " (будет объявлен стандартный графический интерфейс и удалят X или будут использовать их таким способом, чтобы никого "не "). Несмотря на то, что персональный пример всегда субъективен, я могу сказать, что пока я использовал Windows XP как мою основную ОС, я не использовал ни одного приложения, которое отсутствует в Linux. Большинство из них были рождены в Linux и потом портированны в Windows: Mozilla и OpenOffice, если называть только некоторые. Некоторые из этих приложений запускаются намного медленнее в Linux. Даже OpenOffice открывается меньше, чем за две секунды (на AMD 2500+). У меня установлены Unix-утилиты, так что я могу использовать большинство команд оболочки Unix. Windows предоставляет мне только хорошо интегрированный дружелюбный к оборудованию рабочий стол. Я бы мог использовать эти приложения точно так же хоть на Mac OS X.
Что нам нужно
Давайте оставим тех, кто хочет использовать Linux как хакерский инструмент или как "" продукт, для них Linux уже обладает всем, что нужно. Местой многих из нас явлется система, основанная 100% на открытых стандартах и программном обеспечении с открытым исходным кодом, бесплатном, в, как минимум, своих основных формах, и такая же простая и быстрая, как Windows . Мы хотим разрабатывать программное обеспечении для большой публики, не только для таких же чудаков, как мы. Но все имеет свою цену, которую многие из этих хардкорных разработчиков (имеются в вижу разработчики ПО для Linux – прим. переводчика) не хотят платить, потому что многие из них не понимают, что "" враг "". По моему скромному мнению, решение основанное на Linux, нацеленое на замену Windows, должно принять на рассмотрение хотя бы следующие идеи:
a) Фундаментальная ОС
Мы имеем ядро (Linux), а не операционную систему. Операционная система состоит из ядра и других приложений, таких как оболочка, в которой запускаются "утилиты ", например ls, cd, mv и т.д. Она так же имеет загрузчик (во многих случаях LILO). Ядро разрешает наличие модулей, которые его расширяют и помогают операционной системе опознавать базовое и новое оборудование. Так как Linux - всего лишь ядро, давайте назовем это FOS ( Foundation Operating System - Фундаментальная Операционная Система). FOS (в оригинале FOD, думаю, автор опечатался – прим. переводчика) должна предоставлять стандартное ядро (с определенным набором драйверов), одну основную оболочку, стандартный набор утилит и систему конфигурировани для основных сервисов, таких как TCP/IP или жесткие диски. На практике, все дистрибутивы уже являются по своему FOS (аналогично, см. комментарий выше – прим. переводчика), но они нуждаются в единой организации. Проект United Linux, насколько я могу судить, хочет осуществить эту идею, но не все дистрибьюторы их поддержали.
b) Долголетие бинарных файлов
Неработоспособнсть скомпилированны программ – это очень плохая вещь, оправдания которой я не вижу. Обещание об очень быстрых процессорно-зависимых приложениях не материализовалиь. Никто не хочет потратить 3 дня на компиляцию операционной системы, чтобы достичь всего лишь 20% прироста скорости, в то время как процессор на 20% быстрее стоит всего на 50 баксов больше (""
- прим. переводчика). Конечному пользователю не нужна среда разработки. Это все равно, что сказать, что владелец автомобиля должен иметь дома магазин для его обслуживания. Хорошо и даже благоразумно включать так много интерпретаторов как только можно, в том числе Perl, Python, Mono и Java. Однако приложения для этих интерпретаторовдолжны распространяться, используя такие же стандарты, как и FOS. Новые версии ядра (и библиотеки glibc) должны поддерживать программы, скомпилированны для более старых версий. Коммерческое ПО и игры никогда не будут разрабатываться для Linux, если долговечность скомпилированно программы не гарантируется. Это не значит, что все приложения должны быть 386-совместимыми. Многие приложения Windows содержат код, который активируется, если в системе установлен определенный процессор. Так же возможно включать в поставку более одного откомпилированнго варианта программы, пока существует совместимая версия. Несовместимыми будут только те программы, которые скомпилированныдля радикально других процессоров, к примеру, PowerPC или Sparc. Долговечность скомпилированны приложений - это обязательство перед конечным пользователем.
c) Стандартная система драйверов
Драйвера должны корректно регистрироватьс в соответствующих категориях (графика, диск и т.д.). Удалять и устанавливать драйвера должно быть одинаково просто, как из командной строки, так и используя графический интерфейс. Все драйвера должны уметь корректно описать сами себя. Должно существовать дружелюбное к пользователю дерево драйверов в файловой системе для их хранения. Несмотря на то, что в Windows есть достаточно хорошая система для установки, удаления и поиска драйверов, очень трудно найти их, используя командную строку. Большинство перемешаны друг с другом и имеют короткие и ничего не значащие для пользователя имена, к примеру, NVD5443.SYS. Было бы хорошо иметь возможность указывать драйвер в процессе загрузки, когда вам необходимо использовать неподдерживаемо оборудование, например жесткий диск SATA. Очень невежливо просить "качественно новое я" только для того, чтобы установить операционную систему.
d) Общий хорошо интегрированныйрабочий стол
Я не знаю должен ли это быть Gnome, KDE или что-то другое, но он должен быть только один. Самая главная вещь тут состоит в том, что рабочий стол должен быть тесно интегрирован с низлежащим интерфейсом командной строки. Я не думаю, что обязательно требовать присутствия графического интерфейса. Голая основа из командной строки для меня является хорошим решением (большинство пользователей, однако, скорее всего никогда не откажутся от установки GUI). Мы все знаем, как ужасно восстанавливатьWindows, если она не загружается в графическом режиме. Суть в том, что не обязательно позволять настройку 100% только через GUI. Используемые файлы конфигурации должны быть идентичными тем, которые используются через интерфейс командной строки. К примеру, возможно, вы не можете изменить значение MTU, используя графический интерфейс, но если вы отредактируете файл, используя текстовый редактор, вы все еще сможете изменить ip-адрес, используя графический интерфейс, не имея необходимость держать два конфигурационны файла и не нарушая что-нибудь другое. Если пользователь испортил текстовый конфигурационны файл, графический интерфейс должен предложить использовать последнюю рабочую версию. Должны существовать стандартные папки, как "Мои ". Приложения должны комплектоваться стандартным установщиком, основанным на какой-то дружественной к пользователю скриптовой системе. Должна существовать специальная папка, как "Program Files", для приложений, хотя пользователь и может указывать куда их устанавливать. И в Windows, и в Mac OS X легко понять где находятся приложения, которые вы однажды установили, однако то же самое нельзя сказать про Linux. Просто найти приложения, поставляемые в комплекте с вашим дистрибутивом, но если вы скачали новое приложение и забыли куда его установили, то часто оно для вас потеряно.
Итог
Как вы можете видеть, большинство ингридиентов для того, чтобы сделать Linux лидером на рынке существуют. Нам нужны стандарты и мудрые политические решения, чтобы подготовить хороший продукт для широкого применения. Если Linux будет продолжать развиваться под руководством студентов, которые больше верят в свободу выбора и анархию, чем в стандарты, и компаний, дерущиеся за то, чтобы стать стандартом де факто, вместе с тем предлагая каждая свои собственные системы, то мы никогда этого не добьемся. Я хочу увидеть тот день, когда я пойду в магазин и смогу купить "приложение для Linux", которое смогу установить с той же простотой, с которой устанавливаю приложения для Windows и Mac OS X. Это не возможно в данный момент, потому что "Linux" еще не готова для применения в настольных системах.
Об авторе:
Я начал программироватьв 1990 году. В прошлом программировал на BASIC, C, Perl, и в данный момент специализируюсь на технологии Java. Использовал много операционных систем, включая AmigaOS, Digital Unix, Slackware Linux и MS-Windows.
это контент от Центр информации по операционным системам
( http://www.osrc.info/plugins/content/content.php?content.59 )
Эрнесто Гарбарино (Ernesto Garbarino), Пятница, 06 Август 2004, 12:55
Вступление
Но одного этого определения не достаточно. Большинство людей и средств массовой информации понимают, что заменить 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? Должен существовать один "" оконный менеджер для конечного пользователя. А остающиеся в таком случае наборы утилит не обязательно должны погибнуть, они все еще смогут быть использованы для академических целей или как предмет чьего-то хобби.
Запуск одновременно Gnome и KDE хорошее решение только на определенный промежуток времени. Среда X уже достаточно тяжела, что уж говорить насчет того, что будут подгружены и все библиотеки KDE и Gnome. И это все только потому что разработчик хочет выбрать API, который ей нравиться? Мыльная опера не заканчивается на этом. Что если разработчик выбрал последнюю версию API и просит пользователя скачать и скомпилировать последний релиз KDE/Gnome? Ужас. Включение в поставку последней версии библиотеки набора утилит, даже статически скомпилированно, не обязательно плохая вещь. Конечный пользователь даже не должен знать что это такое, она всего лишь хочет скачать, нажать два раза и работать. (“она” используется в данном случае вместо “он” в целях политкорректноси – прим. переводчика)
Плохая низкоуровневая интеграция рабочего стола
Когда впервые появилась Windows 95, каждый говорил о том, что это всего лишь "" и под ней находиться обычный MS-DOS. Я тоже поддерживал этот взгляд в то время, но X намного в большей степени являются "" для основанном на командной строке дистрибутиве Linux, нежели Windows 95 для MS-DOS. Я не буду углубляться в детали и спорить насколько это все хорошо или плохо в отношении стабильности системы, но факты ясны всем: графический интерфейс для Linux медлителен и плохо интегрирован. Вызов getPixe()/putPixel() намного более ресурсоемок в Linux, чем в Windows. Поднимите руку, если вы подумали "но вы можете проектировать рабочий стол через ". 99% процентов пользователей никогда это не используют. Должны ли мы давать им в два раза более медленный рабочий стол, только чтобы оставить возможность настраивать цвет пикселя через сеть? Графический интерфейс Linux должен быть интегрирован на низком уровне так скоро, как это только возможно. Существует несколько проектов, преследующих эту цель, но половина разработчиков признают, что овчинка не стоит выделки.
Более того, интеграция с интерфейсом командной строки так же очень страдает. Если вы измените какую-либо опцию, используя командную строку, то эти изменения обычно "сами по ", и вам не следует ожидать увидеть их в графической версии утилиты. Графические утилиты конфигурировани как правило ориентированы на тех, "кто не знает, как редактировать текстовые конфигурационны ", что, по моему мнению, является ужаснейшим подходом. Вместо этого графические утилиты должны обеспечивать "дополнительный " редактирования файлов конфигурации. Как часто вы находили скрипт, который вызывает другой с комментарием, в котором говорится "Не трогать! Сгенерированно Kjoe"? Графический интерфейс Linux никогда не уйдет далеко с такими вот хаками. Правда, что часть проблемы в том, что многие утилиты, такие как sendmail, имеют настолько плохо спроектированны файлы конфигурации, что очень трудно реконструироват их, используя графический парсер, но как насчет XML? Каждое приложение должно иметь возможность быть сконфигурированым как вручную, используя текстовый редактор, так и с использованием графического интерфейса, используя ОДИН конфигурационны файл. Программисты же должны начать писать конфигурационны файлы, "дружественные к графическому ".
Основные приложения
Я не понимаю, почему большинство людей жалуются на отсутствие приложений для Linux. Это, возможно, самая сильная его сторона. Правда, что для некоторых приложений нет достойных аналогов, к примеру, Cubase (для аудио-продукции) или Photoshop, но эти приложения никогда не будут портированы на Linux, пока не будет осуществлена "чистка в " (будет объявлен стандартный графический интерфейс и удалят X или будут использовать их таким способом, чтобы никого "не "). Несмотря на то, что персональный пример всегда субъективен, я могу сказать, что пока я использовал Windows XP как мою основную ОС, я не использовал ни одного приложения, которое отсутствует в Linux. Большинство из них были рождены в Linux и потом портированны в Windows: Mozilla и OpenOffice, если называть только некоторые. Некоторые из этих приложений запускаются намного медленнее в Linux. Даже OpenOffice открывается меньше, чем за две секунды (на AMD 2500+). У меня установлены Unix-утилиты, так что я могу использовать большинство команд оболочки Unix. Windows предоставляет мне только хорошо интегрированный дружелюбный к оборудованию рабочий стол. Я бы мог использовать эти приложения точно так же хоть на Mac OS X.
Что нам нужно
Давайте оставим тех, кто хочет использовать Linux как хакерский инструмент или как "" продукт, для них Linux уже обладает всем, что нужно. Местой многих из нас явлется система, основанная 100% на открытых стандартах и программном обеспечении с открытым исходным кодом, бесплатном, в, как минимум, своих основных формах, и такая же простая и быстрая, как Windows . Мы хотим разрабатывать программное обеспечении для большой публики, не только для таких же чудаков, как мы. Но все имеет свою цену, которую многие из этих хардкорных разработчиков (имеются в вижу разработчики ПО для Linux – прим. переводчика) не хотят платить, потому что многие из них не понимают, что "" враг "". По моему скромному мнению, решение основанное на Linux, нацеленое на замену Windows, должно принять на рассмотрение хотя бы следующие идеи:
a) Фундаментальная ОС
Мы имеем ядро (Linux), а не операционную систему. Операционная система состоит из ядра и других приложений, таких как оболочка, в которой запускаются "утилиты ", например ls, cd, mv и т.д. Она так же имеет загрузчик (во многих случаях LILO). Ядро разрешает наличие модулей, которые его расширяют и помогают операционной системе опознавать базовое и новое оборудование. Так как Linux - всего лишь ядро, давайте назовем это FOS ( Foundation Operating System - Фундаментальная Операционная Система). FOS (в оригинале FOD, думаю, автор опечатался – прим. переводчика) должна предоставлять стандартное ядро (с определенным набором драйверов), одну основную оболочку, стандартный набор утилит и систему конфигурировани для основных сервисов, таких как TCP/IP или жесткие диски. На практике, все дистрибутивы уже являются по своему FOS (аналогично, см. комментарий выше – прим. переводчика), но они нуждаются в единой организации. Проект United Linux, насколько я могу судить, хочет осуществить эту идею, но не все дистрибьюторы их поддержали.
b) Долголетие бинарных файлов
Неработоспособнсть скомпилированны программ – это очень плохая вещь, оправдания которой я не вижу. Обещание об очень быстрых процессорно-зависимых приложениях не материализовалиь. Никто не хочет потратить 3 дня на компиляцию операционной системы, чтобы достичь всего лишь 20% прироста скорости, в то время как процессор на 20% быстрее стоит всего на 50 баксов больше (""
- прим. переводчика). Конечному пользователю не нужна среда разработки. Это все равно, что сказать, что владелец автомобиля должен иметь дома магазин для его обслуживания. Хорошо и даже благоразумно включать так много интерпретаторов как только можно, в том числе Perl, Python, Mono и Java. Однако приложения для этих интерпретаторовдолжны распространяться, используя такие же стандарты, как и FOS. Новые версии ядра (и библиотеки glibc) должны поддерживать программы, скомпилированны для более старых версий. Коммерческое ПО и игры никогда не будут разрабатываться для Linux, если долговечность скомпилированно программы не гарантируется. Это не значит, что все приложения должны быть 386-совместимыми. Многие приложения Windows содержат код, который активируется, если в системе установлен определенный процессор. Так же возможно включать в поставку более одного откомпилированнго варианта программы, пока существует совместимая версия. Несовместимыми будут только те программы, которые скомпилированныдля радикально других процессоров, к примеру, PowerPC или Sparc. Долговечность скомпилированны приложений - это обязательство перед конечным пользователем.c) Стандартная система драйверов
Драйвера должны корректно регистрироватьс в соответствующих категориях (графика, диск и т.д.). Удалять и устанавливать драйвера должно быть одинаково просто, как из командной строки, так и используя графический интерфейс. Все драйвера должны уметь корректно описать сами себя. Должно существовать дружелюбное к пользователю дерево драйверов в файловой системе для их хранения. Несмотря на то, что в Windows есть достаточно хорошая система для установки, удаления и поиска драйверов, очень трудно найти их, используя командную строку. Большинство перемешаны друг с другом и имеют короткие и ничего не значащие для пользователя имена, к примеру, NVD5443.SYS. Было бы хорошо иметь возможность указывать драйвер в процессе загрузки, когда вам необходимо использовать неподдерживаемо оборудование, например жесткий диск SATA. Очень невежливо просить "качественно новое я" только для того, чтобы установить операционную систему.
d) Общий хорошо интегрированныйрабочий стол
Я не знаю должен ли это быть Gnome, KDE или что-то другое, но он должен быть только один. Самая главная вещь тут состоит в том, что рабочий стол должен быть тесно интегрирован с низлежащим интерфейсом командной строки. Я не думаю, что обязательно требовать присутствия графического интерфейса. Голая основа из командной строки для меня является хорошим решением (большинство пользователей, однако, скорее всего никогда не откажутся от установки GUI). Мы все знаем, как ужасно восстанавливатьWindows, если она не загружается в графическом режиме. Суть в том, что не обязательно позволять настройку 100% только через GUI. Используемые файлы конфигурации должны быть идентичными тем, которые используются через интерфейс командной строки. К примеру, возможно, вы не можете изменить значение MTU, используя графический интерфейс, но если вы отредактируете файл, используя текстовый редактор, вы все еще сможете изменить ip-адрес, используя графический интерфейс, не имея необходимость держать два конфигурационны файла и не нарушая что-нибудь другое. Если пользователь испортил текстовый конфигурационны файл, графический интерфейс должен предложить использовать последнюю рабочую версию. Должны существовать стандартные папки, как "Мои ". Приложения должны комплектоваться стандартным установщиком, основанным на какой-то дружественной к пользователю скриптовой системе. Должна существовать специальная папка, как "Program Files", для приложений, хотя пользователь и может указывать куда их устанавливать. И в Windows, и в Mac OS X легко понять где находятся приложения, которые вы однажды установили, однако то же самое нельзя сказать про Linux. Просто найти приложения, поставляемые в комплекте с вашим дистрибутивом, но если вы скачали новое приложение и забыли куда его установили, то часто оно для вас потеряно.
Итог
Как вы можете видеть, большинство ингридиентов для того, чтобы сделать Linux лидером на рынке существуют. Нам нужны стандарты и мудрые политические решения, чтобы подготовить хороший продукт для широкого применения. Если Linux будет продолжать развиваться под руководством студентов, которые больше верят в свободу выбора и анархию, чем в стандарты, и компаний, дерущиеся за то, чтобы стать стандартом де факто, вместе с тем предлагая каждая свои собственные системы, то мы никогда этого не добьемся. Я хочу увидеть тот день, когда я пойду в магазин и смогу купить "приложение для Linux", которое смогу установить с той же простотой, с которой устанавливаю приложения для Windows и Mac OS X. Это не возможно в данный момент, потому что "Linux" еще не готова для применения в настольных системах.
Об авторе:
Я начал программироватьв 1990 году. В прошлом программировал на BASIC, C, Perl, и в данный момент специализируюсь на технологии Java. Использовал много операционных систем, включая AmigaOS, Digital Unix, Slackware Linux и MS-Windows.
это контент от Центр информации по операционным системам
( http://www.osrc.info/plugins/content/content.php?content.59 )