🥇Algo mais: pacotes de aplicativos Haiku?

TL;DR: o Haiku pode receber suporte adequado para pacotes de aplicativos, como por exemplo catálogos de aplicativos (como .app no Mac) e/ou imagens de aplicativos (Linux AppImage)? Parece-me que isso seria uma adição valiosa, mais fácil de implementar do que em outros sistemas, uma vez que a maior parte da infraestrutura já existe.

Há uma semana descobri o Haiku, um sistema surpreendentemente bom. E como eu me interesso há muito tempo por catálogos e imagens de aplicativos (inspirados na simplicidade do Macintosh), não é surpresa que a ideia tenha surgido na minha mente...

Para plena compreensão: eu sou o criador e autor do AppImage, um formato de distribuição de aplicativos Linux, voltado para a simplicidade do Mac e que dá total controle a autores de aplicativos e usuários finais (se quiser saber mais, veja. wiki e documentação).

E se fizéssemos um AppImage para o Haiku?

Vamos teorizar um pouco: o que seria necessário para obter AppImage, ou algo semelhante, no Haiku? Não é preciso criar algo agora, já que o sistema que já existe no Haiku funciona surpreendentemente bem, e uma experiência imaginária seria interessante. Além disso, demonstra a sofisticação do Haiku em comparação com os ambientes de trabalho Linux, onde coisas assim são incrivelmente difíceis (tenho o direito de dizer isso: há 10 anos luto com depuração).

No Macintosh System 1, cada aplicativo era um arquivo separado, 'gerenciado' no Finder. Usando AppImage, estou tentando recriar essa mesma experiência do usuário no Linux.

Primeiro, o que é AppImage? É um sistema para lançar aplicativos de terceiros (por exemplo, Ultimaker Cura), permitindo que aplicativos sejam lançados quando e como desejarem: não é necessário conhecer as particularidades de diferentes distribuições, políticas de construção ou infraestrutura de construção, não há necessidade de suporte de dependências, e eles não dizem aos usuários o que (não) pode ser instalado em seus computadores. O AppImage deve ser entendido como algo semelhante a um pacote para Mac no formato .app dentro da imagem do disco .dmg. A principal diferença é que os aplicativos não são copiados, mas permanecem dentro do AppImage para sempre, da mesma maneira que os pacotes do Haiku .hpkg são montados, e nunca são instalados no sentido convencional.

AppImage, ao longo de mais de 10 anos de existência, ganhou certa atratividade e popularidade: Linus Torvalds o aprovou publicamente, e projetos amplamente utilizados (como LibreOffice, Krita, Inkscape, Scribus, ImageMagick) adotaram-no como principal método de distribuição de versões contínuas ou noturnas, sem interferir em aplicativos instalados ou não instalados dos usuários. No entanto, ambientes de trabalho e distribuições Linux ainda frequentemente se agarram ao modelo de distribuição tradicional e centralizado, baseado em pacotes e/ou promovem seus próprios programas empresariais e/ou técnicos baseados em Flatpak (RedHat, Fedora, GNOME) e Snappy (Canonical, Ubuntu). Chega a ser cômico.

Como tudo funciona

Cada AppImage contém duas partes: um pequeno executável ELF de clique duplo (chamado de runtime.c), junto com a imagem do sistema de arquivos SquashFS.

O sistema de arquivos SquashFS contém a carga útil do aplicativo e tudo que é necessário para sua execução, que não se pode, em sã consciência, considerar parte da instalação padrão para cada sistema alvo relativamente moderno (distribuição Linux). Ele também contém metadados, como o nome do aplicativo, ícones, tipos MIME, entre outros.

Ao ser iniciado pelo usuário, o runtime utiliza FUSE e squashfuse para montar o sistema de arquivos, após o que processa o lançamento de um ponto de entrada (chamado de AppRun) dentro do AppImage montado.
O sistema de arquivos é desmontado assim que o processo é concluído.

Parece tudo simples.

Mas essas coisas complicam tudo:

com a variedade de distribuições Linux, nada mais pode ser chamado de 'parte da instalação padrão para cada sistema alvo moderno' em sã consciência. Nós contornamos esse problema por meio da construção de uma excludelist, que define o que será empacotado no AppImage e o que precisará ser buscado em outro lugar. Apesar disso, às vezes falhamos, mesmo com tudo funcionando bem no geral. Por esse motivo, recomendamos que os criadores de pacotes testem AppImages em todos os sistemas alvo (distribuições).
Os aplicativos na forma de carga útil devem ser móveis dentro do sistema de arquivos. Infelizmente, muitos aplicativos têm caminhos absolutos rígidos para, por exemplo, recursos em /usr/share. Isso precisa ser corrigido de alguma forma. Além disso, é necessário exportar LD_LIBRARY_PATH, ou corrigir rpath para que o carregador possa encontrar bibliotecas relacionadas. O primeiro método tem suas desvantagens (que são contornadas de maneiras complicadas), enquanto o segundo é simplesmente volumoso.
A maior armadilha de UX para os usuários é que é necessário definir o bit executável para o arquivo AppImage após o download. Acredite ou não, mas para alguns isso é uma barreira real. A necessidade de definir o bit de execução é volumosa, mesmo para usuários experientes. Como uma solução alternativa, propusemos a instalação de um pequeno serviço que monitoriza os arquivos AppImage e configura para eles o bit executável. Na sua forma pura, não é a melhor solução, pois não funcionará "pronto para uso". Distribuições Linux não fornecem este serviço, portanto, para os usuários, "pronto para uso" a situação é ruim.
Os usuários do Linux esperam que um novo aplicativo apareça com um ícone no menu de inicialização. Não se pode dizer ao sistema: "Olha, ali está um novo aplicativo, vamos lá". Em vez disso, de acordo com a especificação XDG, é necessário copiar o arquivo .desktop para o lugar certo em /usr para uma instalação global, ou em $HOME para uma instalação individual. Os ícones de tamanhos específicos, conforme a especificação XDG, devem ser colocados em locais determinados em usr ou $HOME, depois do que é necessário executar comandos no ambiente de trabalho para atualizar o cache de ícones, ou esperar que o gerenciador de janelas perceba e descubra tudo automaticamente. O mesmo se aplica aos tipos MIME. Como uma solução alternativa, recomenda-se usar o mesmo serviço que, além de configurar o bit executável, copiará os ícones e outros do AppImage para os lugares apropriados conforme o XDG, quando disponíveis. Ao remover ou mover, o serviço supostamente limpará tudo. Claro, há diferenças no comportamento de cada ambiente de trabalho, nos formatos de arquivos gráficos, seus tamanhos, locais de armazenamento e maneiras de atualizar caches, o que gera um problema. Resumindo, esse método é uma gambiarra.
Se o que foi mencionado acima não for suficiente, ainda não há ícone AppImage no gerenciador de arquivos. No mundo Linux, ainda não foi tomada uma decisão sobre a implementação do elficon (apesar de desativaram e implementação), então não é possível integrar o ícone diretamente no aplicativo. Assim, os aplicativos no gerenciador de arquivos não têm seus próprios ícones (não importa se é AppImage ou outro), eles aparecem apenas no menu de inicialização. Como uma solução alternativa, usamos miniaturas — um mecanismo que foi inicialmente desenvolvido para que os gerenciadores de desktop pudessem mostrar imagens em miniatura para a visualização de arquivos gráficos como seus ícones. Portanto, o serviço para definir a bit de executabilidade também funciona como um “miniaturizador”, criando e gravando miniaturas de ícones nos locais apropriados. /usr e $HOME. Além disso, esse serviço realiza a limpeza se o AppImage for removido ou movido. Devido ao fato de que cada gerenciador de desktop se comporta de forma um pouco diferente, por exemplo, quais formatos aceitam ícones, quais tamanhos ou locais, isso acaba sendo bastante complicado.
O aplicativo simplesmente falha durante a execução se ocorrem erros (por exemplo, se há uma biblioteca que não faz parte do sistema base e não é fornecida no AppImage), e ninguém informa ao usuário no GUI o que exatamente está acontecendo. Começamos a contornar isso usando pelos desenvolvedores da lista de bloqueio EasyPrivacy, foi na área de trabalho, o que significa que precisamos capturar os erros do terminal, transformá-los em mensagens compreensíveis para o usuário, que então devem ser exibidas na área de trabalho. E, claro, cada ambiente de trabalho processa isso de maneira ligeiramente diferente.
No momento atual (setembro de 2019, — nota do tradutor) não encontrei um caminho simples para informar ao sistema que o arquivo 1.png deve ser aberto com o Krita, e 2.png — com o GIMP.

O local de armazenamento das especificações cross-desktop, usadas em GNOME, KDE e Xfce é freedesktop.org.

Alcançar um nível de sofisticação, profundamente entrelaçado no ambiente de trabalho Haiku, é dificultado, para não dizer ‘impossível’, devido às especificações XDG do freedesktop.org para cross-desktop, bem como as implementações dos gerenciadores de desktop baseados nessas especificações. Por exemplo, uma ícone comum do sistema do Firefox: aparentemente, os autores do XDG não consideraram que um usuário poderia ter várias versões do mesmo aplicativo instaladas.

Ícones de diferentes versões do Firefox.

Eu me perguntei o que o mundo Linux poderia aprender com o Mac OS X para evitar erros na integração de sistemas. Se você tiver tempo e estiver envolvido com isso, definitivamente leia o que Arnaud Gourdol, um dos primeiros engenheiros do Mac OS X, disse:

Queríamos que a instalação de um aplicativo fosse tão simples quanto arrastar o ícone do aplicativo de algum lugar (servidor, disco externo) para o disco do seu computador. Para isso, o pacote do aplicativo contém todas as informações, incluindo ícones, versão, tipo de arquivo processado, e o tipo de esquema de URL que o sistema deve conhecer para processar o aplicativo. Isto também inclui informações para o 'armazenamento centralizado' no banco de dados Icon Services e Launch Services. Para manter o desempenho do aplicativo, ele é 'detectado' em vários 'lugares bem conhecidos': nos diretórios de Aplicativos do sistema e do usuário, e também em alguns outros automaticamente, se o usuário navegar ao Finder para um diretório contendo o aplicativo. Na prática, isso funcionou muito bem.

https://youtu.be/qQsnqWJ8D2c
Apple WWDC 2000 sessão 144 - Mac OS X: empacotamento de aplicativos e impressão de documentos.

Não há nada similar nesta infraestrutura em ambientes de trabalho Linux, então estamos procurando maneiras de contornar as limitações estruturais no projeto AppImage.

Será que o Haiku está correndo em nosso socorro?

Além disso: as plataformas Linux, como base para ambientes de trabalho, geralmente estão tão subespecificadas que muitas coisas que são bem simples em um sistema coeso com pilha completa frustram pela fragmentação e complexidade no Linux. Eu dediquei uma palestra inteira a questões relacionadas à plataforma Linux para ambientes de trabalho (desenvolvedores experientes confirmaram: isso ficará assim por muito tempo).

Por que no hosting comum a administração do PrestaShop é lenta, e no seu não é?

Minha palestra sobre os problemas dos ambientes de trabalho Linux em 2018

Até Linus Torvalds reconheceu que devido à fragmentação, a ideia de ambientes de trabalho não teve sucesso.

É bom ver o Haiku!

Com o Haiku, tudo se torna incrivelmente simples.

Embora a abordagem ingênua de "portar" o AppImage para o Haiku envolva simplesmente tentar compilar (principalmente o runtime.c e os serviços) seus componentes (o que pode ser até possível!), isso não trará muitos benefícios para o Haiku. Porque, na verdade, a maioria desses problemas já foi resolvida no Haiku e é conceitualmente justificada. O Haiku fornece precisamente os blocos que eu tanto procurei nas ambientes de trabalho no Linux e não conseguia acreditar que não estavam lá. Especificamente:

Acredite ou não, mas isso não pode ser superado por muitos usuários do Linux. No Haiku, tudo acontece automaticamente!

Arquivos ELF, que não possuem o bit de executabilidade, recebem isso automaticamente ao serem clicados duas vezes no gerenciador de arquivos.
Os aplicativos podem ter recursos embutidos, como ícones, que são exibidos no gerenciador de arquivos. Não é necessário copiar uma infinidade de imagens para diretórios específicos de ícones, portanto, não é necessário limpar após a remoção ou movimentação do aplicativo.
Há um banco de dados para associar aplicativos a documentos, não é necessário copiar arquivos para isso.
No diretório lib/ próximo ao arquivo executável, as bibliotecas são buscadas por padrão.
Não existem inúmeras distribuições e ambientes de desktop, tudo que funciona — funciona em qualquer lugar.
Não existe um módulo separado para executar que se diferençasse do diretório Aplicativos.
Nos aplicativos, não há caminhos absolutos embutidos para seus recursos, existem funções especiais para determinar localizações em tempo de execução.
A ideia de imagens de sistemas de arquivos comprimidas foi implementada: isso é qualquer pacote hpkg. Todos são montados pelo kernel.
Cada arquivo é aberto pelo aplicativo que o criou, a menos que explicitamente indicado de outra forma. Que legal!

Dois arquivos png. Observe os ícones diferentes, mostrando que eles serão abertos por diferentes aplicativos ao serem clicados duas vezes. Também note o menu suspenso "Abrir com:", onde o usuário pode escolher um aplicativo específico. Que simples!

Parece que muitos gambiarras e caminhos alternativos necessários para o AppImage no Linux se tornam desnecessários no Haiku, que tem em sua base simplicidade e sofisticação, permitindo que atenda à maioria de nossas necessidades.

Serão necessários pacotes de aplicativos Haiku, afinal?

Isso leva a uma grande questão. Se criar um sistema semelhante ao AppImage no Haiku se revelar muito mais fácil do que no Linux, valeria a pena investir tempo nisso? Ou o Haiku, com seu sistema de pacotes hpkg, eliminou de fato a necessidade de desenvolver uma ideia semelhante? Bem, para responder, precisamos olhar para a motivação por trás da existência dos AppImages.

A perspectiva do usuário

Vamos dar uma olhada no nosso usuário final:

Eu quero instalar um aplicativo sem que seja solicitada a senha do administrador (root). No Haiku, não existe o conceito de administrador; o usuário tem controle total, uma vez que se trata de um sistema pessoal! (Na verdade, pode-se imaginar isso em modo multiusuário, espero que os desenvolvedores mantenham a simplicidade)
Quero ter as versões mais recentes e melhores dos aplicativos, sem esperar que elas apareçam na minha distribuição (na maioria das vezes, isso significa "nunca", pelo menos a menos que eu atualize o sistema operacional inteiro). No Haiku, isso é "resolvido" através de lançamentos flutuantes. Isso significa que existe a possibilidade de obter as versões mais recentes e melhores dos aplicativos, mas para isso é necessário atualizar constantemente o restante do sistema, na verdade transformando-o em um "alvo em movimento"..
Gostaria de ter várias versões do mesmo aplicativo lado a lado, pois não posso saber o que foi quebrado na última versão, ou, digamos, como desenvolvedor web, preciso testar meu trabalho em diferentes versões de navegadores. No Haiku, o primeiro problema é resolvido, mas o segundo não. As atualizações podem ser revertidas, mas apenas para o sistema como um todo; não é possível (pelo que sei) executar, por exemplo, várias versões do WebPositive ou do LibreOffice ao mesmo tempo.

Um dos desenvolvedores afirma:

Basicamente, a justificativa é a seguinte: o cenário de uso é tão raro que a otimização para isso não faz sentido; tratá-lo como um caso especial no HaikuPorts parece mais do que aceitável.

Preciso poder armazenar aplicativos onde eu quiser, e não apenas no disco de boot. Frequentemente fico sem espaço nos discos, então preciso conectar um disco externo ou um diretório de rede para armazenar os aplicativos (todas as versões que baixei). Quando conecto tal disco, gostaria que os aplicativos fossem iniciados com um duplo clique. O Haiku mantém versões antigas dos pacotes, mas não sei como transferi-los para um disco externo, nem como depois executar os aplicativos de lá.

Comentário do desenvolvedor:

Tecnicamente, isso já é possível com a equipe mount. Claro, faremos uma GUI para isso assim que houver um número suficiente de usuários interessados.

Não preciso de milhões de arquivos espalhados pelo sistema de arquivos que não posso gerenciar manualmente. Quero um arquivo por aplicativo que eu possa baixar, mover e excluir facilmente. No Haiku, esse problema é resolvido com pacotes .hpkg, que transportam, por exemplo, o Python, de milhares de arquivos para um só. Mas se houver, por exemplo, o Scribus usando Python, terei que lidar com pelo menos dois arquivos. E eu preciso me certificar de que estou guardando as versões que funcionam entre si.

Múltiplas versões de AppImages, executadas lado a lado em um Linux

Uma visão do ponto de vista do desenvolvedor de aplicativos

Vamos olhar do ponto de vista do desenvolvedor de aplicativos:

Quero ter controle total sobre a experiência do usuário. Não quero depender do sistema operacional que me dirá quando e como devo lançar aplicativos. No Haiku, os desenvolvedores podem trabalhar com seus próprios repositórios hpkg, mas isso significa que os usuários terão que configurá-los manualmente, o que torna essa ideia "menos atraente".
Tenho uma página de download no meu site onde distribuo .exe para Windows, .dmg para Mac e .AppImage para Linux. E talvez eu queira monetizar o acesso a essa página, tudo pode acontecer? O que preciso colocar lá para o Haiku? Basta um arquivo .hpkg com dependências apenas do HaikuPorts
Meu software precisa de versões específicas de outro software. Por exemplo, é sabido que para o Krita é necessária uma versão corrigida do Qt, ou um Qt que esteja exatamente configurado para uma versão específica do Krita, pelo menos até que as correções voltem para o Qt. É possível empacotar seu próprio Qt para o aplicativo em um pacote .hpkg, mas provavelmente isso não é bem-vindo.

Uma página de download comum de aplicativos. O que colocar aqui para o Haiku?

Os kits (existindo na forma de diretórios de aplicativos, como AppDir ou .app estilo Apple) e/ou imagens (na forma de AppImages fortemente modificadas ou .dmg de aplicativos da Apple) é um complemento útil para o ambiente de trabalho Haiku? Ou isso irá desvirtuar a visão geral e levar à fragmentação, tornando tudo mais complexo? Estou em dúvida: por um lado, a beleza e a sofisticação do Haiku se baseiam no fato de que geralmente há uma maneira de fazer algo, e não várias. Por outro lado, grande parte da infraestrutura para diretórios e/ou pacotes de aplicativos já existe, portanto, o sistema clama para que os restantes poucos por cento se integrem.

De acordo com o desenvolvedor mr. waddlesplash

No Linux, eles (diretórios e pacotes de aplicativos — nota do tradutor) provavelmente são uma solução técnica para problemas sistêmicos. No Haiku, preferimos simplesmente resolver os problemas sistêmicos.

E você, o que acha?

Antes de você responder...

Espere, vamos fazer uma rápida verificação da realidade: na verdade diretórios de aplicativos — já fazem parte do Haiku:

Os diretórios de aplicativos já existem no Haiku, mas ainda não são suportados no gerenciador de arquivos

Eles simplesmente não são tão bem suportados quanto, por exemplo, no Finder do Macintosh. Quanto seria incrível se o diretório QtCreator tivesse um nome e um ícone 'QtCreator' no canto superior esquerdo, abrindo o aplicativo com um duplo clique?

Um pouco antes, eu já perguntei:

Você tem certeza de que conseguirá executar seus aplicativos de dez anos atrás hoje, quando todas as lojas de aplicativos e repositórios de distribuições esquecerem deles e de suas dependências? Você tem certeza de que ainda poderá acessar seu trabalho atual no futuro?

Há alguma resposta por parte do Haiku, ou os diretórios e pacotes de aplicativos poderão ajudar aqui? Eu acho que poderão.

De acordo com o sr. waddlesplash:

Sim, temos uma resposta para essa questão: vamos apenas manter esses aplicativos pelo tempo que for necessário, até que alguém consiga ler seus formatos de arquivo corretamente ou forneça funcionalidade um a um. Nossa determinação em manter os aplicativos BeOS R5 funcionando no Haiku é uma prova direta disso...

Exatamente!

Qual deve ser o plano de ação do Haiku?

Eu posso imaginar uma coexistência pacífica entre hpkg, diretórios e imagens de aplicativos:

Software de sistema utiliza .hpkg
Para o software mais utilizado (especialmente aquele que precisa de lançamentos flutuantes programados), utiliza-se .hpkg (cerca de 80% de todos os casos)
Alguns, instalados através de .hpkg, os aplicativos se beneficiarão ao migrar para uma infraestrutura com diretórios de aplicativos (por exemplo, QtCreator): eles serão distribuídos na forma de .hpkg, como antes.

mr. waddlesplash comenta:

Se tudo o que você precisa é visualizar aplicativos em /system/apps, em vez disso, é necessário tornar os diretórios na Deskbar mais gerenciáveis para os usuários, uma vez que /system/apps não é projetado para que os usuários o abram e o visualizem regularmente (diferente do MacOS). Para tais situações, o Haiku possui outra paradigma, mas essa abordagem é, em teoria, aceitável.

O Haiku obtém infraestrutura para executar imagens de aplicativos, builds noturnas, contínuas e de teste, além de situações em que o usuário deseja 'congelá-lo no tempo', para software privado e interno, e outros casos de uso especiais (cerca de 20% de todos). Essas imagens contêm os arquivos necessários para executar o aplicativo .hpkg, montados pelos meios do sistema, e após a conclusão do aplicativo — desmontados. (Talvez, o gerenciador de arquivos poderia colocar arquivos .hpkg nas imagens de aplicativos, automaticamente ou a pedido do usuário — assim como quando você arrasta um aplicativo para um diretório de rede ou disco externo. Isso é simplesmente uma canção! Ou melhor, uma poesia — haiku.) Por outro lado, o usuário pode querer instalar o conteúdo da imagem como arquivos.hpkg, após o que eles serão atualizados e processados exatamente como se tivessem sido instalados através do HaikuDepot... Precisamos fazer uma sessão de brainstorming.

Citação de mr. waddlesplash:

Executar aplicativos de discos externos ou diretórios de rede pode ser potencialmente útil. E adicionar a capacidade de configurar mais 'zonas' para o pkgman definitivamente seria uma boa funcionalidade.

Um sistema como esse aproveitaria os benefícios do hpkg, diretórios e imagens de aplicativos. Eles são bons separadamente, mas juntos se tornam invencíveis.

Conclusão

Para o Haiku, existe uma infraestrutura que fornece uma interface de usuário simples e sofisticada para PCs, e que vai muito além do que geralmente é oferecido para PCs com Linux. O sistema de pacotes .hpkg — um desses exemplos, mas as outras partes do sistema também estão imbidas de sofisticação. No entanto, um suporte adequado para catálogos e imagens de aplicativos beneficiaria o Haiku. Como isso pode ser feito da melhor maneira — deve ser discutido com pessoas que conhecem o Haiku, sua filosofia e arquitetura muito melhor do que eu. Afinal, estou usando o Haiku há pouco mais de uma semana. Mas, mesmo assim, acredito que essa nova perspectiva será útil para designers, desenvolvedores e arquitetos do Haiku. Pelo menos, estou feliz em ser um "sparring partner" para eles. Tenho mais de 10 anos de experiência prática com catálogos e pacotes de aplicativos para Linux, e gostaria de encontrar uma aplicação para o Haiku, cuja concepção, na minha opinião, é perfeita para isso. As soluções potenciais que propus não são de forma alguma as únicas corretas para os problemas que descrevi, e se a equipe do Haiku decidir encontrar outras, mais elegantes — eu só estarei torcendo. hpkg ainda mais incrível, sem mudar a maneira como funciona. Aparentemente, a equipe do Haiku já pensou em pacotes de aplicativos ao implementar o sistema de gerenciamento de pacotes, mas infelizmente, (me parece) a ideia ficou "ultrapassada". Talvez seja hora de ressuscitá-la?

Experimente você mesmo! O projeto Haiku oferece imagens para download via DVD ou USB, geradas diariamente.
Tem alguma dúvida? Convidamos você para o nosso canal em russo no telegram.

Resumo de erros: Como dar um tiro no pé em C e C++. Uma coletânea de receitas do Haiku OS

A partir de autor tradução: este é o oitavo e último artigo de uma série sobre o Haiku.

Lista de artigos: Primeiro Segundo Terceiro Quarto Quinto Sexto Sétimo

Apenas usuários registrados podem participar da pesquisa. Entre, por favor.