🥇Algo más: ¿paquetes de aplicaciones Haiku?

TL;DR: puede Haiku recibir el soporte adecuado para paquetes de aplicaciones, como un catálogo de aplicaciones (como .app en Mac) y/o imágenes de aplicaciones (Linux AppImage)? Me parece que sería una adición digna que sería más fácil de implementar que en otros sistemas, ya que gran parte de la infraestructura ya existe.

Hace una semana descubrí Haiku, un sistema sorprendentemente bueno. Y como he estado interesado en catálogos e imágenes de aplicaciones (inspirado en la simplicidad de Macintosh), no es sorprendente que se me ocurriera la idea...

Para su comprensión completa: soy el creador y autor de AppImage, un formato de distribución de aplicaciones de Linux orientado a la simplicidad de Mac y que otorga completo control a los desarrolladores de aplicaciones y a los usuarios finales (si desea saber más, vea wiki y la documentación).

¿Qué pasaría si hacemos AppImage para Haiku?

Hablemos un poco, puramente teóricamente, sobre lo que se necesitaría para obtener AppImage, o algo similar, en Haiku? No es necesario crear algo de inmediato, ya que el sistema que ya existe en Haiku funciona sorprendentemente bien, y una experiencia imaginaria sería interesante. Además, demuestra la sofisticación de Haiku en comparación con los entornos de trabajo de Linux, donde tales cosas son terriblemente difíciles (tengo derecho a decirlo: he estado lidiando con la depuración durante 10 años).

En Macintosh System 1, cada aplicación era un archivo separado, 'gestionado' en Finder. Usando AppImage, intento recrear esta misma experiencia de usuario en Linux.

Primero, ¿qué es AppImage? Es un sistema para lanzar aplicaciones de desarrolladores terceros (por ejemplo, Ultimaker Cura), que permite lanzar aplicaciones cuando y como se desee: no es necesario conocer las particularidades de las distintas distribuciones, políticas de construcción o infraestructura de compilación, no se necesita el soporte de mantenedores, y no dicen a los usuarios lo que pueden o no pueden instalar en sus computadoras. AppImage debe entenderse como algo similar a un paquete para Mac en formato .app dentro de la imagen de disco .dmg. La principal diferencia es que las aplicaciones no se copian, sino que permanecen dentro de AppImage siempre, de manera similar a cómo se montan los paquetes de Haiku, y nunca se instalan en el sentido habitual. .hpkg se montan, y nunca se instalan en el sentido habitual.

AppImage ha adquirido cierta atracción y popularidad en más de 10 años de existencia: el propio Linus Torvalds lo aprobó públicamente, y proyectos reconocidos (como LibreOffice, Krita, Inkscape, Scribus, ImageMagick) lo adoptaron como el método principal para distribuir versiones continuas o nocturnas, sin interferir con las aplicaciones ya instaladas o no instaladas de los usuarios. Sin embargo, los entornos de trabajo y las distribuciones de Linux aún tienden a aferrarse al modelo tradicional de distribución centralizada basado en acompañamientos y/o promocionar sus propios programas empresariales y/o de ingeniería. Flatpak (RedHat, Fedora, GNOME) y Snappy (Canonical, Ubuntu). Llega a lo ridículo.

Cómo funciona todo

Cada AppImage contiene 2 partes: un pequeño ejecutable ELF (llamado runtime.c), seguido de una imagen del sistema de archivos SquashFS.

El sistema de archivos SquashFS contiene la carga útil en forma de la aplicación y todo lo necesario para su ejecución, que en conciencia no se puede considerar parte de la instalación predeterminada para cualquier sistema objetivo suficientemente reciente (distribución de Linux). También contiene metadatos, por ejemplo, el nombre de la aplicación, íconos, tipos MIME, etc.

Al iniciarse, el runtime utiliza FUSE y squashfuse para montar el sistema de archivos, después de lo cual se procesa la ejecución de un punto de entrada (llamado AppRun) dentro del AppImage montado.
El sistema de archivos se desmonta después de que el proceso finaliza.

Parece bastante sencillo.

Y estas cosas lo complican todo:

Con tal variedad de distribuciones de Linux, nada en 'conciencia' se puede llamar 'parte de la instalación predeterminada para cada sistema objetivo reciente'. Abordamos este problema mediante la construcción de excludelist, que permite definir qué se empaquetará en el AppImage y qué deberá tomarse de otro lugar. A veces, fallamos, a pesar de que en general todo funciona perfectamente. Por esta razón, recomendamos a los creadores de paquetes probar AppImages en todos los sistemas objetivos (distribuciones).
Las aplicaciones en forma de carga útil deben ser movibles en el sistema de archivos. Desafortunadamente, en muchas aplicaciones se definen caminos absolutos fijos a, por ejemplo, recursos en /usr/share. Esto necesita corregirse de alguna manera. Además, se debe o exportar LD_LIBRARY_PATH, o corregir rpath para que el cargador pueda encontrar las bibliotecas asociadas. El primer método tiene sus desventajas (que se evitan con métodos complicados), mientras que el segundo es simplemente engorroso.
La mayor trampa de UX para los usuarios es que hay que establecer el bit ejecutable al archivo AppImage después de la descarga. Quieras creerlo o no, pero para algunos esto es una barrera real. La necesidad de establecer el bit de ejecutabilidad es engorrosa incluso para los usuarios experimentados. Como solución alternativa, hemos propuesto la instalación de un pequeño servicio que supervisa los archivos AppImage y les establece el bit ejecutable. En su versión pura, no es la mejor solución, ya que no funcionará 'de forma nativa'. Las distribuciones de Linux no proporcionan este servicio, por lo tanto, los usuarios 'de forma nativa' tienen problemas.
Los usuarios de Linux esperan que la nueva aplicación tenga un ícono en el menú de lanzamiento. No se le puede decir al sistema: 'Mira, ahí hay una nueva aplicación, ponla a trabajar'. En su lugar, según la especificación XDG, se debe copiar el archivo .desktop en el lugar adecuado en /usr para una instalación de sistema completo, o en $HOME para una instalación individual. Los íconos de ciertos tamaños, de acuerdo a la especificación XDG, deben colocarse en ciertos lugares en usr o $HOME, y luego ejecutar comandos en el entorno de trabajo para actualizar la caché de íconos, o esperar que el gestor de ventanas logre detectarlos automáticamente. Lo mismo ocurre con los tipos MIME. Como solución alternativa, se sugiere usar el mismo servicio que además de establecer el bit ejecutable, copiará los íconos y otros elementos de AppImage a los lugares apropiados según XDG cuando existan. Al eliminar o mover, el servicio debería limpiar todo. Por supuesto, hay diferencias en el comportamiento de cada entorno de trabajo, en los formatos de archivos gráficos, sus tamaños, lugares de almacenamiento y métodos de actualización de cachés, lo que crea el problema. En resumen, este método es un parche.
Si lo anterior no es suficiente, no hay ícono de AppImage en el gestor de archivos. En el mundo de Linux, aún no se ha tomado una decisión sobre la implementación de elficon (a pesar de la discusión y implementación), por lo que no es posible incrustar el ícono directamente en la aplicación. Así que ocurre que las aplicaciones en el gestor de archivos no tienen íconos propios (sin importar si es AppImage o algo más), solo los tienen en el menú de lanzamiento. Como solución alternativa, utilizamos miniaturas, un mecanismo que fue diseñado originalmente para que los gestores de escritorio pudieran mostrar imágenes reducidas como vista previa de archivos gráficos como sus íconos. Por lo tanto, el servicio para establecer el bit de ejecutabilidad también funciona como un 'miniaturizador', creando y guardando miniaturas de íconos en los lugares correspondientes. /usr y $HOME. También, este servicio realiza limpieza si se elimina o se mueve el AppImage. Debido a que cada gestor de escritorio se comporta de manera un poco diferente, por ejemplo, en qué formatos acepta íconos, en qué tamaños o ubicaciones, todo esto puede ser realmente problemático.
La aplicación simplemente falla al ejecutarse si hay errores (por ejemplo, hay una biblioteca que no es parte del sistema base y no se incluye en el AppImage), y nadie le informa al usuario en la interfaz gráfica sobre lo que está sucediendo. Hemos comenzado a sortear esto utilizando una notificación en el escritorio, por lo que necesitamos capturar errores desde la línea de comandos, convertirlos en mensajes comprensibles para el usuario, que luego también deben mostrarse en el escritorio. Y, por supuesto, cada entorno de trabajo los maneja de manera un poco diferente.
En este momento (septiembre de 2019, - nota del traductor), no he encontrado una forma sencilla de decirle al sistema que el archivo 1.png debe abrirse con Krita, y 2.png — con GIMP.

El lugar de almacenamiento de las especificaciones cross-desktop, utilizadas en GNOME, KDE y Xfce es freedesktop.org

Alcanzar un nivel de sofisticación, profundamente entrelazado en el entorno de trabajo de Haiku, es difícil, si no se dice que es 'imposible', debido a las especificaciones XDG de freedesktop.org para cross-desktop, así como las implementaciones de los gestores de escritorio basadas en estas especificaciones. Por ejemplo, existe un ícono de sistema común para Firefox: evidentemente, a los autores de XDG no se les ocurrió que un usuario podría tener instaladas varias versiones de la misma aplicación.

Íconos de diferentes versiones de Firefox

Me interesaba saber qué podría aprender el mundo de Linux de Mac OS X para no cometer errores en la integración de sistemas. Si tienes tiempo y te dedicas a esto, asegúrate de leer lo que dijo Arnaud Gurdol, uno de los primeros ingenieros de Mac OS X:

Queríamos que la instalación de una aplicación fuera tan simple como arrastrar el ícono de la aplicación desde algún lugar (servidor, disco externo) al disco de tu ordenador. Para ello, se guarda toda la información en el paquete de la aplicación, incluyendo íconos, versión, tipo de archivo procesado, tipo de esquema de URL que el sistema debe conocer para manejar la aplicación. También se incluye información para el ‘almacenamiento centralizado’ en la base de datos de Icon Services y Launch Services. Para mantener el rendimiento de la aplicación, se ‘detectan’ en varios lugares ‘bien conocidos’: en el directorio de aplicaciones del sistema y del usuario, así como en algunos otros automáticamente, si el usuario accede al Finder en el directorio que contiene la aplicación. En la práctica, esto ha funcionado muy bien.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sesión 144 — Mac OS X: empaquetado de aplicaciones e impresión de documentos.

No existe nada similar en esta infraestructura en los entornos de trabajo de Linux, por lo que buscamos soluciones alternativas para las limitaciones estructurales en el proyecto AppImage.

¿Acaso Haiku viene al rescate?

Y además: las plataformas de Linux como base para entornos de trabajo suelen estar tan poco especificadas que muchas cosas que son bastante simples en un sistema coherente con un stack completo son frustrantes, por su fragmentación y complejidad en Linux. Dediqué un completo discurso a las cuestiones relacionadas con la plataforma Linux para entornos de trabajo (los desarrolladores experimentados confirmaron: esto seguirá así por mucho tiempo).

Mi discurso sobre los problemas de los entornos de trabajo en Linux en 2018

Incluso Linus Torvalds reconoció que es precisamente debido a la fragmentación que la idea de los entornos de trabajo no ha tenido éxito.

¡Es agradable ver a Haiku!

Con Haiku, todo se vuelve increíblemente simple.

Aunque el enfoque ingenuo para "portar" AppImage a Haiku consiste en simplemente intentar compilar (principalmente runtime.c y el servicio) sus componentes (¡lo que puede ser incluso posible!), esto no aportará un gran beneficio para Haiku. Porque, en realidad, la mayoría de estos problemas ya están resueltos en Haiku y son conceptualmente sólidos. Haiku proporciona precisamente los bloques de construcción para la infraestructura del sistema que he estado buscando tanto tiempo en entornos de trabajo en Linux y no podía creer que no estuvieran allí. A saber:

Creas o no, pero esto es algo que muchos usuarios de Linux no pueden superar. ¡En Haiku todo se hace automáticamente!

Los archivos ELF que no tienen el bit de ejecutabilidad lo obtienen automáticamente al hacer doble clic en el gestor de archivos.
Las aplicaciones pueden tener recursos integrados, como íconos, que se muestran en el gestor de archivos. No es necesario copiar un montón de imágenes en directorios especiales de íconos, por lo tanto, no hay necesidad de limpiarlos después de eliminar o mover la aplicación.
Hay una base de datos para vincular aplicaciones con documentos, no es necesario copiar ningún archivo para esto.
En el directorio lib/, junto al archivo ejecutable, las bibliotecas se buscan por defecto.
No hay numerosas distribuciones y entornos de escritorio, todo lo que funciona, funciona en todas partes.
No existe un módulo de ejecución separado que se diferencie del directorio de Aplicaciones.
Las aplicaciones no tienen rutas absolutas integradas a sus recursos; hay funciones especiales para determinar la ubicación durante la ejecución.
Se ha implementado la idea de imágenes de sistemas de archivos comprimidos: esto es cualquier paquete hpkg. Todos ellos son montados por el núcleo.
Cada archivo se abre con la aplicación que lo creó, a menos que se indique lo contrario. ¡Qué genial!

Dos archivos png. Observe los diferentes íconos que muestran que se abrirán con diferentes aplicaciones al hacer doble clic. También preste atención al menú desplegable "Abrir con:", donde el usuario puede elegir una aplicación específica. ¡Qué fácil!

Parece que muchos parches y soluciones alternativas que necesita AppImage en Linux se vuelven innecesarios en Haiku, que se basa en la simplicidad y sofisticación, lo que le permite manejar la mayoría de nuestras necesidades.

¿Necesita Haiku paquetes de aplicaciones, al final?

Esto nos lleva a una gran pregunta. Si crear un sistema como AppImage en Haiku resulta mucho más fácil que en Linux, ¿vale la pena intentarlo? ¿O Haiku, con su sistema de paquetes hpkg, ha hecho que el desarrollo de una idea similar sea innecesario? Bueno, para responder a esto, es necesario mirar la motivación detrás de la existencia de AppImages.

Perspectiva del usuario

Veamos a nuestro usuario final:

Quiero instalar una aplicación sin que se solicite la contraseña del administrador (root). En Haiku no existe el concepto de administrador, el usuario tiene control total, ¡ya que es un sistema personal! (En principio, esto podría imaginarse también en modo multiusuario, espero que los desarrolladores mantengan la simplicidad)
Quiero obtener las últimas y mejores versiones de las aplicaciones sin esperar a que aparezcan en mi distribución (lo que suele significar "nunca", al menos si no actualizo todo el sistema operativo). En Haiku esto se "resuelve" mediante lanzamientos flotantes. Esto significa que hay la posibilidad de obtener las últimas y mejores versiones de las aplicaciones, pero para eso es necesario actualizar constantemente el resto del sistema, convirtiéndolo efectivamente en un "objetivo en movimiento"..
Quiero tener varias versiones de la misma aplicación al mismo tiempo, ya que no se puede saber qué se rompió en la última versión, o, digamos, como desarrollador web, necesito verificar mi trabajo en diferentes versiones del navegador. En Haiku se ha resuelto el primer problema, pero no el segundo. Las actualizaciones se pueden revertir, pero solo para todo el sistema, no es posible (hasta donde yo sé) ejecutar, por ejemplo, varias versiones de WebPositive o LibreOffice al mismo tiempo.

Uno de los desarrolladores escribe:

Esencialmente, la justificación es la siguiente: el caso de uso es tan raro que la optimización para él no tiene sentido; tratarlo como un caso especial en HaikuPorts parece más que aceptable.

Necesito almacenar aplicaciones donde me guste, y no en el disco de arranque. A menudo me quedo sin espacio en los discos, así que necesito conectar un disco externo o una carpeta de red para almacenar aplicaciones (todas las versiones que he descargado). Si conecto dicho disco, las aplicaciones deben abrirse con un doble clic. Haiku guarda versiones antiguas de los paquetes, pero no sé cómo moverlas a un disco externo, ni cómo abrir aplicaciones desde allí después.

Comentario del desarrollador:

Técnicamente, esto ya es posible con el comando mount. Por supuesto, haremos un GUI para esto una vez que haya suficientes usuarios interesados.

No necesito millones de archivos esparcidos por el sistema de archivos que no puedo gestionar manualmente. Quiero un solo archivo por aplicación que pueda descargar, mover o eliminar fácilmente. En Haiku, este problema se resuelve mediante paquetes .hpkg, que agrupan, por ejemplo, python, de miles de archivos en uno solo. Pero si hay, por ejemplo, Scribus que usa python, tengo que lidiar con al menos dos archivos. Y debo asegurarme de que conserven las versiones que funcionan entre sí.

Numerosas versiones de AppImages, ejecutándose lado a lado en un solo Linux.

Una perspectiva desde el lado del desarrollador de aplicaciones.

Veamos desde la perspectiva de un desarrollador de aplicaciones:

Quiero controlar la experiencia del usuario en su totalidad. No quiero depender del sistema operativo que me indique cuándo y cómo debo lanzar aplicaciones. En Haiku, los desarrolladores pueden trabajar con sus propios repositorios hpkg, pero esto significa que los usuarios tendrán que configurarlos manualmente, lo que hace que esta idea sea "menos atractiva".
Tengo una página de descarga en mi sitio web donde distribuyo .exe para Windows, .dmg para Mac y .AppImage para Linux. ¿Y si quiero monetizar el acceso a esta página, podría ser? ¿Qué debería incluir allí para Haiku? Basta con un archivo .hpkg con dependencias solo de HaikuPorts.
Mi software necesita versiones específicas de otro software. Por ejemplo, se sabe que Krita requiere una versión corregida de Qt, o Qt que está ajustada a una versión específica de Krita, al menos hasta que los arreglos se integren de nuevo en Qt. Se puede empaquetar Qt propio para la aplicación en el paquete .hpkg, pero probablemente no será bien recibido.

Una página de descarga de aplicaciones típica. ¿Qué debería incluir aquí para Haiku?

¿Serán los kits (existentes como directorios de aplicaciones, como AppDir o .app en estilo Apple) y/o imágenes (en forma de AppImages fuertemente modificados o .dmg ¿Son las aplicaciones de Apple un complemento útil para el entorno de trabajo de Haiku? ¿O esto fragmentará la imagen completa y generará complejidad? Estoy en un dilema: por un lado, la belleza y sofisticación de Haiku se basa en que normalmente hay una sola forma de hacer algo, no muchas. Por otro lado, gran parte de la infraestructura para directorios y/o conjuntos de aplicaciones ya está en su lugar, por lo que el sistema clama por que se ubiquen allí los restantes pocos por ciento.

Según el desarrollador mr. waddlesplash

En Linux, ellos (directorios y conjuntos de aplicaciones, nota del traductor) probablemente son la solución técnica para problemas sistémicos. En Haiku preferimos simplemente resolver los problemas del sistema.

¿Y tú qué piensas?

Antes de que respondas...

Espera, hagamos una rápida verificación de la realidad: de hecho, los directorios de aplicaciones ya son parte de Haiku:

Los directorios de aplicaciones ya existen en Haiku, pero aún no se soportan en el administrador de archivos.

Simplemente no están tan bien soportados como, digamos, en el Finder de Macintosh. ¿Qué tan genial sería que el directorio de QtCreator tuviera en la esquina superior izquierda el nombre y el ícono de 'QtCreator', que inicie la aplicación con un doble clic?

Un poco antes ya pregunté:

¿Estás seguro de que podrás ejecutar tus aplicaciones de hace diez años hoy, cuando todas las tiendas de aplicaciones y repositorios de distribuciones se olviden de ellas y de sus dependencias? ¿Estás seguro de que aún podrás acceder a tu trabajo actual en el futuro?

¿Ya hay una respuesta de Haiku, o los directorios y conjuntos de aplicaciones podrán ayudar aquí? Creo que sí.

Según el sr. waddlesplash:

Sí, tenemos una respuesta a la pregunta: simplemente vamos a mantener estas aplicaciones tanto tiempo como sea necesario, hasta que alguien pueda leer correctamente sus formatos de archivos o proporcionar funcionalidad uno a uno. Nuestro compromiso de mantener las aplicaciones de BeOS R5 en Haiku es prueba directa de ello...

¡Exactamente!

¿Qué plan de acción debería adoptar Haiku?

Puedo imaginar una coexistencia pacífica de hpkg, directorios y imágenes de aplicaciones:

El software del sistema utiliza .hpkg
Para el software más utilizado (especialmente el que necesita lanzar versiones flotantes) se utiliza .hpkg (aproximadamente el 80% de todos los casos)
Algunos, instalados a través de .hpkg, las aplicaciones se beneficiarán al migrar a una infraestructura con catálogos de aplicaciones (por ejemplo, QtCreator): se distribuirán en forma de .hpkg, como siempre.

mr. waddlesplash dice:

Si todo lo que se necesita es visualizar aplicaciones en /system/apps, en su lugar, los catálogos en Deskbar deben hacerse más manejables para los usuarios, ya que /system/apps no está diseñado para que los usuarios lo abran y lo miren regularmente (a diferencia de MacOS). Para estas situaciones, Haiku tiene otra paradigma, pero esta opción es, en teoría, aceptable.

Haiku obtiene infraestructura para ejecutar imágenes de aplicaciones, nocturnas, continuas y compilaciones de prueba de software, así como en casos en que el usuario desea 'congelarlo en el tiempo', para software privado e interno y otros casos de uso especiales (alrededor del 20% del total). Estas imágenes contienen los archivos necesarios para ejecutar la aplicación .hpkg, montados por el sistema, y después de que la aplicación finaliza, se desmontan. (Quizás, el gestor de archivos podría colocar archivos .hpkg en imágenes de aplicaciones, automáticamente o bajo demanda del usuario — como cuando arrastras una aplicación a un directorio de red o a un disco externo. ¡Es simplemente una canción! Mejor dicho, una poesía — un haiku.) Por otro lado, el usuario puede desear instalar el contenido de la imagen como archivos.hpkg, los cuales se actualizarán y manejarán de la misma manera que si hubieran sido instalados a través de HaikuDepot… Necesitamos hacer una lluvia de ideas).

Cita de mr. waddlesplash:

Ejecutar aplicaciones desde discos externos o catálogos de red puede ser potencialmente útil. Y agregar la posibilidad de configurar más 'zonas' para pkgman definitivamente sería una buena función.

Un sistema así aprovecharía hpkg, catálogos e imágenes de aplicaciones. Son buenos por separado, pero juntos serán invencibles.

Conclusión

Para Haiku hay infraestructura que proporciona una interfaz de usuario simple y refinada para PCs, y va mucho más allá de lo que normalmente se ofrece para PCs en Linux. El sistema de paquetes .hpkg — uno de estos ejemplos, pero las demás partes del sistema también están impregnadas de sofisticación. Sin embargo, el catálogo correcto y el soporte de imágenes de aplicaciones se beneficiarían de Haiku. La mejor manera de hacerlo es discutirlo con personas que conocen Haiku, su filosofía y arquitectura mucho mejor que yo. Después de todo, solo he estado usando Haiku un poco más de una semana. No obstante, creo que esta nueva perspectiva será útil para los diseñadores, desarrolladores y arquitectos de Haiku. Al menos, estaré encantado de ser su "sparring partner". Tengo más de 10 años de experiencia práctica trabajando con catálogos y conjuntos de aplicaciones para Linux, y me gustaría encontrarles un uso en Haiku, cuya concepción, en mi opinión, se adapta perfectamente. Las soluciones potenciales que propongo no son las únicas correctas para los problemas que describí, y si el equipo de Haiku decide buscar otras más elegantes, solo tengo que apoyarlas. En principio, ya estoy considerando la idea de cómo hacer que el sistema hpkg sea aún más sorprendente, sin cambiar la forma en que funciona. Resulta que el equipo de Haiku ha estado pensando en conjuntos de aplicaciones al implementar el sistema de gestión de paquetes, pero desafortunadamente, (me parece) la idea se ha vuelto "obsoleta". Quizás sea el momento de revivirla?

¡Intenta tú mismo! El proyecto Haiku proporciona imágenes para descargar desde DVD o USB, formadas diariamente.
¿Tienes preguntas? Te invitamos a nuestro canal de telegram en ruso.

Revisión de errores: Cómo dispararte en el pie en C y C++. Recopilación de recetas de Haiku OS

Desde autor traducción: este es el octavo y último artículo de la serie sobre Haiku.

Lista de artículos: Primero Segundo Tercero Cuarto Quinta Sexto Séptimo

Solo los usuarios registrados pueden participar en la encuesta. Inicie sesión, por favor.