Зачему нужны "зависимости" в свободном ПО?

()

Что делают зависимости в свободном ПО?

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

Что же такое "зависимости"?

Если коротко, зависимости означают что одна программа (пакет) чтобы работать правильно, нуждается в другой программе. Это не знакомо пользователям Windows, т.к. большинство программ в Windows в других программах не нуждается (кроме некоторых случаев. Например видео-плеерам нужны кодеки). В GNU/Linux часто можно видеть что программные пакеты не независимы и для работы требуют сторонние библиотеки или сторонние утилиты. Это может привести к ситуации когда одна программа требует специальной версии другой программы, которая в системе недоступна. Проблема зависимостей частично решена в большинстве известных дистрибутивов с помощью "пакетных менеджеров". Пакетные менеджеры заботятся об установленном ПО и пытаются разрешить все зависимости автоматически, используя большие программные хранилища и информацию о пакетах.

Свободное ПО против проприетарного ПО.

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

  • Свободное программное обеспечение - программы которые обычно выпускаются под лицензией GPL или BSD. Пользователи могут получить их из Интернета. Благодаря либеральной лицензии на исходный код, программисты могут их модифицировать и распространять свои собственные версии. Примеры: OpenOffice, Firefox, ядро Linux, OpenSSH, Eclipse тысячи других.
  • Проприетарное ПО - это программы которые принадлежат одной конкретной компании, которая даёт пользователям права на ... простое использование. И даже на простое использование налагаются ограничения. Примеры: MS Office, Photoshop, Opera, IntelliJ Idea и многие другие.

Процесс создания обоих типов очень различается и требуется объяснить как зависит способ использования ПО от его создания.

Процесс создания несвободного ПО.

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

Обратной стороной такого подхода является плохое взаимодействие с внешними средствами, медленный процесс разработки, плохая обратная связь и большой размер.

Плохое взаимодействие с внешними средствами

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

Медленный процесс разработки.

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

Плохая обратная связь.

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

Больший размер

Из-за сборки собственных библиотек и средств в единый пакет, размер такого пакета обычно больше чем программы с открытыми исходниками. Фактически большинство программ которые получает пользователь содержат различную реализацию одной и той же библиотеки. Система становится больше и больше, пользователь теряет контроль.

Процесс создания свободного ПО.

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

Звучит непонятно? Не беспокойтесь, у нас есть примеры:
Примеры из жизни

  • k3b и GnomeBaker - популярные программы для записи CD/DVD. Но подождите секундочку, они не запишут ни одного CD оставь их одних. Все что они делают - это используют консольные средства от третьих сторон, такие как cdrecord или cdrdao для задач записи, и многие другие (dvd+rw-tools, cdparanoia и т.д.) для дополнительных задач. Эти программы это лишь "морды" для управления настройками и упрощения использования.
  • Firefox, SeaMonkey, Epiphany или Galleon - веб-броузеры которые различно выглядят, но все они используют один и тот же "движок" для рендеринга страниц: Gecko. Без него, они бы не смогли отобразить не единой страницы.
  • Kaffeine и Totem - отличные мультимедиа проигрыватели для KDE и GNOME. Все что они делают - просто предоставляют контейнер для различных мультимедиа движков. (таких как xine или gstreamer). Эти "морды" выглядят различно но используют один и тот же движок для проигрывания видео или музыки! Кроме того, эти движки используют другие внешние программы, которые называются "кодеками", для раскодирования мультимедиа потока.

Можно найти сотни таких примеров в мире GNU/Linux. Практически все программы Linux используют другие приложения для выполнения различных задач. Это отличная причина зависимостей ПО. Одна программа использует другую для выполнения некоторых задач, только потому что программисты стали достаточно умными (достаточно ленивыми) чтобы использовать работу других людей, вместо того чтобы изобретать в сотый раз велосипед.

Проблемы с зависимостями.

Зависимости имеют свои плохие стороны. Это особенно заметно когда разработчик (или кто-нибудь другой ответственный за сборку программы) плохо определяет зависимость приложения (т.е. не определяет точную версию внешнего приложения которое использует программа). Это может привести к тому что при установке приложения нужные внешние программы не установятся и при работе появятся много ошибок расстраивающих пользователя.

Есть два решения этой проблемы:

  • статическая сборка
  • использования хорошего пакетного менеджера.

Статическая сборка означает что программа собирается со всеми зависимостями. Это делает её намного больше в размере и приводит к установке сотни версий одной и той же библиотеки. Несмотря на это, статическая сборка используется в некоторых операционных системах, например PC-BSD, так как это полностью устраняет проблему зависимостей.

Альтернативой статической сборки является использование хорошего пакетного менеджера - программы которая автоматически заботится о зависимостях ваших программ, когда вы устанавливаете или обновляете приложения. Например Smart Package Manager, которая следит за различными форматами пакетов и различными репозиториями и отлично работает в большинстве популярных дистрибутивов GNU/Linux. Правильно сконфигурированный Smart может полностью устранить плохие стороны использования пакетного подхода. Альтернативой Smart служат встроенные в каждый дистрибутив пакетные менеджеры, такие как APT, yum, urpmi, pacman и другие.

В завершение.

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

Оригинал

Подписаться на обновления: RSS-лента Канал в TamTam Telegram канал Канал в ICQ

Комментарии:

Killy 2006-10-15 23:15:27 (#)

Вроде же возможно использование отдельных OSS модулей в закрытом ПО, еси они подключаются снаружи (в виде плагинов, например)? Конфликт лицензий возникает, если открытые наработки используются внутри закрытого кода.

Если я неправ - поправьте.

MooSE 2006-10-16 10:06:50 (#)

Killy, ты прав. Но к сожалению D-Link например плевали на всякие лицензии... Отсюда и проблемы...

Svolotch 2006-10-16 10:51:51 (#)

>>Это не знакомо пользователям Windows, т.к. большинство программ в Windows в других программах не нуждается
врете все... они как минимум нуждаются в видовсе :))) а так же зачастую нужен последний директХ, фремворк и т.п.
лось превед!

Killy 2006-10-16 11:04:07 (#)

Svolotch:
>>...они как минимум нуждаются в видовсе...

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

LilFox 2006-10-16 15:32:47 (#)

Использование проприетарного продукта ограничевается лицензией по которому он распространяется, соответственно даже использовать код dll наврядли удастся сторонним разработчикам, потому великов на любой вкус найти можно.
Кстати про это тоже не сказали, скажу я по быстрому

Единственный интерфейс который отлично представлен (лучще других) - это winapi, собственно среды на него ориентированые, ms vc++, остальное до его уровня может и не дотянуть, если от проъекта требуется мобильность и размер исполнимых файлов ( ведь скорость работы программы тоже является главенствующим фактором ).

Вытекает это как раз из модели проприетарного ПО, то даже =) если у вас есть новый велик, возможно более удобный в api для конкретного вида задач, компания разработчик OS может его и не включить..

Суть я думаю ясна, все представлено в единственном экзэмпляре.

MooSE 2006-10-18 00:05:09 (#)

> так же зачастую нужен последний директХ, фремворк и т.п.

В кои-то веки ты поддержал линухоидов:)

MooSE 2006-10-18 11:18:01 (#)

С чисто технической точки зрения, WinAPI вполне позволяет реализовивать "пакетный" подход создания ПО, но дело-то как раз в том, что такой метод НЕ ХОТЯТ использовать под Виндой.
Просто исторически так сложилось, что правилом Хорошего Тона (что не пустой звук для хороших прогшраммеров) стало именно "делать самому", вместо "полагаться на других".

В этом плане Линукс имеет большую фору. Пакетные менеджеры действительно убирают все минусы "пакетного" подхода.
Я использую Gentoo и его система Portage удовлетворяет все мои пожелания к управлению пакетами (особенно в плане обновлений - файлы конфигурации от части обновляет сама, отчасти это делает делать Root).

В плане OpenSource и PropSource - не надо делить мир на "Черное и Белое" - есть ещё и оттенки! Не всё то, что коммерческое - плохо, и не всё то, что открытое - хорошо. Тем кто ищет - всегда доступен Разумный Компромис.
Я прекрасно использую вместе и то и другое, например - Линукс, КДЕ, Java и Opera 9.
По долгу службы поднимал сервер на Линуксе, на котором стоит коммерческая Биллинговая Система (УТМка 5).

В Буддизме есть такое понятие "средний путь" - не надо впадать в крайности, ибо компромис можно найти, если пытаться его найти.
Новый комментарий

Жирный текстКурсивный текстПодчёркнутый текстЗачёркнутый текстПрограммный кодСсылкаИзображение




© 2006-2024 Вадим Калинников aka MooSE
Политика конфиденциальности