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