TL; DR: Haiku es un sistema operativo diseñado específicamente para PC, por lo que cuenta con varios trucos que hacen que su entorno de escritorio sea mucho mejor que otros. pero como funciona?
Descubrí Haiku, un sistema inesperadamente bueno. Todavía me sorprende lo bien que funciona, especialmente en comparación con los entornos de escritorio Linux. Hoy echaré un vistazo debajo del capó. Cuando sea necesario para una comprensión profunda, haré comparaciones con los entornos de escritorio originales Macintosh, Mac OS X y Linux (estándar XDG de freedesktop.org).
Recursos en archivos ELF
Ayer supe que IconOMatic puede guardar íconos en recursos rdef en ejecutables ELF. Hoy quiero ver cómo funciona realmente.
¿Recursos? de , el autor original de Macintosh Finder y el "padre" de 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 capacidad de cambiar nada dinámicamente, es el salvajismo más salvaje. Debería ser posible cambiar tanto como sea posible en tiempo de ejecución. Por supuesto, el código de la aplicación en sí no se puede cambiar, pero seguramente se puede cambiar algo sin volver a compilar el código.
En el Macintosh original, hicieron que estos archivos tuvieran una “sección de datos” y una “sección de recursos”, lo que hizo increíblemente fácil guardar cosas como íconos, traducciones y similares. en archivos ejecutables.
En Mac esto se usa , un programa gráfico para - de repente - editar recursos.
ResEdit en el Macintosh original
Como resultado, fue posible editar íconos, elementos de menú, traducciones, etc. bastante fácil, pero aún así “viajan” con las aplicaciones.
En cualquier caso, este enfoque tenía un gran inconveniente: sólo funcionaba en los sistemas de archivos de Apple, lo que fue una de las razones por las que 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 adoptó el concepto de paquetes (de NeXT), directorios que el administrador de archivos trata como "objetos opacos", como archivos en lugar de directorios. Cualquier paquete con una aplicación en el formato .app tiene, entre otras cosas, un archivo Info.plist (en algún tipo de equivalente de Apple a JSON o YAML) que contiene metadatos de la aplicación.
Claves para el archivo Info.plist del paquete de aplicación Mac OS X.
Los recursos, como iconos, archivos de interfaz de usuario y otros, se almacenan en el paquete como archivos. En realidad, el concepto volvió a sus raíces en NeXT.
Mathematica.app en NeXTSTEP 1.0 en 1989: aparece como un directorio de archivos en la terminal, pero como un único objeto en el administrador de archivos gráfico.
Volvamos a BeOS, los conceptos en los que se basa Haiku. Sus desarrolladores, al pasar de PEF (PowerPC) a ELF (x86) (el mismo que se usa en Linux), decidieron agregar una sección de recursos al final de los archivos ELF. No utilizó su propia sección ELF propia, simplemente se añadió al final del archivo ELF. Como resultado del programa strip y otros de binutils, sin darse cuenta, simplemente lo cortan. Por lo tanto, al agregar recursos a un archivo ELF en BeOS, es mejor no manipularlo con herramientas de Linux.
¿Qué está pasando con el Haiku ahora? Básicamente, más o menos lo mismo.
En teoría, sería posible colocar recursos en la sección deseada del ELF. Según los desarrolladores del canal #haiku en irc.freenode.net:
Con ELF la sección tendría más sentido... la única razón por la que no lo hacemos de esa manera es porque es lo que hicimos en BeOS."
Y no tiene sentido cambiar esto ahora.
Administracion de recursos
Los recursos están escritos en un formato de “recurso” estructurado: esencialmente una lista de recursos con tamaños y luego su contenido. Recordé .
¿Cómo consultar recursos en Haiku? ¿Existe algo como ResEdit?
según :
Para ver los recursos proporcionados en el paquete de la aplicación, puede arrastrar el archivo ejecutable a un programa como . También puedes ir a la terminal y ejecutar el comando.
listres имя_файла.
Resourcer está disponible en HaikuDepot, pero a mí me falla.
¿Cómo gestionar recursos en archivos ELF? Usando rsrc и rdef. rdef Los archivos se recopilan en rsrc. Archivo rdef se almacena en formato de texto plano, por lo que es mucho más fácil trabajar con él. Formato de archivo rsrc adjunto al final del archivo ELF. Intentemos jugar:
~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
rc [options] [-o <file>] -d <file>...Options:
-d --decompile create an rdef script from a resource file
--auto-names construct resource names from ID symbols
-h --help show this message
-I --include <dir> add <dir> to the list of include paths
-m --merge do not erase existing contents of output file
-o --output specify output file name, default is out.xxx
-q --quiet do not display any error messages
-V --version show software version and licensePuedes usar el programa. xres para control y control:
/> 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.
(...)Bien, ¿vamos a intentarlo?
/> 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_VERSIONMás sobre recursos y formato rdef puedes leer .
Tipos de recursos estándar
Aunque puedes poner cualquier cosa en recursos, existen algunos tipos estándar definidos:
app_signature: Tipo de aplicación MIME, para mapeo de apertura de archivos, inicio, IPC, etc.app_name_catalog_entry: Dado que el nombre de la aplicación suele estar en inglés, puede especificar los lugares donde se encuentran los nombres traducidos, de modo que los usuarios de diferentes idiomas vean el nombre de la aplicación traducido si lo desean.app_version: exactamente lo que pensabasapp_flags: indicaregistrarcómo procesar la solicitud. Creo que hay más en esto de lo que parece. Por ejemplo, hayB_SINGLE_LAUNCH, que obliga al sistema a iniciar un nuevo proceso de aplicación cada vez que el usuario lo solicita (el mismo principio se utiliza para la mayoría de las aplicaciones en Linux). ComerB_MULTIPLE_LAUNCH, haciendo que el proceso se ejecute durante cada archivo. Finalmente hayB_EXCLUSIVE_LAUNCH, que obliga al sistema a iniciar solo un proceso a la vez, sin importar la frecuencia con la que los usuarios lo inicien (por ejemplo, así es como se ejecuta Firefox en Linux; se puede lograr el mismo resultado en aplicaciones Qt usando la función ). Aplicaciones conB_EXCLUSIVE_LAUNCHreciben una notificación cuando el usuario intenta ejecutarlos nuevamente: por ejemplo, reciben la ruta del archivo que el usuario desea abrir con su ayuda.vector_icon: Icono de aplicación vectorial (BeOS no tenía iconos vectoriales, la mayoría de las aplicaciones tenían dos iconos rasterizados en sus archivos ejecutables).
Por supuesto, puede agregar recursos con cualquier ID y tipo que desee y luego leerlos en la propia aplicación o en otras aplicaciones que utilicen la clase. BResources. Pero primero, veamos el fascinante tema de los íconos.
Iconos vectoriales en estilo Haiku
Por supuesto, no sólo Haiku eligió el mejor formato de icono; en este aspecto, la situación con los entornos de escritorio 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.cacheAl mirar esto ya puedes sentir la pieza que es.
Por supuesto, existe el escalable, que contiene, como puedes comprender, iconos vectoriales. ¿Por qué entonces hay algo más? Porque el resultado de dibujar gráficos vectoriales en tamaños pequeños puede no ser el ideal. Me gustaría tener diferentes opciones optimizadas para diferentes tamaños. En entornos de escritorio Linux, esto se logra distribuyendo iconos de diferentes tamaños por todo 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.pngTenga en cuenta: no existe el concepto de diferentes versiones de Firefox. Por lo tanto, no es posible manejar con elegancia la situación de tener múltiples versiones de una aplicación en el sistema.
Diferentes iconos de Firefox en diferentes versiones. Actualmente es imposible manejar esto en Linux sin varias muletas.
Mac OS X lo maneja un poco más sutilmente:
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.icnsSe puede ver que hay un archivo. firefox.icns en el paquete Firefox.app, que contiene todos los tamaños para que las diferentes versiones de una misma aplicación tengan iconos diferentes.
¡Mucho mejor! Los íconos viajan con la aplicación, todos los recursos están en un solo archivo.
Volvamos al Haiku. Una solución alucinante, sin excepciones. De acuerdo a :
Se desarrolló un formato HVIF especial, altamente optimizado para tamaños pequeños y renderizado rápido. Por lo tanto, nuestros iconos en su mayor parte son mucho más pequeños que los rasterizados o el formato SVG ampliamente utilizado.
Y todavía están optimizados:
Tamaños de iconos en HVIF en comparación con otros formatos.
¡La diferencia es de un orden de magnitud!
Pero la magia no termina aquí. Un mismo HVIF puede mostrar diferentes niveles de detalle dependiendo del tamaño mostrado, aunque sea un formato vectorial.
Diferentes niveles de detalle (LOD) según el tamaño del renderizado
Ahora sobre las desventajas: no puedes tomar SVG, colocarlo en ImageMagick y terminarlo; tienes que pasar por varios ciclos para crear un ícono en formato HVIF. explicaciones. Sin embargo, IconOMatic puede importar SVG de manera bastante imperfecta; Aproximadamente el 90% de los detalles SVG se importan con cierta probabilidad, el 10% restante deberá configurarse y cambiarse manualmente. Lea más sobre cómo HVIF hace su magia en el blog
Agregar un ícono a la aplicación
Ahora puedo agregar un ícono al paquete creado. , teniendo en cuenta toda la información recibida.
Bueno, como no estoy particularmente ansioso por dibujar mi propio ícono para mi QtQuickApp “Hola, mundo” en este momento, lo saqué 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 CreatorComprobemos que el icono ha sido copiado:
/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type ID size name
------ ----------- ----------- --------------------
'VICN' 101 152238 BEOS:ICONSe ve bien, pero ¿por qué cuando se copia el nuevo ícono no aparece?
El VICN:101:BEOS:ICONs copiado aún no se utiliza como icono de aplicación en el administrador de archivos
¿Qué me perdí?
Comentario del desarrollador:
Necesitamos crear un archivo.
rdefcon todos los recursos, luego ejecute el comandorc имя.rdef, esto creará el archivo.rsrc. Entonces necesitas ejecutar el comando.resattr -o имя_бинарника имя.rsrc. Como mínimo, uso comandos como estos para agregar íconos a mis scripts.
Bueno, quería crear un recurso, no un atributo. Estoy realmente confundido.
Almacenamiento en caché inteligente utilizando el sistema de archivos
Abrir y leer atributos ELF es lento. Como escribí anteriormente, el ícono está escrito como un recurso en el propio archivo. Este método es más confiable y le permite sobrevivir copiando a otro sistema de archivos. Sin embargo, luego también se copia al atributo del sistema de archivos, por ejemplo BEOS:ICON. Esto sólo funciona en determinados sistemas de archivos, como BFS. Los íconos que muestra el sistema (en Tracker y Deskbar) se leen desde este atributo extendido, porque esta solución funciona rápidamente. En algunos lugares (donde la velocidad no es importante, por ejemplo, una típica ventana "Acerca de"), el sistema recibe el icono directamente del recurso en el archivo. Pero, este no es el final. Recuerde, en Mac los usuarios pueden reemplazar íconos de aplicaciones, directorios, documentos por los suyos propios, ya que en Mac es posible hacer estas cosas “importantes”, por ejemplo . En Haiku, debes pensar en 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 voluntad (aunque, pista, (la GUI para insertar un ícono personalizado encima del ícono es opcional) (aún no está implementada de manera predeterminada).
Comprobando los atributos del sistema de archivos
Con resaddr Es posible comprobar y configurar los 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.
(...)Es esencialmente el "pegamento" que realiza la conversión entre recursos (confiables) y atributos (rápidos) del sistema de archivos. Y como el sistema espera recibir recursos y realiza la copia automáticamente, no me preocuparé más por eso.
La magia de los paquetes hpkg
Actualmente (con mayor frecuencia) los paquetes se utilizan para obtener programas en Haiku. .hpkg. No te dejes engañar por el nombre simple: el formato .hpkg funciona de manera completamente diferente a otros formatos con nombres similares que hayas encontrado, tiene verdaderos superpoderes.
Con los formatos de paquetes tradicionales, estuve molesto durante mucho tiempo por este hecho: descargas una cosa (paquete) y otra se instala en el sistema (archivos dentro del paquete). Es bastante difícil administrar archivos (por ejemplo, eliminarlos) al instalar un paquete de la forma tradicional. Y todo porque el contenido del paquete. dispersos por todo el sistema de archivos, incluidos lugares donde el usuario medio puede no tener acceso de escritura. Esto da lugar a toda una clase de programas: administradores de paquetes. Pero transferir software ya instalado, por ejemplo, a otra máquina, disco extraíble o servidor de archivos, se vuelve aún más difícil, si no completamente imposible. En un sistema típico basado en Linux, puede haber fácilmente varios cientos de miles o millones de archivos individuales. No hace falta decir que esto es frágil y lento, por ejemplo, al instalar inicialmente un sistema, al instalar, actualizar y desinstalar paquetes regulares y al copiar el volumen de inicio (partición raíz) a otro medio.
Estoy trabajando en el proyecto AppImage, un apoyo parcial para las aplicaciones de usuario final. Este es un formato de distribución de software que recopila una aplicación y todas sus dependencias en una única imagen del sistema de archivos que se monta cuando se inicia la aplicación. Simplifica significativamente las cosas, ya que el mismo ImageMagick de repente se convierte en un solo archivo, administrado en un administrador de archivos por simples mortales. El método propuesto sólo funciona para software, como se refleja en el nombre del proyecto, y también tiene su propio conjunto de problemas, ya que las personas involucradas en la entrega de software para Linux siempre me apuntan a mí.
Volvamos al Haiku. ¿Ha sido posible encontrar el equilibrio óptimo entre los sistemas de paquetes tradicionales y la entrega de software basado en imágenes? sus paquetes .hpkg imágenes del sistema de archivos realmente comprimidas. Cuando se inicia el sistema, el kernel monta todos los paquetes instalados y activos con aproximadamente los siguientes mensajes del kernel:
KERN: package_daemon [16042853: 924] active package: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023: 924] active package: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232: 924] active package: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405: 924] active package: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611: 924] active package: "llvm_libs-5.0.0-3-x86_64.hpkg"Genial, ¿sí? ¡Aguanta, será aún más genial!
Hay un paquete muy especial:
KERN: package_daemon [16040020: 924] active package: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"Contiene un sistema operativo muy minimalista, incluido el kernel. Lo creas o no, ni siquiera el kernel en sí se elimina del volumen de arranque (partición raíz), sino que se carga cuidadosamente en su lugar desde el paquete. .hpkg. ¡Guau! Ya mencioné que creo que parte de la sofisticación y consistencia general de Haiku proviene del hecho de que todo el sistema, desde el núcleo y el espacio de usuario central hasta la administración de paquetes y la infraestructura de tiempo de ejecución, es desarrollado en colaboración por un solo equipo. Imagínese cuántos grupos y equipos diferentes se necesitarían para ejecutar algo como esto en Linux. [Me imagino el proyecto PuppyLinux - aprox. traductor]. Luego imagine cuánto tiempo llevará adoptar este enfoque en las distribuciones. Dicen: tomen un problema simple, divídanlo entre diferentes intérpretes y se volverá tan complicado que ya no será posible resolverlo. Haiku en este caso me abrió los ojos. Creo que esto es exactamente lo que está sucediendo en Linux ahora (Linux en este caso es un término colectivo para la pila Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).
Reversión del sistema usando hpkg
¿Con qué frecuencia ocurre la siguiente situación: la actualización fue exitosa y luego resulta que algo no funciona como debería? Si utiliza administradores de paquetes convencionales, es difícil devolver el estado del sistema a un momento anterior a la instalación de nuevos paquetes (por ejemplo, en caso de que algo saliera mal). Algunos sistemas ofrecen soluciones en forma de instantáneas del sistema de archivos, pero son bastante engorrosas y no se utilizan en todos los sistemas. Haiku resuelve esto usando paquetes. .hpkg. Siempre que los paquetes cambian en el sistema, los paquetes antiguos no se eliminan, sino que se almacenan en el sistema en subdirectorios como /Haiku/system/packages/administrative/state-<...>/ constantemente. Las operaciones no terminadas almacenan sus datos en subdirectorios /Haiku/system/packages/administrative/transaction-<...>/.
contenido /Haiku/system/packages/administrative. Los directorios “estado...” contienen archivos de texto con los nombres de los paquetes activos, y los directorios “transacción...” contienen los paquetes mismos.
"Antiguo estado activo", es decir lista .hpkg Los paquetes activos antes de los cambios se registran después de cada operación en el administrador de archivos en un archivo de texto. /Haiku/system/packages/administrative/state-<...>/activated-packages. De manera similar, se escribe un nuevo "estado activo" en un archivo de texto. /Haiku/system/packages/administrative/activated-packages.
directorio /Haiku/system/packages/administrative/state-<...>/ contiene solo un archivo de texto con una lista de paquetes activos de este estado (en caso de instalación de paquetes sin eliminación), y si los paquetes se eliminaron o actualizaron, el directorio de estado contiene versiones antiguas de los paquetes.
Cuando se inicia el sistema, según la lista de paquetes, se toma la decisión de activar (montar) paquetes. ¡Es así de simple! Si algo sale mal durante la descarga, puede indicarle al administrador de descargas que utilice una lista anterior diferente. ¡Problema resuelto!
Descargador de haikus. Cada punto de entrada muestra un "estado activo" correspondiente
Me gusta el enfoque de tener archivos de texto simples como lista de "estado activo", con nombres que sean fáciles de entender. .hpkg. Esto contrasta marcadamente con estar construidos para máquinas, no para personas. desde OSTree o Flatpak en el sistema de archivos (en el mismo nivel que Microsoft GUID).
Lista de paquetes activos para cada momento
Datos de configuración
Al parecer, en el catálogo. /Haiku/system/packages/administrative/writable-files Contiene archivos de configuración para paquetes, pero se pueden escribir. Después de todo, como recuerdas, .hpkg montado de solo lectura. Por lo tanto, estos archivos deben copiarse de los paquetes antes de escribirlos. Tiene el significado.
Integración GUI para el sistema .hpkg
Veamos ahora cómo funcionan estas bolsas brillantes. .hpkg afrontar la integración en el entorno de trabajo del usuario (UX). Después de todo, Haiku está destinado a uso personal. Personalmente, pongo el listón alto al comparar la experiencia del usuario con los paquetes. .app en Macintosh con la misma experiencia en .hpkg. Ni siquiera compararé la situación con los entornos de trabajo en Linux, porque es absolutamente terrible en comparación con cualquier otro.
Me vienen a la mente los siguientes escenarios:
- Quiero ver el contenido de un paquete.
.hpkg - quiero instalar un paquete
- quiero quitar el paquete
- Quiero eliminar algo que entró en el sistema como parte de un paquete.
- Quiero copiar algo que entró en el sistema como parte de un paquete.
- Quiero descargar todas las dependencias de un paquete, que puede no 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 (o parte de ellos) por separado a otra ubicación, separada del volumen de inicio (partición raíz) (porque, por ejemplo, no tengo suficiente espacio).
Esto debería cubrir la mayoría de los casos más importantes de mi trabajo diario. Bueno, comencemos.
Comprobando 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 sólo un directorio disfrazado! (Sé que hay paquetes .pkg para una parte del sistema que no son aplicaciones, pero los usuarios comunes a menudo no interactúan con ellas).
En haikus Hago clic derecho en el paquete, luego hago clic en "Contenido" para ver qué hay dentro. Pero aquí hay sólo una lista de archivos sin la posibilidad de abrirlos haciendo doble clic.
Sería mucho mejor si hubiera una manera de montar (temporalmente) el paquete. .hpkg para ser visto a través de un administrador de archivos, y el usuario no tendría que preocuparse por los detalles de implementación. (Por cierto, puedes abrir .hpkg paquete en Expander, que puede descomprimirlo como cualquier otro archivo).
La interfaz de HaikuDepot le permite ver una lista de archivos de paquetes, pero no hay forma de ver el contenido, por ejemplo, haciendo doble clic en README.md.
Mac gana en esta categoría, pero agregar la funcionalidad HaikuDepot que desea no debería ser demasiado difícil.
Instalación de un paquete a través de GUI
En Mac, la mayoría de las imágenes de disco .dmg contener paquetes .app. Haga doble clic en la imagen del disco y luego copie el paquete, por ejemplo, arrastrándolo a /Applications en Buscador. Esto es evidente para mí, pero he oído que es posible que algunos novatos no puedan manejar esto. De forma predeterminada, Apple "sugiere" un directorio para todo el sistema /Applications (en NeXT estaba tanto en red como individualmente), pero puedes colocar fácilmente tus aplicaciones en un servidor de archivos o en un subdirectorio $HOME/Applications, si te gusta así.
En haikus, haz doble clic en el paquete, luego haz clic en “Instalar”, no podría ser más fácil. Me pregunto qué sucede si un paquete tiene dependencias que están 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 dependencias. Exactamente lo que hace Haiku.
Descargué el paquete 'sanity' manualmente y hice clic en él, el administrador de paquetes sabe de dónde obtener sus dependencias (suponiendo que los repositorios ya estén registrados en el sistema). No todas las distribuciones de Linux pueden hacer esto.
Otra forma es utilizar un administrador de archivos, simplemente arrastre y suelte .hpkg paquete o en /Haiku/system/packages (para una instalación de todo el sistema, de forma predeterminada), o en /Haiku/home/config/packages (para instalación individual; no disponible al hacer doble clic; todavía me molesta la palabra "config" en este lugar, que para mí en este caso es sinónimo de "configuración"). Y el concepto de múltiples usuarios ni siquiera está disponible para Haiku todavía (probablemente por eso es tan simple; no lo sé, tal vez las capacidades multiusuario compliquen innecesariamente las cosas para un entorno de escritorio).
Haiku gana en esta categoría porque puede funcionar no sólo con aplicaciones, sino también con programas del sistema.
Eliminar un paquete de la GUI
En Mac, debes arrastrar el ícono de la aplicación a la papelera y eso es todo. ¡Fácilmente!
En haikus, en primer lugar, debe encontrar dónde se encuentra el paquete en el sistema, porque rara vez lo instala en el lugar correcto (el sistema hace todo). Normalmente hay que mirar /Haiku/system/packages (con una instalación predeterminada para todo el sistema), o en /Haiku/home/config/packages (¿Mencioné que "config" es un nombre inapropiado?). Luego simplemente se arrastra la aplicación a la papelera y listo.
¡Fácilmente! Sin embargo, yo no diría eso. Esto es lo que realmente está sucediendo:
Esto es lo que sucede si arrastras una aplicación a la papelera desde /Haiku/system/packages
Intenté mover la aplicación "Hello World" de ayer en QtQuickApp a la papelera. No intenté mover el directorio del sistema, y dado que todos los paquetes están instalados en el directorio del sistema, es imposible eliminar el paquete .hpkg sin cambios "su contenido". Un usuario común y corriente se asustaría y presionaría el botón “Cancelar” asignado por defecto.
explica :
Esta publicación tiene más de 10 años. Lo más probable es que necesitemos configurarlo para que la advertencia aparezca solo cuando se mueva el paquete. Los usuarios habituales no necesitan hacer esto de todos modos.
Bien, ¿tal vez debería hacer esto usando HaikuDepot? Hago doble clic en el paquete en /Haiku/system/packages, esperando a que aparezca el botón “Desinstalar”. No, (sólo) existe "Instalar". "Desinstalar", ¿dónde estás?
Sólo por diversión, intenté ver qué pasaría si hacía clic en "Instalar" en un paquete ya instalado. Resulta así:
Esto sucede si intenta instalar un paquete ya instalado.
Aparece lo siguiente:
Si hace clic en "Aplicar cambios" en la ventana anterior, se verá así
Supongo que se trata de un error de software; el enlace a la aplicación ya está ahí. [el autor no proporcionó un enlace - aprox. traductor]
Solución rápida: agregue un botón "Desinstalar" si el paquete ya está en
/Haiku/system/packageso en/Haiku/home/config/packages.
Al ver la lista de paquetes instalados en HaikuDepot, veo mi paquete en la lista y puedo eliminarlo.
El Mac gana en esta categoría. Pero puedo imaginar que con la configuración adecuada, la experiencia del usuario en Haiku será mejor que en Mac. (Uno de los desarrolladores lo calificó de esta manera: “Menos de una hora para agregar la funcionalidad especificada a HaikuDepot, si sabes un poco de C++”, ¿algún voluntario?)
Quitar algo de un paquete
Intentemos eliminar la aplicación en sí, no el paquete. .hpkg, de donde vino (dudo que para los “simples mortales” haya alguna diferencia).
En Mac, el usuario normalmente trabaja con el archivo .dmg¿De dónde viene el paquete de solicitud? .app. Generalmente imágenes .dmg se acumulan en el directorio de descargas y el usuario copia los paquetes en /Applications. Se cree que muchos usuarios no saben lo que están haciendo, esta hipótesis la confirma un ex empleado de Apple. (Una de las cosas que no me gustan en Mac. Y, por ejemplo, con AppImage no hay diferencia entre la aplicación y el paquete en el que estaba. Arrastra el ícono a la papelera = listo. ¡Fácil!)
En haikus, también existe una división entre apps/ и packages/, así que dudo que esto lo haya dejado más claro para los usuarios. Pero, ¿qué sucede si arrastras una aplicación desde apps/ Añadir a la cesta:
Esto es lo que sucede cuando intentas eliminar una aplicación extraída de un archivo .hpkg
Técnicamente es correcto (después de todo, la aplicación está alojada en un sistema de archivos de sólo lectura), pero no es particularmente útil para el usuario.
Solución rápida: sugiera usar GUI para eliminar en su lugar
.hpkg
Sólo por diversión, intenté duplicar la aplicación presionando Alt+D. Recibí el mensaje "No se pueden mover ni copiar objetos en un volumen de solo lectura". Y todo porque /system (además /system/packages и /system/settings) es el punto de montaje de packagefs (recuerde cómo aparece en la salida df?). Desafortunadamente, la salida del comando mount no aclara la situación (como se dijo en uno de los artículos anteriores), mountvolume no muestra lo que está buscando (aparentemente paquetes montados mediante bucle .hpkg no se consideran "volúmenes"), y también olvidé los comandos alternativos.
Nadie ganó en esta categoría excepto AppImage (pero, para ser completamente honesto, es una opinión sesgada). Sin embargo, uno puede imaginar que después de realizar ajustes, la experiencia del usuario en Haiku será mejor que en Mac.
Nota: es necesario averiguar qué es un “volumen” en relación con una “sección”. Probablemente esto sea similar a la relación entre "carpeta" y "directorio": la mayoría de los directorios aparecen como carpetas en el administrador de archivos, pero no todos (los paquetes tratados como archivos, por ejemplo). ¿Este tipo de exhibición me convierte en un nerd oficial?
Copiar el contenido de un paquete a otro sistema
En Mac, arrastro estúpidamente el paquete .app, y dado que las dependencias están dentro del paquete, se mueven juntas.
En haikus, Arrastro la aplicación, pero las dependencias no se procesan en absoluto.
Solución rápida: en su lugar, sugerimos arrastrar el paquete `.hpkg completo, junto con las dependencias, si las hubiera.
Mac claramente gana en esta categoría. Al menos para mí, amante de su paradigma. Debería copiarlo a Haiku .hpkg en lugar de una aplicación, pero el sistema no me ofrece esto...
Descargar un 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í, te estoy mirando, Windows, Mac y Linux modernos) se olvidan de esto. Para mí es importante poder ir, por ejemplo, a un cibercafé, descargar software en una unidad extraíble, insertar esta unidad en la computadora de mi casa y estar seguro de que todo funcionará [tipo arriesgado, haciendo esto en Windows... - aprox. traductor].
Como resultado, tiendo a terminar con dependencias insatisfechas en Windows y Linux con un poco más de frecuencia de lo habitual.
En Mac Este suele ser un archivo, todo lo que necesitas hacer es descargarlo. .dmg. La mayoría de las veces, no tiene más dependencias que las proporcionadas por MacOS de forma predeterminada. Una excepción son las aplicaciones complejas que requieren un entorno de ejecución adecuado, por ejemplo java.
En haikus descargar paquete .hpkg para, digamos, la misma aplicación en java, puede no ser suficiente, ya que java puede estar presente o no en la máquina de destino. ¿Hay alguna manera de descargar todas las dependencias de un paquete determinado? .hpkg, aparte de los que están instalados de forma predeterminada en Haiku y, por lo tanto, deberían estar en todos los sistemas Haiku?
Mac gana esta categoría por un pequeño margen.
Comentarios Sr. chapoteo:
Escribir un programa para recopilar todas las dependencias de una aplicación como un conjunto de paquetes.
.hpkgpara alguien familiarizado con el funcionamiento interno del Haiku, unos 15 minutos son suficientes. Agregar soporte para esto no es tan difícil si existe una necesidad real. Pero para mí esta es una situación rara.
Contengamos la respiración hasta el próximo artículo de esta serie.
Mover paquetes a una ubicación separada
Como escribí antes, quiero colocar mis paquetes .hpkg (bueno, o parte de ellos) a un lugar especial, separado de la ubicación habitual en el volumen de inicio (partición raíz). En el caso habitual (no tan teórico), la razón es que constantemente me quedo sin espacio libre en mis discos (integrados), sin importar cuán grandes sean. Y normalmente conecto unidades externas o recursos compartidos de red donde se encuentran mis aplicaciones.
En Mac solo estoy moviendo paquetes .app a una unidad extraíble o directorio de red en Finder, y eso es todo. Todavía puedo hacer doble clic para abrir la aplicación como lo haría normalmente desde el volumen de inicio. ¡Justo!
En haikus, como me dijeron, esto se puede lograr moviendo mi .hpkg paquetes a una unidad extraíble o directorio de red, pero luego necesita usar algunos comandos no documentados en la consola para poder montarlos en el sistema. No sé cómo hacer esto usando sólo la GUI.
El Mac gana en esta categoría.
Según el sr. chapoteo:
Esta es una optimización basada en el uso normal. Si hay demanda de más de un usuario, lo implementaremos. En cualquier caso, existe la posibilidad de implementación por parte de terceros.
Hablaremos de esto en el próximo artículo.
Hablando de directorios de red, sería fantástico (supongo que para grupos LAN) tener aplicaciones simples, reconocibles y para toda la red (como Zeroconf) que puedan copiarse a la computadora local o ejecutarse directamente desde la red local. Por supuesto, los desarrolladores tienen la opción de optar por no participar a través de app_flags.
Informe final sobre la integración del sistema hpkg con la GUI
Creo que debido principalmente a la relativa novedad de la integración .hpkg La GUI todavía deja mucho que desear. De todos modos, hay algunas cosas que podrían mejorarse en términos de UX...
Una cosa más: Kernel Debug Land
Sería genial poder ingresar comandos durante el pánico del kernel, por ejemplo syslog | grep usb. Pues en Haiku es posible gracias a Kernel Debug Land. ¿Cómo puedes ver esta magia en acción si todo funciona como debería sin entrar en pánico? Fácil presionando Alt+ImprimirPan+D (mnemónico de depuración). lo recuerdo inmediatamente , lo que permitió a los desarrolladores originales de Macintosh ingresar al depurador (si estaba instalado, por supuesto).
Conclusión
Estoy empezando a comprender que la sofisticación del sistema Haiku proviene del hecho de que el trabajo lo lleva a cabo un pequeño equipo con un claro enfoque en el entorno de trabajo, con todas las capas del sistema accesibles.
Un marcado contraste con el mundo de Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, donde todo está dividido en pequeños pedazos hasta tal punto que la abstracción se sienta sobre la abstracción y se conduce con muletas.
También se entendió cómo funciona el sistema. .hpkg combina las mejores prácticas de los administradores de paquetes tradicionales, Snappy, Flatpak, AppImage e incluso btrfs, y las combina con el enfoque de "simplemente funciona" de Mac.
Fue como si algo "cambiara" en mi cabeza y entendí cómo funciona el sistema. .hpkg sabe cómo alejarse rodando, con sólo mirarla. Pero no soy yo, sino la belleza y la sencillez del sistema. Gran parte de esto está inspirado en el espíritu del Mac original.
Sí, la navegación en el navegador puede ser entrecortada y funcionar como un caracol, es posible que falten aplicaciones (no hay Gtk, Electron; los desarrolladores concluyeron que no combinan bien con la sofisticación), el video y la aceleración 3D pueden estar completamente ausentes, pero aún así Me gusta este sistema. Después de todo, estas cosas se pueden corregir y aparecerán tarde o temprano. Es sólo cuestión de tiempo y tal vez de un poco de ojos rojos.
No puedo ofrecer ayuda, pero creo que empezará a partir de ahora. año de Haiku en el escritorio.
Problemas aleatorios
¿Quizás ya haya solicitudes o debería abrirlas?
- BeScreenCapture debería poder exportar a GIF como Peek. Esto se puede hacer usando ffmpeg, ya disponible para Haiku. .
- El software de captura de pantalla no logra capturar una ventana modal, sino que captura toda la pantalla
- No puedes recortar capturas de pantalla con la herramienta de recorte de WonderBrush y luego guardar el resultado en un archivo.
- No me gusta particularmente el cursor de la mano en Haiku, pero creo que tiene que ver con el cálido sentimiento nostálgico. Esto es especialmente molesto cuando se utiliza la herramienta de recorte en Krita, ya que da como resultado un recorte inexacto (ver capturas de pantalla de cuadros de diálogo modales en este artículo). Un cursor en forma de cruz sería maravilloso. .
¡Inténtalo tú mismo! Después de todo, el proyecto Haiku proporciona imágenes para arrancar desde DVD o USB, generadas . Para instalar, simplemente descargue la imagen y escríbala en una unidad flash usando
¿Tiene usted alguna pregunta? Te invitamos a los de habla rusa. .
Resumen de errores:
De traducción: este es el sexto artículo de la serie sobre Haiku.
Lista de artículos:
Fuente: habr.com