Майкл Джонсон - Разработка приложений в среде Linux. Второе издание

Однако исходные серии стандартов POSIX были не полностью завершены. Например, основные концепции UNIX вроде процессов считались необязательными. Более полный стандарт прошел через несколько версий и названий (например, серия стандартов руководства по переносимости X/Open(X/Open Portability Guide — XPG)) перед тем, как был переименован в одиночную спецификацию Unix(Single Unix Specification — SUS), выпущенную The Open Group(владельцем торговой марки UNIX). SUS после нескольких пересмотров была принята IEEE как самая новая версия стандарта POSIX, в настоящее время это IEEE Std 1003.1-2004 [25], и время от времени обновлялась несколькими поправками. IEEE Std 1003.1-2003 был также принят в качестве стандарта ISO/IEC 9945-2003. Самую новую онлайновую версию этого стандарта можно найти по адресу http://www.unixsystems.org/.

Более ранние стандарты, на основе которых был создан этот обновленный унифицированный стандарт, включают все ранние стандарты IEEE Std 1003.1 (POSIX.1 — программный интерфейс С), IEEE Std 1003.2 (POSIX.2 — интерфейс оболочки), а также все связанные стандарты POSIX наподобие расширений реального времени, определенных как POSIX.4, которые позже были переименованы в POSIX.1b, и несколько черновых стандартов.

Поскольку "POSIX" и "SUS" теперь являются синонимами, на комбинированную работу в этой книге мы будем ссылаться как на POSIX.

"Широта выбора — самое лучшее качество, присущее стандартам". [1] Andrew Tanenbaum, Computer Networks, Prentice Hall, 1981, стр. 168. К услугам разработчиков Linux была двадцатилетняя история Unix, но более важным является то, что справочными материалами им служили высококачественные стандарты. Изначально Linux разрабатывался в соответствии с POSIX; там, где не было POSIX, Linux следовала практике System V, за исключением организации сетей, где и системные вызовы, и организация сетей придерживались намного более популярной модели BSD. Теперь, когда существует объединенный стандарт SUS/POSIX, дальнейшее развитие обычно совместимо с более новым стандартом POSIX, а прошлые отклонения от него по возможности откорректированы.

Самым существенным отличием между SVR4 и Linux с точки зрения программирования является то, что Linux не предоставляет столько же дублированных программных интерфейсов. Например, даже программисты, занимавшиеся написанием кода исключительно для систем SVR4, предпочитали сокеты Беркли интерфейсу транспортного уровня (TLI) из SysV; Linux избегает накладных расходов TLI и предоставляет только сокеты.

Когда доступных стандартов (официальных, де-юре , и неофициальных, де-факто ) недостаточно для реализации, Linux иногда предлагает свои собственные расширения, не учитывающие POSIX. Например, асинхронная POSIX-спецификация асинхронного ввода-вывода в большинстве случаев рассматривается как неадекватная для многих реальных приложений, поэтому в Linux реализован стандарт POSIX как оболочка для более общей и полезной реализации. Также не существует общей спецификации для высоко масштабируемого интерфейса опроса ввода-вывода, поэтому был разработан и добавлен совершенно новый интерфейс epoll. Мы обратимся к этим нестандартным интерфейсам, как только они будут документированы.

Новички в мире свободного ПО часто смущены большим количеством лицензий, с ним связанных. Некоторые приверженцы свободного ПО превращают нормальные слова в жаргон и ожидают понимания всех нюансов, связанных с каждым элементом жаргона.

Для написания и распространения ПО, работающего на свободной платформе, такой как Linux, необходимо ориентироваться в лицензиях и авторском праве. Эти понятия часто путаются интеллигентными и образованными людьми, среди которых находятся и приверженцы свободного ПО. Если вы намереваетесь написать свободное или коммерческое ПО, вы будете работать с инструментами, сопровождаемыми множеством лицензионных условий. Общее понимание сферы авторского права и лицензирования поможет избежать распространенных ошибок.

В эти спорные времена крайне необходимо предупредить вас о том, что мы не являемся юристами. Глава отражает наше понимание обсуждаемых проблем, но не предлагает юридических советов. Перед тем, как принимать решения относительно вашей или чьей-либо интеллектуальной собственности, следует более глубоко изучить проблему и в случае необходимости проконсультироваться с юристом.

Сначала рассмотрим более простую проблему. Авторское право(copyright) — это простая защита владения определенными видами интеллектуальной собственности. В соответствии с новейшими соглашениями об авторском праве вам даже не понадобится требовать авторских прав на создаваемый вами материал. Пока вы явно не откажетесь от права собственности, другим лицам будет разрешено использовать вашу интеллектуальную собственность только в строго определенном порядке, называемом законным использованием, пока вы явно не предоставите им разрешение, называемое лицензией, на другие действия. Так что если вы напишете книгу или элемент ПО, вам не нужно помещать на них фразу типа "copyright © год ", чтобы получить право собственности на них. Однако если вы не поместите эту фразу в свою работу, вам будет намного сложнее требовать защиты права собственности в суде, если кто-то нарушит либо ваши авторские права (заявляя о том или действуя так, как будто вам не принадлежат авторские права), либо ваши лицензионные условия.