Outra coisa: pacotes de aplicativos Haiku?

TL, DR: O Haiku pode obter suporte adequado para pacotes de aplicativos, como diretórios de aplicativos (como .app no Mac) e/ou imagens de aplicativos (Linux AppImage)? Penso que esta seria uma adição valiosa e mais fácil de implementar corretamente do que outros sistemas, uma vez que a maior parte da infraestrutura já está instalada.

Uma semana atrás Eu descobri o Haiku, um sistema inesperadamente bom. Pois bem, como há muito me interesso por diretórios e imagens de aplicativos (inspirados na simplicidade do Macintosh), não é de surpreender que uma ideia me tenha ocorrido...

Para total compreensão, sou o criador e autor do AppImage, um formato de distribuição de aplicativos Linux que visa a simplicidade do Mac e dá controle total aos autores de aplicativos e usuários finais (se quiser saber mais, consulte wiki и documentação).

E se fizermos um AppImage para Haiku?

Vamos pensar um pouco, puramente teoricamente: o que é preciso fazer para conseguir AppImage, ou algo semelhante, no Haiku? Não é necessário criar algo agora, porque o sistema que já existe no Haiku funciona de maneira incrível, mas um experimento imaginário seria legal. Também demonstra a sofisticação do Haiku, em comparação com ambientes de desktop Linux, onde tais coisas são terrivelmente difíceis (tenho o direito de dizer isso: tenho lutado com depuração há 10 anos).

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

Em primeiro lugar, o que é um AppImage? Este é um sistema para liberar aplicativos de terceiros (por exemplo, Ultimaker Cura), permitindo que os aplicativos sejam lançados quando e como eles quiserem: não há necessidade de conhecer as especificidades de várias distribuições, construir políticas ou construir infraestrutura, nenhum suporte de mantenedor é necessário e eles não dizem aos usuários o que (não) eles podem instalar em seus computadores. AppImage deve ser entendido como algo semelhante a um pacote 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 forma que os pacotes Haiku .hpkg montado e nunca instalado no sentido usual.

Ao longo de mais de 10 anos de existência, o AppImage ganhou algum apelo e popularidade: o próprio Linus Torvalds o endossou publicamente, e projetos comuns (por exemplo, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) o adotaram como principal forma distribuir compilações contínuas ou noturnas, não interferindo nos aplicativos do usuário instalados ou desinstalados. No entanto, os ambientes de desktop e distribuições Linux na maioria das vezes ainda se apegam ao modelo de distribuição tradicional, centralizado e baseado no mantenedor e/ou promovem seus próprios negócios corporativos e/ou programas de engenharia baseados em Flatpak (RedHat, Fedora, GNOME) e Mal-humorado (Canônico, Ubuntu). Vêm ridiculamente.

Como funciona

• Cada AppImage contém 2 partes: um pequeno ELF de clique duplo (chamado. runtime.c), seguido por uma imagem do sistema de arquivos SquashFS.

• O sistema de arquivos SquashFS contém a carga útil do aplicativo e tudo o que é necessário para executá-lo, o que em sã consciência não pode ser considerado parte da instalação padrão para todos os sistemas de destino relativamente recentes (distribuição Linux). Ele também contém metadados, como nome do aplicativo, ícones, tipos MIME, etc., etc.

• Quando executado pelo usuário, o tempo de execução usa FUSE e squashfuse para montar o sistema de arquivos e, em seguida, executa algum ponto de entrada (também conhecido como AppRun) dentro do AppImage montado.
  O sistema de arquivos é desmontado após a conclusão do processo.

Parece que tudo é simples.

E essas coisas complicam tudo:

• Com tanta variedade de distribuições Linux, nada “em sã consciência” pode ser chamado de “parte da instalação padrão para cada novo sistema de destino”. Nós contornamos esse problema construindo lista de exclusão, permitindo determinar o que será empacotado no AppImage e o que precisará ser levado para outro lugar. Ao mesmo tempo, às vezes erramos, apesar de, em geral, tudo funcionar bem. Por esse motivo, recomendamos que os criadores de pacotes testem AppImages em todos os sistemas alvo (distribuições).
• As cargas úteis do aplicativo devem ser realocáveis ​​no sistema de arquivos. Infelizmente, muitos aplicativos possuem caminhos absolutos codificados para, por exemplo, recursos em /usr/share. Isso precisa ser corrigido de alguma forma. Além disso, você deve exportar LD_LIBRARY_PATHou corrigir rpath para que o carregador possa encontrar bibliotecas relacionadas. O primeiro método tem suas desvantagens (que são superadas de maneiras complexas) e o segundo é simplesmente complicado.
• A maior armadilha de UX para os usuários é que definir bit executável Arquivo AppImage após o download. Acredite ou não, esta é uma barreira real para alguns. A necessidade de definir o bit de executabilidade é complicada mesmo para usuários experientes. Como solução alternativa, sugerimos a instalação de um pequeno serviço que monitora os arquivos AppImage e define seu bit de execução. Na sua forma pura, não é a melhor solução, pois não funciona imediatamente. As distribuições Linux não fornecem este serviço, portanto, os usuários têm uma experiência ruim imediatamente.
• Os usuários do Linux esperam que um novo aplicativo tenha um ícone no menu de inicialização. Não dá para dizer ao sistema: “Olha, tem um aplicativo novo, vamos trabalhar”. Em vez disso, de acordo com a especificação XDG, você precisa copiar o arquivo .desktop para o lugar certo em /usr para uma instalação em todo o sistema ou em $HOME para indivíduo. Ícones de determinados tamanhos, de acordo com a especificação XDG, precisam ser colocados em determinados locais do usr ou $HOMEe, em seguida, execute comandos no ambiente de trabalho para atualizar o cache de ícones ou espere que o gerenciador do ambiente de trabalho descubra e detecte tudo automaticamente. O mesmo acontece com os tipos MIME. Como solução alternativa, propõe-se a utilização do mesmo serviço, que, além de definir o sinalizador de executabilidade, o fará, se houver ícones, etc. no AppImage, copie-os do AppImage para os lugares certos de acordo com o XDG. Quando excluído ou movido, espera-se que o serviço limpe tudo. É claro que existem diferenças no comportamento de cada ambiente de trabalho, nos formatos de arquivos gráficos, seus tamanhos, locais de armazenamento e métodos de atualização de caches, o que cria um problema. Em suma, este método é uma muleta.
• Se o acima não for suficiente, ainda não há ícone AppImage no gerenciador de arquivos. O mundo Linux ainda não decidiu implementar o elficon (apesar discussão и implementação), portanto é impossível incorporar o ícone diretamente no aplicativo. Acontece que os aplicativos no gerenciador de arquivos não possuem ícones próprios (sem diferença, AppImage ou qualquer outra coisa), eles estão apenas no menu iniciar. Como solução alternativa, estamos usando miniaturas, um mecanismo que foi originalmente projetado para permitir que os gerenciadores de desktop mostrem imagens de visualização em miniatura de arquivos gráficos como seus ícones. Consequentemente, o serviço de configuração do bit de executabilidade também funciona como um “miniaturizador”, criando e gravando miniaturas de ícones nos locais apropriados /usr и $HOME. Este serviço também realiza a limpeza se o AppImage for excluído ou movido. Pelo fato de cada gerenciador de desktop se comportar de maneira um pouco diferente, por exemplo, em quais formatos aceita ícones, em quais tamanhos ou locais, tudo isso é muito doloroso.
• O aplicativo simplesmente trava na execução se ocorrerem erros (por exemplo, há uma biblioteca que não faz parte do sistema base e não é fornecida no AppImage) e não há ninguém informando ao usuário na GUI o que exatamente está acontecendo. Começamos a contornar isso usando уведомления na área de trabalho, o que significa que precisamos detectar erros na linha de comando, convertê-los em mensagens compreensíveis pelo usuário, que então precisam ser exibidas na área de trabalho. E, claro, cada ambiente de desktop lida com eles de maneira um pouco diferente.
• No momento (setembro de 2019 - nota do tradutor) não encontrei uma maneira simples de informar ao sistema que o arquivo 1.png deve ser aberto usando o Krita, e 2.png - usando o GIMP.

Local de armazenamento para especificações cross-desktop usadas em GNOME, KDE и Xfce é freedesktop.org

Alcançar o nível de sofisticação profundamente enraizado no ambiente de trabalho do Haiku é difícil, se não impossível, devido às especificações XDG de freedesktop.org para cross-desktop, bem como implementações de gerenciadores de desktop baseados nessas especificações. Como exemplo, podemos citar um ícone do Firefox para todo o sistema: aparentemente, os autores do XDG nem pensaram que um usuário pudesse ter várias versões do mesmo aplicativo instaladas.

Ícones para diferentes versões do Firefox

Eu queria saber o que o mundo Linux poderia aprender com o Mac OS X para evitar atrapalhar a integração do sistema. Se você tiver tempo e estiver interessado nisso, leia o que Arnaud Gurdol, um dos primeiros engenheiros do Mac OS X, disse:

Queríamos tornar a instalação do aplicativo tão fácil quanto arrastar o ícone do aplicativo de algum lugar (servidor, unidade externa) para a unidade do computador. Para fazer isso, o pacote de aplicativos armazena todas as informações, incluindo ícones, versão, tipo de arquivo que está sendo processado, tipo de esquema de URL que o sistema precisa saber para processar o aplicativo. Isso também inclui informações para 'armazenamento central' no banco de dados Icon Services e Launch Services. Para suportar o desempenho, os aplicativos são 'descobertos' em vários locais 'bem conhecidos': os diretórios de aplicativos do sistema e do usuário, e alguns outros automaticamente se o usuário navegar até o Finder no diretório que contém 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 parecido com essa infraestrutura em desktops Linux, por isso estamos procurando soluções alternativas para as limitações estruturais do projeto AppImage.

O Haiku está vindo para o resgate?

E mais uma coisa: as plataformas Linux como base dos ambientes de desktop tendem a ser tão subespecificadas que muitas coisas que são bastante simples em um sistema full-stack consistente são frustrantemente fragmentadas e complexas no Linux. Dediquei um relatório inteiro a questões relacionadas à plataforma Linux para ambientes desktop (desenvolvedores experientes confirmaram que tudo permanecerá assim por muito tempo).

Meu relatório sobre os problemas dos ambientes de desktop Linux em 2018

Até Linus Torvalds admitiu que a fragmentação foi a razão pela qual a ideia do espaço de trabalho falhou.

Que bom ver o Haiku!

Haiku torna tudo incrivelmente simples

Embora a abordagem ingênua para "portar" o AppImage para o Haiku seja simplesmente tentar construir (principalmente runtime.c e serviço) seus componentes (o que pode até ser possível!), isso não trará muitos benefícios ao Haiku. Porque, na verdade, a maioria desses problemas são resolvidos no Haiku e são conceitualmente sólidos. O Haiku fornece exatamente os blocos de construção da infraestrutura do sistema que venho procurando em ambientes de desktop Linux há tanto tempo e não conseguia acreditar que não existiam. Nomeadamente:

Acredite ou não, isso é algo que muitos usuários do Linux não conseguem superar. No Haiku tudo é feito automaticamente!

• Arquivos ELF que não possuem um bit de executábilidade obtêm um automaticamente quando clicados duas vezes no gerenciador de arquivos.
• Os aplicativos podem ter recursos integrados, como ícones, que são exibidos no gerenciador de arquivos. Não há necessidade de copiar um monte de imagens em diretórios especiais com ícones e, portanto, não há necessidade de limpá-las após excluir ou mover o aplicativo.
• Existe um banco de dados para vinculação de aplicativos a documentos, não há necessidade de copiar nenhum arquivo para isso.
• No diretório lib/ próximo ao arquivo executável, as bibliotecas são pesquisadas por padrão.
• Não existem inúmeras distribuições e ambientes de desktop; tudo o que funciona, funciona em qualquer lugar.
• Não há nenhum módulo separado para executar que seja diferente do diretório Aplicativos.
• Os aplicativos não possuem caminhos absolutos integrados para seus recursos; eles possuem funções especiais para determinar a localização em tempo de execução.
• A ideia de imagens compactadas do sistema de arquivos foi introduzida: este é qualquer pacote hpkg. Todos eles são montados pelo kernel.
• Cada arquivo é aberto pelo aplicativo que o criou, a menos que você especifique explicitamente o contrário. Que legal é isso!

Dois arquivos png. Observe os diferentes ícones que indicam que eles serão abertos por diferentes aplicativos quando clicados duas vezes. Observe também o menu suspenso “Abrir com:”, onde o usuário pode selecionar um aplicativo individual. Quão simples!

Parece que muitas das muletas e soluções alternativas exigidas pelo AppImage no Linux se tornam desnecessárias no Haiku, que tem em sua essência a simplicidade e a sofisticação que o fazem atender à maioria de nossas necessidades.

Afinal, o Haiku precisa de pacotes de aplicativos?

Isso leva a uma grande questão. Se fosse muito mais fácil criar um sistema como AppImage no Haiku do que no Linux, valeria a pena fazer isso? Ou o Haiku, com seu sistema de pacotes hpkg, eliminou efetivamente a necessidade de desenvolver tal ideia? Bem, para responder precisamos analisar a motivação por trás da existência do AppImages.

Perspectiva do usuário

Vejamos nosso usuário final:

• Quero instalar um aplicativo sem solicitar uma senha de administrador (root). Não existe o conceito de administrador no Haiku, o usuário tem controle total, pois é um sistema pessoal! (Em princípio, você pode imaginar isso no modo multijogador, espero que os desenvolvedores mantenham as coisas simples)
• Quero obter as melhores e mais recentes versões dos aplicativos, sem esperar que eles apareçam na minha distribuição (na maioria das vezes isso significa “nunca”, pelo menos a menos que eu atualize todo o sistema operacional). No Haiku isso é “resolvido” com lançamentos flutuantes. Isso significa que é possível obter as melhores e mais recentes versões dos aplicativos, mas para isso é necessário atualizar constantemente o restante do sistema, transformando-o efetivamente em um “alvo móvel”..
• Quero várias versões do mesmo aplicativo lado a lado, pois não há como saber o que quebrou na versão mais recente ou, digamos, eu, como desenvolvedor web, preciso testar meu trabalho em diferentes versões do navegador. O Haiku resolve o primeiro problema, mas não o segundo. As atualizações são revertidas, mas apenas para todo o sistema, é impossível (até onde eu sei) executar, por exemplo, várias versões do WebPositive ou LibreOffice ao mesmo tempo.

Um dos desenvolvedores escreve:

Essencialmente, a lógica é esta: o caso de uso é tão raro que a otimização para ele não faz sentido; tratá-lo como um caso especial no HaikuPorts parece mais do que aceitável.

• Preciso manter os aplicativos onde gosto, não na unidade de inicialização. Muitas vezes fico sem espaço em disco, então preciso conectar uma unidade externa ou diretório de rede para armazenar aplicativos (todas as versões que baixei). Se eu conectar essa unidade, preciso que os aplicativos sejam iniciados clicando duas vezes. O Haiku salva versões antigas de pacotes, mas não sei como movê-los para uma unidade externa ou como iniciar aplicativos a partir daí posteriormente.

Comentário do desenvolvedor:

Tecnicamente, isso já é possível com o comando mount. Claro, faremos uma GUI para isso assim que tivermos usuários interessados ​​suficientes.

• Não preciso de milhões de arquivos espalhados pelo sistema de arquivos que não consigo gerenciar manualmente. Quero um arquivo por aplicativo que possa baixar, mover e excluir facilmente. No Haiku este problema é resolvido usando pacotes .hpkg, que transfere, por exemplo, python, de milhares de arquivos para um. Mas se houver, por exemplo, Scribus usando python, então terei que lidar com pelo menos dois arquivos. E tenho que tomar cuidado para manter versões deles que funcionem entre si.

Várias versões de AppImages rodando lado a lado no mesmo Linux

A perspectiva de um desenvolvedor de aplicativos

Vejamos do ponto de vista de um desenvolvedor de aplicativos:

• Quero controlar toda a experiência do usuário. Não quero depender de um sistema operacional para me dizer quando e como devo lançar aplicativos. O Haiku permite que os desenvolvedores trabalhem com seus próprios repositórios hpkg, mas isso significa que os usuários terão que configurá-los manualmente, o que torna a ideia “menos atraente”.
• Tenho uma página de download no meu site onde distribuo .exe para Windows, .dmg para Mac e .AppImage para Linux. Ou talvez eu queira monetizar o acesso a esta página, tudo é possível? O que devo colocar lá para o Haiku? O arquivo é suficiente .hpkg com dependências apenas do HaikuPorts
• Meu software requer versões específicas de outro software. Por exemplo, sabe-se que o Krita necessita de uma versão corrigida do Qt, ou do Qt que esteja ajustado para uma versão específica do Krita, pelo menos até que os patches sejam transferidos de volta para o Qt. Você pode empacotar seu próprio Qt para sua aplicação em um pacote .hpkg, mas provavelmente isso não é bem-vindo.

Página normal de download de aplicativos. O que devo postar aqui para o Haiku?

Os pacotes (existentes como diretórios de aplicativos como AppDir ou .app no estilo Apple) e/ou imagens (na forma de AppImages fortemente modificadas ou .dmg da Apple) são uma adição útil ao ambiente de desktop Haiku? Ou diluirá todo o quadro e levará à fragmentação e, portanto, aumentará a complexidade? Estou dividido: por um lado, a beleza e a sofisticação do Haiku baseiam-se no fato de que geralmente existe uma maneira de fazer algo, em vez de muitas. Por outro lado, a maior parte da infra-estrutura para catálogos e/ou conjuntos de aplicativos já está instalada, então o sistema clama para que os poucos por cento restantes sejam implementados.

De acordo com o desenvolvedor senhor. waddlesplash

No Linux eles (catálogos e kits de aplicação, - aprox. tradutor) são provavelmente uma solução técnica para problemas sistémicos. No Haiku preferimos simplesmente resolver problemas de sistema.

O que você acha?

Antes de responder...

Espere, vamos fazer uma rápida verificação da realidade: na verdade diretórios de aplicativos - já faz 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, digamos, o Macintosh Finder. Não seria legal se o diretório QtCreator tivesse um nome e ícone "QtCreator" no canto superior esquerdo, iniciando o aplicativo quando clicado duas vezes?

Um pouco antes eu já Perguntou:

Você tem certeza de que pode executar seus aplicativos de uma década hoje, quando todas as lojas de aplicativos e repositórios de distribuição se esqueceram deles e de suas dependências? Você tem certeza de que ainda poderá acessar seu trabalho atual no futuro?

Já existe uma resposta do Haiku ou os catálogos e pacotes de aplicativos podem ajudar aqui? Eu acho que eles podem.

De acordo com o Sr. waddlesplash:

Sim, temos a resposta para a pergunta: simplesmente daremos suporte a esses aplicativos pelo tempo que for necessário, até que alguém possa ler seus formatos de arquivo da maneira correta ou fornecer funcionalidade individual. Nosso compromisso em oferecer suporte a aplicativos BeOS R5 no Haiku é prova disso...

Está certo!

Que curso de ação o Haiku deve tomar?

Posso imaginar a coexistência pacífica de hpkg, diretórios e imagens de aplicativos:

• O software do sistema usa .hpkg
• Para o software usado com mais frequência (especialmente aqueles que precisam agendar lançamentos contínuos), use .hpkg (aproximadamente 80% de todos os casos)
• Alguns instalados via .hpkg, os aplicativos se beneficiarão da mudança para uma infraestrutura de diretório de aplicativos (por exemplo, QtCreator): eles serão distribuídos como .hpkg, como antes.

senhor. waddlesplash escreve:

Se tudo que você precisa é visualizar aplicativos em /system/apps, em vez disso, deveríamos tornar os diretórios no Deskbar mais gerenciáveis ​​para os usuários, já que /system/apps não se destina a ser aberto e visualizado regularmente pelos usuários (ao contrário do MacOS). Para tais situações, o Haiku possui um paradigma diferente, mas esta opção é, em teoria, aceitável.

• O Haiku recebe a infraestrutura para execução de imagens de aplicativos, compilações noturnas, contínuas e de teste de software, bem como para casos 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 tudo). Essas imagens contêm os arquivos necessários para executar o aplicativo .hpkg, montado pelo sistema e após a conclusão do aplicativo - desmontado. (Talvez um gerenciador de arquivos possa colocar arquivos .hpkg em imagens de aplicativos, automaticamente ou a pedido do usuário - bem, como quando você arrasta um aplicativo para um diretório de rede ou unidade externa. É apenas uma música! Ou melhor, poesia - haicai.) Por outro lado, o usuário pode querer instalar o conteúdo da imagem na forma de arquivos.hpkg, após o que serão atualizados e processados ​​​​da mesma forma como se fossem instalados através do HaikuDepot... Precisamos fazer um brainstorming).

Citação do Sr. waddlesplash:

A execução de aplicativos a partir de unidades externas ou diretórios de rede pode ser potencialmente útil. E adicionar a capacidade de configurar mais "zonas" para o pkgman seria definitivamente um recurso interessante.

Tal sistema aproveitaria hpkg, diretórios e imagens de aplicativos. Eles são bons individualmente, mas juntos se tornarão invencíveis.

Conclusão

O Haiku possui uma estrutura que fornece uma experiência de usuário simples e sofisticada para PC e vai muito além do que normalmente é fornecido para PC Linux. Sistema de pacotes .hpkg é um exemplo, mas o resto do sistema também está imbuído de sofisticação. No entanto, o Haiku se beneficiaria com o suporte adequado a diretórios e imagens de aplicativos. Vale a pena discutir a melhor forma de fazer isso 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. No entanto, acredito que os designers, desenvolvedores e arquitetos do Haiku se beneficiarão com esta nova perspectiva. No mínimo, eu ficaria feliz em ser seu “parceiro de treino”. Tenho mais de 10 anos de experiência prática com catálogos e pacotes de aplicativos Linux e gostaria de encontrar um uso para eles no Haiku, para o qual acho que eles são perfeitos. As possíveis soluções 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 soluções mais elegantes, sou totalmente a favor. Basicamente já estou pensando na ideia de como fazer um sistema hpkg ainda mais incrível sem mudar a maneira como funciona. Acontece que a equipe do Haiku já vinha pensando em pacotes de aplicativos há muito tempo ao implementar um sistema de gerenciamento de pacotes, mas infelizmente (eu acho) a ideia se tornou "obsoleta". Talvez seja hora de revivê-lo?

Tente você mesmo! Afinal, o projeto Haiku disponibiliza imagens para inicialização a partir de DVD ou USB, geradas diariamente.
Você tem alguma pergunta? Nós convidamos você para o idioma russo canal de telegrama.

Visão geral do erro: Como dar um tiro no próprio pé em C e C++. Coleção de receitas do Haiku OS

De autor tradução: este é o oitavo e último artigo da série sobre Haiku.

Lista de artigos: primeiro O segundo Третья Quarto Quinto Sexto Sétimo

Apenas usuários registrados podem participar da pesquisa. Entrarpor favor

Faz sentido portar o sistema hpkg para Linux?

• Sim

• Não

• Já implementado, escreverei nos comentários

20 usuários votaram. 5 usuários se abstiveram.

Fonte: habr.com