Una aplicación portátil ( aplicación portátil ), a veces también llamada software independiente , es un programa informático 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 de cualquier computadora compatible sin configuración ni efectos secundarios. [1]
En términos prácticos, una aplicación portátil suele almacenar los datos creados por el usuario y las opciones de configuración en el mismo directorio en el que se encuentra. 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 , almacenamiento en la nube o almacenamiento externo como unidades USB , memorias USB [2] y disquetes , almacenando sus archivos de programa y cualquier información de configuración y datos 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 solo lectura como CD-ROM y DVD-ROM . Algunas aplicaciones están disponibles en versiones instalables y portátiles.
Algunas aplicaciones que no son portables de manera predeterminada sí admiten la portabilidad opcional a través de otros mecanismos, siendo el más común el uso de argumentos de línea de comandos . Algunos ejemplos pueden incluir /portable
simplemente indicarle al programa que se comporte como un programa portable o --cfg=/path/inifile
especificar la ubicación del archivo de configuración.
Como cualquier aplicación, las aplicaciones portátiles deben ser compatibles con el hardware del sistema informático y el sistema operativo .
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 portables.
La mayoría de las aplicaciones portátiles no dejan archivos o configuraciones en el equipo host ni modifican el sistema existente y su configuración. La aplicación no puede escribir en el registro de Windows [3] ni almacenar sus archivos de configuración (como un archivo INI ) en el perfil del usuario , pero hoy en día, muchas aplicaciones portátiles sí lo hacen; muchas, sin embargo, aún almacenan sus archivos de configuración en el directorio portátil. Otra posibilidad, ya que las rutas de archivo a menudo diferirán en equipos cambiantes 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 dichos programas es el uso de un programa de inicio para copiar las configuraciones y archivos necesarios en el equipo 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 aplicaciones dentro de Windows, sin necesidad de cambiar el código fuente de la aplicación, es la virtualización de aplicaciones : una aplicación se "secuencia" o "empaqueta" contra una capa de tiempo de ejecución que intercepta de manera transparente sus llamadas al sistema de archivos y al registro, y luego las redirige a otro almacenamiento persistente sin el conocimiento de la aplicación. Este enfoque deja la aplicación en sí misma sin cambios, pero es portátil.
El mismo enfoque se utiliza para componentes de aplicaciones individuales: bibliotecas de tiempo de ejecución , componentes COM o ActiveX , no solo para la aplicación completa. [4] Como resultado, cuando los componentes individuales se portan de esa manera, pueden: integrarse en aplicaciones portátiles originales, instanciarse repetidamente (instalarse virtualmente) con diferentes configuraciones/ajustes en el mismo sistema operativo (OS) sin conflictos mutuos. Como los componentes portados no afectan a las entidades relacionadas protegidas por el SO (registro y archivos), los componentes no requerirán privilegios administrativos para su instalación y gestión.
Microsoft ya había detectado la necesidad de un registro específico de aplicaciones para su sistema operativo Windows en 2005. [5] Finalmente, incorporó parte de esta tecnología, utilizando las técnicas mencionadas anteriormente, a través de su base de datos de compatibilidad de aplicaciones [6] utilizando su biblioteca de código Detours [7] en Windows XP. No puso ninguna de estas tecnologías a disposición a través de sus API de sistema .
Los programas escritos con una base similar a Unix en mente a menudo no hacen suposiciones. Mientras que muchos programas de Windows suponen que el usuario es un administrador (algo muy común en la época de Windows 95 / 98 / ME (y hasta cierto punto en Windows XP / 2000 , aunque no en Windows Vista o Windows 7 ), esto daría lugar rápidamente a errores de "Permiso denegado" en entornos similares a 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 usar la HOME
variable de entorno para almacenar configuraciones (por ejemplo, $HOME/.w3m
para el navegador w3m ). El enlazador dinámico proporciona una variable de entorno LD_LIBRARY_PATH
que los programas pueden usar para cargar bibliotecas desde directorios no estándar. Suponiendo que /mnt
contiene los programas y la configuración portables, una línea de comandos podría 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 distintas rutas de directorio con la opción GCC Linker$ORIGIN
, que permite una ruta de búsqueda de biblioteca relativa. [8]
No todos los programas respetan esto: algunos ignoran completamente $HOME y en su lugar realizan una búsqueda del usuario /etc/passwd
para encontrar el directorio de inicio, lo que impide la portabilidad.
También hay formatos de paquetes entre distribuciones que no requieren derechos de administrador para ejecutarse, como Autopackage , AppImage o CDE, pero que obtuvieron solo una aceptación y soporte limitados en la comunidad Linux en la década de 2000. [9] [10] [11] Alrededor de 2015, la idea de empaquetado portátil e independiente de la distribución para el ecosistema Linux ganó más fuerza cuando Linus Torvalds discutió este tema en DebConf 2014 y respaldó más tarde AppImage para su aplicación de registro de inmersiones Subsurface . [12] [13] [14] Por ejemplo, MuseScore y Krita siguieron en 2016 y comenzaron a usar compilaciones de AppImage para la implementación de software. [15] [16] RedHat lanzó en 2016 el sistema Flatpak , que es un sucesor del proyecto glick de Alexander Larsson que se inspiró en klik (ahora llamado AppImage). [17] 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 mediante arrastrar y soltar son inherentemente portátiles como paquetes de aplicaciones de Mac. [18] Los ejemplos incluyen Mozilla Firefox , Skype y Google Chrome, que no requieren acceso de administrador y no necesitan colocarse en un área central restringida. Las aplicaciones colocadas en /Users/username/Applications
( ~/Applications
) se registran con macOS LaunchServices de la misma manera que las aplicaciones colocadas en la /Applications
carpeta principal. Por ejemplo, hacer clic derecho en un archivo en Finder y luego seleccionar "Abrir con..." mostrará las aplicaciones disponibles tanto en /Aplicaciones como en ~/Aplicaciones. Los desarrolladores pueden crear instaladores de productos Mac que permitan al usuario realizar una instalación del directorio de inicio, etiquetada como "Instalar solo para mí" en la interfaz de usuario del instalador. [19] Dicha instalación se realiza como usuario.
Puedes usar una palabra clave especial $ORIGIN para decir 'en relación con la ubicación actual 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 criticar duramente a CDE. [...] "Deberíamos estar usando la gestión de paquetes". Esto es lo que quiero decir, y que mis palabras sean transmitidas desde las cimas de las montañas, escritas en pequeñas tablas de piedra: la gestión de paquetes no es una panacea universal.
Si Hearn está en lo cierto, la verdadera lección de Autopackage no es cómo mejorar la instalación de software, sino la dificultad (quizás la imposibilidad) de realizar cambios a gran escala en la arquitectura de Linux en esta etapa tan avanzada de su historia. Es una conclusión aleccionadora y decepcionante para un proyecto que alguna vez pareció tan prometedor.
He visto esto de primera mano con el otro proyecto en el que estoy involucrado, que es mi aplicación de registro de inmersiones. Hacemos binarios para Windows y OSX, básicamente no hacemos binarios para Linux. ¿Por qué? Porque hacer binarios para aplicaciones de escritorio Linux es un gran dolor de cabeza.
Finalmente me decidí a probar la versión "AppImage" de +Subsurface y realmente parece que "funciona".
Yo, como responsable del mantenimiento de la aplicación, ya no quiero que mi aplicación forme parte de una distribución. Es demasiado trabajo para obtener cero beneficios. Siempre que recibo un informe de error, mi primera pregunta es: "Ah, ¿qué versión de qué distribución? ¿Qué versión de qué biblioteca? ¿Qué conjunto de parches descabellados se aplicaron a esas bibliotecas?". No, Windows y Mac lo hacen bien. Yo controlo las bibliotecas con las que se ejecuta mi aplicación. [...] Con una AppImage puedo darles exactamente eso. Algo que se ejecuta en su computadora.