Библиотека сайта rus-linux.net
Свободная система для свободных людей
(обзор истории операционной системы Linux)
(С) Костромин В.А., март 2005 г.
Linux совершенствуется
Изменения в личной жизни
Пока шла подготовка в выпуску версии 1.0, в личной жизни Торвальдса произошли довольно существенные перемены. Осенью 1992 года его назначили ассистентом в шведских классах факультета информатики. Здесь он познакомился со своей будущей женой, Туве. Туве была дошкольным педагогом и шестикратным чемпионом Финляндии по карате, у нее было много друзей. Через несколько месяцев Торвальдс переехал в ее крошечную квартирку.
После выхода версии 1.0 к Linux начали присматриваться крупные корпорации. Среди них была и компания Novell, в которой открыли небольшой "побочный" проект на базе Linux под названием "Looking Glass" (зеркало). В августе 1994 года Novell пригласила Торвальдса приехать в Орем (шт. Юта) поговорить об этой разработке. Это был первый визит Линуса за океан.
Второй раз Линус побывал в Америке еще через год. Приехал, чтобы выступить перед DECUS (группой пользователей Digital) в Новом Орлеане. Встреча была организована Джоном Холлом, по прозвищу Мэддог. Он ведал техническим маркетингом Digital Unix и был давним пользователем Unix.
Одним из последствий этого выступления в Новом Орлеане было то, что Мэддог договорился чтобы Digital одолжила Торвальдсу компьютер на основе процессора Alpha. В результате Linux впервые была перенесена на компьютер, отличный от PC. До этого Linux уже переносили на другие архитектуры. Была версия для компьютеров Atari и Amiga на базе микропроцессора Motorola 68000. Но перенос в этих случаях был осуществлен таким образом, что Linux не годилась для двух платформ одновременно. Просто куски программы, которые не работали на новой машине, выкидывались и вместо них писались другие. Перенос на Alpha был первым настоящим переносом. Исходники для PC и для Alpha практически не различались, использовался один и тот же исходный код при компиляции программ для разных архитектур.
Перенос Linux на другие платформы стал темой магистерской диссертации Торвальдса. Он пишет в своей книге, что факультет информатики Университета Хельсинки всегда оказывал ему большую помощь. В 1995 году Торвальдса перевели в научные сотрудники и он впервые начал получать деньги за свою работу над Linux. "Когда в марте 1995-го мы выпустили версию 1.2, ядро уже включало в себя 250 тысяч строк кода, новый журнал "Linux Journal" хвалился десятитысячным тиражом, a Linux могла работать на процессорах Intel, Digital и Sun SPARC. Это был большой прогресс.
Но учеба все еще формально была не закончена. Только весной 1996-го Торвальдс наконец закончил курс обучения на звание магистра.
Вскоре после этого Линус получил приглашение работать в компании Transmeta, офис которой расположен в городе Санта-Клара, штат Калифорния. В этой компании работал один из давних приверженцев Linux - Питер Энвин, который и организовал это приглашение. Компания Transmeta в то время работала в условиях глубокой конспирации и о ней было известно только то, что там разрабатываются "программируемые чипы".
Известие о приглашении Торвальдса в Transmeta обеспокоило сообщество сторонников Linux, потому что Transmeta частично финансировалась одним из основателей Microsoft Полом Алленом; некоторые видели тут хитрый план захвата Linux.
Когда прошел слух, что Торвальдс приглашен в Transmeta, ему поступило несколько других предложений: от финской компании Tele, от Digital, от Red Hat. В Red Hat даже обещали дать Торвальдсу зарплату выше, чем в Transmeta, и превысить предложение Transmeta в отношении пакета акций, каково бы оно ни было. Но Торвальдс не хотел работать на какую-то одну конкретную Linux-компанию и решил принять предложение Transmeta. Тем более, что контракт с Transmeta предусматривал возможность продолжать работу над Linux, причем даже в рабочие часы.
5 декабря 1996 года в семье Торвальдсов появилась дочь Патриция. "Следующие несколько недель мы были заняты Патрицией и хлопотами по получению американских виз, которые, казалось, займут всю жизнь." Утренним рейсом 17 февраля 1997 года Торвальдсы вылетели в Сан-Франциско, предварительно отправив в Америку свое имущество.
Компания Transmeta Corporation занималась разработкой нового микропроцессора Crusoe™, работы над которым велись под большим секретом. Целью разработки было создание процессора с низким потреблением энергии и сокращенным набором встроенных команд, на котором можно было бы эмулировать другие процессоры (включая Intel) программным путем. Линус был приглашен в команду разработчиков этого процессора. Как он пишет в своей книге "На самом деле я не делал в Transmeta ничего особенного. Прежде всего я занялся устранением некоторых возникших у них проблем с Linux. В компании использовалось большое количество многопроцессорных машин, работавших под Linux. Сам я никогда раньше не занимался вопросами симметричной многопроцессорной обработки под Linux, и выяснилось, что многие вещи работают вовсе не так, как ожидалось. Я воспринял это как личный вызов и, естественно, принялся все исправлять. ... Я писал и обслуживал интерпретатор х86, который мы и сегодня используем (хотя обслуживают его теперь другие). Интерпретатор по существу является составной частью программного обеспечения Transmeta: его задача брать команды Intel одну за другой и выполнять их (т.е. по-командно интерпретировать язык архитектуры 80x86). Позже я занялся другими вещами, но тогда я впервые столкнулся со странным и восхитительным миром эмуляции аппаратных средств."
Таким образом, работая в Transmeta, Торвальдс продолжал уделять свое время и работам по развитию ядра Linux. Но только теперь он уже не являлся единственным разработчиком ядра, его основной задачей стало управление развитем ядра. О том, как он это делает, сам Торвальдс рассказывает следующим образом:
“Я управляю ядром Linux, которое лежит в основе всего, потому что до сих пор все связанные с Linux люди доверяют мне больше, чем кому-либо другому. Управляя проектом с сотнями тысяч разработчиков, я действую точно так же, как в студенческие времена: никому ничего не поручаю, а просто жду, пока кто-нибудь сам вызовется. Это началось с того, что я сложил с себя менее интересные обязанности, например, составление кода пользовательского уровня. Нашлись добровольцы, которые взяли на себя отдельные подсистемы. Ко мне все попадает через этих руководителей подсистем. Я утверждаю или отвергаю их работу, но по большей части позволяю событиям идти своим путем. Если два человека ведут сходные направления, то я принимаю работу обоих, чтобы посмотреть, чья начнет использоваться. Иногда используются обе, но они начинают развиваться в разные стороны. Однажды между двумя людьми была сильная конкуренция: каждый из них настаивал на том, чтобы были использованы его заплатки, которые конфликтовали с заплатками соперника. Я перестал принимать заплатки от обоих, пока один из разработчиков не потерял интерес. Так поступил бы царь Соломон, если бы руководил детским садом.”
|
|
|
Рис. 9. Линус Торвальдс с семьей. |
По признанию Торвальдса, в Transmeta ему создали прекрасные условия для работы над ядром, но из-за этого он часто ощущал неловкость: на Linux он тратил больше рабочего времени, чем на исполнение прямых служебных обязанностей. “Как ни смешно, хотя мой стиль управления Linux заслужил высокую оценку прессы, в Transmeta в роли менеджера я потерпел полное фиаско. На короткое время меня было назначили руководителем группы разработчиков. Но я не справился. Каждый, кто побывал в помойке моего кабинета, знает, что я совершенно безалаберный человек. Мне было трудно сладить с еженедельными собраниями, составлением отчетов, повседневным руководством. Через три месяца стало очевидно, что мой стиль работы совершенно не идет на пользу Transmeta, несмотря на все дифирамбы, которые напели журналисты о моем управлении Linux.“
Поэтому 16 июня 2003 года Линус Торвальдс объявил о своем уходе из компании Transmeta (в ней он проработал более шести лет) и переходе на работу в Лабораторию разработок с открытым кодом (Open-Source Development Laboratory – OSDL). OSDL представляет собой некоммерческую организацию, созданную консорциумом, состоящим из ряда крупных компьютерных компаний. В их число, среди прочих, входят IBM, Intel, Fujitsu, Hitachi, NEC и HP. Позже к ним присоединилась и Novell. Главной служебной обязанностью Торвальдса в ODSL является совершенствование Linux. В заявлении Торвальдса, распространенном консорциумом ODSL, говорится: "Кажется немного странным, что я, наконец, буду официально работать над тем, чем занимался последние двенадцать лет, но ввиду предстоящего выпуска версии 2.6.x имеет смысл целиком сконцентрироваться на Linux. OSDL - это идеальное место для независимой от поставщиков и нейтральной разработки Linux". Компания Transmeta объявила, что отпускает Торвальдса в бессрочный отпуск, но готова принять его снова, "как только он почувствует, что его работа над Linux превращается в рутину".
В ноябре 2004 года издание CRN опубликовало список 25 лучших по их мнению руководителей 2004 года. На первом месте в этом году оказался основатель Linux Линус Торвальдс. Объясняет свой выбор CRN тем, что Линус успешно руководит разработкой ядра операционной системы последние 15 лет. За эти годы Linux приобрела множество новых качеств и завоевала обширную аудиторию. Особенно отмечается тот факт, что за последний год разработка Linux сильно продвинулась вперед. Столь быстрое развитие ядра ветви 2.6 отчасти объясняется тем, что Линус в прошлом году покинул Transmeta, где разработка ядра не была его прямой обязанностью, и теперь работает в Open Source Development Labs (OSDL).
Дальнейшее развитие ядра
|
|
|
Рис. 10. Образование 2-х веток ядра |
Новые версии в стабильной ветке ядра появлялись сравнительно редко, только после тщательной отладки, а в экспериментальной ветке - значительно чаще. Например, выход версии 1.0.9 состоялся только через полгода после 1.0, а версия 1.1.0 претерпела более 50 изменений за первые 10 месяцев. Наконец, после выхода версии 1.1.60 в экспериментальной ветке была выпущена стабильная версия 1.2.0. Одновременно ее двойник под номером 1.3.0 дал начало новой экспериментальной ветке (см. рис. 10).
Одной из главных проблем, которые стояли перед разработчиками Linux на первых этапах ее развития, было обеспечение поддержки широкого спектра аппаратных устройств. В самых первых версиях Linux поддерживал только стандартные IDE-диски. Естественно, что такая система не могла получить широкого распространения. Начиная с версии 1.2 каждая новая версия ядра включала поддержку новых типов процессоров и новых устройств. Процесс этот проходил достаточно сложно.
Во-первых, чтобы написать и отладить драйвер устройства, необходимо это устройство иметь. Очевидно, что ни у Линуса, ни у каждого из его добровольных помощников не было в наличии различных материнских плат, сетевых и звуковых карт, IDE-контроллеров, цифровых камер, принтеров и других видов устройств, общее число которых исчисляется тысячами. К счастью, большинство драйверов устройств независимы друг от друга и взаимодействуют с ядром операционной системы через строго определенные интерфейсы. Поэтому довольно легко можно написать драйвер устройства, не вникая во все сложности операционной системы. Это как нельзя лучше соответствовало той модели распределенной разработки, которая сложилась в ходе развития Linux. Разработчики ядра освобождены от необходимости заниматься разработкой драйверов и имеют возможность сосредоточится на обеспечении функциональности собственно ядра, возложив разработку драйверов на плечи тех независимых разработчиков, у которых соответствующее устройство имеются, и которые непосредственно заинтересованы в разработке драйвера для него.
Но такая модель тоже не лишена своих проблем. Когда новое устройство появляется на рынке, проходит несколько месяцев, пока какой-то программист удосужится написать для него драйвер. А производители устройств не были заинтересованы выпускать драйверы своих устройств под Linux, пока эта ОС еще не получила достаточно широкого распространения. Более того, для создания независимым программистом драйвера какого-то устройства, как правило, необходимо, чтобы были опубликованы спецификации этого оборудования, данные об интерфейсах и т.п.. На первых этапах существования Linux не все производители публиковали эту информацию, поскольку не считали нужным обеспечивать поддержку своего оборудования в системе Linux. Разработчики Linux даже вынуждены были создавать специальные списки устройств, с которыми могла работать эта система. Однако по мере того, как Linux приобретал все больше и больше сторонников, ситуация менялась и большинство фирм-производителей не только предоставляют необходимые данные разработчикам, но и сами разрабатывают драйверы устройств под Linux. Поэтому в наши дни Linux обеспечивает работу со всем спектром производимых аппаратных средств.
Поскольку число различных аппаратных устройств очень велико, драйверы устройств составляют бОльшую часть объема программного кода в Linux. Основные функции ядра, типа организации многозадачного режима или управления памятью, реализуются сравнительно небольшими частями программ. И если, с одной стороны, поддержка широкого диапазона аппаратных средств и платформ является в настоящее время одной из сильных сторон ОС Linux, то, с другой стороны, непосредственным следствием включения драйверов различных устройств является рост объема программного кода ядра. В таблице 3 показано, как происходил этот рост.
Таблица 3. Развитие ядра Linux
|
Версия |
Дата выхода |
Объем кода |
Новые свойства |
|---|---|---|---|
|
0.01 |
|
8400 строк |
|
|
1.0 |
|
170 000 строк |
|
|
1.2.x |
Март 1995 |
250 тысяч строк |
|
|
1.4 |
|
|
|
|
2.0 |
июнь 1996 |
|
Поддержка множества новых архитектур, но что наиболее важно, это была первая версия, которая поддерживала многопроцессорные машины (SMP - symmetrical multiprocessing). |
|
2.2 |
январь 1999 |
|
Существенно повышена производительность на многопроцессорных машинах и снова расширен диапазон поддерживаемых аппаратных средств. |
|
2.4 |
январь 2001 |
>3 000 000 строк |
|
|
2.6 |
15 декабря 2003 |
|
В этой версии ядра изменений так много, что первоначально даже поговаривали, будто номер его будет версия 3.0, а не 2.6. Это действительно продукт совсем иного качества, и это даже не шаг, а прыжок вперед. Подробнее о всех изменениях в этой версии можно прочитать в следующих статьях:
|
Кроме поддержки различных устройств большая работа была проделана по переносу Linux на различные аппаратные платформы, Alpha, Mac, PowerPC и даже на наладонные компьютеры Впрочем, этому процессу будет посвящен отдельный раздел настоящего обзора, поэтому сейчас на этом не будем задерживаться.
В наши дни, как только появляется новое устройство, ядро Linux дорабатывается с целью обеспечить поддержку этого устройства. Например, через несколько недель после того, как фирма Intel выпустила микропроцессор Xeon® в ядро Linux были внесены необходимые изменения для его поддержки.
Распределение полномочий
Первоначально поддержку ядра осуществлял единолично Линус Торвальдс. Но со временем он делегировал часть полномочий по поддержке не самых последних стабильных версий ядра другим лицам. Сам же он сосредоточился на руководстве разработкой самой последней версии ядра.
Сказанное не означает, что все новые функции и доработки вносятся только самим Торвальдсом. Другие разработчики могут выпускать свои версии ядра в экспериментальной ветке. Такие версии помечаются особо, например, версии от Алана Кокса обозначаются примерно так: 2.5.32-ac3. Такие версии служат для отработки самых новых драйверов устройств, опробования каких-то особенностей, предлагаемых независимыми разработчиками. Сам Линус достаточно консервативен и включает в официальные версии ядра только те изменения и дополнения, которые прошли основательную обкатку в экспериментальной ветке.
Приведу краткие справки о некоторых основных помощниках Линуса Торвальдса (в пределах того, что мне встретилось в Интернете).
|
|
|
Рис. 11. Алан Кокс |
Алан Кокс занимался поддержкой версий 2.0.34/35/36, 2.2.x, 2.4.x вплоть до версии 2.4.17, которая была выпущена уже Марселло Тосатти. Кроме того, он занимался разработкой сетевой подсистемы для версии 2.0, портированием Linux на Mac68K и SGI, программами видеозахвата и многими другими вещами.
Питер Анвин (Peter Anvin) принимал участие в развитии Linux практически с момента зарождения этой ОС. Когда Линус Торвальдс купил за 3500 долларов свой первый компьютер, на котором он начал разрабатывать ядро Linux, новейший по тем временам PC с 4 мегабайтами ОЗУ и тактовой частотой 33 мегагерца, он не мог его сразу оплатить и взял в кредит, планируя выплатить его стоимость в течение трех лет. Но уже через год, когда ядро Linux начало развиваться и образовалось сообщество пользователей, именно Питер организовал сбор средств, собрал 3000 долларов и выплатил кредит.
Позже, когда Линус окончил университет в Хельсинки, Питер убедил его отправиться в Калифорнию, работать в компании Трансмета, в которой сам Питер работал уже около года. Примерно в это время родилась идея создания архива версий ядра Linux kernel.org, который Питер и поддерживает до настоящего времени.
Ричард Гуч (Richard E. Gooch) создал множество разных утилит и патчей ядра, включая MTRR, devfs и fastpoll.
Дэвид Миллер (David S. Miller) занимался портированием Linux на 32-битовые и 64-битовые Sparc-платформы, а также на процессоры MIPS. Он также разрабатывал поддержку IP-сетей в ядре и занимался проблемами производительности и масштабируемости.
Теодор Тсо (Theodore Y. T'so) в течение многих лет писал, переписывал и поддерживал управление заданиями, терминальный драйвер, драйвер последовательного порта, поддержку виртуальных дисков, e2fsck/e2fsprogs и других частей кода ядра и различных утилит. Он является членом технического комитета (Technical Board) в Linux International, а также членом Internet Engineering Task Force, где он входит в директорат безопасности (Security Area Directorate). Его основная работа в MIT связана с разработкой протокола Kerberos и других вопросов сетевой безопасности и информационной архитектуры.
Роджер Вольф (Roger Wolff) зарабатывает себе на жизнь написанием драйверов устройств для Linux.
|
|
|
Рис. 12. Эндрю Мортон |
Мортон является пользователем Linux примерно с 1994 года. В марте 2000 года он предложил свой первый патч к ядру 2.3.47, который однако был отвергнут Аланом Коксом как "устаревший". Но это не обескуражило Мортона, и вскоре он отправил Торвальдсу еще один патч объемом 2,500 строк кода. К настоящему времени его вклад включает множество компонент ядра, включая файловую систему ext3 для ядра 2.4 и патч, обеспечивающий малое время отклика системы на запросы.
Рик ван Риэль (Rik van Riel) разработал подсистему управления памятью и планировщик задач. Он является также основателем kernelnewbies.org. Рик родился в 1978 году, на северо-востоке Нидерландов в семье фермера. На самостоятельно заработанные деньги он купил себе компьютер, поработал под MS-DOS и OS/2, а когда в 1994 году приобрел 486-ой, установил себе Linux. В начале 2000 года он поступил на работу в фирму Conectiva, самую большую Linux-компанию в Южной Америке и перебрался в Бразилию.
|
|
|
Рис. 13. Марсело Тосатти |
Инго Молнар (Ingo Molnar) работает над развитием ядра с 1995 года. Перечень сделанных им доработок впечатляющ. Из последних его разработок можно отметить новый планировщик задач, который включен в экспериментальное ядро 2.5, и доработки в части управления потоками (the handling of threads). Он разрабатывал также поддержку программных RAID-массивов и встроенные в ядро Web- и FTP-серверы.
Мигуэль де Иказа (Miguel de Icaza) был одним из первых разработчиков Midnight Commander (еще в 1992 году). Вместе с Дэвидом Миллером (David Miller) он портировал Linux на SPARC. Затем он занимался разработкой драйверов для Linux RAID, Вместе с Федерико Мена (Federico Mena), который разработал GIMP, Мигуэль начал проект GNOME, первая версия которого вышла в августе 1997 года. Следующим летом он разработал Gnumeric. Позже они вместе с тем же Ф.Мена организовали компанию Ximian, которая впоследствии была приобретена Novell. Мигуэль участвовал в разработке клиента электронной почты Evolution, а в последнее время работает над проектом Mono.
Дэвид Вейнхолл (David Weinehall) поддерживает версию 2.0 ядра. Алан Кокс передал ему поддержку ветки 2.0 более 4 лет назад. Как рассказывает сам Дэвид: "В декабре 1999 года обнаружилась досадная ошибка в ядре версии 2.0, которая приводила к тому, что локальный пользователь мог "обрушить" систему. Алан Кокс признался, что у него нет времени на поддержку ядра версии 2.0, и сказал мне, что если я хочу заняться поддержкой ветки 2.0 и устранить эту ошибку (и еще некоторые), он будет только рад."
Андреа Арканджели (Andrea Arcangeli) известен тем, что он полностью переписал систему управлению памяти в ядре 2.4. Многие были удивлены, когда Линус Торвальдс включил ее в версию 2.4.10 ядра, но с тех пор новая подсистема управления памяти полностью доказала правильность этого решения. Андреа живет в Италии и работает на SUSE.
Расти Рассел (Rusty Russell) живет в Австралии, работает в Технологическом Центре IBM по Linux. Он известен своим остроумием и интересными выступлениями на встречах сторонников Linux. Рассел написал программы ipchains и netfilter/iptables, полностью переписал встроенный в ядро загрузчик модулей, а также внес множество других усовершенствований в ядро ветки 2.6.
В интервью CNET News.com в июле 2003 года Линус Торвальдс так
ответил на вопрос "Кто ваши главные заместители?":
"Со
временем они меняются, и обычно это зависит от подсистемы. Например,
за последний год это были Эндрю Мортон (виртуальная память,
взаимодействие с файловой системой, "родовой" код), Дэвид
Миллер (сетевые дела), Грег Кроу-Хартман (USB, горячее подключение к
PCI), Джефф Гарзик (драйверы сетевых устройств), Дженс Эксбоу (block
device layer), Дейв Джонс (AGP и clean-ups), Кай Гермашевски (build
infrastructure и ISDN), Пэт Мочел (инфраструктура менеджера устройств
и sysfs), Расселл Кинг (PCMCIA и ARM), Расти Расселл (cleanups и
управление модулями) и Эл Вайроу (файловые системы).
И это не
считая мейнтейнеров архитектуры, управляющих своими собственными
архитектурами (Itanium, PowerPC и AMD64), и других, кого я, возможно,
просто упустил. А есть еще люди, занимающиеся очень специфическими
системами: Роланд Макграт и Инго Молнар, которые работают над кодом
управления сигналами и потоками.
Но со временем состав меняется.
Люди приходят и уходят - первые месяцы некоторые бывают очень
активны, потом на какое-то время исчезают, затем возвращаются."
В том же интервью Линус говорит, что почти всем ценным участникам проекта работа над Linux оплачивается в той или иной форме. Мало кто из разработчиков получает деньги с самого начала, но, проявив себя, они без труда находят компании, которые платят за работу над Linux. Например, Эндрю Мортон, назначенный "мейнтейнером" или ответственным за ядро 2.6 вслед за Торвальдсом пришел работать в OSDL.
В начале мая 2005 года глава Open Source Development Labs (это там где Линус Торвальдс сейчас работает) Стюарт Коен (Stuart Cohen) заявил, что миф о том, что Linux развивается усилиями тысяч добровольцев и вольных хакеров, давным давно не верен и уже давно разработка ведется профессионалами. Цитата: “Глядя сегодня на 25 ведущих разработчиков ядра, вы увидите, что более 90% из них наняты на полную ставку для этого в таких компаниях как HP, IBM, Intel, Novell, Oracle, Red Hat, Veritas и других. Причем процесс, которому они следуют, разрабатывая Linux, выглядит практически идентично тому, как остальные сотрудники этих корпораций разрабатывают другие программные проекты, хотя и с важными отличиями.” Далее он пишет, что важным отличием является лишь то, что процесс разработки является открытым. Однако, никаких любителей в этом процессе уже нет. Более того, теперь все разработчики должны идентифицировать свою работу и анонимный код больше не принимается. Да и сам Торвальдс давно уже предпочитает работать с профи. Не делайте ошибки - Линукс делают профессионалы, заключает С.Коэн.
Tux - эмблема Linux
|
|
|
Рис. 14. Tux - эмблема |
|
|
|
Рис. 15. Альтернативный |
В начале 1996 года в листе рассылки linux-kernel mailing list несколько человек предложили выбрать логотип для Linux. В ответ было предложено множество разных вариантов такого логотипа. Предлагалось, например, использовать изображения таких благородных животных как акулы или орлы. В процессе обсуждения Линус Торвальдс вскользь упомянул, что ему нравятся пингвины. Это практически сразу прекратило дебаты и появились несколько вариантов изображения пингвина в разных позах, в том числе был предложен пингвин, держащий земной шар. На это Линус в письме от 9 мая 1996 года возразил, что "бедный пингвин не так силен, чтобы удержать земной шар, он пожалуй будет раздавлен... Так что если вы думаете о "пингвине", вы должны представлять себе слегка растолстевшего сидящего пингвина, хорошо поевшего и отрыгнувшего. Он сидит с довольной улыбкой - мир кажется прекрасным, если вы только что съели несколько галлонов свежей рыбы...".
Был объявлен конкурс на лучшее изображение пингвина и победителем был признан рисунок Ларри Ивинга (Larry Ewing) - графика, работавшего в Институте научных вычислений университета А&М в Техасе. Как писал Ларри, первый вариант этого рисунка был сделан с помощью программы GIMP (The GNU Image Manipulation Program). Вы можете найти описание того, как создавался этот образ на сайте Ларри. Линус хотел, чтобы у пингвиненка был счастливый вид и, главное, чтобы пингвин был узнаваемым. Поэтому, хотя у всех остальных пингвинов клювы и ласты черные, у талисмана Linux они оранжевые, как будто папа этого пингвина был селезнем.
Не все линуксоиды сразу согласились с выбором пингвина в качестве эмблемы Linux, например Алан Маккей предлагал альтернативный символ - лисенка, изображенного на рис. 15. И у этого варианта были свои сторонники, но в конце концов Такс завоевал всеобщее признание.
Имя Такс происходит от американского слова tuxedo, означающего "смокинг", - ведь пингвины как будто одеты в смокинги. Впрочем, есть и другой вариант объяснения этого слова: (T)orvalds (U)ni(X) --> TUX!
Между прочим, несколько английских линуксоидов во главе с Аланом Коксом к одному из дней рождения подарили Линусу Торвальдсу живого пингвина, который живет в настоящее время в зоопарке города Бристоль.
Подробнее об эмблеме, символе Linux, пингвине Такс, вы можете прочитать на посвященной ему страничке: http://www.sjbaker.org/tux/.
Дистрибутивостроение
В разделе о первых дистрибутивах было сказано, что к моменту выхода первой версии ядра Linux уже были выпущены несколько дистрибутивов: Debian, MCC, Slackware, Software Landing Systems (SLS), SUSE, TAMU, Yggdrasil. Основным способом распространения этих дистрибутивов были комплекты дискет. Интернет тогда только начинался, тем не менее все производители дистрибутивов уже тогда размещали дистрибутивы и на ftp-сайтах, а также на досках объявлений. Это был второй способ распространения Linux: пользователям надо было скачать всего около 50 МБайт (правда, через модем!).
Вскоре появился и третий, наиболее перспективный способ распространения Linux - на CD-ROM. По крайней мере 4 компании начали поставлять дистрибутивы на отдельном CD-ROM. Естественно, при этом появилась возможность добавить в дистрибутив массу дополнительных программ и документации, например, систему X-Window, исходные коды программ, архивы документации с Интернет-сайтов, программное обеспечение от независимых производителей и многое другое. Первыми компаниями, которые начали выпускать дистрибутивы на CD, были: InfoMagic, Morse Telecommunication, Nascent, Red Hat Software, Trans-Ameritech, Walnut Creek и Yggdrasil Computing, Inc. Эти диски продавались по цене от 20 до 40 долларов. В сравнении со стоимостью дистрибутива на дискетах, который стоил 20 долларов, это было не дорого (правда, односкоростной дисковод для CD-дисков стоил еще 100 долларов, но ведь установка Linux была не единственным поводом для его покупки).
Стоит отметить, что нумерация дистрибутивов не была никак связана с нумерацией версий ядра. Например, версия дистрибутива могла иметь вид "the Fall 1993 release" или "the 2.0 release", хотя еще не было выпущено даже ядро версии 1.0. Иногда это приводило к некоторой путанице.
Самым широко известным из Linux-дистрибутивов является дистрибутив Red Hat Linux, выпускаемый одноименной компанией. Фирма Red Hat была основана Марком Ивингом (Marc Ewing), а в 1995 году была куплена фирмой ACC Bookstores, принадлежавшей Бобу Янгу (Bob Young). В течение следующего десятилетия, выпуская одну версию своего дистрибутива за другой, компания заработала для своих продуктов репутацию хорошей основы для создания разного рода серверов, легко устанавливающихся и обладающих неплохим набором инструментов для конфигурирования. Red Hat - это самая известная и самая большая из компаний, чей бизнес полностью основан на Linux. Это первый из производителей дистрибутивов, акции которого котируются на бирже, и одна из немногих компаний, которой удалось достичь успеха в бизнесе на основе Linux. На примере ее дистрибутивов можно проследить, как шло развитие дистрибутивов вообще.
Первый публичный релиз Red Hat Linux появился чуть позже выхода дистрибутива Slackware, но задолго до того, как Linux получил сколь-нибудь широкое распространение. Хронология выхода дистрибутивов Red Hat приведена в следующей таблице, заимствованной с сайта fedora.redhat.com (источник):
Таблица 4. Хронология выхода дистрибутивов Red Hat.
|
Дата |
Версия (условное имя) |
Описание |
|---|---|---|
|
29 июля 1994 |
без номера (предварительная бета-версия) |
Первоначальная тестовая версия, широко не распространявшаяся, построенная на системе управления пакетами RPP, разработанной в Red Hat. В прилагаемой документации эта версия называлась "Red Hat Software Linux" и поставлялась на одном CD с красной наклейкой (with an unmarked solid red label). В прилагаемом к CD сопроводительной записке выражалась благодарность за покупку бета-версии. Записка была подписана Марком Ивингом, основателем Red Hat и Дэмиэном Нейлом (Damien Neil), первым сотрудником Red Hat. Эта версия была построена на ядре версии 1.1.18 из экспериментальной ветки. |
|
31 октября 1994 |
RHL 0.9 (Halloween) |
Первая широко доступная бета-версия Red Hat Linux.
Продавалась все еще как бета, но уже с документацией.
Пользователям предоставлялись на выбор два варианта ядра:
стабильное 1.0.9 или экспериментальное 1.1.54. В руководстве
предлагалось вместо программы управления пакетами rpp
использовать LIM (Linux Installation Manager) - графический
интерфейс к этой программе, построенный на основе Tcl/Tk. |
|
май 1995 |
RHL 1.0 (Mother's Day) |
Первая версия, не имевшая статуса бета. Построена на основе ядра 1.2.8. Название "Red Hat Software Linux" было заменено на "Red Hat Commercial Linux", а в качестве логотипа был изображен быстро идущий мужчина, в одной руке несущий портфель, а второй рукой держащийся за красную шляпу. Версия 1.0 была выпущена уже после того, как ACC Bookstores (Bob Young) купила Red Hat Software, Inc. |
|
Конец лета 1995 |
RHL 2.0 beta |
Первая версия, в которой для библиотек и исполняемых файлов использован формат ELF; предыдущие версии использовали формат "a.out". Это была также первая версия, в которой использована система управления пакетами RPM. Следствием этого стала несовместимость с более ранними версиями. Эта версия RPM в целях ускорения разработки была написана на Perl. |
|
20 сентября 1995 |
RHL 2.0 |
Первая официальная версия, использующая RPM. |
|
23 ноября 1995 |
RHL 2.1 |
Версия, исправлявшая ошибки предыдущей. Но на основе ее Digital создала диск под названием "Red Hat 2.1 LiNUX" для платформы x86, послуживший прообразом для создания аналогичного продукта для платформы Alpha; "Red Hat Linux/Alpha 2.1" был выпущен в январе 1996. Включала версии 1.2.13 (стабильное) и 1.3.32 (экспериментальное) ядра. |
|
March 15 1996 |
RHL 3.0.3 (Picasso) |
Инженеры намеревались обозначить этот релиз как
"2.2", но маркетологи (т.е. Боб Янг) решили, что он
будет продаваться успешнее, если дать ему номер "3.0.3".
Это была первая много-платформенная версия: поддерживалась
архитектура тогдашней Digital Alpha. Для бинарных файлов на Alpha
использовался формат a.out, потому что стандарт ELF для Alpha еще
не был принят; для Alpha отсутствовали также разделяемые
библиотеки. |
|
июль-август 1996 |
RHL 3.0.4/3.95 (Rembrandt) |
RPM переписан на C; впервые применен PAM (Pluggable Authentication Modules); новые средства конфигурирования, написанные на Python с TkInter вместо TCL/TK. Благодаря переходу на ядро ветки 2.0 стало возможно использование модулей ядра; до этого существовало 72 различных варианта ядра из которых пользователь должен был выбрать наиболее соответствующее его аппаратуре. Теперь разные аппаратные конфигурации обслуживались путем загрузки соответствующих модулей. |
|
3 октября 1996 |
RHL 4.0 (Colgate) |
Основана на ядре 2.0.18. Поддерживаются три
архитектуры: x86, Alpha и SPARC. На Alpha стало возможным
использование формата бинарных файлов ELF, поскольку был принят
стандарт и разработаны соответствующие инструменты. Впервые
документация к дистрибутиву в электронном виде стала
общедоступной. Логотип дистрибутива изменен на тот, который
применяется до настоящего времени - Shadowman™
|
|
3 февраля 1997 |
RHL 4.1 (Vanderbilt) |
Версия, содержащая в основном исправления ошибок. Ядро 2.0.27. |
|
19 мая 1997 |
RHL 4.2 (Biltmore) |
Продолжалось использование слегка устаревшей версии библиотеки libc (5.3) вместо более новой версии 5.4, из-за некоторой нестабильности и несовместимости новой версии. Как показали дальнейшие события, это решение было полностью оправданным, поскольку те дистрибутивы, которые поспешно перешли на libc 5.4, были завалены потоком сообщений об ошибках. Последняя версия, с которой поставлялся веб-браузер Red Baron, в котором обнаружилась масса ошибок. |
|
27 августа - 16 сентября 1997 |
RHL 4.8/4.8.1/4.95 (Thunderbird) |
Первая версия, использовавшая glibc 2.0. |
|
7 - 16 октября 1997 |
RHL 4.9/4.9.1/4.96 (Mustang) |
В этой серии бета-выпусков была сделана масса изменений, связанных со сменой версий C-библиотек. |
|
1 декабря 1997 |
RHL 5.0 (Hurricane) |
Первый релиз, который включал программу резервного копирования BRU2000-PE™ и программное обеспечение сервера и клиента для Real Audio ™ в качестве проприетарных компонент. |
|
1 июня 1998 |
RHL 5.1 (Manhattan) |
Первый выпуск Linux Applications CD, диска с проприетарными приложениями от третьих компаний. Некоторые части GNOME были включены в основной дистрибутив для обеспечения работы нескольких приложений, а предварительная версия GNOME была представлена в отдельном каталоге (но она не устанавливалась в процессе инсталляции). Первый выпуск, который использовал linuxconf как единое конфигурационное средство. Впервые в дистрибутив был включен проприетарный браузер Netscape. Последняя версия, которая размещалась на одном CD; после этого объем ПО стал таким, что уже не помещался на одном диске. |
|
12 октября 1998 |
RHL 5.2 (Apollo) |
Предварительная версия (Technology preview) GNOME включена в виде отдельного каталога. |
|
17 марта 1999 |
RHL 5.9 (Starbuck) |
- |
|
19 апреля 1999 |
RHL 6.0 (Hedwig) |
glibc 2.1, egcs, ядро 2.2, GNOME интегрирована в дистрибутив. |
|
6 сентября 1999 |
RHL 6.0.50 (Lorax) |
Первая бета-версия с графической программой инсталляции (anaconda); инсталлятор, как в текстовом, так и в графическом режиме, был полностью переписан на Python. |
|
4 октября 1999 |
RHL 6.1 (Cartman) |
- |
|
27 марта 2000 |
RHL 6.2 (Zoot) |
Первая версия, ISO-образы которой были выложены для скачивания по FTP. |
|
25 сентября 2000 |
RHL 7.0 (Guinness) |
Хотя ядро 2.4 к этому моменту еще не появилось,
было решено выпустить новую версию, потому что вышла библиотека
glibc 2.2, которая с точки зрения пользователя, пожалуй, даже
больше ядра влияет на систему. Версия 7.0 была также первой
версией, которая обеспечивала поддержку Red Hat Network сразу
после установки. |
|
31 января 2001 |
RHL 7.0.90 (Fisher) |
Переход на ядро 2.4. |
|
16 апреля 2001 |
RHL 7.1 (Seawolf) |
Первый релиз, включавший одновременную поддержку многих языков (включая китайский, японский и корейский). Его выпуск существенно задерживался и сроки были почти выдержаны только благодаря героическим усилиям части сотрудников, сумевших решить сложную проблему потери данных ядром. Это была также первая версия, поставлявшаяся с браузером Mozilla. |
|
2-21 августа 2001 |
RHL 7.1.93, 7.1.94 (Roswell) |
Файловой системой, используемой по умолчанию, стала журналируемая файловая система ext3, причем инсталлятор в процессе установки предлагал преобразовать разделы с ext2 в ext3. Grub заменил LILO в качестве используемого по умолчанию менеджера загрузки. |
|
22 октября 2001 |
RHL 7.2 (Enigma) |
GNOME 1.4, KDE 2.2. Эта версия стала базисом для разработки дистрибутива Red Hat Enterprise Linux 2.1 AS (который первоначально назывался Red Hat Advanced Server 2.1) |
|
22 марта 2002 |
RHL 7.2.91 (Skipjack) |
Несмотря на то, что фирма Red Hat всегда заявляла, что не существует формально определенного порядка нумерации версий и нигде не обещала, что всегда будут выпускаться версии ".0", ".1" и ".2", тем не менее этот порядок соблюдался при выпуске 4-х, 5-х, 6-х и 7-х версий. Первоначально выход версии 7.3 не планировался, однако сложилась такая ситуация, когда новые версии gcc3, GTK+ 2, Python2 и других программ не успевали к запланированному сроку выпуска Red Hat Linux 8.0. Поэтому было принято решение исключить из системы все эти новые разработки, перекомпилировать все на старой версии компилятора и выпустить версию ".3". |
|
6 мая 2002 |
RHL 7.3 (Valhalla) |
Последняя версия, включавшая проприетарный браузер от Netscape. |
|
6 мая 2002 |
RHEL 2.1 AS (Pensacola) |
Red Hat Enterprise Linux 2.1 AS (первоначально выпущенный под названием Red Hat Linux Advanced Server 2.1) - это первая версия Red Hat, ориентированная на корпоративное применение. Основой для ее разработки служила версия 7.2, но были включены некоторые наработки из версии 7.3. |
|
30 сентября 2002 |
RHL 8.0 (Psyche) |
В этот выпуск было включено очень много новых разработок: gcc 3.2, glibc 2.3 release candidate (официально одобренный главным разработчиком!), OpenOffice.org 1.0.1, GNOME 2, KDE 3.0.3. В эту версию была впервые включена тема рабочего стола Bluecurve™, которая имела большой успех у пользователей. |
|
31 марта 2003 |
RHL 9 (Shrike) |
Эта версия ознаменовала изменение политики фирмы в
отношении построения дистрибутивов. Если ранее Red Hat
обеспечивала как прямую, так и обратную совместимость
программного обеспечения, то теперь решила, что не будет
обеспечивать возможность запуска новых версий ПО на старых
версиях дистрибутива. |
|
21 июля 2003 |
RHL 9.0.93 (Severn) |
Последняя версия, носившая имя Red Hat Linux; далее разработка разветвилась на RHEL и FC. |
|
25 сентября 2003 |
FC 0.94 (Severn) |
Через неделю после того, как Red Hat объявила, что процесс разработки некоммерческой ветки теперь будет вестись сообществом независимых разработчиков, в рамках проекта Fedora, вышла переименованная версия: Fedora Core 1 test 2, version 0.94. Это был первый тестовый релиз, включавший патч, обеспечивающий улучшенную безопасность. |
|
13 октября 2003 |
FC 0.95 (Severn) |
Первая версия, использующая репозиторий yum для обновления системы. |
|
22 октября 2003 |
RHEL 3 (Taroon) |
Red Hat Enterprise Linux 3 был первой версией, работавшей одновременно на 7 архитектурах: Intel X86, Intel Itanium, AMD AMD64, IBM zSeries, IBM iSeries, IBM pSeries и IBM S/390. Включала множество новых свойств и особенностей, например, ACL. Построена на основе GCC 3.2, ядра Linux 2.4.21, glibc 2.3.2 |
|
5 ноября 2003 |
FC 1 (Yarrow) |
Первая версия Fedora Core и последняя версия на основе ядра 2.4. |
|
12 февраля; |
FC 1.90, 1.91, 1.92 |
Первые версии на основе ядра 2.6, одновременно работавшие на x86 и x86-64. |
|
5 марта 2004 |
FC 1 (Yarrow) |
Fedora Core 1 для x86-64; выпущена благодаря усилиям Джастина Форбса (Justin Forbes). |
|
18 мая 2004 |
FC 2 (Tettnang) |
Второй релиз Fedora Core; ядро 2.6, KDE 3.2, GNOME 2.6. |
|
8 ноября 2004 |
FC 3 (Heidelberg) |
Третий релиз Fedora Core. Включала GNOME 2.8 и KDE 3.3. |
.
В дистрибутив в качестве дополнительного пакета включен браузер
"Red Baron", распространявшийся на коммерческой основе.22 сентября 2003 года фирма объявила о разделении своих продуктов на две линейки: полностью открытый и свободный проект Fedora Core и коммерческий, предназначенный для использования корпорациями, Red Hat Enterprise Linux (RHEL). Это решение вызвало противоречивые отклики в рядах сторонников Linux. Некоторые посчитали, что Red Hat полностью переориентировалась на корпоративные применения и бросила индивидуальных пользователей на произвол судьбы. Однако время показало, что ничего страшного не произошло, индивидуалы успешно перешли на Fedora Core (или другие дистрибутивы), а фирма Red Hat продолжает оказывать материальную поддержку проекту Fedora Core. И в материальном плане фирма от такого разделения только выиграла - ее доходы в первое время только возросли. Но в первом квартале 2005 года появились сообщения о том, что некоторые корпорации вместо приобретения Enterprise Linux стали использовать на корпоративных серверах Fedora Core.
Red Hat - это только один (пусть и один из самых заметных) из огромного числа дистрибутивов, появившихся за эти годы. Как пишут в своих воспоминаниях многие разработчики дистрибутивов, они занялись созданием собственного дистрибутива потому, что их не устраивали те системы, которыми они пользовались. А поскольку такая неудовлетворенность естественно возникает у многих людей с творческой жилкой, число новых дистрибутивов постоянно растет. По состоянию на 14 января 2005 года сайт DistroWatch.com (на котором ведется учет разных дистрибутивов) насчитывал 373 дистрибутива. Поддержка некоторых из них уже прекращена, но все же еще более 300 разработок были “живы”. Только за 2004 год появилось более сотни новых дистрибутивов. И это еще не конец, потому что чуть ли не ежедневно появляются новые и новые дистрибутивы!
Однако совершенно новые системы возникают все же очень редко - в большинстве случаев разработка начинается на основе одного из ранее существовавших дистрибутивов. Таким образом сложились несколько "родовых семейств" дистрибутивов. Основных семейств три, их основоположниками являются три старейших дистрибутива: Red Hat, Debian и Slackware. На приводимом ниже рисунке 16 приведены обобщенные данные о развитии этих "семейств". Цифры в окружностях в нижней части рисунка показывают число "потомков" основных дистрибутивов (по данным сайта DistroWatch за март 2005 года).
Рис. 16. Хронология развития основных дистрибутивов Linux.
(Перечни дистрибутивов в группах, образованных по признаку
"происхождения", приведены на сайте DistroWatch.com.)
Вполне возможно, что к настоящему времени четкой границы между разными семействами уже и не существовало бы, если бы не проблема систем управления пакетами программного обеспечения. В наше время именно здесь проходит граница, разделяющая дистрибутивы на отдельные семейства.
Наиболее известными (или распространенными) системами управления пакетами являются:
RPM/YUM — менеджер пакетов Red Hat. Сейчас аббревиатура RPM расшифровывается обычно рекурсивно (RPM = RPM Package Manager), но первоначально ее расшифровывали как менеджер пакетов Red Hat (Red Hat Package Manager), поскольку разработана она была для дистрибутива Red Hat. В настоящее время она используется и во многих других дистрибутивах.
dpkg/APT — система управления пакетами *.deb дистрибутива Debian, тоже портированная в настоящее время в другие дистрибутивы. Пакеты .deb представляют собой просто два tar-архива, сжатых с помощью gzip: в одном архиве содержится управляющая информация, в другом - данные. Стандартным средством управления такими пакетами является консольная программа dpkg, дополненная оболочкой APT (Advanced Packaging Tool).
tgz или tar.gz — стандартный набор из двух программ tar + gzip, иногда дополненный некоторыми дополнительными управляющими файлами. Используется в дистрибутиве Slackware и некоторых других, не обеспечивает разрешения зависимостей. От Source-based дистрибутивов эта система отличается тем, что внутри tar.gz-архивов находятся заранее скомпилированные программы.
система портежей дистрибутива Gentoo, которая представляет собой набор файлов ebuild, содержащих информацию о том, как получить (из любых доступных источников - сети, локального диска и т.д.), скомпилировать и установить пакет в системе Gentoo, используя консольную команду emerge. Обычно пакет ПО в этом случае содержит исходные коды программ, и приложение компилируется прямо в процессе инсталляции, за счет чего оптимизируется для конкретной машины. Хотя этим способом могут устанавливаться и заранее откомпилированные программы, но такой вариант используется только в исключительных случаях, например, при инсталляции системы на очень медленные машины.
YaST - утилита, используемая в дистрибутиве SuSE.
- Source-based дистрибутивы не имеют специальных средств управления пакетами, в них все программы компилируются из исходных кодов. Примерами таких дистрибутивов являются дистрибутивы Linux From Scratch или LFS (это даже не дистрибутив, а руководство по сборке собственного дистрибутива), Lunar, Sorcerer, Source Mage.
Еще одно различие между основными "семействами" дистрибутивов связано с используемой со способом организации и размещения сценариев (или скриптов) начальной инициализации системы. Большая часть дистрибутивов Linux использует на этапе загрузки стиль System V. К этому классу относятся Debian, все клоны Red Hat, включая Mandrake и российские дистрибутивы ASPlinux и ALT Linux. В стиле BSD организована загрузка в дистрибутиве Slackware и его производных. Однако тот или иной стиль сценариев начальной загрузки выдерживается не очень четко. Поскольку стиль System V взят за основу при создании стандарта LSB (Linux Standart Base), дистрибутивы, ранее использовавшие стиль BSD, в последнее время заботятся о совместимости с System V. Slackware обеспечивает такую совместимость начиная с версии 7.0.
Стандартизация Linux
Все увеличивающее число дистрибутивов Linux невольно заставляет задуматься о том, а приведет ли это к тому, что системы станут несовместимыми. Как было рассказано в начале настоящей заметки, Unix-войны стали в свое время серьезным препятствием на пути развития Unix-систем. Не угрожает ли аналогичная опасность и Linux? Ведь у этой системы нет единого организующего центра или разрабатывающей систему компании. Конечно, разработкой ядра руководит Линус Торвальдс, но ведь независимые разработчики не обязаны ему подчиняться, любой желающий может не только сформировать свой дистрибутив, но и создать свою версию ядра. Сообщество разработчиков Linux достаточно хорошо понимает эту опасность и предпринимает определенные усилия для выработки определенных стандартов, которые позволили бы ее избежать.
Некоей гарантией того, что подобная опасность не грозит Linux, является применение лицензии GPL и публикация исходных кодов. Развитие Unix в период Unix-войн сильно замедлилось в силу того, что конкурирующие производители тратили годы на внедрение аналогичных функций - просто потому, что у них не было доступа к базе решений, найденных другими. Независимая разработка одних и тех же функций не только стоила Unix годы, но и привела к судебным тяжбам. В Linux-сообществе ситуация принципиально иная. Исходные коды всего программного обеспечения доступны всем и отбор наиболее правильных и красивых решений происходит естественным образом. Тем не менее, очевидно, что разработка общепринятых стандартов очень полезна всему сообществу, так как позволяет упорядочить процесс разработки, договориться об общепринятых основах, не тратить силы на "тупиковые ветки".
Вообще говоря, Линус Торвальдс с самого начала придерживался в своей разработке основных стандартов, существовавших для Unix, в частности стандарта POSIX. Практически вся сетевая подсистема Linux - реализация открытых интернет-стандартов, изложенных в известных документах серии RFC. Графическая подсистема основана на стандарте X Window, который, по мнению многих экспертов, давно уже устарел, и его эффективность сомнительна - но все же это стандарт, и (кроме как для карманных компьютеров и других специфических задач) мало кто позволяет себе отойти от него.
Вероятно, одним из первых проектов стандартизации в Linux стала попытка упорядочить структуру каталогов файловой системы. Работа над этим проектом была начата в августе 1993 года. Вначале стандарт назывался проектом стандартов файловой системы - Filesystem Standarts project (FSSTND), и был ориентирован только на систему Linux. Его первая версия была выпущена 14 февраля 1994 года. Последующие редакции были выпущены 9 октября 1994 и 28 марта 1995 года. В разработке стандарта принимало участие большое количество добровольцев, но главным организатором был Дэниел Квинлан (Daniel Quinlan).
В начале 1995 года с участием сообщества разработчиков системы BSD была поставлена цель создания более общей версии FSSTND, предназначенной не только для Linux, но и для других UNIX-подобных операционных систем. В результате объединенных усилий разработка стандарта сосредоточилась на вопросах, которые являются общими для всех UNIX-подобных систем, включая операционные системы типа 4.4BSD. Учитывая расширение сферы действия стандарта, он был переименован в Filesystem Hierarchy Standard или, для краткости, FHS. Естественно, что «настоящие» UNIX-системы, созданные задолго до появления этого стандарта, ему не соответствуют. Однако FHS учитывает все положительные качества, присущие BSD и другим системам в части поддержки различных архитектур и учета требований работы в гетерогенных сетях. На момент написания этой статьи последней версией стандарта FHS является версия 2.3, которая была выпущена в августе 2004 года. Полный исходный текст этого стандарта можно найти в Интернет на сайте http://www.pathname.com/fhs/ (русский перевод версии 2.2.находится по адресу http://rus-linux.net/MyLDP/file-sys/fhs-2.2-rus/index.html).
В мае 1998 года Линус Торвальдс, Брюс Перенс (Bruce Perens) и несколько других известных сторонников систем с открытыми исходными кодами подписали декларацию о начале разработки проекта Linux Standart Base (LSB), который должен был определить набор тех компонент, которые должны присутствовать в любой "Linux-системе". Инициаторы проекта ставили амбициозную цель обеспечить в результате бинарную совместимость дистрибутивов, удовлетворяющих стандарту LSB. Под бинарной совместимостью понималось следующее:
С точки зрения пользователя: Не должно иметь значения, какой именно дистрибутив он использует. Он должен иметь возможность установить в свою систему программное обеспечение, разработанное для любого другого дистрибутива. Пакеты, соответствующие LSB, не должны зависеть ни от каких других пакетов, кроме других пакетов, соответствующих LSB.
С точки зрения поставщиков программного обеспечения (ISV): Программное обеспечение, которое сертифицировано для какой-то конкретной версии Linux, удовлетворяющей требованиям LSB, должно без проблем работать на любой другой версии системы, также удовлетворяющей LSB. Поставщик не должен зависеть от поддержки конкретным дистрибутивом.
- С точки зрения разработчика ПО: Достаточно просто писать программное обеспечение так, чтобы оно удовлетворяло требованиям LSB, и можно быть уверенным, что оно будет работать в любом дистрибутиве. Не требуется проверять его работоспособность в разных дистрибутивах.
Для того, чтобы обеспечить достижение поставленной цели, требовалось стандартизовать многие компоненты операционной системы.
- Разделяемые библиотеки (glibc, pthreads, ncurses и т.д.)
-
Различные дистрибутивы Linux используют разные системные библиотеки,
точнее разные их версии. Поэтому программа, легко инсталлируемая в
системе A, может не установиться в системе B, использующей более
раннюю версию библиотек, поскольку существует проблема "обратной
совместимости". Решение этой проблемы состоит в том, что некая
версия библиотеки объявляется стандартной и ей дается
соответствующее имя, например,
ld-lsb.so.1
Если эта библиотека будет затем включена во все дистрибутивы, претендующие на соответствие LSB, все приложения, которым эта библиотека необходима, будут работать без проблем. Это не означает, что все другие версии этой библиотеки запрещены: они тоже могут быть включены в дистрибутив, чтобы запускалось ПО, специфичное для данного дистрибутива. - Системные команды
-
Необходимо определить четкий перечень стандартных системных команд,
включающий также указание на точное размещение соответствующих
исполняемых файлов в файловой системе. Это необходимо для того,
чтобы программисты знали, какие команды они могут вызывать из своих
программ и скриптов, без риска получить сообщение об ошибке. Поэтому
LSB определяет минимальный набор системных команд (
man,cat,grepи т.д.), которые должны присутствовать во всех LSB-совместимых системах (см. обзор). - Иерархия каталогов файловой системы
- Стандартизация библиотек и системных команд не будет иметь большого смысла, если не известно, где эти библиотеки найти. Поэтому LSB включает в свой состав Filesystem Hierarchy Standard (FHS), благодаря чему авторы других программ и скриптов знают, где размещены соответствующие файлы.
- Системные и инициализационные скрипты и процесс начальной инициализации системы
- Поставщикам программного обеспечения нужно многое знать о системе еще до того, как она полностью загрузилась. Поставщики больших баз данных, например, должны знать, на каком этапе загрузки становятся доступны основные базовые сервисы (например, сетевые службы). Поэтому LSB определяет также то, как должны быть структурированы инициализационные файлы, в какой последовательности они вызываются и где они хранятся в системе.
- Реализация стандарта POSIX.1 (+ glibc Extensions)
- Для того, чтобы программисты, пишущие приложения для Linux, знали какие функции им доступны, LSB использует стандарт POSIX (Portable Operating System Interface), являющийся одним из самых важных стандартов для UNIX и UNIX-подобных систем.
- Сокеты
- Linux с самого своего возникновения был системой, предназначенной для работы в сети. Поэтому LSB также определяет механизмы, с помощью которых система взаимодействует с Интернет и сетями. Впрочем, в этом вопросе LSB в основном следует существующим стандартам.
- X11
- Многие, хотя и не все приложения нуждаются в графическом интерфейсе. Размер графических приложений существенно увеличивается, если все необходимые библиотеки скомпилированы статически. LSB стандартизует протоколы нижнего уровня для того, чтобы управлять этим феноменом. На более высоких уровнях программисты могут делать все, что они хотят.
- Основы процедур установки ПО
- Использование унифицированого формата пакетов ПО - еще один предмет рассмотрения для LSB. Принятый LSB формат пакетов в основном соответствует широко распространенному формату RPM (определеному в Maximum RPM). LSB не определяет, как создавать пакеты. Однако, он содержит четкие указания о порядке именования пакетов и спецификации описаний взаимозависимостей пакетов.
- ELF
- Формат исполняемых файлов ELF ("executable linkage format") является стандартным в Linux. Он описывает структуру бинарных файлов с программами и библиотеками.
С целью поддержки процесса разработки стандартов для Linux была образована независимая некоммерческая организация Free Standards Group. В число ее основателей и участников входят такие известные фирмы и организации как Conectiva, Debian, Dell, Hewlett Packard, Hitachi, IBM, Miracle Linux, The Open Group, Oracle, Red Hat, Sun, SuSE and TurboLinux, а также отдельные независимые представители сообщества разработчиков открытого программного обеспечения.
В рамках Free Standards Group были образованы несколько рабочих групп, задачей которых является разработка отдельных стандартов. Разработка проекта Linux Standard Base стала задачей одной из таких рабочих групп. Другие рабочие группы занимаются разработкой следующих стандартов:
OpenI18N (ранее назывался Li18nux) - стандарт по интернационализации и локализации приложений для Linux и других платформ, включающий конкретные спецификации и наборы тестов;
LANANA - стандартный перечень имен и номеров устройств, используемых а Linux;
DWARF - формат описания программ на C и других языках программирования для облечения процессов отладки;
- OpenPrinting - набор стандартов, определяющих процедуры организации печати в корпоративных сетях, включая управление печатью, обеспечение надежности, безопасности, расширяемости, сетевой доступности и т.д.
В октябре 2004 года организация Free Standards Group выпустила версию 2.0 стандарта Linux Standard Base (LSB). О своей поддержке нового стандарта заявили такие компании, как AMD, IBM, Dell, Hewlett Packard, Red Hat, Red Flag (основной китайский поставщик Linux) и т.д. Со временем все большее число компаний осознают, что следование стандарту LSB снижает расходы на тестирование производимых ими продуктов и предоставляет определенные преимущества в конкурентной борьбе, поскольку дает покупателям уверенность в высоких качествах продукта и отсутствии проблем с его эксплуатацией. Поэтому в 2005 году все новые компании заявляют о поддержке LSB. В их число входят, в часности, поставщик средств хранения данных Veritas, разработчик баз данных MySQL и поставщик программных средств управления Levanta.
Перечень программ и дистрибутивов, удовлетворяющих требованиям LSB, можно просмотреть здесь.
Кроме стандартов, разрабатываемых Free Standart Group, нужно упомянуть еще консорциум Embedded Linux, который разработал проект стандарта по использованию Linux во встраиваемых устройствах, таких как сетевые маршрутизаторы и заводские роботы.