Una aplicación portátil ( portable app ), a veces también llamada independiente , es un programa diseñado para funcionar sin cambiar otros archivos ni requerir la instalación de otro software. De esta manera, se puede agregar, ejecutar y eliminar fácilmente desde cualquier computadora compatible sin configuración ni efectos secundarios. [1]
En términos prácticos, una aplicación portátil a menudo almacena datos creados por el usuario y ajustes de configuración en el mismo directorio en el que reside. Esto facilita la transferencia del programa con las preferencias y los datos del usuario entre diferentes computadoras. Un programa que no tiene opciones de configuración también puede ser una aplicación portátil. [1]
Las aplicaciones portátiles se pueden almacenar en cualquier dispositivo de almacenamiento de datos , incluido el almacenamiento masivo interno , un recurso compartido de archivos , el almacenamiento en la nube o el almacenamiento externo, como unidades USB y disquetes , almacenando sus archivos de programa y cualquier información y datos de configuración solo en el medio de almacenamiento. Si no se requiere información de configuración, se puede ejecutar un programa portátil desde un almacenamiento de sólo lectura, como CD-ROM y DVD-ROM . Algunas aplicaciones están disponibles en versiones instalables y portátiles.
Algunas aplicaciones que no son portátiles de forma predeterminada admiten la portabilidad opcional a través de otros mecanismos, siendo los más comunes los argumentos de línea de comandos . Los ejemplos podrían incluir /portablesimplemente indicar al programa que se comporte como un programa portátil o --cfg=/path/inifileespecificar la ubicación del archivo de configuración.
Como cualquier aplicación, las aplicaciones portátiles deben ser compatibles con el hardware y el sistema operativo del sistema informático .
Dependiendo del sistema operativo, la portabilidad es más o menos compleja de implementar; Para sistemas operativos como AmigaOS , todas las aplicaciones son por definición portátiles.
La mayoría de las aplicaciones portátiles no dejan archivos ni configuraciones en la computadora host ni modifican el sistema existente y su configuración. Es posible que la aplicación no escriba en el registro de Windows [2] ni almacene sus archivos de configuración (como un archivo INI ) en el perfil del usuario , pero hoy en día, muchos portátiles sí lo hacen; Muchos, sin embargo, todavía almacenan sus archivos de configuración en el directorio portátil. Otra posibilidad, dado que las rutas de los archivos a menudo diferirán al cambiar de computadora debido a la variación en las asignaciones de letras de unidad , es que las aplicaciones portátiles puedan almacenarlas en un formato relativo . Si bien algunas aplicaciones tienen opciones para admitir este comportamiento, muchos programas no están diseñados para hacerlo. Una técnica común para este tipo de programas es el uso de un programa de inicio para copiar las configuraciones y archivos necesarios a la computadora host cuando se inicia la aplicación y moverlos nuevamente al directorio de la aplicación cuando se cierra.
Una estrategia alternativa para lograr la portabilidad de las aplicaciones dentro de Windows, sin requerir cambios en el código fuente de la aplicación, es la virtualización de la aplicación : una aplicación se "secuencia" o "empaqueta" contra una capa de tiempo de ejecución que intercepta de forma transparente sus llamadas al sistema de archivos y al registro, y luego las redirige a otras. almacenamiento persistente sin el conocimiento de la aplicación. Este enfoque deja la aplicación sin cambios, pero portátil.
El mismo enfoque se utiliza para componentes individuales de la aplicación: bibliotecas de tiempo de ejecución , componentes COM o ActiveX , no sólo para toda la aplicación. [3] Como resultado, cuando los componentes individuales se portan de tal manera, pueden: integrarse en aplicaciones portátiles originales, crear instancias repetidas (instalar virtualmente) con diferentes configuraciones/valores en el mismo sistema operativo (SO) sin conflictos mutuos. Como los componentes trasladados no afectan a las entidades relacionadas protegidas por el sistema operativo (registro y archivos), los componentes no requerirán privilegios administrativos para la instalación y administración.
Microsoft vio la necesidad de un registro específico de la aplicación para su sistema operativo Windows ya en 2005. [4] Eventualmente incorporó parte de esta tecnología, utilizando las técnicas mencionadas anteriormente, a través de su base de datos de compatibilidad de aplicaciones [5] usando su Detours [ 6] biblioteca de códigos, en Windows XP. No puso a disposición ninguna de estas tecnologías a través de las API de su sistema .
Los programas escritos con una base similar a Unix en mente a menudo no hacen suposiciones. Mientras que muchos programas de Windows asumen que el usuario es un administrador , algo muy frecuente en los días de Windows 95 / 98 / ME (y hasta cierto punto en Windows XP / 2000 , aunque no en Windows Vista o Windows 7 ), esto rápidamente resultaría en Errores de "permiso denegado" en entornos tipo Unix, ya que los usuarios estarán en un estado sin privilegios con mucha más frecuencia. Por lo tanto, los programas generalmente están diseñados para utilizar la HOME variable de entorno para almacenar configuraciones (por ejemplo, $HOME/.w3mpara el navegador w3m ). El vinculador dinámico proporciona una variable de entorno LD_LIBRARY_PATHque los programas pueden usar para cargar bibliotecas desde directorios no estándar. Suponiendo que /mntcontiene los programas portátiles y la configuración, una línea de comando puede verse así:
HOME=/mnt/home/user LD_LIBRARY_PATH=/mnt/usr/lib /mnt/usr/bin/w3m www.example.com
Se puede lograr una aplicación Linux sin necesidad de interacción del usuario (por ejemplo, adaptar un script o una variable de entorno) en diferentes rutas de directorio con la opción GCC Linker$ORIGIN , que permite una ruta de búsqueda de biblioteca relativa. [7]
No todos los programas respetan esto; algunos ignoran por completo $HOME y en su lugar realizan una búsqueda por parte del usuario /etc/passwdpara encontrar el directorio de inicio, lo que frustra la portabilidad.
También hay formatos de paquetes entre distribuciones que no requieren derechos de administrador para ejecutarse, como Autopackage , klik (ahora llamado AppImage) o CDE, pero que solo obtuvieron aceptación y soporte limitados en la comunidad Linux en la década de 2000. [8] [9] [10] Alrededor de 2015, la idea de un paquete portátil y de distribución independiente para el ecosistema Linux cobró más fuerza cuando Linus Torvalds discutió este tema en la DebConf 2014 y luego respaldó AppImage para su aplicación de registro de buceo Subsurface . [11] [12] [13] Por ejemplo, MuseScore y Krita siguieron en 2016 y comenzaron a utilizar compilaciones de AppImage para la implementación de software. [14] [15] RedHat lanzó en 2016 el sistema Flatpak , que es un sucesor del proyecto glick de Alexander Larsson, que se inspiró en klik (ahora AppImage). [16] De manera similar, Canonical lanzó en 2016 paquetes Snap para Ubuntu y muchas otras distribuciones de Linux.
Muchas aplicaciones de Mac que se pueden instalar arrastrando y soltando son inherentemente portátiles como paquetes de aplicaciones de Mac. [17] Los ejemplos incluyen Mozilla Firefox , Skype y Google Chrome , que no requieren acceso de administrador y no necesitan estar ubicados en un área central restringida. Las aplicaciones ubicadas en /Users/username/Applications( ~/Applications) se registran en macOS LaunchServices de la misma manera que las aplicaciones ubicadas en la /Applicationscarpeta principal. Por ejemplo, al hacer clic derecho en un archivo en Finder y luego seleccionar "Abrir con..." se mostrarán las aplicaciones disponibles tanto en /Aplicaciones como en ~/Aplicaciones. Los desarrolladores pueden crear instaladores de productos Mac que permiten al usuario realizar una instalación en el directorio principal, con la etiqueta "Instalar solo para mí" en la interfaz de usuario del instalador. [18] Dicha instalación la realiza el usuario.
Puede utilizar una palabra clave especial $ORIGIN para decir "relativo a la ubicación real del ejecutable". De repente descubrimos que podíamos usar -rpath $ORIGIN/lib y funcionó. El juego cargaba las bibliotecas correctas, por lo que era estable y portátil, ¡pero ahora también estaba completamente en el espíritu de la LGPL y en la letra!
La comunidad Linux, en su infinita sabiduría, procede a incendiar CDE. [...] "Todos deberíamos utilizar la gestión de paquetes". Esto es lo que quiero decir, y que mis palabras bajen desde las cimas de las montañas, escritas en diminutas tablillas de piedra: La gestión de paquetes no es una panacea universal.
Si Hearn tiene razón, la verdadera lección de Autopackage no es cómo mejorar la instalación de software, sino la dificultad (quizás la imposibilidad) de cambios a gran escala en la arquitectura Linux en una etapa tan tardía de su historia. Es una conclusión aleccionadora y decepcionante para un proyecto que alguna vez pareció tan prometedor.
Lo he visto de primera mano en el otro proyecto en el que estoy involucrado, que es mi aplicación de registro de inmersiones. Creamos binarios para Windows y OSX, básicamente no creamos binarios para Linux. ¿Por qué? Porque crear archivos binarios para aplicaciones de escritorio de Linux es un puto dolor de cabeza.
Finalmente pude jugar con la versión "AppImage" de +Subsurface, y realmente parece "funcionar".
Yo, como mantenedor de la aplicación, ya no quiero que mi aplicación esté incluida en una distribución. Demasiado dolor para una ganancia absolutamente nula. Cada vez que recibo un informe de error, mi primera pregunta es "oh, ¿qué versión de qué distribución? ¿Qué versión de qué biblioteca? ¿Qué conjunto de parches locos se aplicaron a esas bibliotecas?". No, Windows y Mac lo hacen bien. Controlo las bibliotecas con las que se ejecuta mi aplicación. [...] Con una AppImage puedo darles precisamente eso. Algo que se ejecuta en su computadora.