Algo más: paquetes de aplicaciones Haiku?

TL; DR : ¿Puede Haiku obtener el soporte adecuado para paquetes de aplicaciones, como directorios de aplicaciones (como .app en Mac) y / o imágenes de aplicaciones (Linux AppImage )? Me parece que esta será una adición digna, que es más fácil de implementar correctamente que en otros sistemas, ya que la mayor parte de la infraestructura ya está allí.

Hace una semana, descubrí Haiku, un sistema inesperadamente bueno. Bueno, desde hace mucho tiempo que me interesan los catálogos y las imágenes de aplicaciones (inspiradas en la simplicidad de Macintosh), no es sorprendente que se me ocurriera una idea ...

Para una comprensión completa: soy el creador y autor de AppImage, un formato de distribución de aplicaciones de Linux destinado a la simplicidad de Mac y que proporciona un control completo a los autores de las aplicaciones y a los usuarios finales (quiero saber más, ver la wiki y la documentación ).

¿Qué pasa si hacemos una AppImage para Haiku?

Pensemos un poco, puramente teóricamente: ¿qué se debe hacer para obtener una AppImage , o algo similar, en Haiku? No es necesario crear algo en este momento, porque el sistema que ya está en Haiku funciona de manera sorprendente, pero un experimento imaginario resultaría agradable. También demuestra la sofisticación de Haiku, en comparación con los entornos de escritorio de Linux donde tales cosas son terriblemente difíciles (tengo derecho a decirlo: he estado depurando durante 10 años).

En Macintosh System 1, cada aplicación era un archivo separado que se "administraba" en Finder. Usando AppImage intento recrear la misma experiencia de usuario en Linux.

En primer lugar, ¿qué es AppImage? Este es un sistema para lanzar aplicaciones de terceros (por ejemplo, Ultimaker Cura ) que le permite lanzar aplicaciones cuando y cómo cazan: no necesita conocer las características de varias distribuciones, políticas de construcción o infraestructura de construcción, no necesitan el apoyo de los mantenedores y no les dicen a los usuarios qué (no) se puede instalar en computadoras. AppImage debe entenderse como algo así como un paquete para Mac en formato .app dentro de una imagen de disco .dmg . La principal diferencia es que las aplicaciones no se copian, sino que permanecen dentro de AppImage siempre, al igual que los paquetes Haiku .hpkg están instalados y nunca se instalan en el sentido habitual.

Durante más de 10 años de su existencia, AppImage ganó cierto atractivo y popularidad: el propio Linus Torvalds lo aprobó públicamente, y proyectos generalizados (por ejemplo, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) lo tomaron como la principal forma de distribuir asambleas continuas o nocturnas, no interferir con aplicaciones de usuario instaladas o no instaladas. Sin embargo, los escritorios y las distribuciones de Linux a menudo se aferran al modelo de distribución centralizado tradicional basado en los mantenedores y / o promueven sus propios negocios corporativos y / o programas de ingeniería basados ​​en Flatpak (RedHat, Fedora, GNOME) y Snappy (Canonical, Ubuntu) . Viene a gracioso .

Como funciona

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

• El sistema de archivos SquashFS contiene una carga útil en forma de una aplicación y todo lo que necesita para ejecutarla, lo que en su sano juicio no puede considerarse parte de la instalación predeterminada para cada sistema de destino bastante nuevo (distribución de Linux). También contiene metadatos, por ejemplo, nombre de la aplicación, iconos, tipos MIME, etc., etc.

• Cuando el usuario lo inicia, el tiempo de ejecución usa FUSE y squashfuse para montar el sistema de archivos, después de lo cual procesa el lanzamiento de algún punto de entrada (el llamado AppRun) dentro de la AppImage montada.
  El sistema de archivos se desmonta una vez que se completa el proceso.

Parece que todo es simple.

Y estas cosas complican las cosas:

• Con tal variedad de distribuciones de Linux, no hay nada "en su sano juicio" que pueda llamar "parte de la instalación predeterminada para cada nuevo sistema de destino". Evitamos este problema mediante el ensamblaje de una lista de exclusión , lo que nos permite determinar qué se empaquetará en AppImage y qué se debe llevar a otro lugar. Al mismo tiempo, a veces echamos de menos, a pesar de que, en general, todo funciona bien. Por esta razón, recomendamos que los creadores de paquetes comprueben AppImages en todos los sistemas de destino (distribuciones).
• Las aplicaciones en forma de carga útil deben estar deambulando por el sistema de archivos. Desafortunadamente, en muchas aplicaciones, las rutas absolutas a, por ejemplo, los recursos en /usr/share codificadas. Esto necesita ser arreglado de alguna manera. Además, debe exportar LD_LIBRARY_PATH o corregir rpath para que el cargador pueda encontrar bibliotecas relacionadas. El primer método tiene sus inconvenientes (que se manejan de manera compleja), y el segundo es simplemente engorroso.
• La mayor trampa de UX para los usuarios es establecer el bit ejecutable en el archivo AppImage después de la descarga. Lo creas o no, para algunos es una verdadera barrera. La necesidad de establecer un bit ejecutable es engorrosa incluso para usuarios avanzados. Como solución alternativa, propusimos instalar un pequeño servicio que monitorea los archivos de AppImage y establece el bit ejecutable para ellos. En su forma pura, no es la mejor solución, porque no funcionará de fábrica. Las distribuciones de Linux no ofrecen este servicio, por lo tanto, los usuarios listos para usar no lo están haciendo bien.
• Los usuarios de Linux esperan que la nueva aplicación tenga un icono en el menú de inicio. No puede decirle al sistema: "Mire, hay una nueva aplicación, trabajemos". En cambio, de acuerdo con la especificación XDG, debe copiar el archivo .desktop en la ubicación deseada en /usr para la instalación en todo el sistema, o en $HOME para la instalación individual. Iconos de ciertos tamaños, de acuerdo con la especificación XDG, debe colocarlo en ciertos lugares en usr o $HOME , y luego ejecutar comandos en el entorno de trabajo para actualizar el caché de iconos, o esperar que el administrador del entorno de trabajo lo resuelva y detecte automáticamente todo. De manera similar con los tipos MIME. Como solución alternativa, ofrece Para usar el mismo servicio, que, además de establecer el indicador de ejecución, si hay íconos, etc. en AppImage, los copiará de AppImage en los lugares correctos según el XDG, se supone que el servicio borrará todo al eliminarlo o moverlo. Por supuesto, hay diferencias en el comportamiento de cada uno. entorno de trabajo, en formatos de archivos gráficos, sus tamaños, ubicaciones de almacenamiento y formas de actualizar cachés, lo que crea un problema. En resumen, este método es una muleta.
• Si lo anterior no es suficiente, no hay un ícono de AppImage en el administrador de archivos. En el mundo de Linux, todavía no han decidido implementar elficon (a pesar de la discusión e implementación ), por lo que es imposible incrustar el ícono directamente en la aplicación. Resulta que las aplicaciones en el administrador de archivos no tienen sus propios iconos (sin diferencia, AppImage u otra cosa), solo están en el menú de inicio. Como solución alternativa, utilizamos miniaturas, un mecanismo que se desarrolló originalmente para que los administradores de escritorio puedan mostrar miniaturas para obtener una vista previa de los archivos gráficos como iconos. Por lo tanto, el servicio para configurar el bit ejecutable también funciona como un "miniaturizador", creando y grabando miniaturas de iconos en los lugares correspondientes /usr y $HOME . Este servicio también realiza la eliminación si AppImage se elimina o se mueve. Debido al hecho de que cada administrador de escritorio se comporta de manera un poco diferente, por ejemplo, en qué formatos acepta íconos, en qué tamaños o lugares, todo esto es realmente doloroso.
• La aplicación simplemente se bloquea en tiempo de ejecución si se producen errores (por ejemplo, hay una biblioteca que no forma parte del sistema base y no se proporciona en AppImage), y nadie le dice al usuario en la GUI qué está sucediendo exactamente. Comenzamos a solucionar esto usando notificaciones en el escritorio, lo que significa que necesitamos detectar errores desde la línea de comandos, convertirlos en mensajes entendibles por el usuario, que luego aún deben mostrarse en el escritorio. Y, por supuesto, cada entorno de trabajo los trata un poco diferente.
• En este momento (septiembre de 2019, aprox. Traductor), no he encontrado una manera simple de decirle al sistema que el archivo 1.png abrirse usando Krita y 2.png - usando GIMP.

La ubicación de almacenamiento para las especificaciones de escritorio cruzado utilizadas por GNOME , KDE y Xfce es freedesktop.org

Lograr un nivel de sofisticación profundamente entretejido en el entorno de trabajo de Haiku es difícil, si no imposible, debido a las especificaciones XDG de freedesktop.org para cross-desktop, así como a las implementaciones de administradores de escritorio basados ​​en estas especificaciones. Como ejemplo, podemos citar un ícono de Firefox en todo el sistema: aparentemente, los autores de XDG ni siquiera pensaron que el usuario pueda tener varias versiones de la misma aplicación.

Iconos de diferentes versiones de Firefox

Me preguntaba qué podría aprender el mundo Linux de Mac OS X, para no meterse con la integración del sistema. Si tiene tiempo y lo está haciendo, asegúrese de leer lo que Arno Gourdol, uno de los primeros ingenieros de Mac OS X dijo:

Queríamos instalar la aplicación tan fácil como arrastrar el ícono de la aplicación desde algún lugar (servidor, unidad externa) al disco de su computadora. Para hacer esto, toda la información se almacena en el paquete de la aplicación, incluidos los iconos, la versión, el tipo de archivo que se procesa, el tipo de esquemas de URL que el sistema debe conocer para procesar la aplicación. Esto también incluye información para el 'almacenamiento centralizado' en la base de datos de Icon Services y Launch Services. Para mantener el rendimiento, las aplicaciones se "descubren" en varios lugares "conocidos": en el sistema y en el directorio de usuario Aplicaciones, así como en algunos otros, automáticamente si el usuario se ha movido al Finder al directorio que contiene la aplicación. En la práctica, esto funcionó muy bien.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 Sesión 144 - Mac OS X: aplicaciones de empaque y documentos de impresión.

No hay nada similar a esta infraestructura en los escritorios de Linux, por lo que estamos buscando soluciones a las restricciones estructurales en el proyecto AppImage.

¿Haiku tiene prisa por ayudar?

Y una cosa más: las plataformas Linux como base de los entornos de trabajo, por regla general, no están tan especificadas que muchas cosas que son muy simples en un sistema consistente con una pila completa decepcionan la fragmentación y la complejidad de Linux. Dediqué un informe completo a cuestiones relacionadas con la plataforma Linux para entornos de trabajo (los desarrolladores expertos lo han confirmado: todo seguirá así durante mucho tiempo).

Mi informe sobre entornos de escritorio Linux en 2018

Incluso Linus Torvalds admitió que fue debido a la fragmentación que la idea de los entornos de trabajo falló.

¡Qué bueno ver a Haiku!

Con Haiku, todo es increíblemente simple.

Aunque el enfoque ingenuo para portar AppImage a Haiku es simplemente intentar construir (principalmente runtime.c y servicio) sus componentes (¡lo que incluso puede ser posible!), No traerá muchos beneficios a Haiku. Porque, de hecho, la mayoría de estos problemas han sido resueltos por Haiku y conceptualmente justificados. Haiku proporciona exactamente esos ladrillos para la infraestructura del sistema que he estado buscando en entornos de escritorio Linux durante tanto tiempo y no podía creer que no estuvieran allí. A saber:

Lo creas o no, muchos usuarios de Linux no pueden superar esto. ¡En Haiku, todo se hace automáticamente!

• Los archivos ELF que no tienen un bit ejecutable lo reciben automáticamente cuando hace doble clic en el administrador de archivos.
• Las aplicaciones pueden tener recursos integrados, por ejemplo, iconos que aparecen en el administrador de archivos. No necesita copiar un montón de imágenes en directorios de iconos especiales y, por lo tanto, no necesita limpiarlas 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 / al lado del ejecutable, las bibliotecas se buscan por defecto.
• No hay numerosas distribuciones y entornos de escritorio, todo lo que funciona, funciona en todas partes.
• No hay un módulo separado para el lanzamiento que difiera del directorio de Aplicaciones.
• Las aplicaciones no tienen rutas absolutas incorporadas a sus recursos; hay funciones especiales para determinar la ubicación en tiempo de ejecución.
• Se ha introducido la idea de las imágenes del sistema de archivos comprimido: este es cualquier paquete hpkg. Todos ellos están montados por el núcleo.
• La aplicación que lo creó abre cada archivo, a menos que especifique explícitamente otra cosa. ¡Qué asombroso es!

Dos archivos png. Preste atención a los diferentes iconos que muestran que serán abiertos por diferentes aplicaciones haciendo doble clic. También preste atención al menú desplegable "Abrir con:", donde el usuario puede seleccionar una aplicación separada. Que facil

Parece que muchas de las muletas y soluciones alternativas que necesita AppImage en Linux se vuelven innecesarias en Haiku, que se basa en la simplicidad y la sofisticación, gracias a lo cual hace frente a la mayoría de nuestras necesidades.

¿Haiku necesita paquetes de aplicaciones al final?

Esto lleva a una gran pregunta. Si fuera un orden de magnitud más fácil crear un sistema como AppImage en Haiku que en Linux, ¿valdría la pena? ¿O Haiku, con su sistema de paquetes hpkg, prácticamente eliminó la necesidad de desarrollar tal idea? Bueno, para la respuesta necesitas mirar la motivación para la existencia de AppImages.

Vista desde el usuario

Echa un vistazo a nuestro usuario final:

• Quiero instalar la aplicación sin pedir la contraseña de administrador (root). En Haiku no existe el concepto de administrador, el usuario tiene el control total, ¡ya que este es un sistema personal! (En principio, puedes imaginar esto en modo multiusuario, espero que los desarrolladores mantengan la simplicidad)
• Quiero obtener las últimas y mejores versiones de las aplicaciones, no esperar a que aparezcan en mi distribución (a menudo significa "nunca", al menos si no actualiza todo el sistema operativo). En Haiku, esto se "resuelve" con lanzamientos flotantes. Esto significa que es posible obtener las últimas y mejores versiones de las aplicaciones, pero para esto necesita actualizar constantemente el resto del sistema, convirtiéndolo en un "objetivo móvil" .
• Quiero varias versiones de la misma aplicación cerca, porque no puedes descubrir qué se rompió en la última versión o, por ejemplo, como desarrollador web, necesito verificar mi trabajo en diferentes versiones del navegador. Haiku resolvió el primero, pero no el segundo problema. Las actualizaciones se revierten, pero solo para todo el sistema, es imposible (como sé) lanzar, por ejemplo, varias versiones de WebPositive o LibreOffice al mismo tiempo.

Uno de los desarrolladores escribe:

En esencia, la razón es esta: el caso de uso es tan raro que la optimización no tiene sentido; manejarlo como un caso especial en HaikuPorts parece más que aceptable.

• Necesito guardar las aplicaciones donde me gusta, y no en el disco de arranque. A menudo me quedo sin espacio en los discos, por lo que necesito conectar una unidad externa o un directorio de red para almacenar aplicaciones (todas las versiones que descargué). Si conecto dicha unidad, necesito que las aplicaciones se inicien haciendo doble clic. Haiku guarda versiones anteriores de paquetes, pero no sé cómo moverlos a una unidad externa o cómo llamar a las aplicaciones desde allí más tarde.

Comentario del desarrollador:

Técnicamente, esto ya es posible con el comando mount. Por supuesto, haremos una GUI para esto tan pronto como se reúnan suficientes usuarios interesados.

• No necesito millones de archivos repartidos por el sistema de archivos que no puedo administrar manualmente. Quiero un archivo por aplicación, que puedo descargar, mover y eliminar fácilmente. En Haiku, este problema se resolvió con la ayuda de paquetes .hpkg , que transfieren, por ejemplo, Python, de miles de archivos a uno. Pero si hay, por ejemplo, Scribus usando Python, entonces tengo que lidiar con al menos dos archivos. Y tengo que asegurarme de que sus versiones funcionen entre sí.

Numerosas versiones de AppImages que se ejecutan lado a lado en un solo Linux

Vista desde el lado del desarrollador de la aplicación

Miremos desde el punto de vista del desarrollador de la aplicación:

• Quiero gestionar toda la experiencia del usuario. No quiero depender del sistema operativo, que me dirá cuándo y cómo debo lanzar las aplicaciones. En Haiku, los desarrolladores pueden trabajar con sus propios repositorios hpkg, pero esto significa que los usuarios deberán 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. O tal vez quiero monetizar el acceso a esta página, ¿puede ser todo? ¿Qué necesito publicar allí para Haiku? Suficiente archivo .hpkg solo con dependencias de .hpkg
• Mi software necesita ciertas versiones de otro software. Por ejemplo, se sabe que Krita necesita una versión fija de Qt, o Qt, que está ajustada a una versión específica de Krita, al menos hasta que las correcciones vuelvan a Qt. Puede empaquetar su propio Qt para la aplicación en el paquete .hpkg , pero lo más probable es que esto no sea bienvenido.

Página de descarga de la aplicación normal. ¿Qué colocar aquí para Haiku?

¿Los paquetes (existentes como directorios de aplicaciones como AppDir o .app estilo Apple) y / o imágenes (como AppImages o .dmg muy modificadas de .dmg ) serán adiciones útiles al escritorio Haiku? ¿O diluirá toda la imagen y conducirá a la fragmentación y, por lo tanto, agregará complejidad? Estoy desgarrado: por un lado, la belleza y la sofisticación de Haiku se basa en el hecho de que generalmente hay una forma de hacer algo, no mucho. , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

Conclusión

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

Lista de artículos: Primero Segundo Tercero Cuarto Quinto Sexto Séptimo Octavo Noveno