Я часто сталкиваюсь с термином "Unix-like" на многих веб-сайтах.
Там нет стандарта; это просто в том, как он себя ведет.
Но если бы я разрабатывал ядро с нуля, что бы оно считало «unix-like»?
В основном, что делает написанный код таким, как Unix?
Я часто сталкиваюсь с термином "Unix-like" на многих веб-сайтах.
Там нет стандарта; это просто в том, как он себя ведет.
Но если бы я разрабатывал ядро с нуля, что бы оно считало «unix-like»?
В основном, что делает написанный код таким, как Unix?
Ответы:
Там нет стандарта; это просто в том, как он себя ведет.
Я полагаю, что большинство "unix-подобных" ОС действительно прилагают очень серьезные усилия, чтобы придерживаться стандарта POSIX , который контролируется Open Group, которая также контролирует Единственную Спецификацию UNIX, которая определяет "истинную UNIX". Первое - это ядро позднего.
Таким образом, на самом деле существует стандарт, который определяет практичность Unix-подобных операционных систем. Посмотрите список «полностью» и «в основном» совместимых ОС в конце статьи в Википедии о POSIX.
Есть несколько очевидных причин, по которым linux, в частности, может не считаться полностью совместимым или сертифицируемым Спецификацией Single Unix (SUS), но это не потому, что любая данная система linux обязательно несовместима с ней. Статья в Википедии кратко описывает спецификацию следующим образом:
SUSv3 насчитывает около 3700 страниц, которые тематически разделены на четыре основные части:
Базовые определения (XBD) - список определений и соглашений, используемых в спецификациях, и список файлов заголовков C, которые должны предоставляться совместимыми системами. Всего доступно 84 заголовочных файла.
Shell and Utilities (XCU) - список утилит и описание оболочки, sh. Всего указано 160 утилит.
Системные интерфейсы (XSH) - содержит спецификацию различных функций, которые реализованы как системные вызовы или библиотечные функции. Всего указано 1123 системных интерфейса.
Обоснование (XRAT) - объяснение стандарта.
Стандартный пользовательский интерфейс командной строки и сценариев - это оболочка POSIX, расширение Bourne Shell, основанное на ранней версии Korn Shell.
Другие пользовательские программы, сервисы и утилиты включают awk, echo, ed, vi и сотни других. Требуемые сервисы программного уровня включают базовые сервисы ввода-вывода (файловые, терминальные и сетевые).
Набор тестов сопровождает стандарт. Он называется PCTS или комплектом сертификационных испытаний POSIX.
Кроме того, SUS включает в себя спецификацию CURSES (XCURSES), которая определяет 372 функции и 3 заголовочных файла. Всего в SUSv3 указано 1742 интерфейса.
Это, очевидно, относится конкретно ко многим пользовательским компонентам (таким как оболочка), которые просто не являются частью ядра Linux. Таким образом, нет никакого способа, которым linux.org et. и др. может иметь только сертифицированное ядро - в этом смысле это вовсе не операционная система. Конечно, они могли бы попытаться сертифицировать какую-то конкретную систему, используя ядро, но это было бы бессмысленно в свете общей схемы распространения: ядро и люди, которые его поддерживают, независимы от людей, которые поддерживают ядро пользовательского пространства (GNU). которые не зависят от людей, которые поддерживают фактически собранные дистрибутивы ОС (Debian, Fedora и т. д.).
Я полагаю, что Debian или Fedora сами могут участвовать в процессе сертификации (например, RedHat Enterprise может стать «сертифицированным Unix»), но возникает вопрос, что это действительно желательно. Я бы предположил, что основной причиной для систем SUS является запуск программного обеспечения (коммерческого масштаба, не для потребителя), написанного для такого, что просто не является нишей для linux - люди, занимающиеся этим, будут платить тысячи долларов за лицензию для ОС, включая много поддержки и т. д., поскольку они также платят десятки или сотни тысяч долларов за лицензию за любое дополнительное программное обеспечение, которое они хотят запустить в системе. Linux и другие выпадающие, с другой стороны, преследовали цели проектирования помимо простого соответствия коммерческим целям, и есть различные примеры этого, например (изhttp://en.wikipedia.org/wiki/STREAMS ):
STREAMS требовались для соответствия версиям Single UNIX Specification 1 (UNIX 95) и 2 (UNIX 98), но в результате отказа разработчиков BSD и Linux от предоставления STREAMS [цитата нужна] была помечена как необязательная для POSIX соответствие Austin Group в версии 3 (UNIX 03).
Интересное размещение, в котором подчеркивается, что SUS и The Open Group! = Linux,! = BSD и т. Д.
Чтобы расширить первый ответ о POSIX, понять, что означает «unix-like», сначала нужно попытаться понять, что такое UNIX. Посмотрев документацию от Open Group , которой принадлежит торговая марка Unix, вы найдете подробности об эволюции спецификации Single UNIX - вот UNIX03 :
Стандарт продукта UNIX 03 является знаком для систем, соответствующих версии 3 Единой спецификации UNIX. Это значительно улучшенная версия стандарта продуктов UNIX 98. Обязательные улучшения включают в себя приведение в соответствие с языком программирования ISO / IEC 9989: 1999 C, стандартом IEEE 1003.1-2001 и ISO / IEC 9945: 2002. Этот стандарт продукта включает в себя следующие обязательные стандарты продукта: интернационализированные системные вызовы и библиотеки Extended V3, команды и утилиты V4, язык C V2 и интернационализированные терминальные интерфейсы.
UNIX98 :
Стандарт продукта UNIX 98 является значительно улучшенной версией стандарта продукта UNIX 95. Обязательные улучшения включают в себя (1) интерфейсы потоков, (2) расширение поддержки многобайтовых файлов (MSE), (3) поддержку больших файлов, (4) динамическое связывание, (5) изменения для удаления аппаратных зависимостей или ограничений длины данных и (6 ) 2000 год перемен. Кроме того, включены следующие дополнительные усовершенствования: средства администрирования программного обеспечения и набор API-интерфейсов для поддержки в реальном времени. Этот стандарт продукта включает в себя следующие обязательные стандарты продукта: интернационализированные системные вызовы и библиотеки Extended V2, команды и утилиты V3, язык C, транспортная служба (XTI) V2, сокеты V2 и интернационализированные интерфейсы терминалов. Кроме того, он также может соответствовать Стандарту продукта для администрирования программного обеспечения.
UNIX95 (мой акцент):
В настоящем стандарте на продукцию определяется консолидированная платформа для поддержки широкого спектра приложений, первоначально разработанных для одной из классов операционных систем, которые были получены из кода операционной системы UNIX и / или интерфейсов, первоначально разработанных AT & T , в дополнение к предоставляемым средствам. по стандарту базового продукта. Он имеет более широкий охват, чем база. Этот стандарт продукта включает следующие стандарты продукта: расширенные интернационализированные системные вызовы и библиотеки, команды и утилиты V2, язык C, транспортная служба (XTI), сокеты и интернационализированные терминальные интерфейсы.
Серверные версии стандарта добавляют Интернет-сервер и IPv6 в некоторых случаях.
Поэтому, конечно, мы видим ссылку на AT & T Bell Laboratories, и язык C лежит в основе UNIX: язык C, модульные базовые инструменты и оболочка, а также то, как ядро, файловая система и другие ключевые компоненты ОС были спроектированы и реализованы. ,


Вот где книга Мориса Дж. Баха «Дизайн операционной системы UNIX» становится бесценным чтением, потому что это исторические вопросы на данный момент. Следует отметить, конечно, как это связано с другими изобретениями, такими как язык Си. C был разработан AT & T Bell для реализации Unix с языком, который может быть таким же быстрым, как сборка, но переносимым на другое оборудование, и большая часть POSIX является расширением стандарта C.
Что касается самого ядра, вы часто найдете такую концептуальную диаграмму, как эта, чтобы проиллюстрировать то, чем традиционно было ядро UNIX:

Вот некоторые выдержки из классической книги господина Баха (1986), в которой обсуждаются основы ядра UNIX System V:
Однако все они [прикладные подсистемы и программы] используют низкоуровневые сервисы, в конечном итоге предоставляемые ядром, и пользуются этими сервисами с помощью набора системных вызовов. В System V имеется около 64 системных вызовов, из которых менее 32 часто используются. У них есть простые опции, которые делают их простыми в использовании, но предоставляют пользователю много возможностей. Набор системных вызовов и внутренние алгоритмы, которые их реализуют, образуют тело ядра [...]
[...] два его главных компонента - файловая подсистема и подсистема процессов.
Файлы организованы в файловые системы, которые рассматриваются как логические устройства; физическое устройство, такое как диск, может содержать несколько логических устройств (файловых систем). Каждая файловая система имеет суперблок, который описывает структуру и содержимое файловой системы, а каждый файл в файловой системе описывается индексом, который дает атрибуты файла. Системные вызовы, которые манипулируют файлами, делают это через inode. [и буферный пул]
[...] Существует две версии inode: копия диска, которая хранит информацию inode, когда файл не используется, и внутренняя копия, которая записывает информацию об активных файлах.
Выполнение пользовательских процессов в системах UNIX разделено на два уровня: пользовательский и ядро. Когда процесс выполняет системный вызов, режим выполнения процесса изменяется от пользовательского режима в режим ядра : операционная система выполняет и попытку обслужить запрос пользователя [...]
[...] философия системы UNIX заключается в предоставлении примитивов операционной системы, которые позволяют пользователям писать небольшие модульные программы, которые можно использовать в качестве строительных блоков для создания более сложных программ. Одним из таких примитивов, видимых пользователям оболочки, является возможность перенаправления ввода / вывода .
[...] В дополнение к обслуживанию системных вызовов ядро ведет общую бухгалтерию для сообщества пользователей, управляя расписанием процессов, управляя хранением и защитой процессов в основной памяти, выставляя прерывания, управляя файлами и устройствами и заботясь о системных ошибках. условия.
Если вас интересуют различные реализации ядер в Unix-подобных операционных системах, вы также можете взглянуть на реализацию FreeBSD (4.4BSD) или на ядро Mach или посмотреть на сравнение этих возможностей.
Чем больше вы знаете о дизайне UNIX, тем больше вы понимаете, что произошло на следующей диаграмме о происхождении UNIX и его истории . Г-н Бах в своей книге говорит в основном о Системе V, но также обсуждает BSD:

Это больше, чем кажется на первый взгляд . Например, Mac OSX сертифицирована UNIX03, но вы видите, что он подключен к любому из чистых UNIX (в основном красным)?

Выше вы можете увидеть, как BSD, GNU, Microsoft и другие люди внесли свой вклад в эту вселенную. Хотя GNU и, в конечном счете, linux не имеют прямого отношения к UNIX, вы видите, что GNU - это попытка реорганизовать в мире открытого исходного кода инструменты и программное обеспечение из коммерческой UNIX, которые стали закрытыми. Таким образом, рассмотрение программного обеспечения, поддерживаемого GNU, дает представление, например, о первоначальных прототипных приложениях и библиотеках.
Лицензионные войны сыграли свою роль в эволюции (и иногда стагнации) UNIX. Вы можете сразу увидеть, что UNIX выстроены в соответствии с типом лицензии - закрытая или BSD ( BSD позволяет создавать код с закрытым исходным кодом ... см. OSX) и GPL, что позволяет Linux и GNU дополнять себя в мире авторского лева. Вот классическая карта ядра Linux, изначально разработанная Линусом Торвальдсом, которая также показывает, что ядро «может» быть в Unix-подобной операционной системе:

Это намекает на мысль о том, что тип конструкции « ядро » - это не то, что делает стандарт UNIX или что определяет Unix-подобную ОС. Об этом свидетельствует тот факт, что многие unix-подобные ОС могут иметь либо монолитное ядро, либо микроядро - монолитный был классическим типом разработки для UNIX. На самом деле, даже в чистых UNIX, HPUX имеет монолитное ядро, тогда как AIX использует микроядро. Эта дискуссия о дизайне связана с производительностью и не связана с происхождением или идентичностью Unix. С другой стороны, существует традиционный концептуальный подход к предоставлению сервисов программному обеспечению, работе с файловыми системами и т. Д. В операционных системах UNIX / unix.
Я полагаю, что такие соображения добавят контекст к части OS вашего вопроса.