Algo máis: paquetes de aplicacións Haiku?

TL, RD: Haiku pode obter soporte adecuado para paquetes de aplicacións, como directorios de aplicacións (como .app en Mac) e/ou imaxes de aplicacións (Linux AppImage)? Creo que esta sería unha adición digna que é máis fácil de implementar correctamente que outros sistemas xa que a maior parte da infraestrutura xa está instalada.

Hai unha semana Descubrín o Haiku, un sistema inesperadamente bo. Pois ben, xa que hai tempo que me interesaban os directorios e as imaxes de aplicacións (inspiradas na sinxeleza do Macintosh), non é de estrañar que se me ocorrese unha idea...

Para unha comprensión total, son o creador e autor de AppImage, un formato de distribución de aplicacións de Linux que pretende a simplicidade de Mac e dá control total aos autores e usuarios finais de aplicacións (se queres saber máis, consulta wiki и documentación).

E se facemos unha AppImage para Haiku?

Pensemos un pouco, puramente teoricamente: que hai que facer para conseguir AppImage, ou algo semellante, en Haiku? Non é necesario crear algo agora mesmo, porque o sistema que xa existe en Haiku funciona incriblemente, pero un experimento imaxinario estaría ben. Tamén demostra a sofisticación do Haiku, en comparación cos entornos de escritorio Linux, onde tales cousas son terriblemente difíciles (teño dereito a dicilo: levo 10 anos loitando coa depuración).

No Macintosh System 1, cada aplicación era un ficheiro separado "xestionado" no Finder. Usando AppImage estou tentando recrear a mesma experiencia de usuario en Linux.

En primeiro lugar, que é unha AppImage? Este é un sistema para lanzar aplicacións de terceiros (por exemplo, Ultimaker Cure), permitindo que as aplicacións se publiquen cando e como queiran: non é necesario coñecer as características específicas de varias distribucións, crear políticas ou construír infraestruturas, non se precisa soporte de mantedores e non din aos usuarios o que (non) poden instalar. nos seus ordenadores. AppImage debe entenderse como algo similar a un paquete de Mac no formato .app dentro da imaxe do disco .dmg. A principal diferenza é que as aplicacións non se copian, senón que permanecen dentro da AppImage para sempre, o mesmo que os paquetes Haiku. .hpkg montado, e nunca instalado no sentido habitual.

Ao longo de máis de 10 anos de existencia, AppImage gañou certo atractivo e popularidade: o propio Linus Torvalds aprobouno publicamente e proxectos comúns (por exemplo, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) adoptárono como a principal vía. para distribuír compilacións continuas ou nocturnas, sen interferir coas aplicacións de usuario instaladas ou desinstaladas. Non obstante, os ambientes de escritorio e as distribucións de Linux a miúdo seguen aferrados ao modelo de distribución tradicional e centralizado baseado en mantedores e/ou promoven o seu propio negocio empresarial e/ou programas de enxeñería baseados en Flatpak (RedHat, Fedora, GNOME) e Mal humor (Canónico, Ubuntu). Vén ridículamente.

Como funciona todo

• Cada AppImage contén 2 partes: un pequeno ELF de dobre clic (o chamado. runtime.c), seguido dunha imaxe do sistema de ficheiros SquashFS.

• O sistema de ficheiros SquashFS contén a carga útil da aplicación e todo o necesario para executala, o que, no seu caso, non se pode considerar parte da instalación predeterminada para todos os sistemas de destino bastante recentes (distribución Linux). Tamén contén metadatos, como o nome da aplicación, iconas, tipos MIME, etc., etc.

• Cando o usuario o executa, o tempo de execución usa FUSE e squashfuse para montar o sistema de ficheiros e, a continuación, xestiona a execución dalgún punto de entrada (tamén coñecido como AppRun) dentro da AppImage montada.
  O sistema de ficheiros desmontarase despois de que se complete o proceso.

Todo parece sinxelo.

E estas cousas complican todo:

• Con tanta variedade de distribucións de Linux, nada "no seu criterio" pode ser chamado "parte da instalación predeterminada para cada novo sistema de destino". Resolvemos este problema construíndo lista de exclusións, o que lle permite determinar o que se empaquetará na AppImage e o que haberá que levar a outro lugar. Ao mesmo tempo, ás veces botamos de menos, a pesar de que, en xeral, todo funciona moi ben. Por este motivo, recomendamos que os creadores de paquetes proben AppImages en todos os sistemas (distribucións) de destino.
• As cargas útiles das aplicacións deben ser reubicables no sistema de ficheiros. Desafortunadamente, moitas aplicacións teñen rutas absolutas codificadas para, por exemplo, recursos /usr/share. Isto debe ser corrixido dalgún xeito. Ademais, debes exportar LD_LIBRARY_PATH, ou corrixir rpath para que o cargador poida atopar bibliotecas relacionadas. O primeiro método ten os seus inconvenientes (que se superan de xeito complexo), e o segundo é simplemente engorroso.
• O maior problema de UX para os usuarios é iso establecer o bit executable Ficheiro AppImage despois da descarga. Créao ou non, esta é unha verdadeira barreira para algúns. A necesidade de establecer o bit de executabilidade é complicada incluso para usuarios experimentados. Como solución alternativa, suxerimos instalar un pequeno servizo que supervisa os ficheiros de AppImage e establece o seu bit de executabilidade. Na súa forma pura, non é a mellor solución, xa que non funcionará fóra da caixa. As distribucións de Linux non ofrecen este servizo, polo tanto, os usuarios teñen unha mala experiencia fóra da caixa.
• Os usuarios de Linux esperan que unha nova aplicación teña unha icona no menú de inicio. Non lle podes dicir ao sistema: "Mira, hai unha nova aplicación, imos traballar". Pola contra, segundo a especificación XDG, cómpre copiar o ficheiro .desktop ao lugar correcto /usr para unha instalación en todo o sistema, ou en $HOME para individual. As iconas de determinados tamaños, segundo a especificación XDG, deben colocarse en determinados lugares usr ou $HOME, e despois execute comandos no ambiente de traballo para actualizar a caché de iconas, ou espere que o xestor do ambiente de traballo o descubra e detecte todo automaticamente. O mesmo cos tipos MIME. Como solución alternativa, proponse utilizar o mesmo servizo que, ademais de establecer a bandeira de executabilidade, fará, se hai iconas, etc. en AppImage, cópiaos desde AppImage aos lugares correctos segundo XDG. Cando se elimina ou se move, espérase que o servizo limpa todo. Por suposto, existen diferenzas no comportamento de cada contorno de traballo, nos formatos de ficheiros gráficos, os seus tamaños, localizacións de almacenamento e métodos de actualización das cachés, o que crea un problema. En resumo, este método é unha muleta.
• Se o anterior non é suficiente, aínda non hai icona de AppImage no xestor de ficheiros. O mundo Linux aínda non decidiu implementar elficon (a pesar discusión и implementación), polo que é imposible inserir a icona directamente na aplicación. Polo tanto, resulta que as aplicacións do xestor de ficheiros non teñen as súas propias iconas (sen diferenzas, AppImage ou outra cousa), só están no menú de inicio. Como solución alternativa, estamos a usar miniaturas, un mecanismo que foi deseñado orixinalmente para permitir aos xestores do escritorio mostrar imaxes de vista previa en miniatura de ficheiros gráficos como as súas iconas. En consecuencia, o servizo para configurar o bit de executabilidade tamén funciona como un "miniaturizador", creando e escribindo miniaturas de iconas nas localizacións adecuadas. /usr и $HOME. Este servizo tamén realiza a limpeza se a AppImage se elimina ou se move. Debido ao feito de que cada xestor de escritorio se comporta de forma lixeiramente diferente, por exemplo, en que formatos acepta iconas, en que tamaños ou lugares, todo isto é realmente doloroso.
• A aplicación simplemente falla ao executarse se se producen erros (por exemplo, hai unha biblioteca que non forma parte do sistema base e non se proporciona en AppImage) e non hai ninguén que lle di ao usuario o que está a suceder exactamente na GUI. Comezamos a sortear isto usando notificacións no escritorio, o que significa que necesitamos detectar erros desde a liña de comandos, convertelos en mensaxes entendidas polo usuario, que logo deben mostrarse no escritorio. E, por suposto, cada ambiente de escritorio manexaos dun xeito un pouco diferente.
• Polo momento (setembro de 2019 - nota do tradutor) non atopei unha forma sinxela de dicirlle ao sistema que o ficheiro 1.png debe abrirse usando Krita e 2.png - usando GIMP.

Localización de almacenamento para as especificacións de escritorio que se usan en GNOME, KDE и Xfce é freedesktop.org

Conseguir o nivel de sofisticación profundamente tecido no ambiente de traballo de Haiku é difícil, se non imposible, debido ás especificacións XDG de freedesktop.org para multidesktop, así como implementacións de xestores de escritorio baseados nestas especificacións. Como exemplo, podemos citar unha icona de Firefox para todo o sistema: ao parecer, os autores de XDG nin sequera pensaban que un usuario puidese ter instaladas varias versións da mesma aplicación.

Iconas para diferentes versións de Firefox

Preguntábame que podía aprender o mundo Linux de Mac OS X para evitar arruinar a integración do sistema. Se tes tempo e estás nisto, asegúrate de ler o que dixo Arnaud Gurdol, un dos primeiros enxeñeiros de Mac OS X:

Queriamos que a instalación da aplicación fose tan sinxela como arrastrar a icona da aplicación desde algún lugar (servidor, unidade externa) á unidade do teu ordenador. Para iso, o paquete da aplicación almacena toda a información, incluíndo iconas, versión, tipo de ficheiro que se está a procesar, tipo de esquemas de URL que o sistema necesita coñecer para procesar a aplicación. Isto tamén inclúe información para o "almacenamento central" na base de datos de Servizos de Iconos e Servizos de Lanzamento. Para soportar o rendemento, as aplicacións son "descubertas" en varios lugares "coñecidos": os directorios de aplicacións do sistema e do usuario, e algúns outros automaticamente se o usuario navega ao Finder no directorio que contén a aplicación. Na práctica isto funcionou moi ben.

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

Non hai nada como esta infraestrutura nos escritorios Linux, polo que estamos a buscar solucións para as limitacións estruturais do proxecto AppImage.

Haiku vén ao rescate?

E unha cousa máis: as plataformas Linux como base dos ambientes de escritorio adoitan estar tan pouco especificadas que moitas cousas que son bastante simples nun sistema de pila completa consistente son frustrantemente fragmentadas e complexas en Linux. Dediquei un informe enteiro a cuestións relacionadas coa plataforma Linux para ambientes de escritorio (desenvolvedores experimentados confirmaron que todo permanecerá así durante moito tempo).

O meu informe sobre os problemas dos entornos de escritorio Linux en 2018

Incluso Linus Torvalds admitiu que a fragmentación foi o motivo polo que fallou a idea do espazo de traballo.

Da gusto ver Haiku!

Haiku fai que todo sexa incriblemente sinxelo

Aínda que o enfoque inxenuo para "portar" AppImage a Haiku consiste simplemente en tentar construír (principalmente runtime.c e servizo) os seus compoñentes (que ata pode ser posible!), isto non proporcionará moito beneficio a Haiku. Porque, de feito, a maioría destes problemas resólvense en haiku e son conceptualmente sólidos. Haiku proporciona exactamente os bloques de construción da infraestrutura do sistema que estiven buscando en ambientes de escritorio Linux durante tanto tempo e que non podía crer que non estivesen alí. A saber:

Créao ou non, isto é algo que moitos usuarios de Linux non poden superar. En Haiku todo faise automaticamente!

• Os ficheiros ELF que non teñen un bit de executabilidade obteñen un automaticamente cando se fai dobre clic no xestor de ficheiros.
• As aplicacións poden ter recursos incorporados, como iconas, que se amosan no xestor de ficheiros. Non é necesario copiar un montón de imaxes en directorios especiais con iconas e, polo tanto, non é necesario limpalas despois de eliminar ou mover a aplicación.
• Hai unha base de datos para vincular aplicacións con documentos, non é necesario copiar ningún ficheiro para iso.
• No directorio lib/ a carón do ficheiro executable, as bibliotecas son buscadas por defecto.
• Non hai moitas distribucións e ambientes de escritorio; o que funcione, funciona en todas partes.
• Non hai ningún módulo separado para executar que sexa diferente do directorio Aplicacións.
• As aplicacións non teñen camiños absolutos incorporados aos seus recursos; teñen funcións especiais para determinar a localización no tempo de execución.
• Introduciuse a idea das imaxes do sistema de ficheiros comprimidos: este é calquera paquete hpkg. Todos eles están montados polo núcleo.
• Cada ficheiro é aberto pola aplicación que o creou, a non ser que especifique expresamente o contrario. Que chulo é isto!

Dous ficheiros png. Teña en conta as diferentes iconas que indican que as diferentes aplicacións abrirán ao facer dobre clic. Teña en conta tamén o menú despregable "Abrir con:" onde o usuario pode seleccionar unha aplicación individual. Que sinxelo!

Parece que moitas das muletas e solucións alternativas requiridas por AppImage en Linux fanse innecesarias en Haiku, que ten a sinxeleza e a sofisticación no seu núcleo que o fan xestionar a maioría das nosas necesidades.

Haiku precisa paquetes de aplicacións despois de todo?

Isto leva a unha gran pregunta. Se fose unha orde de magnitude máis fácil crear un sistema como AppImage en Haiku que en Linux, pagaría a pena facelo? Ou Haiku, co seu sistema de paquetes hpkg, eliminou efectivamente a necesidade de desenvolver tal idea? Pois ben, para responder temos que ver a motivación detrás da existencia de AppImages.

Perspectiva do usuario

Vexamos o noso usuario final:

• Quero instalar unha aplicación sen pedir un contrasinal de administrador (raíz). Non hai concepto de administrador en Haiku, o usuario ten o control total xa que é un sistema persoal. (En principio, podes imaxinar isto no modo multixogador, espero que os desenvolvedores o fagan sinxelo)
• Quero obter as versións máis recentes e mellores das aplicacións, sen esperar a que aparezan na miña distribución (a maioría das veces isto significa "nunca", polo menos a menos que actualice todo o sistema operativo). En Haiku isto "resólvese" con versións flotantes. Isto significa que é posible obter as versións máis recentes e mellores das aplicacións, pero para iso cómpre actualizar constantemente o resto do sistema, converténdoo efectivamente nun "obxectivo en movemento"..
• Quero varias versións da mesma aplicación en paralelo, xa que non hai forma de saber o que se rompeu na última versión ou, digamos, eu, como desenvolvedor web, teño que probar o meu traballo en diferentes versións do navegador. Haiku resolve o primeiro problema, pero non o segundo. As actualizacións son revertidas, pero só para todo o sistema; é imposible (polo que eu sei) executar, por exemplo, varias versións de WebPositive ou LibreOffice ao mesmo tempo.

Un dos desenvolvedores escribe:

Esencialmente, a razón é esta: o caso de uso é tan raro que optimizalo non ten sentido; tratalo como un caso especial en HaikuPorts parece máis que aceptable.

• Necesito manter as aplicacións onde me gustan, non na miña unidade de inicio. Moitas veces quedo sen espazo no disco, polo que teño que conectar unha unidade externa ou un directorio de rede para almacenar aplicacións (todas as versións que descarguei). Se conecto unha unidade deste tipo, necesito que se inicien aplicacións facendo dobre clic. Haiku garda versións antigas dos paquetes, pero non sei como movelos a unha unidade externa nin como lanzar aplicacións desde alí máis tarde.

Comentario do programador:

Tecnicamente, isto xa é posible co comando mount. Por suposto, faremos unha GUI para isto en canto teñamos suficientes usuarios interesados.

• Non necesito millóns de ficheiros espallados polo sistema de ficheiros que non podo xestionar manualmente. Quero un ficheiro por aplicación que poida descargar, mover e eliminar facilmente. En Haiku este problema resólvese usando paquetes .hpkg, que transfiren, por exemplo, python, de miles de ficheiros a un só. Pero se hai, por exemplo, Scribus usando Python, entón teño que tratar con polo menos dous ficheiros. E teño que coidar de manter versións deles que funcionen entre si.

Varias versións de AppImages funcionando en paralelo no mesmo Linux

Perspectiva dun programador de aplicacións

Vexamos desde o punto de vista dun programador de aplicacións:

• Quero controlar toda a experiencia do usuario. Non quero depender dun sistema operativo para dicirme cando e como debo lanzar aplicacións. Haiku permite aos desenvolvedores traballar cos seus propios repositorios hpkg, pero isto significa que os usuarios terán que configuralos manualmente, o que fai que a idea sexa "menos atractiva".
• Teño unha páxina de descarga no meu sitio web onde distribuín .exe para Windows, .dmg para Mac e .AppImage para Linux. Ou quizais quero monetizar o acceso a esta páxina, algo é posible? Que debo poñer alí para o Haiku? O ficheiro é suficiente .hpkg con dependencias só de HaikuPorts
• O meu software require versións específicas doutro software. Por exemplo, sábese que Krita require unha versión parcheada de Qt, ou Qt que estea afinada a unha versión específica de Krita, polo menos ata que os parches sexan empuxados de novo en Qt. Podes empaquetar o teu propio Qt para a túa aplicación nun paquete .hpkg, pero o máis probable é que isto non sexa benvido.

Páxina de descarga regular da aplicación. Que debo publicar aquí para Haiku?

Paquetes Will (que existen como directorios de aplicacións como AppDir ou .app ao estilo de Apple) e/ou imaxes (en forma de AppImages moi modificadas ou .dmg de Apple) unha adición útil ao entorno de escritorio Haiku? Ou diluirá toda a imaxe e levará á fragmentación e, polo tanto, engadirá complexidade? Estou desgarrado: por unha banda, a beleza e sofisticación do Haiku baséase no feito de que normalmente hai un xeito de facer algo, en lugar de moitos. Por outra banda, a maior parte da infraestrutura para catálogos e/ou paquetes de aplicacións xa está instalada, polo que o sistema pide a gritos que se poña en marcha o pouco por cento restante.

Segundo o creador Señor. waddlesplash

En Linux eles (catálogos e kits de aplicación, - aprox. tradutor) son probablemente unha solución técnica a problemas sistémicos. En Haiku preferimos simplemente resolver problemas do sistema.

Que opinas?

Antes de responder...

Agarda, imos facer unha comprobación rápida da realidade: de feito directorios de aplicacións - xa forma parte do Haiku:

Os directorios de aplicacións xa existen en Haiku, pero aínda non se admiten no xestor de ficheiros

Non son tan compatibles como, por exemplo, o Macintosh Finder. Que xenial sería se o directorio QtCreator tivese un nome e unha icona "QtCreator" na esquina superior esquerda, iniciando a aplicación cando se fai dobre clic?

Un pouco antes eu xa preguntou:

Estás seguro de que podes executar as túas aplicacións de unha década hoxe cando todas as tendas de aplicacións e os repositorios de distribución se esqueceron delas e das súas dependencias? Estás seguro de que aínda poderás acceder ao teu traballo actual no futuro?

Hai xa unha resposta de Haiku, ou os catálogos e os paquetes de aplicacións poden axudar aquí? Creo que poden.

Segundo o sr. waddlesplash:

Si, temos a resposta á pregunta: simplemente admitiremos estas aplicacións durante o tempo que sexa necesario ata que alguén poida ler os seus formatos de ficheiro da forma correcta ou proporcionar unha funcionalidade individual. O noso compromiso de apoiar as aplicacións BeOS R5 en Haiku é unha proba diso...

Isto é seguro!

Que curso de acción debería tomar Haiku?

Podo imaxinar a coexistencia pacífica de hpkg, directorios e imaxes de aplicacións:

• Usos do software do sistema .hpkg
• Para o software de uso máis frecuente (especialmente aqueles que precisan programar versións continuas), use .hpkg (aproximadamente o 80% dos casos)
• Algunhas instaladas vía .hpkg, as aplicacións beneficiaranse de pasar a unha infraestrutura de directorio de aplicacións (por exemplo, QtCreator): distribuiranse como .hpkg, como antes.

Señor. waddlesplash escribe:

Se todo o que precisa é ver as aplicacións en /system/apps, en cambio deberíamos facer que os directorios da barra de escritorio sexan máis manexables para os usuarios, xa que /system/apps non está pensado para ser aberto e visto regularmente polos usuarios (a diferenza de MacOS). Para tales situacións, o Haiku ten un paradigma diferente, pero esta opción é, en teoría, aceptable.

• Haiku recibe a infraestrutura para executar imaxes de aplicacións, compilacións nocturnas, continuas e de proba de software, así como para os casos nos que o usuario quere "conxelalo a tempo", para software privado e interno e outros casos de uso especiais (aproximadamente un 20% de todos). Estas imaxes conteñen os ficheiros necesarios para executar a aplicación .hpkg, montado polo sistema e despois de completar a aplicación - desmontado. (Quizais un xestor de ficheiros podería poñer ficheiros .hpkg en imaxes de aplicacións, automaticamente ou a petición do usuario, así, como cando arrastras unha aplicación a un directorio de rede ou a unidade externa. É só unha canción! Ou mellor dito, poesía - haiku.) Por outra banda, o usuario pode querer instalar o contido da imaxe en forma de ficheiros.hpkg, tras o cal actualizaranse e procesaranse do mesmo xeito que se se instalasen a través de HaikuDepot... Hai que facer unha chuvia de ideas).

Cita do sr. waddlesplash:

Executar aplicacións desde unidades externas ou directorios de rede pode ser útil. E engadir a posibilidade de configurar máis "zonas" para pkgman sería definitivamente unha boa característica.

Un sistema deste tipo aproveitaría hpkg, directorios e imaxes de aplicacións. Son bos individualmente, pero xuntos converteranse en invencibles.

Conclusión

Haiku ten un marco que ofrece unha experiencia de usuario sinxela e sofisticada para o PC, e vai moito máis alá do que normalmente se proporciona para o PC Linux. Sistema de paquetes .hpkg é un destes exemplos, pero o resto do sistema tamén está impregnado de sofisticación. Non obstante, Haiku beneficiaríase dunha compatibilidade adecuada de directorios e imaxes da aplicación. A mellor forma de facelo paga a pena discutir con persoas que coñecen o Haiku, a súa filosofía e arquitectura moito mellor ca min. Despois de todo, levo algo máis dunha semana usando Haiku. Non obstante, creo que os deseñadores, desenvolvedores e arquitectos de Haiku se beneficiarán desta nova perspectiva. Como mínimo, estaría feliz de ser o seu "compañeiro de combate". Teño máis de 10 anos de experiencia práctica con catálogos e paquetes de aplicacións de Linux, e gustaríame atopar un uso para eles en Haiku, para o que creo que son perfectos. As posibles solucións que propuxen non son en absoluto as únicas correctas para os problemas que describín, e se o equipo de Haiku decide buscar outras máis elegantes, estou a favor. Basicamente, xa estou pensando na idea de como facer un sistema hpkg aínda máis sorprendente sen cambiar a forma de funcionar. Resulta que o equipo de Haiku levaba moito tempo pensando nos paquetes de aplicacións ao implementar un sistema de xestión de paquetes, pero desgraciadamente (creo) a idea quedou “obsoleta”. Quizais sexa o momento de revivir?

Probao vostede mesmo! Despois de todo, o proxecto Haiku ofrece imaxes para o arranque desde DVD ou USB, xeradas diario.
Tes algunha dúbida? Convidámoste ao rusofalante canle de telegrama.

Visión xeral do erro: Como dispararse no pé en C e C++. Colección de receitas Haiku OS

De autor tradución: este é o oitavo e último artigo da serie sobre o haiku.

Lista de artigos: Primeira O segundo Terceiro Cuarto Quinto Sexto Sétimo

Só os usuarios rexistrados poden participar na enquisa. Rexístrate, por favor.

Ten sentido levar o sistema hpkg a Linux?

• Si

• Non

• Xa implementado, escribirei nos comentarios

Votaron 20 usuarios. 5 usuarios abstivéronse.

Fonte: www.habr.com