Дистрибутивы Linux состоят из кубиков-пакетов, связанных между собой определёнными зависимостями и хранящихся в специальных архивах — репозиториях. При обновлении программ разработчикам приходится тестировать кучу сопутствующего софта, чтобы на выходе не получить конфликтов. К такой ситуации все привыкли, и большинство пользователей она устраивает. Однако в действительности она далека от идеала.
Недавно я пытался установить экспериментальную сборку GIMP в Ubuntu 11.10 из репозитория PPA на сервисе Launchpad и не смог этого сделать без риска сломать основную рабочую ОС. Из-за проблем с зависимостями нужно было подключать другие репозитории и обновлять важные системные компоненты, что чревато новыми программными конфликтами. Не знаю как вам, а мне подобная ситуация кажется нарушением если не буквы, то духа пресловутых четырёх свобод. Судите сами: в свободном дистрибутиве я не могу использовать свободную программу по своему усмотрению.
Парадоксально, но проще всего оказалось установить экспериментальный GIMP в Windows: для этого достаточно было запустить скачанный с sourceforge инсталлятор. И никаких тебе проблем с зависимостями. Понятно, что можно держать на машине VirtualBox с тестовыми ОС, но зачем это простым пользователям настольных дистрибутивов? Им ведь требуется немногое — всего лишь возможность поставить любую прикладную программу, не рискуя сломать рабочую систему. А разработчики предлагают варианты для гиков, вроде дистрибутивов с непрерывным циклом обновлений или использования виртуализации. Слава богу, что собирать ПО вручную уже не заставляют. И зачем делать выбор между новизной и стабильностью софта, рискуя работоспособностью системы, когда нужно всего одно нестабильное приложение? В проприетарных ОС проблема стоит не так остро. Получается, что с точки зрения простых пользователей они более «свободны»?
Проблема даже не в том, что Linux собирается из кубиков, как конструктор Lego, а в Windows и Mac OS X есть базовая ОС и сторонние приложения. Это технические нюансы. Во FreeBSD основная ОС тоже не разбита на кучу мелких блоков, а программы ставятся из портов/пакетов. Проблем с зависимостями там не меньше. Дело в количестве кубиков, которые пытаются контролировать разработчики дистрибутива. Когда их счёт идёт на десятки тысяч, начинаются сложности не то что с нововведениями, с простым обновлением некоторых пакетов. Про то, сколько усилий нужно приложить авторам программы или сборщикам пакета (если авторы не хотят сами этим заниматься), чтобы она попала в репозиторий, я уже не говорю. Они вынуждены следить за работоспособностью огромного множества сопутствующих продуктов. Различные сервисы автосборки и сторонние репозитории здорово помогают, но они не решают проблему полностью в ситуации, когда кроме установки самого приложения приходится с риском для «жизни» обновлять связанные с ним компоненты системы. Непрерывный цикл обновлений всего архива пакетов тоже не вариант, поскольку одновременно с возможностью пробовать новое хочется стабильности системы.
Решить проблему можно только в том случае, если принципиально изменить конструкцию дистрибутива. Необходимо уменьшить количество контролируемых его разработчиками кубиков с зависимостями и сформировать из них небольшую базовую систему (при этом совершенно неважно, будет она состоять из отдельных пакетов или нет, это частности) с хорошо стандартизированными API и ABI. Любые дополнительные пакеты (не имеет значения, контролируются они некой компанией вроде Canonical или независимым сообществом) не должны при установке или обновлении требовать обязательного обновления других пакетов. Кроме того, необходимо по возможности сохранять совместимость интерфейсов между версиями базовой системы.
Не хотелось бы приводить пример Mac OS X, где этой проблемы не существует, — едва ли используемые там методы можно адекватно перенести в Linux. Но почему бы не позаимствовать принцип? Тем более что один удачный пример подобного заимствования в мире СПО есть — это PC-BSD. Она основана на базовой ОС FreeBSD, а для установки программ там используются разработанные в рамках проекта средства — фирменный формат пакетов PBI и собственный репозиторий pbidir.com. В пакет PBI включаются все необходимые библиотеки, что убирает трудности с зависимостями и позволяет инсталлировать приложения без риска сломать систему, но приводит к увеличению используемого дискового пространства. В последней версии продукта эта проблема решена: появилась возможность совместного использования файлов и библиотек различными пакетами.
Для перевода дистрибутивов Linux на подобный подход потребуется огромная работа (стратегию придумать проще всего, с тактикой все куда сложнее), но делать её необходимо. Лично мне уже надоела шаткая, построенная из огромного множества цепляющихся друг за друга элементов система. Она напоминает карточный домик: конструкция выглядит красиво, пока нет потребности заменить один из её элементов, не трогая остальные.
Евгений Крестников
Ещё пару абзацев, и товарищ изобрёл бы виртуальные машины ;-)))
Еще один горе-линуксоид, который ничего не понимает в идеях, заложенных в основу свободного софта, но уже предлагает "принципиально изменить конструкцию дистрибутива". По этой же причине возникают бредовые мысли о большей свободе проприетарного софта.
На самом деле, если хотя бы несколько часов потратить на чтение документации, то все становится на свои места. Никто не заставляет пользоваться только репозиторием. Если так хочется опробовать экспериментальную версию (а она, кстати, предназначена для специалистов, а не для графоманствующих ламеров), то можно скачать исходный код, скомпилировать его и установить в изолированную директорию с любыми версиями библиотек.
А в чем тут проблема? Я вижу тут только большую гибкость. Если эта гибкость не нужна непосредственно автору креатива, то зачем себя насиловать и продолжать пользоваться Линуксом?
По факту, автор предлагает заморозить развитие Линукса, а разработчикам осознано использовать старые версии библиотек.
Так в чем проблема? В магазине Windows отказываются продать? А система она на то и система, чтобы ее составные части взаимодействовали друг с другом. Интересно, а что сам автор понимает под этим словом? ;)
Причина, по которой автор вышележащего поста конкретно жаловался на разработчиков линуксового софта, состоит не в наличии этой системы в целом, а в ряде не самых оптимальных решений, принятых мейнтейнерами репозиториев.
Во-первых, держать несколько библиотек разных версий в линуксе можно. Именно для этого, кстати, им в конце имён придумали вставлять номера версий. Взгляните в /usr/lib/, и вы увидите:
libboost_iostreams-mt.a
libboost_iostreams-mt.so
libboost_iostreams.so
libboost_iostreams.so.1.42.0
libboost_iostreams.so.1.48.0
libboost_program_options.a
libboost_program_options-mt.a
libboost_program_options-mt.so
libboost_program_options.so
libboost_program_options.so.1.48.0
libboost_python-py26.so.1.42.0
libboost_python-py26.so.1.46.1
libboost_python-py27.so.1.42.0
libboost_python-py27.so.1.46.1
libboost_python-py32.so.1.46.1
libboost_random.so.1.48.0
libboost_regex.a
libboost_regex-mt.a
libboost_regex-mt.so
libboost_regex.so
libboost_regex.so.1.46.1
libboost_regex.so.1.48.0
libboost_serialization.a
libboost_serialization-mt.a
Библиотеки Boost 1.42.0 и 1.46.1 успешно сосуществуют с 1.48.0.
Проблема же в том, что то же самое должно быть и в репозитории -- если библиотека отличается своим ABI от прошлых версий, то и лежать она должна в отдельном пакете, а зависимости к библиотекам не должны иметь прописанных версий. Ну и, естественно, они не должны из этого репозитория удаляться до тех пор, когда исчезнут последние зависимые приложения (в эпоху Ubuntu и проприетарных разработчиков, которые хотят писать код быстро, в больших объёмах и не обращать внимание на поддержку уже написанного кода, это особенно верно).
И если данный принцип будет соблюдаться, то про проблемы с обновлением софта можно будет забыть.
Мало того, значительно повысится стабильность дистрибутива, как и облегчится работа проприетарных разработчиков, которым не надо будет переписывать весь свой софт при выходе новых версий библиотек или (о, ужас!) их статически линковать.
gentoo stage3, арчевский набор base, debian овская минимальная система(в убунте тоже самое) - есть такая партия
Невозможность держать несколько версий одной программы — это не правильно! Вот захотел я поставить ZSNES на x86_64 Oneiric — вот но в синаптике: клик-клик, и что? Мне предлагают снести Gimp и VLC ибо нельзя иметь lib-чего-то-там и lib-чего-то-там:i386 одновременно. Ха-ха, и что я сделал? Скачал виндовую версию, запустил под вайном и заработало!
Почему надо иметь эти жёсткие пути? Почему нельзя иметь базу библиотек с версиями и атрибутами, чтобы программа выбирала что нужно? Почему нельзя избавиться от файловой системы?
Надуманная проблема. Хотите иметь несколько версий библиотек в системе без лишних заморочек? Переходите на rpm-дистрибутив. У проприетарных разработчиков проблемы? Да нет у них никаких проблем. Линкуют все статически как в винде и о существовании новых версий библиотек вообще не думают. Все ставится в домашнюю папку и работает на любом дистрибутиве. Не вижу опять же каких-то трудностей. Единственный недостаток - лишнее место на диске занято, но 1) оно сейчас дешево, 2) виндоюзеры ниразу не жаловались. Проблема со старым проприетарным софтом бывает как раз, если он слинкован динамически, а этой версии библиотеки в вашем дистрибутиве уже давно нет, но тут опять же rpm вам в помощь или можно собрать пакет со старой библиотекой под новым названием и он не будет конфликтовать с текущей версией.
Отправить комментарий