В конце 1980-х годов начали проявляться негативные последствия имеющегося широкого разнообразия доступных реализаций UNIX. Одни реализации основывались на BSD, в то время как другие были созданы на основе System V, а у третьих функционал был позаимствован из обоих вариантов. Кроме того, каждый коммерческий распространитель добавлял к своей собственной реализации дополнительные функции. Все это привело к постепенному усложнению портирования программных продуктов и перехода людей с одной реализации UNIX на другую. Эта ситуация показала, что требовалась стандартизация языка программирования С и системы UNIX, чтобы упростить портирование приложений с одной системы на другую. Рассмотрим выработанные в итоге стандарты.
Язык программирования С
К началу 1980-х годов язык С существовал уже в течение 10 лет и был реализован во множестве разнообразных UNIX-систем, а также в других операционных системах. В некоторых реализациях отмечались незначительные различия. В частности, это произошло из-за того, что определенные аспекты требуемого функционионала языка не были подробно описаны в существующем де-факто стандарте С. Этот стандарт приводился в вышедшей в 1978 году книге Кернигана (Kernighan) и Ритчи (Ritchie) «Язык программирования Си». (Синтаксис языка С, иногда называют традиционным С, или K&R С.) Кроме того, с появлением в 1985 году языка C++ проявились конкретные улучшения и дополнения, которые могли быть привнесены в С без нарушения совместимости с существующими программами. В частности, сюда можно отнести прототипы функций, присваивание структур, спецификаторы типов (const и volatile), перечисляемые типы и ключевое слово void.
Эти факторы побудили к стандартизации С. Ее кульминацией в 1989 году стало утверждение Американским институтом национальных стандартов (ANSI) стандарта языка С (ХЗ.159-1989), который в 1990 году был принят в качестве стандарта (ISO/IEC 9899:1990) Международной организацией по стандартизации (ISO). Наряду с определением синтаксиса и семантики языка С в этом стандарте давалось описание стандартной библиотеки С, включающей возможности stdio, функции обработки строк, математические функции, различные файлы заголовков и т. д. Эту версию С обычно называют С89 или (значительно реже) ISO С90, и она полностью рассмотрена во втором издании (1988 года) книги Кернигана и Ритчи «Язык программирования Си».
Пересмотренное издание стандарта языка С было принято ISO в 1999 году (ISO/IEC 9899:1999; см. здесь). Его обычно называют С99, и он включает несколько изменений языка и его стандартной библиотеки. В частности, там описаны добавление типов данных long long и логического (булева), присущий C++ стиль комментариев (//), ограниченные указатели и массивы переменной длины. Новый стандарт для языка Си (ISO/IEC 9899:2011) опубликован 8 декабря 2011. В нем описаны поддержка многопоточности, обобщенные макросы, анонимные структуры и объединения, статичные утверждения, функция quick_exit, новый режим эксклюзивного открытия файла и др.
Стандарты языка С не зависят от особенностей операционной системы, то есть они не привязаны к UNIX-системе. Это означает, что программы на языке С, для написания которых использовалась только стандартная библиотека С, должны быть портированы на любой компьютер и операционную систему, предоставляющую реализацию языка С.
Исторически С89 часто называли ANSI С, и это название до сих пор иногда употребляется в таком значении. Например, оно используется в дсс, где спецификатор -ansi означает «поддерживать все программы ISO С90». Но мы будем избегать этого названия, поскольку теперь оно звучит несколько двусмысленно. После того как комитет ANSI принял пересмотренную версию С99, будет правильным считать, что стандартом ANSI С следует называть С99.
Первые стандарты POSIX
Термин POSIX (аббревиатура от Portable Operating System Interface) обозначает группу стандартов, разработанных под руководством Института инженеров электротехники и электроники — Institute of Electrical and Electronic Engineers (IEEE), а точнее, его комитета по стандартам для портируемых приложений — Portable Application Standards Committee (PASC). Цель PASC-стандартов — содействие портируемости приложений на уровне исходного кода.
Название POSIX было предложено Ричардом Столлманом (Richard Stallman). Последняя буква X появилась потому, что названия большинства вариантов UNIX заканчивались на X. В стандарте указывалось, что название должно произноситься как pahzicks, наподобие слова positive («положительный»).
Для нас в стандартах POSIX наибольший интерес представляет первый стандарт POSIX, который назывался POSIX. 1 (или в более полном виде POSIX 1003.1), и последующий стандарт POSIX.2.
POSIX. 1 и POSIX.2
POSIX. 1 стал IEEE-стандартом в 1988 году и после небольшого количества пересмотров был принят как стандарт ISO в 1990 году (ISO/IEC 9945-1:1990). (Полных версий POSIX нет в свободном доступе, но их можно приобрести у IEEE)
POSIX. 1 сначала основывался на более раннем (1984 года) неофициальном стандарте, выработанном объединением поставщиков UNIX под названием /usr/group.
В POSIX. 1 документируется интерфейс прикладного программирования (API) для набора сервисов, которые должны быть доступны программам из соответствующей операционной системы. ОС, способная справиться с этой задачей, может быть сертифицирована в качестве совместимой с POSIX. 1.
POSIX. 1 основан на системном вызове UNIX и API библиотечных функций языка С, но при этом не требует, чтобы с этим интерфейсом была связана какая-либо конкретная реализация. Это означает, что интерфейс может быть реализован любой операционной системой и не обязательно UNIX. Фактически некоторые поставщики добавили API к своим собственным операционным системам, сделав их совместимыми с POSIX. 1, в то же время оставив сами ОС в практически неизменном виде.
Большое значение приобрели также расширения исходного стандарта POSIX. 1. Стандарт IEEE POSIX 1003.1b (POSIX.lb, ранее называвшийся POSIX.4 или POSIX 1003.4), одобренный в 1993 году, содержит расширения базового стандарта POSIX для работы в режиме реального времени. Стандарт IEEE POSIX 1003.1с (POSIX. 1с), одобренный в 1995 году, содержит определения потоков в POSIX. В 1996 году была разработана пересмотренная версия стандарта POSIX.l (ISO/IEC 9945-1:1996), основной текст которой остался без изменений, но в него были внесены дополнения, касающиеся работы в режиме реального времени и использования потоков. Стандарт IEEE POSIX 1003. lg (POSIX. lg) определил API для работы в сети, включая сокеты. Стандарт IEEE POSIX 1003.Id (POSIX.Id), одобренный в 1999 году, и POSIX. lj, одобренный в 2000 году, определили дополнительные расширения основного стандарта POSIX для работы в режиме реального времени.
Расширения POSIX.lb для работы в режиме реального времени включают файловую синхронизацию, асинхронный ввод/вывод, диспетчеризацию процессов, высокоточные часы и таймеры, а также обмен данными между процессами с применением семафоров, совместно используемой памяти и очереди сообщений. Префикс POSIX часто применяется для трех методов обмена данными между процессами, чтобы их можно было отличить от похожих, но более старых методов реализации семафоров, совместного использования памяти и очередей сообщений из System V.
Родственный стандарт POSIX.2 (1992, ISO/IEC 9945-2:1993) затрагивает оболочку и различные утилиты UNIX, включая интерфейс командной строки компилятора кода языка С.
FIPS 151-1 и FIPS 151-2
FIPS является аббревиатурой от федерального стандарта обработки информации — Federal Information Processing Standard. Это название набора стандартов, разработанных правительством США и используемых гражданскими правительственными учреждениями. В 1989 году был опубликован стандарт FIPS 151-1, основанный на стандарте 1988 года IEEE
POSIX.1 и предварительной версии стандарта ANSI С. Основное отличие FIPS 151-1 от POSIX. 1 (1988 года) заключалось в том, что по стандарту FIPS требовалось наличие кое- каких функций, которые в POSIX. 1 оставались необязательными. Поскольку основным покупателем компьютерных систем было правительство США, большинство поставщиков обеспечили совместимость своих UNIX-систем с FIPS 151-1-версией стандарта POSIX.1.
Стандарт FIPS 151-2 совмещен с редакцией 1990 ISO стандарта POSIX.1, но в остальном остался без изменений. Уже устаревший FIPS 151-2 был отменен в феврале 2000 года.
X/Open Company и Open Group
X/Open Company представляла собой консорциум, основанный международной группой поставщиков UNIX. Он предназначался для принятия и внедрения существующих стандартов с целью выработки всеобъемлющего согласованного набора стандартов открытых систем. Им было выработано руководство X/Open Portability Guide, состоящее из серий руководств по обеспечению портируемости на базе стандартов POSIX. Первым весомым выпуском этого руководства в 1989 году стал документ под названием Issue 3 (XPG3), за которым в 1992 году последовал документ XPG4. Последний был пересмотрен в 1994 году, в результате чего появился XPG4 версии 2, стандарт, который также включал в себя важные части документа AT&T’s System V Interface Definition Issue 3. Эта редакция также была известна как Spec 1170, где число 1170 соответствует количеству интерфейсов (функций, файлов заголовков и команд), определенных стандартом.
Когда компания Novell, которая в начале 1993 года приобрела у AT&T бизнес, связанный с системами UNIX, позже самоустранилась от него, она передала права на торговую марку UNIX консорциуму Х/Open. (Планы по этой передаче были анонсированы в 1993 году, но в силу юридических требований передача прав была отложена до начала 1994 года.) Стандарт XPG4 версии 2 был перекомпонован в единую UNIX-спецификацию — Single UNIX Specification (SUS, иногда встречается вариант SUSvl), которая также известна под названием UNIX 95. Эта перекомпоновка включала XPG4 версии 2, спецификацию X/Open Curses Issue 4 версии 2 и спецификацию X/Open Networking Services (XNS) Issue 4. Версия 2 Single UNIX Specification (SUSv2, http://www.unix.org/version2/online.html) появилась в 1997 году, а реализация UNIX, сертифицированная на соответствие требованиям этой спецификации, может называть себя UNIX 98. (Данный стандарт иногда также называют XPG5.)
В 1996 году консорциум X/Open объединился с Open Software Foundation (OSF), в результате чего был сформирован консорциум The Open Group. В настоящее время в The Open Group, где продолжается разработка стандартов API, входят практически все компании или организации, имеющие отношение к системам UNIX.
OSF был одним из двух консорциумов поставщиков, сформировавшихся в ходе UNIX-войн в конце 1980-х годов. Кроме прочих, в него входили Digital, IBM, HP, Apollo, Bull, Nixdorf и Siemens. OSF был сформирован главным образом в ответ на угрозы, вызванные бизнес- альянсом AT&T (изобретателей UNIX) и Sun (наиболее мощного игрока на рынке рабочих станций под управлением UNIX). В свою очередь, AT&T, Sun и другие компании сформировали конкурирующий консорциум UNIX International.
SUSv3 и POSIX.1-2001
Начиная с 1999 года IEEE, Open Group и ISO/IEC Joint Technical Committee 1 объединились в Austin Common Standards Revision Group (CSRG) с целью пересмотра и утверждения стандартов POSIX и Single UNIX Specification. (Свое название Austin Group получила потому, что ее первое заседание состоялось в городе Остин, штат Техас, в сентябре 1998 года.) В результате этого в декабре 2001 года был одобрен стандарт POSIX 1003.1-2001, иногда называемый просто POSIX.1-2001 (который впоследствии был утвержден в качестве ISO-стандарта ISO/IEC 9945:2002).
POSIX 1003.1-2001 заменил собой SUSv2, POSIX.l, POSIX.2 и ряд других более ранних стандартов POSIX. Этот стандарт также известен как Single UNIX Specification версии 3, и ссылки на него в основном имеют вид SUSv3.
Базовая спецификация SUSv3 состоит почти из 3700 страниц, разбитых на следующие четыре части.
- Base Definitions (XBD). Включает в себя определения, термины, положения и спецификации содержимого файлов заголовков. Всего предоставляются спецификации 84 файлов заголовков.
- System Interfaces (XSH). Начинается с различной полезной справочной информации. В основном в ней содержатся спецификации разных функций (реализуемых либо в виде системных вызовов, либо в виде библиотечных функций в конкретной реализации UNIX). Всего в нее включено 1123 системных интерфейса.
- Shell and Utilities (XCU). В этой части определяются возможности оболочки и различные команды (утилиты) UNIX. Всего в ней представлено 160 утилит.
- Rationale (XRAT). Включает в себя текстовые сведения и объяснения, касающиеся предыдущих частей.
Кроме того, в SUSv3 входит спецификация X/Open CURSES Issue 4 версии 2
(XCURSES), в которой определяются 372 функции и три файла заголовков для API curses, предназначенного для управления экраном.
Всего в SUSv3 описано 1742 интерфейса. Для сравнения, в POSIX.1-1990 (с FIPS 151-2) определено 199 интерфейсов, а в POSIX.2-1992 — 130 утилит.
Спецификация SUSv3 доступна по адресу. Реализации UNIX, сертифицированные в соответствии с требованиями SUSv3, имеют право называться UNIX 03.
В результате проблем, обнаруженных с момента одобрения исходного текста SUSv3, в него были внесены различные незначительные правки и уточнения. В итоге появилось техническое исправление номер 1 (Technical Corrigendum Number 1), уточнения из которого были внесены в редакцию SUSv3 от 2003 года, и техническое исправление номер 2 (Technical Corrigendum Number 2), уточнения из которого добавлены в редакцию 2004 года.
POSIX-соответствие, XSI-соответствие и XSI-расширение
Исторически стандарты SUS (и XPG) полагались на соответствующие стандарты POSIX и были структурированы как их функциональные расширенные варианты. Поскольку в стандартах SUS определялись дополнительные интерфейсы, эти стандарты сделали обязательными многие интерфейсы и особенности поведения, считавшиеся необязательными в POSIX.
С некоторыми нюансами эти различия сохраняются в POSIX 1003.1-2001, являющемся одновременно стандартом IEEE и Open Group Technical Standard (то есть, как уже было отмечено, он представляет собой объединение раннего POSIXhSUS). Этот документ определяет два уровня соответствия.
- Соответствие POSIX: задает основной уровень интерфейсов, который должен предоставляться реализацией, претендующей на соответствие. Допускает предоставление реализацией других необязательных интерфейсов.
- Соответствие X/Open System Interface (XSI): чтобы соответствовать XSI, реализация должна отвечать всем требованиям соответствия POSIX, а также предоставлять ряд интерфейсов и особенностей поведения, которые считаются для него необязательными. Реализация должна достичь этого уровня, чтобы получить от Open Group право называться UNIX 03.
Дополнительные интерфейсы и особенности поведения, требуемые для XSI-соответствия, обобщенно называются XSI-расширением. В их число входит поддержка потоков, функций mmap() и munmap(), API dlopen, ограничений ресурсов, псевдотерминалов, System V IPC, API syslog, функции poll(), учетных записей пользователей.
В дальнейшем, когда речь пойдет о SUSv3-cootbctctbhh, мы будем иметь в виду XSI- соответствие.
Поскольку теперь POSIX и SUSv3 относятся к одному и тому же документу, дополнительные интерфейсы и перечень обязательных возможностей, требуемых для SUSv3, выделяются в тексте документа особым образом.
Неопределенные и слабо определенные интерфейсы
Временами вам будут попадаться ссылки на неопределенные или слабо определенные в SUSv3 интерфейсы.
Под неопределенным будет пониматься интерфейс, который не определяется в официальном стандарте, хотя упоминается в имеющихся справочных заметках или в тексте пояснений.
Когда говорится, что интерфейс слабо определен, подразумевается, что, хотя интерфейс включен в стандарт, важные подробности не определены (зачастую по причине того, что в комитете не достигли согласия из-за различий в существующих реализациях).
При использовании неопределенных или слабо определенных интерфейсов нельзя на 100 % гарантировать успешную портируемость приложений на другие реализации UNIX, а портируемые приложения не должны полагаться на поведение конкретной реализации. И все же в некоторых случаях подобные интерфейсы в различных реализациях достаточно согласованы, и о таких случаях я, как правило, буду писать отдельно.
Средства с пометкой LEGACY
Иногда какое-то средство в SUSv3 имеет пометку LEGACY. Она означает, что это средство оставлено для сохранения совместимости со старыми приложениями, а в новых приложениях его лучше не использовать. Во многих случаях существуют другие API, предоставляющие эквивалентные функциональные возможности.
SUSv4 и POSIX. 1-2008
В 2008 году Austin Group завершила пересмотр объединенной спецификации POSIX. 1 и Single UNIX. Как и предшествующая версия стандарта, она состоит из основной спецификации, дополненной XSI-расширением. Эту редакцию мы будем называть SUSv4.
Изменения в SUSv4 не столь масштабные, как в SUSv3. Из наиболее существенных можно выделить следующие.
- Добавлены новые спецификации для некоторых функций. Из их числа популярны
dirfd(),fdopendir(),fexecve(),futimens(),mkdtemp(),psignal(),strsignal()иutimensat(). Другие новые функции предназначены для работы с файлами и практически являются аналогами существующих функций (например,open()). Они отличаются лишь тем, что относительный путь к файлу разрешается относительно каталога, на который ссылается дескриптор открытого файла, а не относитльно текущего рабочего каталога процесса. - Некоторые функции, указанные в SUSv3 как необязательные, становятся обязательной частью стандарта в SUSv4. Например, отдельные функции, составлявшие в SUSv3 часть XSI-расширения, в SUSv4 стали частью базового стандарта. Среди функций, ставших обязательными в SUSv4, можно назвать функции, входящие в API сигналов режима реального времени, в API POSIX-таймеров, в API
diopenи в API POSIX-семафоров. - Кое-какие функции из SUSv3 в SUSv4 помечены как устаревшие. К их числу относятся
asctime(),ctime(),ftw(),gettimeofday(),getitimer(),setitimer()иsiginterrupt(). - Спецификации некоторых функций, помеченных в SUSv3 как устаревшие, из SUSv4 удалены. Среди них
gethostbyname(),gethostbyaddr()иvfork(). - Различные особенности существующих в SUSv3 спецификаций претерпели изменения в SUSv4. Например, к списку функций, от которых требуется обеспечение безопасной обработки асинхронных сигналов, добавились дополнительные функции.
Этапы развития стандартов UNIX
На рис. 1, где рассмотренные в предыдущих разделах стандарты расположены в хронологическом порядке, показано обобщенное представление об их взаимосвязи. Сплошными линиями на этой схеме обозначено прямое наследование стандартов, а прерывистыми стрелками показаны случаи, когда один стандарт, повлиявший на другой, был включен в качестве его части или же просто перенесен в него.
Ситуация с сетевыми стандартами была несколько сложнее. Действия по стандартизации в этой области начали предприниматься в конце 1980-х годов. В то время был образован комитет POSIX 1003.12 для стандартизации API сокетов, API X/Open Transport Interface (XTI) (альтернативный API программирования сетевых приложений на основе интерфейса транспортного уровня System V Transport Layer Interface) и различных API, связанных с работой в сети. Становление стандарта POSIX 1003.12 заняло несколько лет, в течение которых он был переименован в POSIX 1003.lg. Этот стандарт был одобрен в 2000 году.
Параллельно с разработкой POSIX 1003. lg в X/Open велась разработка спецификации X/Open Networking Specification (XNS). Первая ее версия, XNS, выпуск 4, была частью первой версии Single UNIX Specification. За ней последовала спецификация XNS, выпуск 5, которая составила часть SUSv2. По сути, XNS, выпуск 5, была такой же, как и текущая на то время предварительная версия (6.6) POSIX.lg. Затем последовала спецификация XNS, выпуск 5.2, отличавшаяся от XNS, выпуск 5, и был одобрен стандарт POSIX.lg. В нем был помечен устаревшим API XTI и включен обзор протокола Internet Protocol version 6 (IPv6), разработанного в середине 1990-х годов. XNS, выпуск 5.2, заложил основу для документации, относящейся к работе в сети и включенной в замененный нынче стандарт SUSv3. По аналогичным причинам POSIX. lg был отозван в качестве стандарта вскоре после своего одобрения.
Рис. 1. Взаимоотношения между различными стандартами UNIX и С
Стандарты реализаций
В дополнение к стандартам, разработанным независимыми компаниями, иногда даются ссылки на два стандарта реализаций, определенных финальным выпуском BSD (4.4BSD) и AT&T’s System V, выпуск 4 (SVR4). Последний стандарт реализации был документально оформлен публикацией System V Interface Definition (SVID) (компания AT&T). В 1989 году AT&T опубликовала выпуск 3 стандарта SVID, определявшего интерфейс, который должна предоставлять реализация UNIX, чтобы называться System V, выпуск 4. (В Интернете SVID можно найти по адресу)
Поскольку поведение некоторых системных вызовов и библиотечных функций в SVR4 и BSD различается, во многих реализациях UNIX предусмотрены библиотеки совместимости и средства условной компиляции. Они эмулируют поведение тех особенностей, которые не были включены в конкретную реализацию UNIX. Тем самым облегчается портирование приложений из другой реализации UNIX.
Linux, стандарты и нормативная база Linux
В первую очередь разработчики Linux (то есть ядра, библиотеки glibc и инструментария) стремятся соответствовать различным стандартам UNIX, особенно POSIX и Single UNIX Specification. Но на время написания этих строк ни один из распространителей Linux не получил от Open Group права называться UNIX. Проблемы — во времени и средствах. Чтобы получить такое право, каждому дистрибутиву от поставщика необходимо пройти тестирование на соответствие, и с выпуском каждого нового дистрибутива требуется повторное тестирование. Тем не менее близкое соблюдение различных стандартов позволяет Linux успешно оставаться на рынке UNIX.
Что касается большинства коммерческих реализаций UNIX, разработкой и распространением операционной системы занимается одна и та же компания. А вот с Linux картина иная — реализация отделена от распространения, и распространением Linux занимаются многие организации: как коммерческие, так и некоммерческие.
Линус Торвальдс не занимается распространением или поддержкой какого-либо конкретного дистрибутива Linux. Но в отношении других отдельных разработчиков Linux ситуация иная. Многие разработчики, занимающиеся ядром Linux и другими проектами свободного программного обеспечения, являются сотрудниками различных компаний-распространителей Linux или работают на компании (такие как IBM и HP), испытывающие большой интерес к Linux. Хотя эти компании могут влиять на направление, в котором развивается Linux, выделяя программистам время на разработку конкретных проектов, ни одна из них не управляет операционной системой Linux как таковой. И конечно же, многие другие разработчики ядра Linux и GNU-проектов трудятся на добровольной основе.
На время написания этих строк Торвальдс числился сотрудником фонда Linux Foundation, бывшей лаборатории Open Source Development Laboratory, OSDL, некоммерческого консорциума организаций, уполномоченных оказывать содействие развитию Linux.
Из-за наличия нескольких распространителей Linux, а также из-за того, что реализаторы ядра не контролируют содержимое дистрибутивов, «стандартной» коммерческой версии Linux не существует. Ядро отдельного дистрибутива Linux обычно базируется на некоторой версии ядра Linux из основной ветки разработки (которую ведет Торвальдс) с набором необходимых изменений.
В этих изменениях (патчах) предоставляются функции, которые в той или иной степени считаются коммерчески востребованными и способными тем самым обеспечить конкурентные преимущества на рынке. Иногда эти исправления принимаются в качестве основной ветви разработки. Фактически некоторые новые функции ядра изначально были разработаны компаниями-распространителями и, прежде чем стать частью основной ветки, появились в их дистрибутивах. Например, версия 3 журналируемой файловой системы Reiserfs была частью ряда дистрибутивов Linux задолго до того, как была принята в качестве основной ветки версии 2.4.
Итогом всех ранее упомянутых обстоятельств стали в основном незначительные различия в системах, предлагаемых разными компаниями-распространителями Linux. Это напоминает расхождения в реализациях в начальные годы существования UNIX, но в существенно меньших масштабах. В результате усилий по обеспечению совместимости между разными дистрибутивами Linux появился стандарт под названием Linux Standard Base (LSB) (http://www.linux-foundation.org/en/LSB). В рамках LSB был разработан и внедрен набор стандартов для систем Linux. Они обеспечивают возможность запуска двоичных приложений (то есть скомпилированных программ) на любой LSB-совместимой системе.
Двоичная портируемость, внедренная с помощью LSB, отличается от портируемости исходного кода, внедренной стандартом POSIX. Портируемость исходного кода означает возможность написания программы на языке С с ее последующей успешной компиляцией и запуском на любой POSIX-совместимой системе. Двоичная совместимость имеет куда более привередливый характер, и, как правило, она недостижима на различных аппаратных платформах. Она позволяет осуществлять однократную компиляцию на конкретной аппаратной платформе, после чего запускать откомпилированную программу в любой совместимой реализации, запущенной на этой аппаратной платформе. Двоичная портируемость является весьма важным требованием для коммерческой жизнеспособности приложений, созданных под Linux независимыми поставщиками программных продуктов — independent software vendor (ISV).
Резюме
Впервые система UNIX была введена в эксплуатацию в 1969 году на мини-компьютере Digital PDP-7 Кеном Томпсоном из Bell Laboratories (подразделения AT&T). Множество идей было привнесено из ранее созданной системы MULTICS. К 1973 году UNIX была перенесена на мини-компьютер PDP-11 и переписана на С, языке программирования, разработанном и реализованном в Bell Laboratories Деннисом Ритчи (Dennis Ritchie). По закону не имея возможности продавать UNIX, компания AT&T за символическую плату распространяла полноценную систему среди университетов. Дистрибутив включал исходный код и стал весьма популярен в университетской среде. Это была недорогая операционная система, код которой можно было изучать и изменять как преподавателям, так и студентам, изучающим компьютерные технологии.
Ключевую роль в разработке UNIX сыграл Калифорнийский институт в Беркли. Там операционная система была расширена Кеном Томпсоном и несколькими студентами- выпускниками. К 1979 году университет создал собственный UNIX-дистрибутив под названием BSD. Он получил широкое распространение в академических кругах и стал основой для нескольких коммерческих реализаций.
Тем временем компания AT&T лишилась своего монопольного положения на рынке и занялась продажами системы UNIX. В результате появился еще один основной вариант UNIX под названием System V, который также послужил базой для нескольких коммерческих реализаций.
К разработке (GNU) Linux привели два разных проекта. Одним из них был GNU-проект, основанный Ричардом Столлманом. В конце 1980-х годов в рамках GNU была создана практически завершенная, свободно распространяемая реализация UNIX. Недоставало только работоспособного ядра. В 1991 году Линус Торвальдс, вдохновленный ядром Minix, придуманным Эндрю Таненбаумом, создал работоспособное ядро UNIX для архитектуры Intel х86-32. Торвальдс обратился за помощью к другим программистам для усовершенствования ядра. На его призыв откликнулось множество программистов, и со временем система Linux была расширена и портирована на большое количество разнообразных аппаратных архитектур.
Проблемы портирования, возникшие из-за наличия разных реализаций UNIX и С, существовавших к концу 1980-х годов, сильно повлияли на решение вопросов стандартизации. Язык С прошел стандартизацию в 1989 году (С89), а пересмотренный стандарт вышел в 1999 году (С99). Первая попытка стандартизации интерфейса операционной системы привела к выпуску POSIX. 1, одобренному в качестве стандарта IEEE в 1988 году и в качестве стандарта ISO в 1990 году. В 1990-е годы были разработаны дополнительные стандарты, включая различные версии спецификации Single UNIX Specification. В 2001 году был одобрен объединенный стандарт POSIX 1003.1-2001 и SUSv3. Этот стандарт собрал воедино и расширил различные более ранние стандарты POSIX и более ранние версии спецификации Single UNIX Specification. В 2008 году был завершен менее масштабный пересмотр стандарта, что привело к объединенному стандарту POSIX 1003.1-2008 и SUSv4.
В отличие от большинства коммерческих реализаций UNIX, в Linux реализация отделена от дистрибутива. Следовательно, не существует какого-либо «официального» дистрибутива Linux. Предложения каждого распространителя Linux состоят из какого-то варианта текущей стабильной версии ядра с добавлением различных усовершенствований. В рамках LSB разрабатывается и внедряется набор стандартов для систем Linux с целью обеспечения совместимости двоичных приложений в разных дистрибутивах Linux. Эти стандарты позволяют запускать откомпилированные приложения в любой LSB-совместимой системе, запущенной на точно таком же аппаратном оборудовании. Дополнительная информация
Дополнительные сведения об истории и стандартах UNIX можно найти в публикациях [Ritchie, 1984], [McKusick et al., 1996], [McKusick & Neville-Neil, 2005], [Libes & Ressler, 1989], [Garfinkel et al., 2003], [Stevens & Rago, 2005], [Stevens, 1999], [Quartermann & Wilhelm, 1993], [Goodheart & Cox, 1994] и [McKusick, 1999].
В публикации [Salus, 1994] изложена подробная история UNIX, откуда и были почерпнуты основные сведения. В публикации [Salus, 2008] предоставлена краткая история Linux и других проектов по созданию свободных программных продуктов. Многие подробности истории UNIX можно также найти в выложенной в Интернет книге Ронды Хобен (Ronda Hauben) History of UNIX. Весьма подробную историческую справку, относящуюся к выпускам различных реализаций UNIX, вы найдете по адресу.
В публикации [Josey, 2004] дается обзорная информация по истории систем UNIX и разработке SUSv3, а также приводится руководство по использованию спецификации, сводные таблицы имеющихся в SUSv3 интерфейсов и пособие по переходу от SUSv2 к SUSv3 и от С89 к С99.
Наряду с предоставлением программных продуктов и документации, на сайте GNU (http://www.gnu.org/) содержится подборка философских статей, касающихся свободного программного обеспечения. А в публикации [Williams, 2002] дается биография Ричарда Столлмана.
Собственные взгляды Торвальдса на развитие Linux можно найти в публикации [Torvalds & Diamond, 2001].
