Портативное приложение ( portable app ), иногда также называемое автономным программным обеспечением , представляет собой компьютерную программу, разработанную для работы без изменения других файлов или требующую установки другого программного обеспечения. Таким образом, его можно легко добавлять, запускать и удалять с любого совместимого компьютера без настройки или побочных эффектов. [1]
На практике портативное приложение часто хранит созданные пользователем данные и параметры конфигурации в том же каталоге, в котором оно находится. Это упрощает перенос программы с настройками и данными пользователя между разными компьютерами. Программа, не имеющая никаких параметров конфигурации, также может быть портативным приложением. [1]
Портативные приложения могут храниться на любом устройстве хранения данных , включая внутреннее запоминающее устройство , файловый ресурс , облачное хранилище или внешнее хранилище, такое как USB-накопители , флэш-накопители [2] и дискеты — сохраняя свои программные файлы и любую информацию о конфигурации и данные только на носителе. Если информация о конфигурации не требуется, портативную программу можно запустить с хранилища только для чтения, такого как CD-ROM и DVD-ROM . Некоторые приложения доступны как в устанавливаемой , так и в портативной версии.
Некоторые приложения, которые не являются переносимыми по умолчанию, поддерживают дополнительную переносимость через другие механизмы, наиболее распространенными из которых являются аргументы командной строки . Примерами могут быть /portableпросто указание программе вести себя как переносимая программа или --cfg=/path/inifileуказание местоположения файла конфигурации.
В зависимости от операционной системы, переносимость может быть более или менее сложной в реализации; в таких операционных системах, как AmigaOS , все приложения по определению переносимы.
Большинство переносимых приложений не оставляют файлы или настройки на хост-компьютере и не изменяют существующую систему и ее конфигурацию. Приложение может не записывать в реестр Windows [3] или не хранить свои файлы конфигурации (например, файл INI ) в профиле пользователя , но сегодня многие переносимые приложения делают это; многие, однако, по-прежнему хранят свои файлы конфигурации в переносимом каталоге. Другая возможность, поскольку пути к файлам часто будут отличаться при смене компьютеров из-за различий в назначении букв дисков , заключается в том, что переносимые приложения могут хранить их в относительном формате. Хотя некоторые приложения имеют параметры для поддержки такого поведения, многие программы не предназначены для этого. Распространенным приемом для таких программ является использование программы запуска для копирования необходимых настроек и файлов на хост-компьютер при запуске приложения и перемещения их обратно в каталог приложения при его закрытии.
Альтернативной стратегией достижения переносимости приложений в Windows, не требующей изменения исходного кода приложения, является виртуализация приложений : приложение «упорядочивается» или «упаковывается» в среде выполнения, которая прозрачно перехватывает его вызовы файловой системы и реестра, а затем перенаправляет их в другое постоянное хранилище без ведома приложения. Этот подход оставляет само приложение неизменным, но при этом переносимым.
Тот же подход используется для отдельных компонентов приложения: библиотек времени выполнения , компонентов COM или ActiveX , а не только для всего приложения. [4] В результате, когда отдельные компоненты переносятся таким образом, они могут быть: интегрированы в оригинальные переносимые приложения, многократно инстанцированы (виртуально установлены) с различными конфигурациями/настройками в одной и той же операционной системе (ОС) без взаимных конфликтов. Поскольку перенесенные компоненты не влияют на защищенные ОС связанные сущности (реестр и файлы), компонентам не потребуются административные привилегии для установки и управления.
Microsoft увидела необходимость в реестре, специфичном для приложений, для своей операционной системы Windows еще в 2005 году. [5] В конечном итоге она включила часть этой технологии, используя упомянутые выше методы, через свою базу данных совместимости приложений [6] с использованием своей библиотеки кода Detours [7] , в Windows XP. Она не сделала ни одну из этих технологий доступной через свои системные API .
Программы, написанные с учетом Unix-подобной базы, часто не делают никаких предположений. В то время как многие программы Windows предполагают, что пользователь является администратором — что было очень распространено во времена Windows 95 / 98 / ME (и в некоторой степени в Windows XP / 2000 , хотя не в Windows Vista или Windows 7 ) — это быстро приведет к ошибкам «Отказано в доступе» в Unix-подобных средах, поскольку пользователи будут находиться в непривилегированном состоянии гораздо чаще. Поэтому программы, как правило, разрабатываются для использования HOME переменной среды для хранения настроек (например, $HOME/.w3mдля браузера w3m ). Динамический компоновщик предоставляет переменную среды LD_LIBRARY_PATH, которую программы могут использовать для загрузки библиотек из нестандартных каталогов. Предполагая, что /mntсодержит переносимые программы и конфигурацию, командная строка может выглядеть так:
HOME=/mnt/home/user LD_LIBRARY_PATH=/mnt/usr/lib /mnt/usr/bin/w3m www.example.com
Приложение Linux без необходимости взаимодействия с пользователем (например, адаптация скрипта или переменной среды) на различных путях к каталогам может быть создано с помощью опции GCC Linker$ORIGIN , которая позволяет использовать относительный путь поиска библиотек. [8]
Не все программы учитывают это — некоторые полностью игнорируют $HOME и вместо этого выполняют поиск пользователя, /etc/passwdчтобы найти домашний каталог, тем самым нарушая переносимость.
Существуют также кросс-дистрибутивные форматы пакетов, для запуска которых не требуются права администратора, такие как Autopackage , AppImage или CDE, но которые получили лишь ограниченное признание и поддержку в сообществе Linux в 2000-х годах. [9] [10] [11] Около 2015 года идея портативной и независимой от дистрибутива упаковки для экосистемы Linux получила большую популярность, когда Линус Торвальдс обсудил эту тему на DebConf 2014 и позже одобрил AppImage для своего приложения для ведения журнала погружений Subsurface . [12] [13] [14] Например, MuseScore и Krita последовали их примеру в 2016 году и начали использовать сборки AppImage для развертывания программного обеспечения. [15] [16] В 2016 году RedHat выпустила систему Flatpak , которая является преемницей проекта Александра Ларссона glick , вдохновленного klik (теперь AppImage). [17] Аналогичным образом Canonical выпустила в 2016 году пакеты Snap для Ubuntu и многих других дистрибутивов Linux.
Многие приложения Mac, которые можно установить методом перетаскивания, по своей сути являются переносимыми как пакеты приложений Mac. [18] Примерами служат Mozilla Firefox , Skype и Google Chrome, которым не требуется доступ администратора и которые не нужно помещать в центральную ограниченную область. Приложения, помещенные в /Users/username/Applications( ~/Applications), регистрируются в macOS LaunchServices таким же образом, как и приложения, помещенные в основную /Applicationsпапку. Например, щелчок правой кнопкой мыши по файлу в Finder и последующий выбор «Открыть с помощью...» покажет приложения, доступные как из /Applications, так и из ~/Applications. Разработчики могут создавать установщики продуктов Mac, которые позволяют пользователю выполнять установку в домашний каталог, помеченную как «Установить только для меня» в пользовательском интерфейсе установщика. [19] Такая установка выполняется от имени пользователя.
Вы можете использовать специальное ключевое слово $ORIGIN, чтобы сказать "относительно фактического расположения исполняемого файла". Внезапно мы обнаружили, что можем использовать -rpath $ORIGIN/lib, и это сработало. Игра загружала правильные библиотеки, поэтому была стабильной и переносимой, но также теперь полностью соответствовала духу LGPL, а также букве!
Сообщество Linux в своей бесконечной мудрости продолжает ругать CDE. [...] «Мы все должны просто использовать управление пакетами». Вот что я хочу сказать, и пусть мои слова будут донесены с вершин гор, записанные на маленьких каменных табличках: Управление пакетами — не универсальная панацея.
Если Хирн прав, настоящий урок Autopackage заключается не в том, как улучшить установку программного обеспечения, а в сложности — возможно, невозможности — крупномасштабных изменений в архитектуре Linux на столь позднем этапе ее истории. Это отрезвляющий, разочаровывающий вывод для проекта, который когда-то казался таким многообещающим.
Я видел это своими глазами на примере другого проекта, в котором я участвую, а именно моего приложения для дайв-логов. Мы делаем двоичные файлы для Windows и OSX, но в основном не делаем двоичные файлы для Linux. Почему? Потому что создание двоичных файлов для настольных приложений Linux — это чертовски муторно.
Я наконец-то добрался до версии +Subsurface "AppImage", и она действительно, похоже, "просто работает".
Я, как сопровождающий приложения, больше не хочу, чтобы мое приложение было включено в дистрибутив. Слишком много боли за абсолютно нулевую выгоду. Когда я получаю отчет об ошибке, мой первый вопрос: "О, какая версия какого дистрибутива? Какая версия какой библиотеки? Какой набор безумных исправлений был применен к этим библиотекам?". Нет, Windows и Mac справляются с этим правильно. Я контролирую библиотеки, с которыми работает мое приложение. [...] С AppImage я могу дать им именно это. Что-то, что работает на их компьютере.