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 )? Parece-me que essa será uma adição valiosa, mais fácil de implementar corretamente do que em outros sistemas, pois a maioria da infraestrutura já está lá.

Há uma semana, descobri o Haiku, um sistema inesperadamente bom. Bem, desde que há muito tempo me interesso por catálogos e imagens de aplicativos (inspirados na simplicidade do Macintosh), não é de surpreender que uma idéia me veio à mente ...

Para uma compreensão completa: Sou o criador e autor do AppImage, um formato de distribuição de aplicativos Linux que visa a simplicidade do Mac e fornece controle total aos autores e usuários finais do aplicativo (deseja saber mais - consulte o wiki e a documentação ).

E se fizermos uma AppImage para Haiku?

Vamos pensar um pouco, puramente teoricamente: o que precisa ser feito para obter uma AppImage , ou algo semelhante, no Haiku? Não é necessário criar algo agora, porque o sistema que já está no Haiku funciona surpreendentemente, mas um experimento imaginário seria bom. Ele também demonstra a sofisticação do Haiku, em comparação com os ambientes de desktop Linux, onde essas coisas são terrivelmente difíceis (tenho o direito de dizer isso: estou depurando há 10 anos).

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

Primeiro de tudo, o que é AppImage? Este é um sistema para liberar aplicativos de terceiros (por exemplo, Ultimaker Cura ) que permite liberar aplicativos quando e como eles caçam: você não precisa conhecer os recursos de várias distribuições, criar políticas ou construir infraestrutura, eles não precisam de suporte dos mantenedores e não dizem aos usuários o que (not) pode ser instalado em computadores. AppImage deve ser entendido como algo como um pacote para Mac no formato .app dentro de uma imagem de disco .dmg . A principal diferença é que os aplicativos não são copiados, mas permanecem dentro do AppImage sempre, assim como os pacotes .hpkg do Haiku, estão instalados e nunca são instalados no sentido usual.

Por mais de 10 anos de existência, a AppImage ganhou algum apelo e popularidade: o próprio Linus Torvalds aprovou-a publicamente e projetos difundidos (por exemplo, LibreOffice, Krita, Inkscape, Scribus, ImageMagick) o aceitaram como a principal maneira de distribuir montagens contínuas ou noturnas, não interferindo com aplicativos de usuário instalados ou não instalados. No entanto, os desktops e distribuições Linux geralmente ainda se apegam ao modelo de distribuição centralizado e tradicional, com base nos mantenedores e / ou promovem seus próprios negócios corporativos e / ou programas de engenharia baseados em Flatpak (RedHat, Fedora, GNOME) e Snappy (Canonical, Ubuntu) . Vem a engraçado .

Como isso funciona

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

• O sistema de arquivos SquashFS contém uma carga útil na forma de um aplicativo e tudo o que você precisa para executá-lo, o que, no seu perfeito juízo, não pode ser considerado parte da instalação padrão para todo sistema de destino bastante recente (distribuição Linux). Ele também contém metadados, por exemplo, nome do aplicativo, ícones, tipos MIME etc. etc.

• Quando iniciado pelo usuário, o tempo de execução usa o FUSE e o squashfuse para montar o sistema de arquivos, após o qual processa o lançamento de algum ponto de entrada (o chamado 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 as coisas:

• com uma variedade de distribuições Linux, não há nada "em sã consciência" que você possa chamar de "parte da instalação padrão para todos os novos sistemas de destino". Contornamos esse problema montando uma lista de excludentes , que nos permite determinar o que será empacotado no AppImage e o que precisa ser levado para outro lugar. Ao mesmo tempo, às vezes sentimos falta, apesar de, em geral, tudo funcionar bem. Por esse motivo, recomendamos que os criadores do pacote verifiquem a AppImages em todos os sistemas de destino (distribuições).
• Os aplicativos na forma de carga útil devem estar em roaming no sistema de arquivos. Infelizmente, em muitos aplicativos, caminhos absolutos para, por exemplo, recursos em /usr/share codificados. Isso precisa ser corrigido de alguma forma. Além disso, você deve exportar LD_LIBRARY_PATH ou corrigir o rpath para que o carregador possa encontrar bibliotecas relacionadas. O primeiro método tem suas desvantagens (que são gerenciadas de maneiras complexas), e o segundo é simplesmente complicado.
• A maior interceptação de UX para os usuários é definir o bit executável no arquivo AppImage após o download. Acredite ou não, para alguns, é uma barreira real. A necessidade de definir um bit executável é complicada, mesmo para usuários avançados. Como solução alternativa, propusemos a instalação de um pequeno serviço que monitora os arquivos do AppImage e define o bit executável para eles. Na sua forma pura, não é a melhor solução, porque não funcionará imediatamente. As distribuições Linux não oferecem esse serviço, portanto, os usuários prontos para o uso não estão indo bem.
• Os usuários do Linux esperam que o novo aplicativo tenha um ícone no menu de inicialização. Você não pode dizer ao sistema: "Olha, há um novo aplicativo, vamos trabalhar." Em vez disso, de acordo com a especificação XDG, você precisa copiar o arquivo .desktop para o local desejado em /usr para instalação em todo o sistema ou em $HOME para instalação individual. Ícones de determinados tamanhos, de acordo com a especificação XDG, é necessário colocá-lo em determinados lugares em usr ou $HOME e, em seguida, executar comandos no ambiente de trabalho para atualizar o cache de ícones, ou esperar que o gerente do ambiente de trabalho o descubra e detecte tudo automaticamente. Para usar o mesmo serviço, que, além de definir o sinalizador de execução, copiará-os do AppImage para os locais corretos, de acordo com o XDG, se houver ícones etc. no AppImage, é assumido que o serviço limpará tudo ao excluí-lo ou movê-lo. ambiente de trabalho, em formatos de arquivo gráfico, seus tamanhos, locais de armazenamento e maneiras de atualizar caches, o que cria um problema.Em resumo, esse método é uma muleta.
• Se as opções acima não forem suficientes, não há ícone AppImage no gerenciador de arquivos. No mundo Linux, eles ainda não decidiram implementar o elficon (apesar da discussão e implementação ), por isso é impossível incorporar o ícone diretamente no aplicativo. Portanto, os aplicativos no gerenciador de arquivos não têm seus próprios ícones (sem diferença, AppImage ou outra coisa), eles estão apenas no menu Iniciar. Como solução alternativa, usamos miniaturas - um mecanismo originalmente desenvolvido para que os gerentes de área de trabalho possam exibir miniaturas para visualizar arquivos gráficos como seus ícones. Portanto, o serviço para definir o bit executável também funciona como um “miniaturizador”, criando e gravando miniaturas de ícones nos locais /usr e $HOME . Este serviço também executa a remoção se a AppImage for excluída ou movida. Devido ao fato de que cada gerenciador de desktop se comporta de maneira um pouco diferente, por exemplo, em quais formatos ele aceita ícones, em quais tamanhos ou lugares, tudo isso é realmente doloroso.
• O aplicativo simplesmente trava no tempo de 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 ninguém diz ao usuário na GUI o que exatamente está acontecendo. Começamos a contornar isso usando notificações na área de trabalho, o que significa que precisamos capturar erros na linha de comando, convertê-los em mensagens compreensíveis pelo usuário, que precisam ser exibidas na área de trabalho. E, é claro, cada ambiente de trabalho os trata de maneira um pouco diferente.
• No momento (setembro de 2019, aprox. Tradutor), não encontrei uma maneira simples de informar ao sistema que o arquivo 1.png ser aberto usando o Krita e 2.png - usando o GIMP.

O local de armazenamento para as especificações entre desktops usadas pelo GNOME , KDE e Xfce é freedesktop.org

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

Ícones de diferentes versões do Firefox

Fiquei me perguntando o que o mundo Linux poderia aprender com o Mac OS X, para não mexer com a integração do sistema. Se você tiver tempo e estiver fazendo isso, leia o que Arno Gourdol, um dos primeiros engenheiros do Mac OS X, disse:

Queríamos instalar o aplicativo tão facilmente quanto arrastar o ícone do aplicativo de algum lugar (servidor, unidade externa) para o disco do seu computador. Para fazer isso, todas as informações são armazenadas no pacote do aplicativo, incluindo ícones, versão, tipo de arquivo sendo processado, tipo de esquema de URL que o sistema deve saber para processar o aplicativo. Isso também inclui informações para 'armazenamento centralizado' no banco de dados de Serviços de Ícones e Serviços de Inicialização. Para manter o desempenho, os aplicativos são 'descobertos' em vários locais 'conhecidos': no ​​diretório do sistema e do usuário, Aplicativos e em alguns outros automaticamente, se o usuário mudou para o Finder para o diretório que contém o aplicativo. Na prática, isso funcionou muito bem.

https://youtu.be/qQsnqWJ8D2c
Sessão 144 da Apple WWDC 2000 - Mac OS X: Empacotando aplicativos e imprimindo documentos.

Não há nada semelhante a essa infraestrutura nos desktops Linux, portanto, estamos procurando soluções alternativas para as restrições estruturais no projeto AppImage.

O Haiku tem pressa em ajudar?

E mais uma coisa: as plataformas Linux como base dos ambientes de trabalho, como regra, são tão não especificadas que muitas coisas que são muito simples em um sistema consistente com uma pilha cheia decepcionam a fragmentação e a complexidade do Linux. Dediquei um relatório inteiro a questões relacionadas à plataforma Linux para ambientes de trabalho (desenvolvedores experientes confirmaram: tudo permanecerá assim por muito tempo).

Meu relatório sobre ambientes de desktop Linux em 2018

Até Linus Torvalds admitiu que foi por causa da fragmentação que a idéia de ambientes de trabalho falhou.

Bom ver o Haiku!

Com o Haiku, tudo é incrivelmente simples.

Embora a abordagem ingênua de transportar o AppImage para o Haiku seja simplesmente tentar compilar (principalmente o runtime.c e o serviço) seus componentes (o que pode ser possível!), Ele não trará muitos benefícios ao Haiku. Porque, na verdade, muitos desses problemas foram resolvidos pelo Haiku e conceitualmente justificados. O Haiku fornece exatamente esses tijolos para a infraestrutura do sistema que eu tenho procurado nos ambientes de desktop Linux há tanto tempo e não podia acreditar que eles não estão lá. Ou seja:

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

• Os arquivos ELF que não possuem um bit executável o recebem automaticamente quando você clica duas vezes no gerenciador de arquivos.
• Os aplicativos podem ter recursos incorporados, por exemplo, ícones que aparecem no gerenciador de arquivos. Você não precisa copiar um monte de imagens para diretórios de ícones especiais e, portanto, não é necessário limpá-las após excluir ou mover o aplicativo.
• Há um banco de dados para vincular aplicativos a documentos, não há necessidade de copiar nenhum arquivo para isso.
• No diretório lib / próximo ao 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á módulo separado para inicialização que seja diferente do diretório Aplicativos.
• Os aplicativos não possuem caminhos absolutos internos para seus recursos; existem funções especiais para determinar o local no tempo de execução.
• A idéia de imagens de sistema de arquivos compactados foi introduzida: este é qualquer pacote hpkg. Todos eles são montados pelo núcleo.
• Cada arquivo é aberto pelo aplicativo que o criou, a menos que você especifique explicitamente outra coisa. Como é impressionante!

Dois arquivos png. Preste atenção aos diferentes ícones, mostrando que eles serão abertos por diferentes aplicativos clicando duas vezes. Também preste atenção no menu suspenso "Abrir com:", onde o usuário pode selecionar um aplicativo separado. Quão fácil!

Parece que muitas das muletas e soluções alternativas necessárias para o AppImage no Linux se tornam desnecessárias no Haiku, que se baseia na simplicidade e sofisticação, graças às quais ele atende a maioria de nossas necessidades.

O Haiku precisa de pacotes de aplicativos no final?

Isso leva a uma grande questão. Se fosse uma ordem de magnitude mais fácil criar um sistema como o AppImage no Haiku do que no Linux, valeria a pena? Ou o Haiku, com seu sistema de pacotes hpkg, praticamente eliminou a necessidade de desenvolver essa idéia? Bem, para obter a resposta, você precisa considerar a motivação para a existência da AppImages.

Vista do usuário

Dê uma olhada no nosso usuário final:

• Quero instalar o aplicativo sem solicitar a senha do administrador (root). No Haiku não há conceito de administrador, o usuário tem controle total, pois esse é um sistema pessoal! (Em princípio, você pode imaginar isso no modo multiusuário, espero que os desenvolvedores mantenham a simplicidade)
• Desejo obter as melhores e mais recentes versões dos aplicativos, para não esperar que eles apareçam na minha distribuição (na maioria das vezes significa "nunca", pelo menos se você não atualizar todo o sistema operacional). No Haiku, isso é "resolvido" com lançamentos flutuantes. Isso significa que é possível obter as versões melhores e mais recentes dos aplicativos, mas para isso, você precisa atualizar constantemente o restante do sistema, transformando-o em um "alvo em movimento" .
• Quero várias versões do mesmo aplicativo por perto, porque você não consegue descobrir o que foi quebrado na versão mais recente ou, por exemplo, como desenvolvedor da web, preciso verificar meu trabalho em diferentes versões do navegador. Haiku resolveu o primeiro, mas não o segundo problema. As atualizações são revertidas, mas apenas para todo o sistema, é impossível (como eu sei) iniciar, por exemplo, várias versões do WebPositive ou LibreOffice ao mesmo tempo.

Um dos desenvolvedores escreve:

Em essência, a lógica é esta: o caso de uso é tão raro que a otimização não faz sentido para ele; lidar com isso como um caso especial no HaikuPorts parece mais do que aceitável.

• Preciso salvar os aplicativos onde eu quiser, e não no disco de inicialização. Costumo ficar sem espaço nos discos, portanto, preciso conectar uma unidade externa ou um diretório de rede para armazenar aplicativos (todas as versões que baixei). Se eu conectar uma unidade desse tipo, preciso que os aplicativos sejam iniciados clicando duas vezes. O Haiku salva versões mais antigas de pacotes, mas não sei como movê-las para uma unidade externa ou como chamar aplicativos a partir daí mais tarde.

Comentário do desenvolvedor:

Tecnicamente, isso já é possível com o comando mount. Obviamente, criaremos uma GUI para isso assim que reunir usuários 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 ser facilmente baixado, movido e excluído. No Haiku, esse problema foi resolvido com a ajuda de pacotes .hpkg , que transferem, por exemplo, python, de milhares de arquivos para um. Mas se houver, por exemplo, Scribus usando python, então eu tenho que lidar com pelo menos dois arquivos. E eu tenho que tomar cuidado para manter suas versões trabalhando umas com as outras.

Inúmeras versões do AppImages rodando lado a lado em um único Linux

Vista do lado do desenvolvedor do aplicativo

Vamos olhar do ponto de vista do desenvolvedor de aplicativos:

• Quero gerenciar toda a experiência do usuário. Não quero depender do sistema operacional, que me dirá quando e como devo liberar aplicativos. No Haiku, os desenvolvedores podem trabalhar com seus próprios repositórios hpkg, mas isso significa que os usuários precisarão 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. Ou talvez eu queira monetizar o acesso a esta página, tudo pode ser? O que preciso postar no Haiku? Arquivo .hpkg suficiente .hpkg com dependências do .hpkg
• Meu software precisa de certas versões de outro software. Por exemplo, sabe-se que o Krita precisa de uma versão fixa do Qt, ou Qt, que seja ajustada para uma versão específica do Krita, pelo menos até que as correções retornem ao Qt. Você pode empacotar seu próprio Qt para o aplicativo no pacote .hpkg , mas provavelmente isso não é bem-vindo.

Página de download normal do aplicativo. O que colocar aqui para o Haiku?

Os pacotes (existentes como diretórios de aplicativos como AppDir ou .app no estilo Apple) e / ou imagens (como AppImages ou .dmg da Apple fortemente modificados) serão adições úteis ao ambiente de trabalho do Haiku? Ou diluirá todo o quadro e levará à fragmentação e, portanto, aumentará a complexidade? Estou empolgado: por um lado, a beleza e a sofisticação do Haiku se baseiam no fato de que geralmente há uma maneira de fazer algo, não muito. , / , , .

mr. waddlesplash

Linux ( , — . ) . Haiku .

?

...

, : — Haiku:

Haiku,

, , , Macintosh Finder. , QtCreator "QtCreator", ?

:

, , ? , - ?

Haiku, ? , .

mr. waddlesplash:

, : , , - . BeOS R5 Haiku — ...

!

Haiku?

hpkg, :

• .hpkg
• ( , ) .hpkg ( 80% )
• , .hpkg , ( , QtCreator): .hpkg , .

mr. waddlesplash :

, , — /system/apps , Deskbar , /system/apps , ( MacOS). Haiku , , , .

• Haiku , , , , " ", , ( 20% ). .hpkg , , — . (, .hpkg , — , . ! — .) , .hpkg , , HaikuDepot… ).

mr. waddlesplash:

. "" pkgman .

hpkg, . , .

Conclusão

Haiku , , , Linux. .hpkg — , . , Haiku . — , Haiku, , . Haiku . , , , Haiku. , «-». 10 Linux, Haiku, , , . , , Haiku , , — . , , hpkg , . , Haiku , , ( ) "". , ?

! Haiku DVD USB, .
? telegram- .

: C C++. Haiku OS

: Haiku.

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