Разработка приложений в среде 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.4. Происхождение Linux

"Широта выбора — самое лучшее качество, присущее стандартам".[1] К услугам разработчиков 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. Мы обратимся к этим нестандартным интерфейсам, как только они будут документированы.

Глава 2 Лицензии и авторские права

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

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

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

2.1. Авторское право