🥇Mi sexto día con Haiku: tras el capó de recursos, íconos y paquetes

TL;DR: Haiku es un sistema operativo diseñado específicamente para PC, por lo que tiene varios trucos que hacen que su entorno de trabajo sea mucho mejor que el de otros. Pero, ¿cómo funciona?

Recientemente Descubrí Haiku, un sistema sorprendentemente bueno. Aún estoy asombrado de lo fluidamente que funciona, especialmente en comparación con los entornos de trabajo en Linux. Hoy miraré bajo el capó. Donde sea necesario para una comprensión más profunda, haré comparaciones con el Macintosh original, Mac OS X y los entornos de trabajo de Linux (estándar XDG de freedesktop.org).

Recursos en archivos ELF

Ayer descubrí que IconOMatic puede guardar íconos en los recursos rdef de los archivos ejecutables ELF. Hoy quiero ver cómo funciona realmente.

¿Recursos? Cita desde Bruce Horn, el autor original del programa Macintosh Finder y el 'padre' del Macintosh Resource Manager:

Me preocupa la naturaleza rígida de la codificación tradicional. Para mí, la idea misma de una aplicación congelada en código, sin la posibilidad de cambiar nada dinámicamente, es una locura absoluta. Debe haber la posibilidad de cambiar tanto como sea posible en tiempo de ejecución. Por supuesto, el propio código de la aplicación no puede ser modificado, pero ¿no se puede cambiar algo sin recompilar el código?

En el Macintosh original, se hizo que estos archivos tuvieran una 'sección de datos' y una 'sección de recursos', lo que facilitó extraordinariamente el almacenamiento de diversas cosas, como íconos, traducciones, etc., en los archivos ejecutables.

En Mac, se utiliza ResEdit, una aplicación gráfica para — sorprendentemente — editar recursos.

ResEdit en el Macintosh original

Como resultado, se permitió editar íconos, elementos de menú, traducciones y más con relativa facilidad, aunque aún 'viajan' con las aplicaciones.
De todos modos, este enfoque tenía una gran desventaja: solo funcionaba en sistemas de archivos de Apple, lo que se convirtió en una de las razones por las cuales Apple abandonó la 'sección de recursos' al pasar a Mac OS X.
En Mac OS X, Apple quería una solución independiente del sistema de archivos, por lo que aplicó el concepto de paquetes (de NeXT), directorios que el administrador de archivos maneja como 'objetos opacos', similar a los archivos, en vez de a directorios. Cualquier paquete con una aplicación en formato .app tiene, entre otras cosas, un archivo Info.plist (en un análogo a JSON o YAML de Apple), que contiene los metadatos de la aplicación.

Claves del archivo Info.plist del paquete de la aplicación Mac OS X.

Los recursos, como iconos, archivos de interfaz de usuario y otros, se almacenan en el paquete como archivos. La idea en realidad volvió a sus raíces en NeXT.

Mathematica.app en NeXTSTEP 1.0 en 1989: se muestra como un directorio con archivos en la terminal, pero como un único objeto en el gestor de archivos gráfico.

Volvamos a BeOS, sobre cuyas ideas se basa Haiku. Sus desarrolladores, al pasar de PEF (PowerPC) a ELF (x86) (el mismo que se utiliza en Linux), decidieron añadir una sección de recursos al final de los archivos ELF. Para esto no se utilizó una sección ELF adecuada, simplemente se añadía al final del archivo ELF. Como resultado, los programas strip y otros de binutils, que no conocen esto, simplemente la eliminaron. Por lo tanto, al añadir recursos a un archivo ELF en BeOS, es mejor no trabajar con él con herramientas de Linux.

¿Y qué está sucediendo ahora con Haiku? En esencia, más o menos lo mismo.

En teoría, sería posible colocar recursos en la sección adecuada de ELF. Según los desarrolladores en el canal #haiku en irc.freenode.net:

Con ELF la sección tendría más sentido... la única razón por la que no hacemos eso es porque así se hacía en BeOS.
Y cambiarlo ahora no vale la pena.

Gestión de recursos

Los recursos se escriben en un formato "estructurado" de "recursos": esencialmente es una lista de recursos con tamaños y luego su contenido. Recordé el formato ar..
¿Cómo se pueden verificar los recursos en Haiku? ¿Hay algo como ResEdit?
Según la documentación:

Para visualizar los recursos que se entregan en el paquete de la aplicación, se puede arrastrar el archivo ejecutable a un programa como Resourcer.También se puede acceder a la terminal y ejecutar el comando listres nombre_del_archivo..

Resourcer está en HaikuDepot, pero simplemente se cierra.

¿Cómo se gestionan los recursos en archivos ELF? Usando rsrc. y rdef.. rdef. los archivos se compilan en. rsrc.. El archivo rdef. se almacena en un formato de texto simple, así que es más fácil trabajar con él. Un archivo en formato rsrc. se añade al final del archivo ELF. Vamos a intentar jugar:

~> rc -h
Compilador de Recursos de Haiku 1.1
Para compilar un script rdef en un archivo de recursos:
    rc [opciones] [-o ] ...
Para convertir un archivo de recursos de nuevo a un script rdef:
    rc [opciones] [-o ] -d ...
Opciones:
    -d --decompilar       crear un script rdef a partir de un archivo de recursos
       --nombres-automáticos construir nombres de recursos a partir de símbolos ID
    -h --ayuda            mostrar este mensaje
    -I --incluir    añadir  a la lista de rutas de inclusión
    -m --fusionar        no borrar los contenidos existentes del archivo de salida
    -o --salida          especificar el nombre del archivo de salida, por defecto es out.xxx
    -q --silencioso      no mostrar mensajes de error
    -V --versión        mostrar la versión del software y licencia

Se puede usar el programa xres. para ver y gestionar:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

Bueno, ¿vamos a probar?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

Más sobre los recursos y el formato rdef. se puede leer aquí.

Tipos de recursos estándar

Aunque se puede incluir cualquier cosa en los recursos, hay varios tipos estándar específicos:

app_signature: Tipo MIME de la aplicación, utilizado para asociar archivos abiertos, ejecutar, IPC, etc.
app_name_catalog_entry: Dado que el nombre de la aplicación suele estar en inglés, aquí se pueden indicar las ubicaciones donde están los nombres traducidos, de modo que los usuarios de diferentes idiomas puedan ver el nombre traducido de la aplicación si lo desean.
app_version: exactamente lo que piensas
app_flags: indica registrar cómo manejar la aplicación. Creo que hay algo más de lo que parece a simple vista. Por ejemplo, hay B_SINGLE_LAUNCH, que hace que el sistema inicie un nuevo proceso de la aplicación cada vez que lo solicita el usuario (el mismo principio se utiliza para la mayoría de las aplicaciones en Linux). Hay B_MULTIPLE_LAUNCH, que hace que se inicie un proceso para cada archivo. Finalmente, hay B_EXCLUSIVE_LAUNCH, que hace que el sistema ejecute solo un proceso a la vez, independientemente de cuántas veces lo inicien los usuarios (por ejemplo, así se inicia Firefox en Linux; el mismo resultado se puede lograr en aplicaciones Qt usando la función QtSingleApplication). Las aplicaciones con B_EXCLUSIVE_LAUNCH son notificadas cuando un usuario intenta iniciarlas de nuevo: por ejemplo, reciben la ruta del archivo que el usuario desea abrir con su ayuda.
vector_icon: Icono vectorial de la aplicación (En BeOS no había iconos vectoriales, la mayoría de las aplicaciones en su lugar tenían dos iconos rasterizados en los archivos ejecutables).

Por supuesto, se pueden agregar recursos con cualquier ID y tipo deseado, después de lo cual se pueden leer en la misma aplicación o en otras aplicaciones utilizando la clase BResources. Pero primero, centrémonos en el fascinante tema de los iconos.

Iconos vectoriales al estilo Haiku

Por supuesto, no solo Haiku eligió el mejor formato de iconos; en esta parte, la situación con los entornos de escritorio de Linux está lejos de ser ideal:

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

Mirando esto, ya se puede sentir de qué se trata este fragmento.

Por supuesto, hay íconos vectoriales escalables que, como se puede entender, están contenidos. Entonces, ¿por qué hay algo más? Porque el resultado de renderizar gráficos vectoriales a tamaños pequeños puede no ser el ideal. Se desea tener varias versiones, optimizadas para diferentes tamaños. En los entornos de trabajo de Linux, esto se logra dispersando los íconos de diferentes tamaños en el sistema de archivos.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

Tenga en cuenta: no hay concepto de diferentes versiones de Firefox. Por lo tanto, no se puede manejar sutilmente la situación de tener varias versiones de la aplicación en el sistema.

Diferentes íconos de Firefox en diferentes versiones. Hasta ahora, es imposible manejar esto en Linux sin diversos trucos.

Mac OS X lo gestiona de forma un poco más sutil:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

Se observa que hay un archivo firefox.icns en el paquete Firefox.app, que contiene todos los tamaños, por lo que diferentes versiones de una misma aplicación tienen íconos diferentes.
¡Mucho mejor! Los íconos viajan juntos con la aplicación, todos los recursos en un solo archivo.

Regresando a Haiku. Una solución sorprendente, sin excepciones. De acuerdo con la documentación:

Se desarrolló un formato especial, altamente optimizado para tamaños pequeños y rápida renderización, HVIF. Por lo tanto, nuestros íconos son en gran medida mucho más pequeños que en formatos rasterizados o ampliamente usados como SVG.

Y de hecho están optimizados:

Tamaños de ícono en HVIF en comparación con otros formatos.

¡La diferencia es abismal!

Pero la magia no termina aquí. El mismo HVIF puede mostrar diferentes niveles de detalle dependiendo del tamaño de representación, a pesar de ser un formato vectorial.

Diferentes niveles de detalle (LOD) según el tamaño de representación

Ahora sobre las desventajas: no se puede simplemente tomar un SVG, cargarlo en ImageMagick y terminar ahí; hay que pasar por varios ciclos para crear un ícono en formato HVIF. Aquí explanaciones. Sin embargo, IconOMatic puede importar SVG de manera bastante imperfecta; alrededor del 90% de los detalles del SVG se importan con cierta probabilidad, los otros 10% deberán ajustarse y cambiarse manualmente. Lea más sobre cómo HVIF hace su magia en en el blog Lea Genson

Agregando un ícono a la aplicación

Ahora puedo agregar un ícono al paquete creado la última vez, teniendo en cuenta toda la información recibida.
Dado que en este momento no tengo muchas ganas de crear un ícono propio para mi 'Hola, Mundo' QtQuickApp, lo tomaré de Qt Creator.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

Verifiquemos que el ícono se haya copiado:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Se ve bien, pero, ¿por qué, cuando se copia un nuevo ícono, no se muestra?

El VICN:101:BEOS:ICONs copiado todavía no se utiliza como ícono para la aplicación en el gestor de archivos.

¿Qué he pasado por alto?

Comentario del desarrollador:

Es necesario crear un archivo rdef. con todos los recursos, luego ejecutar el comando rc nombre.rdef, eso creará el archivo .rsrc. Luego, se debe ejecutar el comando resattr -o nombre_binario nombre.rsrc. Al menos, utilizo comandos como este para agregar íconos a mis scripts.

Bueno, se deseaba crear un recurso, no un atributo. Estoy completamente confundido.

El almacenamiento en caché inteligente usando el sistema de archivos

Abrir y leer atributos ELF es lento. Como mencioné anteriormente, el ícono se escribe como un recurso en el propio archivo. Este método es más confiable y permite sobrevivir a la copia a otro sistema de archivos. Sin embargo, luego también se copia al atributo del sistema de archivos, por ejemplo BEOS:ICON. Esto solo funciona en ciertos sistemas de archivos, como BFS. Los íconos que muestra el sistema (en Tracker y Deskbar) se leen de este atributo extendido porque esta solución funciona rápidamente. En algunos lugares (donde la velocidad no es crítica, como en el cuadro de diálogo 'Acerca de') el sistema obtiene el ícono directamente del recurso en el archivo. Pero esto no es todo. Recuerde que en Mac, los usuarios podían reemplazar íconos de aplicaciones, carpetas y documentos por los suyos, ya que en Mac existe la posibilidad de hacer estas 'cosas importantes', como reemplazar el nuevo ícono de Slack con el anterior.En Haiku, se debe considerar el recurso (en el archivo) como el ícono original que viene con la aplicación, y el atributo (en el sistema de archivos BFS) como algo que permite al usuario realizar cambios a su antojo (aunque, pista, la interfaz gráfica para insertar un ícono personalizado sobre el ícono predeterminado aún no se ha implementado).

Comprobación de los atributos del sistema de archivos

Con resaddr hay una opción para verificar y establecer atributos del sistema de archivos.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

En esencia, esto es como un "pegamento" que realiza la conversión de un lado a otro entre recursos (fiables) y atributos (rápidos) del sistema de archivos. Y dado que el sistema asume la recepción de recursos y realiza la copia automáticamente, no me preocuparé más por ello.

La magia de los paquetes hpkg

Actualmente (en su mayoría) los programas en Haiku se obtienen mediante paquetes .hpkg. No se dejen engañar por el nombre simple: el formato .hpkg funciona de una manera completamente diferente a otros formatos con nombres similares que ustedes hayan encontrado, tiene verdaderos superpoderes.

Con los formatos de paquetes tradicionales, me he frustrado mucho por el siguiente hecho: descargas uno (paquete), pero en el sistema se instala otro (archivos dentro del paquete). Es bastante difícil manejar los archivos (por ejemplo, eliminarlos) cuando se instala un paquete de manera tradicional. Y todo esto se debe a que el contenido del paquete se dispersa por todo el sistema de archivos, incluyendo lugares donde el usuario común puede no tener acceso de escritura. Esto genera toda una clase de programas — gestores de paquetes. Y el traslado de software ya instalado, por ejemplo, a otra máquina, unidad extraíble o servidor de archivos se vuelve aún más difícil, o incluso completamente imposible. En un sistema típico basado en Linux pueden existir fácilmente desde cientos de miles hasta millones de archivos aislados. Por supuesto, esto es tanto frágil como lento, por ejemplo, durante la instalación inicial del sistema, al instalar, actualizar y eliminar paquetes convencionales, así como al copiar el volumen de arranque (la partición raíz) a otro medio.

Estoy trabajando en el proyecto AppImage, un soporte parcial para aplicaciones de usuario final. Este es un formato de distribución de software que empaqueta la aplicación y todas sus dependencias en una única imagen del sistema de archivos, que se monta al iniciar la aplicación. Simplifica significativamente las cosas, ya que el mismo ImageMagick de repente se convierte en un solo archivo, manejado en el gestor de archivos por simples mortales. El método propuesto solo funciona para software, como refleja el nombre del proyecto, y también tiene su propio conjunto de problemas, ya que quienes se encargan de la distribución de software para Linux siempre desvían la atención hacia mí.

Regresamos a Haiku. ¿Se logró encontrar el equilibrio óptimo entre los sistemas de paquetes tradicionales y el suministro de software basado en imágenes? Sus paquetes .hpkg son en realidad imágenes comprimidas del sistema de archivos. Al arrancar el sistema, el núcleo monta todos los paquetes instalados y activos aproximadamente con los siguientes mensajes del núcleo:

KERN: package_daemon [16042853:   924] paquete activo: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] paquete activo: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] paquete activo: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] paquete activo: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] paquete activo: "llvm_libs-5.0.0-3-x86_64.hpkg"

¡Increíble, ¿verdad?! Sostenganse, ¡hay más cosas geniales por venir!

Hay un paquete muy especial:

KERN: package_daemon [16040020:   924] paquete activo: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Contiene un sistema operativo bastante minimalista, incluyendo el núcleo. Lo crean o no, incluso el núcleo no se extrae del volumen de arranque (la partición raíz), sino que se carga cuidadosamente en su lugar desde el paquete. .hpkg¡Qué sorprendente! Ya mencioné que, en mi opinión, parte de la elegancia y coherencia de Haiku se debe a que todo el sistema, desde el núcleo y el espacio de usuario básico, hasta la gestión de paquetes y la infraestructura del entorno de trabajo, es desarrollado en conjunto por un solo equipo. Imaginen cuántos grupos y equipos diferentes se necesitarían para montar algo así basado en Linux. [imagino el proyecto PuppyLinux, —nota del traductor]. Luego imaginen cuánto tiempo tomaría implementar este enfoque en las distribuciones. Se dice: toma una tarea sencilla, divídela entre diferentes ejecutores, y se complicará tanto que ya no se podrá resolver. Haiku, en este caso, me abrió los ojos. Creo que esto es precisamente lo que está sucediendo en Linux ahora (Linux en este caso es un término colectivo que se refiere al stack Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Rollback del sistema utilizando hpkg

¿Cuántas veces ocurre la siguiente situación: una actualización se realiza con éxito y luego se descubre que algo no funciona como debería? Al usar gestores de paquetes convencionales, es difícil restaurar el estado del sistema al momento antes de la instalación de nuevos paquetes (por ejemplo, en caso de que algo salga mal). Algunos sistemas ofrecen soluciones en forma de instantáneas del sistema de archivos, pero son bastante engorrosas y tampoco se aplican en todos los sistemas. En Haiku, esto se resuelve mediante paquetes. .hpkg. Cada vez que se cambian paquetes en el sistema, los paquetes antiguos no se eliminan, sino que se almacenan en subdirectorios del tipo /Haiku/system/packages/administrative/state-<...>/ de forma constante. Las operaciones incompletas almacenan sus datos en subdirectorios /Haiku/system/packages/administrative/transaction-<...>/.

Contenido /Haiku/system/packages/administrative. Los directorios «state…» contienen archivos de texto con los nombres de los paquetes activos, y «transaction…» — los propios paquetes.

El «estado activo anterior», es decir, la lista .hpkg de los paquetes activos antes de los cambios, se registra después de cada operación en el gestor de archivos en un archivo de texto /Haiku/system/packages/administrative/state-<...>/activated-packages. De manera similar, se escribe el nuevo «estado activo» en un archivo de texto /Haiku/system/packages/administrative/activated-packages.

Directorio /Haiku/system/packages/administrative/state-<...>/ que contiene solo un archivo de texto con la lista de paquetes activos de ese estado (en caso de instalación de paquetes sin eliminación), y si los paquetes fueron eliminados o actualizados, el directorio state contiene las versiones anteriores de los paquetes.

Al iniciar el sistema, se toma la decisión de activar (montar) paquetes en función de la lista de paquetes. ¡Así de simple! Si algo sale mal durante el arranque, se puede indicar al gestor de arranque que use otra lista, más antigua. ¡Problema resuelto!

Cargador de Haiku. Cada punto de entrada refleja el correspondiente «estado activo»

Me gusta el enfoque de usar archivos de texto simples como lista de «estado activo», donde se registran nombres comprensibles .hpkg. Esto contrasta drásticamente con la creada-para-máquinas-y-no-para-humanos montón de OSTree o Flatpak en el sistema de archivos (al mismo nivel que el Microsoft GUID).

La lista de paquetes activos para cada momento en el tiempo

Datos de configuración

Aparentemente, en el directorio /Haiku/system/packages/administrative/writable-files se encuentran archivos de configuración para paquetes, pero disponibles solo para escritura. Después de todo, como recordarán, .hpkg se montan solo como lectura. Por lo tanto, estos archivos deben ser copiados de los paquetes antes de escribir. Tiene sentido.

Integración de GUI para el sistema .hpkg

Veamos ahora cómo estos brillantes paquetes .hpkg se integran en el entorno de trabajo del usuario (UX). Después de todo, Haiku está destinado a un uso personal. Personalmente, puse el listón alto al comparar la experiencia del usuario con paquetes .app en Macintosh con la misma experiencia en .hpkg. Ni siquiera voy a comparar la situación con los entornos de trabajo en Linux, porque es absolutamente horrible en comparación con cualquier otro.

Se me ocurren los siguientes escenarios:

Quiero ver el contenido del paquete .hpkg
Quiero instalar el paquete
Quiero eliminar el paquete
Quiero eliminar algo que llegó al sistema como parte del paquete
Quiero copiar algo que llegó al sistema como parte del paquete
Quiero descargar todas las dependencias del paquete que no pueden ser parte de cada instalación de Haiku (por ejemplo, tengo una máquina físicamente aislada sin acceso a Internet).
Quiero mover mis paquetes (bueno, o parte de ellos) a otro lugar aislado, distinto del volumen de arranque (la partición raíz) (porque, por ejemplo, me falta espacio en él).

Esto debería cubrir la mayoría de los casos básicos de mi trabajo diario. Bien, empecemos.

Verificando el contenido del paquete

En Mac simplemente hago clic derecho en el paquete para abrirlo y ver el contenido en Finder. Después de todo, en realidad es solo un directorio enmascarado. (Sé que hay paquetes .pkg para partes del sistema que no son aplicaciones, pero la mayoría de los usuarios no interactúan con ellos en su mayoría).

En Haiku hago clic derecho en el paquete, luego hago clic en 'Contents' para ver lo que hay dentro. Pero aquí solo hay una lista de archivos sin la posibilidad de abrirlos con un doble clic.
Sería mucho mejor si hubiera una forma (temporal) de montar el paquete .hpkg para verlo a través del gestor de archivos, sin que el usuario tenga que preocuparse por los detalles de implementación. (Por cierto, se puede abrir .hpkg el paquete en Expander, que puede descomprimirlo como cualquier otro archivo comprimido).

En la interfaz de HaikuDepot, se puede ver la lista de archivos del paquete, pero no hay forma de visualizar el contenido, por ejemplo, haciendo doble clic en README.md.

En esta categoría, Mac gana, pero agregar la funcionalidad necesaria a HaikuDepot no debería causar grandes dificultades.

Instalación del paquete a través de GUI

En Mac, la mayoría de las imágenes de disco .dmg contienen paquetes .app. Abrimos la imagen de disco haciendo doble clic, después copiamos el paquete, por ejemplo, arrastrándolo a /Applications Finder. Para mí esto es algo obvio, pero he oído que algunos principiantes pueden no entenderlo. Por defecto, Apple "ofrece" un directorio de sistema general /Applications (en NeXT era uno individual y otro de red), pero se puede colocar fácilmente tus aplicaciones en un servidor de archivos o en un subdirectorio $HOME/Applications, si así lo prefieres.

En Haiku, doble clic en el paquete, luego clic en "Instalar", no puede ser más sencillo. Me pregunto qué pasará si el paquete tiene dependencias disponibles en HaikuPorts, pero que aún no están instaladas. En Linux, realmente no saben qué hacer en esta situación, pero la solución es obvia: preguntar al usuario si necesita descargar e instalar las dependencias. Justo lo que hace Haiku.

Descargué el paquete ‘sanity’ manualmente y hice clic en él; el gestor de paquetes sabe de dónde obtener sus dependencias (siempre que los repositorios ya estén configurados en el sistema). No todas las distribuciones de Linux pueden hacer esto.

Otra forma es usar el gestor de archivos, simplemente arrastra .hpkg el paquete a /Haiku/system/packages (para instalación del sistema general, por defecto), o a /Haiku/home/config/packages (para instalación individual; no disponible con doble clic — todavía me molesta la palabra “config” en este contexto, que para mí en este caso es sinónimo de “settings”). Y es que el concepto de múltiples usuarios aún no está disponible para Haiku (quizás por eso todo es tan simple — no sé, tal vez las capacidades multusuario complicarían demasiado las cosas para el entorno de trabajo de una computadora personal).

En esta categoría, Haiku gana, porque puede trabajar no solo con aplicaciones, sino también con programas del sistema.

Eliminar un paquete desde la GUI

En Mac, solo tienes que arrastrar el ícono de la aplicación a la papelera, y eso es todo. ¡Fácil!

En Haiku, en primer lugar, necesitas encontrar dónde está el paquete en el sistema, porque rara vez lo instalarás en el lugar correcto (todo lo hace el sistema). Normalmente se debe buscar en /Haiku/system/packages (para instalación del sistema general por defecto), o en /Haiku/home/config/packages (ya mencioné que “config” es un nombre incorrecto?). Luego, la aplicación simplemente se arrastra a la papelera, y eso es todo.
¡Fácil! Sin embargo, no lo diría de esa manera. Esto es lo que realmente sucede:

Esto es lo que sucede si arrastras la aplicación a la papelera desde /Haiku/system/packages

Simplemente intenté mover a la papelera mi aplicación de ayer 'Hola, mundo' en QtQuickApp. No intenté mover el directorio del sistema, y dado que todos los paquetes se instalan en el directorio del sistema, es imposible eliminar un paquete .hpkg sin modificar su contenido. Un usuario normal probablemente se asustaría, pulsaría el botón 'Cancelar', que está asignado por defecto.

Explica mr. waddlesplash:

Este mensaje tiene más de 10 años. Probablemente necesitamos configurarlo para que la advertencia solo aparezca al mover el propio paquete. De todos modos, los usuarios normales no necesitan hacer eso.

Bien, tal vez deberíamos hacer esto, usando HaikuDepot. Hago doble clic en el paquete en /Haiku/system/packages, esperando que aparezca el botón 'Desinstalar'. No, solo hay 'Instalar'. 'Desinstalar', ¿dónde estás?

Por curiosidad, intenté ver qué pasaría si pulso 'Instalar' para un paquete ya instalado. Así es como resulta:

Esto es lo que pasa si intentas instalar un paquete ya instalado.

A continuación aparece:

Si se pulsa 'Aplicar cambios' en la ventana anterior, resultará así

Supongo que esto es un error de software, ya hay un enlace a la solicitud. [el autor no proporcionó enlace, — nota del traductor]

Solución rápida: Agregar el botón 'Desinstalar' si el paquete ya está en /Haiku/system/packages, o en /Haiku/home/config/packages.

Al revisar la lista de paquetes instalados en HaikuDepot, veo mi paquete en la lista y puedo eliminarlo.

En esta categoría, Mac gana. Pero puedo imaginar que con la configuración adecuada, la experiencia del usuario en Haiku sería mejor que en Mac. (Uno de los desarrolladores lo evaluó así: 'Menos de una hora para agregar la funcionalidad mencionada en HaikuDepot, si sabes un poco de C++', ¿hay voluntarios?)

Eliminar algo del paquete

Intentemos eliminar la propia aplicación, y no el paquete .hpkg, del cual provino (dudo que para los 'mortales comunes' haya alguna diferencia).

En Mac, un usuario normalmente trabaja con el archivo .dmg, del cual proviene el paquete de la aplicación .app. Normalmente, las imágenes .dmg se acumulan en el directorio de descargas, mientras que los paquetes son copiados por el usuario en /ApplicationsSe dice que muchos usuarios no saben lo que están haciendo, y esta hipótesis es confirmada por un ex-empleado de Apple. (Una de las cosas que no me gustan de Mac. Por ejemplo, con AppImage no hay diferencia entre la aplicación y el paquete en el que se encuentra. Arrastras el ícono a la papelera = eso es todo. ¡Fácil!)

En Haiku, también hay una división entre apps/ y packages/, así que dudo que esto aclare las cosas para los usuarios. Pero, ¿qué pasa si arrastras una aplicación de apps/ a la papelera:

Esto es lo que sucede al intentar eliminar una aplicación que fue extraída de un archivo .hpkg

Técnicamente está correcto (después de todo, la aplicación está ubicada en un sistema de archivos de solo lectura, en primer lugar), pero no es muy útil para el usuario.

Solución rápida: en lugar de esto, ofrecer a través de la interfaz gráfica eliminar .hpkg

Por curiosidad, intenté duplicar la aplicación presionando Alt+D. Recibí el mensaje 'No se pueden mover o copiar objetos en un volumen de solo lectura'. Y todo porque /system (además de /system/packages y /system/settings) es el punto de montaje de packagefs (¿recuerdas cómo aparece en la salida? df?). К сожалению, вывод команды mount no aclara la situación (como se comentó en uno de los artículos anteriores), mountvolume no muestra lo que busco (aparentemente, los paquetes montados a través de loop .hpkg no se consideran 'volúmenes'), además de que olvidé comandos alternativos.

En esta categoría, nadie ha ganado, excepto AppImage (pero esto, si se es completamente honesto, es una opinión sesgada). Sin embargo, se puede imaginar que después de ajustes, la experiencia del usuario en Haiku será mejor que en Mac.

Nota: hay que averiguar qué es un 'volumen' en relación con 'partición'. Probablemente es algo parecido a la relación de 'carpeta' con 'directorio': la mayoría de los directorios se muestran en el gestor de archivos como carpetas, pero no todos (por ejemplo, paquetes, que se manejan como archivos). ¿Estas explicaciones me convierten oficialmente en un nerd?

Copiar el contenido de un paquete a otro sistema

En Mac, simplemente arrastro el paquete .app, y como las dependencias están dentro del paquete, se mueven juntas.

En Haiku, arrastro la aplicación, pero las dependencias no se manejan en absoluto.

Solución rápida: Mejor que se proponga arrastrar el paquete '.hpkg' completo, junto con las dependencias, si las hay.

En esta categoría, Mac definitivamente gana. Al menos para mí, amante de su paradigma. En Haiku debería copiarse .hpkg en lugar de la aplicación, pero el sistema no me ofrece eso...

Descargando el paquete con todas sus dependencias

No todas las máquinas están conectadas a la red todo el tiempo. Por el contrario, algunas máquinas (sí, estoy mirando a ustedes, modernos Windows, Mac y Linux) se olvidan de esto. Para mí, es importante que pueda ir, por ejemplo, a un cibercafé, descargar software a un dispositivo extraíble, insertar ese dispositivo en mi computadora de casa y estar seguro de que todo funcionará [un chico arriesgado, haciendo eso en Windows... — nota del traductor].

Como resultado, un poco más a menudo de lo habitual, normalmente obtengo dependencias insatisfechas en Windows y Linux.

En Mac normalmente es un solo archivo, todo lo que necesitas es descargarlo .dmg. La mayoría de las veces no tiene dependencias, excepto aquellas que proporciona MacOS por defecto. Como excepción, se pueden citar aplicaciones complejas que requieren un entorno de ejecución específico, como java.

En Haiku descargar el paquete .hpkg para, digamos, la misma aplicación en java, puede resultar insuficiente, ya que java puede estar presente o no en la máquina de destino. ¿Hay alguna forma de descargar todas las dependencias para este paquete .hpkg, excepto las que se instalan en Haiku por defecto y, por lo tanto, deben estar en cada sistema Haiku?

En esta categoría, Mac gana con una ligera ventaja.

Comenta mr. waddlesplash:

Para escribir un programa que recoja todas las dependencias de una aplicación en forma de un conjunto de paquetes .hpkg para alguien que esté familiarizado con el funcionamiento interno de Haiku, bastan unos 15 minutos. Añadir soporte para esto no es tan complicado, si realmente hay necesidad. Pero para mí, es una situación poco común.

Contengamos la respiración hasta el próximo artículo de esta serie.

Moviendo paquetes a un lugar separado

Como ya he mencionado antes, quiero colocar mis paquetes .hpkg (bueno, o parte de ellos) en un lugar especial, separado de la ubicación usual en el volumen de arranque (partición raíz). En circunstancias normales (no tan teóricas), la razón es que constantemente me quedo sin espacio en mis discos (internos), sin importar cuán grandes sean. Normalmente conecto discos externos o recursos de red donde se encuentran mis aplicaciones.

En Mac simplemente muevo los paquetes .app en el disco extraíble o en el directorio de red en Finder, y eso es todo. Aún puedo abrir la aplicación con un doble clic como lo hacía normalmente desde el volumen de arranque. ¡Simple!

En Haiku, como me dijeron, esto se puede lograr moviendo mis .hpkg paquetes a un disco extraíble o directorio de red, pero luego es necesario usar algunos comandos no documentados en la consola para montarlos en el sistema. No sé cómo hacerlo usando solo el GUI.

En esta categoría, Mac gana.

Según el sr. waddlesplash:

Aquí hay una optimización para un uso común. Si hay más demanda que un solo usuario, lo implementaremos. En cualquier caso, hay posibilidad de implementación de terceros.

Hablaremos de esto en el próximo artículo.

Hablando de directorios de red: sería genial (supongo en LAN party) tener aplicaciones simples, descubiertos, de red común (por ejemplo, mediante Zeroconf), que se puedan copiar al ordenador local o ejecutar inmediatamente desde la red local. Por supuesto, los desarrolladores tienen la opción de rechazar a través de app_flags.

Informe final sobre la integración del sistema hpkg con GUI

Creo que sobre todo debido a la relativa novedad, la integración .hpkg con GUI aún deja mucho que desear. De todos modos, hay varias cosas que se pueden mejorar en términos de UX...

Otra cosa: Kernel Debug Land

Sería genial tener la capacidad de introducir comandos en caso de un kernel panic, por ejemplo syslog | grep usb. Bueno, en Haiku esto es posible gracias a Kernel Debug Land. ¿Cómo ver esta magia en acción si todo funciona como se espera sin entrar en kernel panic? Fácil, presionando Alt+PrintScn+D (mnemotécnico Debug). Me vienen a la mente Programmer’s Key, que permitía a los primeros desarrolladores de Macintosh acceder al depurador (si estaba instalado, por supuesto).

Conclusión

Empiezo a entender que la sofisticación del sistema Haiku proviene del hecho de que es desarrollado por un pequeño equipo con un enfoque claro en el entorno de trabajo y la accesibilidad de todas las capas del sistema.
Un contraste marcado con el mundo de Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, donde todo está descompuesto en partes tan pequeñas que la abstracción se encuentra sobre la abstracción y se mantiene con parches.
También ha llegado la comprensión de cómo el sistema .hpkg combina las mejores prácticas de los gestores de paquetes tradicionales, Snappy, Flatpak, AppImage, incluso btrfs, y las mezcla con el principio de que «simplemente funciona» de Mac.

Como si algo se hubiera «cambiado» en mi cabeza, y entendí cómo el sistema .hpkg puede revertirse, al solo mirarlo. Pero no soy yo, es la belleza y la simplicidad del sistema. Mucho de esto está impregnado del espíritu del Mac original.

Sí, navegar por páginas en el navegador puede ser entrecortado y funcionar como un caracol, puede haber escasez de aplicaciones (falta Gtk, Electron — los desarrolladores han llegado a la conclusión de que no se combinan bien con la sofisticación), la aceleración de video y 3D puede estar completamente ausente, pero aún así, me gusta este sistema. Porque esas cosas se pueden corregir y surgirán tarde o temprano. Solo es cuestión de tiempo y, tal vez, un poco de ojos rojos.

No puedo ofrecer ayuda, pero creo que a partir de este momento comenzará el año Haiku en el escritorio.

Problemas aleatorios

¿Ya hay solicitudes, o debería abrir algunas?

BeScreenCapture debería tener la capacidad de exportar a GIF, como en Peek. Esto se puede hacer con ffmpeg, ya disponible para Haiku. Solicitud.
El programa para capturas de pantalla no puede tomar una captura de una ventana modal, en lugar de eso captura toda la pantalla
No se pueden recortar capturas de pantalla utilizando la herramienta de recorte en WonderBrush y luego guardar el resultado en un archivo
No me gusta mucho el cursor de mano en Haiku, pero creo que está relacionado con sentimientos nostálgicos cálidos. Esto es especialmente molesto al usar la herramienta de recorte en Krita, ya que resulta en un recorte impreciso (ver capturas de pantalla con dialogos modales en este artículo). Un cursor en forma de cruz sería maravilloso. Solicitud.

¡Intenta tú mismo! El proyecto Haiku proporciona imágenes para descargar desde DVD o USB, formadas diariamente. Para instalar, solo necesitas descargar la imagen y grabarla en un pendrive con Etcher

¿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 sexto artículo de la serie sobre Haiku.

Lista de artículos: Primero Segundo Tercero Cuarto Quinta

Fuente: habr.com