🥇Meu sexto dia com o Haiku: sob o capô de recursos, ícones e pacotes

TL;DR: Haiku — um sistema operacional projetado especificamente para PCs, por isso possui várias características que tornam seu ambiente de trabalho muito melhor do que os outros. Mas como ele funciona?

Recentemente Descobri o Haiku, um sistema surpreendentemente bom. Estou até agora impressionado com a fluidez com que ele funciona, especialmente em comparação com os ambientes de trabalho no Linux. Hoje, vou dar uma olhada sob o capô. Onde for necessário para uma compreensão mais profunda, farei uma comparação com o Macintosh original, Mac OS X e ambientes de trabalho Linux (padrão XDG do freedesktop.org).

Recursos em arquivos ELF

Ontem, descobri que o IconOMatic pode salvar ícones em recursos rdef em arquivos executáveis ELF. Hoje, quero ver como isso realmente funciona.

Recursos? Citação de Bruce Horn, o autor original do programa Macintosh Finder e o "pai" do Macintosh Resource Manager:

O que me preocupa é a rigidez do código tradicional. Para mim, a ideia de um aplicativo congelado em código, sem possibilidade de mudar algo dinamicamente, é uma grande barbaridade. Deve haver a possibilidade de modificar o máximo possível em tempo de execução. Claro, o próprio código do aplicativo não pode ser alterado, mas há coisas que podem ser mudadas sem recompilar o código?

No Macintosh original, foi feito de modo que esses arquivos tivessem uma "seção de dados" e uma "seção de recursos", o que facilitou extraordinariamente a preservação de várias coisas, como ícones, traduções, etc., em arquivos executáveis.

No Mac, para isso, utiliza-se ResEdit, um programa gráfico para — surpresa — edição de recursos.

ResEdit no Macintosh original

Assim, tornou-se possível editar ícones, itens de menu, traduções e outros de forma relativamente fácil, no entanto, eles ainda "viajam" com os aplicativos.
De qualquer forma, essa abordagem tinha uma grande desvantagem: funcionava apenas em sistemas de arquivos da Apple, o que se tornou um dos motivos pelos quais a Apple abandonou a "seção de recursos" ao migrar para o Mac OS X.
No Mac OS X, a Apple queria uma solução independente do sistema de arquivos, por isso implementaram o conceito de pacotes (do NeXT), diretórios que são tratados pelo gerenciador de arquivos como "objetos opacos", semelhantes a arquivos, e não a diretórios. Qualquer pacote de aplicativo no formato .app possui, entre outras coisas, um arquivo Info.plist (em uma espécie de análogo ao JSON ou YAML da Apple), contendo os metadados do aplicativo.

As chaves do arquivo Info.plist no pacote de aplicativos do Mac OS X.

Recursos, como ícones, arquivos de interface do usuário e outros, são armazenados no pacote na forma de arquivos. O conceito na verdade retorna às suas origens na NeXT.

Mathematica.app no NeXTSTEP 1.0 em 1989: é exibido como um diretório com arquivos no terminal, mas como um único objeto no gerenciador de arquivos gráfico.

Voltando ao BeOS, cujas concepções formam a base do Haiku. Seus desenvolvedores, ao mudar de PEF (PowerPC) para ELF (x86) (o mesmo que é usado no Linux), decidiram adicionar uma seção de recursos ao final dos arquivos ELF. Para isso, não foi utilizada uma seção própria e adequada do ELF, ela simplesmente foi adicionada ao final do arquivo ELF. Como resultado, programas como strip e outros do binutils, que não sabiam disso, simplesmente a cortaram. Portanto, ao adicionar recursos ao arquivo ELF no BeOS, é melhor não trabalhar com ele usando ferramentas do Linux.

E o que acontece atualmente com o Haiku? Em princípio, mais ou menos a mesma coisa.

Na teoria, seria possível colocar recursos na seção correta do ELF. Segundo os desenvolvedores no canal #haiku na rede irc.freenode.net:

Com o ELF a seção faria mais sentido ... a única razão pela qual não fazemos isso é porque assim era no BeOS.
E não vale a pena mudar isso agora.

Gerenciamento de recursos

Os recursos são escritos em um formato de "recurso" estruturado: essencialmente é uma lista de recursos com tamanhos e depois seu conteúdo. Lembrou-se do formato ar..
Como verificar recursos no Haiku? Existe algo como ResEdit?
De acordo com documentação:

Para visualizar os recursos fornecidos no pacote do aplicativo, você pode arrastar o arquivo executável para um programa como Resourcer.Você também pode ir ao terminal e executar o comando listres nome_do_arquivo..

O Resourcer está disponível no HaikuDepot, mas ele simplesmente trava para mim.

Como gerenciar recursos em arquivos ELF? Usando rsrc. e rdef.. rdef. Os arquivos são montados em rsrc.. O arquivo rdef. é armazenado em um formato de texto comum, tornando muito mais fácil trabalhar com ele. O arquivo no formato rsrc. é adicionado ao final do arquivo ELF. Vamos tentar brincar:

~> rc -h
Compilador de Recursos Haiku 1.1 Para compilar um script rdef em um arquivo de recurso:
    rc [opções] [-o ] ... Para converter um arquivo de recurso de volta em um script rdef:
    rc [opções] [-o ] -d ... Opções:
    -d --decompile       cria um script rdef a partir de um arquivo de recurso
       --auto-names      constrói nomes de recursos a partir de símbolos de ID
    -h --help            exibe esta mensagem
    -I --include    adiciona  à lista de caminhos de inclusão
    -m --merge           não apaga o conteúdo existente do arquivo de saída
    -o --output          especifica o nome do arquivo de saída, o padrão é out.xxx
    -q --quiet           não exibe mensagens de erro
    -V --version         mostra a versão do software e a licença.

Você pode usar o programa xres. para verificação e gerenciamento:

/> xres
Usage: xres ( -h | --help )
       xres -l <file> ...
       xres <command> ...The first form prints this help text and exits.The second form lists the resources of all given files.The third form manipulates the resources of one or more files according to
the given commands.
(...)

Certo, vamos experimentar?

/> xres -l /Haiku/system/apps/WebPositive/Haiku/system/apps/WebPositive resources:type           ID        size  name
------ ----------- -----------  --------------------
'MIMS'           1          36  BEOS:APP_SIG
'APPF'           1           4  BEOS:APP_FLAGS
'MSGG'           1         421  BEOS:FILE_TYPES
'VICN'         101        7025  BEOS:ICON
'VICN'         201          91  kActionBack
'VICN'         202          91  kActionForward
'VICN'         203         300  kActionForward2
'VICN'         204         101  kActionStop
'VICN'         206         243  kActionGoStart
'MSGG'         205        1342  kActionGo
'APPV'           1         680  BEOS:APP_VERSION

Mais sobre recursos e formato rdef. pode ser lido aqui.

Tipos padrão de recursos

Embora seja possível colocar qualquer coisa nos recursos, existem alguns tipos padrão definidos:

app_signature: tipo MIME do aplicativo, para mapeamento de arquivos abertos, execução, IPC, etc.
app_name_catalog_entry: Como o nome do aplicativo geralmente é em inglês, aqui pode-se indicar os locais onde os nomes traduzidos estão, assim os usuários de diferentes idiomas verão o nome traduzido do aplicativo, caso desejem.
app_version: exatamente o que você pensou
app_flags: indica registrar como processar o aplicativo. Acredito que há algo mais do que parece à primeira vista. Por exemplo, há B_SINGLE_LAUNCH, que faz com que o sistema inicie um novo processo do aplicativo toda vez que solicitado pelo usuário (o mesmo princípio é usado para a maioria dos aplicativos no Linux). Há também B_MULTIPLE_LAUNCH, que faz com que um processo seja iniciado para cada arquivo. Por fim, há B_EXCLUSIVE_LAUNCH, que faz com que o sistema inicie apenas um processo de cada vez, independentemente de quantas vezes os usuários o iniciem (por exemplo, assim como o Firefox no Linux; o mesmo resultado pode ser alcançado em aplicativos Qt, usando a função QtSingleApplication). Aplicativos com B_EXCLUSIVE_LAUNCH são notificados quando o usuário tenta iniciá-los novamente: por exemplo, recebem o caminho do arquivo que o usuário deseja abrir com eles.
vector_icon: Ícone vetorial do aplicativo (No BeOS não havia ícones vetoriais, a maioria dos aplicativos, em vez disso, tinha duas ícones raster em arquivos executáveis).

Claro, é possível adicionar recursos com quaisquer IDs e tipos desejados, após o que eles podem ser lidos no próprio aplicativo ou em outros aplicativos usando a classe BResources. Mas para começar, vamos nos concentrar em um tema interessante sobre ícones.

Ícones vetoriais no estilo Haiku

Certamente não só o Haiku escolheu o melhor formato para ícones, nesta parte a situação com ambientes de desktop no Linux está longe de ser ideal:

me@host:~$ ls /usr/share/icons/hicolor/
128x128  256x256  512x512           index.theme
160x160  28x28    64x64             scalable
16x16    32x32    72x72             symbolic
192x192  36x36    8x8
22x22    42x42    96x96
24x24    48x48    icon-theme.cache

Olhando para isso, já dá para sentir o que é esse pedaço.

Claro, existem ícones vetoriais escaláveis. Por que ainda existe algo mais? Porque o resultado da renderização de gráficos vetoriais em tamanhos pequenos pode ser inferior ao ideal. É desejável ter diferentes variantes, otimizadas para tamanhos diversos. Em ambientes Linux, isso é alcançado espalhando os ícones de diferentes tamanhos pelo sistema de arquivos.

me@host:~$ find /usr/share/icons/ -name 'firefox.*'
/usr/share/icons/HighContrast/16x16/apps/firefox.png
/usr/share/icons/HighContrast/22x22/apps/firefox.png
/usr/share/icons/HighContrast/24x24/apps/firefox.png
/usr/share/icons/HighContrast/256x256/apps/firefox.png
/usr/share/icons/HighContrast/32x32/apps/firefox.png
/usr/share/icons/HighContrast/48x48/apps/firefox.png
/usr/share/icons/elementary-xfce/apps/128/firefox.png
/usr/share/icons/elementary-xfce/apps/16/firefox.png
/usr/share/icons/elementary-xfce/apps/22/firefox.png
/usr/share/icons/elementary-xfce/apps/24/firefox.png
/usr/share/icons/elementary-xfce/apps/32/firefox.png
/usr/share/icons/elementary-xfce/apps/48/firefox.png
/usr/share/icons/elementary-xfce/apps/64/firefox.png
/usr/share/icons/elementary-xfce/apps/96/firefox.png
/usr/share/icons/hicolor/128x128/apps/firefox.png

Observe: não há conceito de diferentes versões do Firefox. Assim, não é possível lidar de forma refinada com a situação de várias versões do aplicativo estarem presentes no sistema.

Diferentes ícones do Firefox em diferentes versões. Até agora, isso não pode ser tratado no Linux sem várias gambiarras.

O Mac OS X lida com isso de forma um pouco mais refinada:

Mac:~ me$ find /Applications/Firefox.app | grep icns
/Applications/Firefox.app/Contents/MacOS/crashreporter.app
/Contents/Resources/crashreporter.icns
/Applications/Firefox.app/Contents/MacOS/updater.app/Contents/Resources/updater.icns
/Applications/Firefox.app/Contents/Resources/document.icns
/Applications/Firefox.app/Contents/Resources/firefox.icns

É evidente que há um arquivo firefox.icns no pacote Firefox.app, contendo todos os tamanhos, de modo que diferentes versões de um mesmo aplicativo tenham ícones diferentes.
Muito melhor! Os ícones viajam juntos com o aplicativo, todos os recursos em um único arquivo.

Voltando ao Haiku. Uma solução impressionante, sem exceções. De acordo com documentação:

Foi desenvolvido um formato especial, altamente otimizado para tamanhos pequenos e renderização rápida, chamado HVIF. Portanto, nossos ícones são em grande parte muito menores do que nos formatos rasterizados ou no amplamente utilizado formato SVG.

E eles realmente estão otimizados:

Tamanhos dos ícones em HVIF comparados a outros formatos.

A diferença é significativa!

Mas a magia não termina aqui. O mesmo HVIF pode exibir diferentes níveis de detalhamento dependendo do tamanho de exibição, mesmo sendo um formato vetorial.

Diferentes níveis de detalhamento (LOD) dependendo do tamanho da renderização.

Agora sobre as desvantagens: não é possível pegar um SVG, jogá-lo no ImageMagick e acabar por aí, é preciso passar por várias etapas para criar um ícone no formato HVIF. Aqui explicações. No entanto, o IconOMatic pode importar SVG de maneira bastante imperfeita; cerca de 90% dos detalhes do SVG são importados com certa probabilidade, os restantes 10% precisarão ser ajustados e alterados manualmente. Para ler mais sobre como o HVIF faz sua mágica é possível no blog Lea Ganson

Adicionando um ícone ao aplicativo

Agora posso adicionar um ícone ao pacote que foi criado na última vez, levando em conta todas as informações obtidas.
Bem, como neste momento não estou muito animado para desenhar meu próprio ícone para o meu "Olá, Mundo" QtQuickApp — vou extrair um do Qt Creator.

/Haiku/home> xres /Haiku/system/apps/QtCreator/bin/Qt Creator  -o /Haiku/home/QtQuickApp/QtQuickApp  -a VICN:101:BEOS:ICON /Haiku/system/apps/QtCreator/bin/Qt Creator

Vamos verificar se o ícone foi copiado:

/Haiku/home> xres -l /Haiku/home/QtQuickApp/QtQuickApp/Haiku/home/QtQuickApp/QtQuickApp
resources:type           ID        size  name
------ ----------- -----------  --------------------
'VICN'         101      152238  BEOS:ICON

Parece bom, mas por que, quando o novo ícone foi copiado, ele não é exibido?

O VICN:101:BEOS:ICONs copiado ainda não está sendo usado como ícone para o aplicativo no gerenciador de arquivos

O que eu perdi?

Comentário do desenvolvedor:

É necessário criar um arquivo rdef. com todos os recursos, depois executar o comando rc nome.rdef, isso criará o arquivo .rsrc. Depois, é preciso executar o comando resattr -o nome_binário nome.rsrc. No mínimo, eu uso comandos semelhantes para adicionar ícones aos meus scripts.

Bem, eu queria criar um recurso, e não um atributo. Estou completamente confuso.

Cache inteligente usando o sistema de arquivos

Abrir e ler atributos ELF é lento. Como mencionei acima, o ícone é escrito como um recurso dentro do próprio arquivo. Esse método é mais confiável, permitindo sobreviver à cópia para outro sistema de arquivos. No entanto, ele também é copiado para o atributo do sistema de arquivos, por exemplo, BEOS:ICON. Isso funciona apenas em determinados sistemas de arquivos, como o BFS. Os ícones exibidos pelo sistema (no Tracker e Deskbar) são lidos desse atributo estendido, porque essa solução funciona rapidamente. Em alguns lugares (onde a velocidade não é importante, como na janela típica "Sobre"), o sistema obtém o ícone diretamente do recurso no arquivo. Mas isso ainda não é o fim. Lembre-se, no Mac, os usuários podiam substituir ícones de aplicativos, pastas, documentos pelos seus, pois no Mac há a possibilidade de fazer essas "coisas importantes", como substituir o novo ícone do Slack pelo anterior. No Haiku, deve-se considerar o recurso (no arquivo) como o ícone original fornecido com o aplicativo, e o atributo (no sistema de arquivos BFS) como algo que permite ao usuário fazer alterações caso deseje (embora, dica, a interface gráfica para inserir um ícone personalizado sobre o ícone padrão ainda não tenha sido implementada).

Verificação de atributos do sistema de arquivos

Com resaddr é possível verificar e definir atributos do sistema de arquivos.

/> resattr
Usage: resattr [ <options> ] -o <outFile> [ <inFile> ... ]

Reads resources from zero or more input files and adds them as attributes
to the specified output file, or (in reverse mode) reads attributes from
zero or more input files and adds them as resources to the specified output
file. If not existent the output file is created as an empty file.
(...)

Na essência, isso é uma "cola" que faz a conversão de recursos (confiáveis) e (rápidos) atributos do sistema de arquivos. E como o sistema pressupõe a obtenção de recursos e realiza cópias automaticamente, não me preocuparei mais com isso.

A magia dos pacotes hpkg

Atualmente, na maioria das vezes, os programas para Haiku são obtidos por meio de pacotes .hpkg. Não se deixe enganar pelo nome simples: o formato .hpkg funciona de maneira completamente diferente de outros formatos com nomes semelhantes que você pode ter encontrado, e ele possui verdadeiros superpoderes.

Com formatos de pacotes tradicionais, eu costumava ficar frustrado por um fato: você baixa um (pacote), mas o que é instalado no sistema são outros (arquivos dentro do pacote). É bastante difícil lidar com os arquivos (por exemplo, removê-los) quando um pacote é instalado da maneira tradicional. Isso ocorre porque o conteúdo do pacote se espalha por todo o sistema de arquivos, incluindo locais onde o usuário comum pode não ter acesso de gravação. Isso gera toda uma classe de programas — gerenciadores de pacotes. E mover software já instalado, por exemplo, para outra máquina, disco removível ou servidor de arquivos, se torna ainda mais difícil, ou até mesmo impossível. Em um sistema baseado em Linux, pode haver facilmente de centenas de milhares a milhões de arquivos isolados. Isso, naturalmente, é ao mesmo tempo frágil e lento, por exemplo, durante a instalação inicial do sistema, na instalação, atualização e remoção de pacotes comuns, além da cópia da unidade de boot (partição raiz) para outro meio.

Estou trabalhando no projeto AppImage, uma solução parcial para aplicativos de usuário final. Este é um formato de distribuição de software que empacota o aplicativo e todas as suas dependências em uma única imagem de sistema de arquivos, que é montada ao iniciar o aplicativo. Torna as coisas muito mais simples, já que o mesmo ImageMagick, de repente, se transforma em um único arquivo, gerenciado em um gerenciador de arquivos por meros mortais. O método proposto funciona apenas para software, como refletido no nome do projeto, e também tem seu próprio conjunto de problemas, uma vez que as pessoas que se ocupam da entrega de software para Linux sempre jogam a responsabilidade sobre mim.

Vamos voltar ao Haiku. Conseguimos encontrar um equilíbrio ideal entre sistemas de pacotes tradicionais e a entrega de software baseado em imagens? Seus pacotes .hpkg são na verdade imagens comprimidas do sistema de arquivos. Ao iniciar o sistema, o núcleo monta todos os pacotes instalados e ativos com mensagens semelhantes às seguintes do núcleo:

KERN: package_daemon [16042853:   924] pacote ativo: "gawk-4.2.1-1-x86_64.hpkg"
KERN: package_daemon [16043023:   924] pacote ativo: "ca_root_certificates_java-2019_01_23-1-any.hpkg"
KERN: package_daemon [16043232:   924] pacote ativo: "python-2.7.16-3-x86_64.hpkg"
KERN: package_daemon [16043405:   924] pacote ativo: "openjdk12_default-12.0.1.12-1-x86_64.hpkg"
KERN: package_daemon [16043611:   924] pacote ativo: "llvm_libs-5.0.0-3-x86_64.hpkg"

Impressionante, né? Aguentem firme, ainda vai ficar melhor!

Há um pacote muito especial:

KERN: package_daemon [16040020:   924] pacote ativo: "haiku-r1~beta1_hrev53242-1-x86_64.hpkg"

Ele contém um sistema operacional bastante minimalista, incluindo o núcleo. Acreditem ou não, mas até o núcleo em si não é extraído do volume de inicialização (partição raiz), mas é cuidadosamente carregado em seu lugar a partir do pacote .hpkg. Uau! Eu já mencionei que, na minha opinião, parte da sofisticação e coerência do Haiku se deve ao fato de que todo o sistema, desde o núcleo e o espaço do usuário básico até a gestão de pacotes e a infraestrutura do ambiente de trabalho, é desenvolvido por uma única equipe. Imagine quantos grupos e equipes diferentes seriam necessários para implementar algo assim com base no Linux [eu imagino o projeto PuppyLinux - nota do tradutor]. Depois, imagine quanto tempo levaria para que essa abordagem fosse implantada nas distribuições. Dizem que: pegue uma tarefa simples, divida entre diferentes executores, e ela se tornará tão complexa que será impossível resolvê-la. No caso do Haiku, isso me abriu os olhos. Acho que é exatamente isso que está acontecendo com o Linux agora (Linux, neste caso, é um termo coletivo que abrange a pilha Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Reversão do sistema usando hpkg

Quantas vezes acontece a seguinte situação: a atualização foi bem-sucedida, mas depois descobre-se que algo não está funcionando corretamente? Se você usar gerenciadores de pacotes comuns, é difícil restaurar o estado do sistema para o momento anterior à instalação de novos pacotes (por exemplo, quando algo dá errado). Alguns sistemas oferecem alternativas na forma de instantâneas do sistema de arquivos, mas elas são bastante complicadas e não são aplicadas em todos os sistemas. No Haiku, isso é resolvido com pacotes. .hpkgToda vez que os pacotes são alterados no sistema, os pacotes antigos não são removidos, mas armazenados no sistema em subdiretórios do tipo. /Haiku/system/packages/administrative/state-<...>/ constantemente. Operações não finalizadas armazenam seus dados em subdiretórios. /Haiku/system/packages/administrative/transaction-<...>/.

Conteúdo /Haiku/system/packages/administrativeOs diretórios "state..." contêm arquivos de texto com os nomes dos pacotes ativos, "transaction..." — os próprios pacotes.

"Estado ativo antigo", ou seja, a lista .hpkg de pacotes ativos antes das mudanças, é gravada após cada operação no gerenciador de arquivos em um arquivo de texto. /Haiku/system/packages/administrative/state-<...>/activated-packagesDe forma semelhante, o novo "estado ativo" é escrito em um arquivo de texto. /Haiku/system/packages/administrative/activated-packages.

Diretório /Haiku/system/packages/administrative/state-<...>/ contém apenas um arquivo de texto com a lista de pacotes ativos desse estado (no caso de instalação de pacotes sem remoção), e se os pacotes foram removidos ou atualizados — o diretório state contém versões antigas dos pacotes.

Ao iniciar o sistema, com base na lista de pacotes, é tomada a decisão sobre a ativação (montagem) dos pacotes. É assim que funciona! Se algo der errado ao iniciar, é possível indicar ao gerenciador de inicialização para usar outra lista, mais antiga. O problema está resolvido!

Gerenciador de Inicialização do Haiku. Cada ponto de entrada reflete o correspondente "estado ativo".

Eu gosto da abordagem com arquivos de texto simples como lista do "estado ativo", onde estão gravados nomes compreensíveis. .hpkgIsso contrasta profundamente com a confusão criada para máquinas e não para humanos. de OSTree ou Flatpak no sistema de arquivos (no mesmo nível que o GUID da Microsoft). A lista de pacotes ativos para cada momento no tempo.

Dados de configuração.

Pelo que parece, no diretório

estão os arquivos de configuração para pacotes, mas disponíveis para gravação. Como você deve se lembrar, /Haiku/system/packages/administrative/writable-files são montados apenas para leitura. Assim, esses arquivos devem ser copiados dos pacotes antes da gravação. Faz sentido. .hpkg Integração de GUI para o sistema .hpkg.

Integração GUI para o sistema .hpkg

Agora vamos ver como esses pacotes brilhantes .hpkg se integram no ambiente de trabalho do usuário (UX). Afinal, o Haiku é projetado para aplicações pessoais. Pessoalmente, estabeleci um padrão alto, comparando a experiência do usuário com pacotes .app no Macintosh com a mesma experiência em .hpkg. Não vou nem comparar a situação com ambientes de trabalho no Linux, porque é absolutamente horrível em comparação com qualquer outro.

Os seguintes cenários vêm à mente:

Quero visualizar o conteúdo do pacote .hpkg
Quero instalar o pacote
Quero remover o pacote
Quero excluir algo que chegou ao sistema como parte do pacote
Quero copiar algo que chegou ao sistema como parte do pacote
Quero baixar todas as dependências do pacote que podem não fazer parte de cada instalação do Haiku (por exemplo, eu tenho uma máquina fisicamente isolada sem acesso à Internet).
Quero mover meus pacotes (ou parte deles) separadamente para outro lugar, diferente do volume de inicialização (partição raiz) (porque, por exemplo, estou com falta de espaço nele).

Isso deve cobrir a maioria dos casos fundamentais do meu dia a dia. Agora, vamos lá.

Verificando o conteúdo do pacote

No Mac eu simplesmente clico com o botão direito no pacote para abri-lo e visualizar seu conteúdo no Finder. Afinal, na verdade, é apenas um diretório disfarçado! (Eu sei que existem pacotes .pkg para partes do sistema que não são aplicações, mas usuários comuns geralmente não interagem com eles).

No Haiku eu clico com o botão direito no pacote, em seguida, clico em 'Contents' para ver o que há dentro. Mas aqui há apenas uma lista de arquivos, sem possibilidade de abri-los com um duplo clique.
Seria muito melhor se houvesse uma forma de (temporariamente) montar o pacote .hpkg para visualização através do gerenciador de arquivos, e o usuário não precisasse se preocupar com os detalhes de implementação. (Aliás, é possível abrir .hpkg o pacote no Expander, que pode descompactá-lo como qualquer outro arquivo).

Na interface do HaikuDepot é possível visualizar a lista de arquivos do pacote, mas não há como ver o conteúdo, por exemplo, clicando duas vezes em README.md

Nesta categoria, o Mac vence, mas adicionar a funcionalidade necessária ao HaikuDepot não deve ser uma grande dificuldade.

Instalação de pacotes através da GUI

No Mac, a maioria das imagens de disco .dmg contém pacotes .app. Abrimos a imagem de disco com um clique duplo, em seguida, copiamos o pacote, por exemplo, arrastando-o para /Applications o Finder. Para mim isso é evidente, mas ouvi que alguns iniciantes podem ter dificuldades com isso. Por padrão, a Apple "oferece" o diretório do sistema geral /Applications (no NeXT era rede, assim como individual), mas é fácil colocar seus aplicativos em um servidor de arquivos ou em um subdiretório $HOME/Applications, se você preferir.

No Haiku, clique duas vezes no pacote, depois clique em "Install", é mais fácil do que isso. Fico curioso sobre o que acontece se o pacote tiver dependências disponíveis no HaikuPorts, mas ainda não instaladas. No Linux, de fato, não sabem o que fazer nessa situação, mas a solução é óbvia — perguntar ao usuário se deseja baixar e instalar as dependências. Exatamente o que o Haiku faz.

Baixei o pacote 'sanity' manualmente e cliquei nele, o gerenciador de pacotes sabe de onde pegar suas dependências (desde que os repositórios já estejam configurados no sistema). Nem todas as distribuições Linux fazem isso.

Outra maneira é usar o gerenciador de arquivos, basta arrastar .hpkg o pacote ou para /Haiku/system/packages (para instalação do sistema geral, por padrão), ou para /Haiku/home/config/packages (para instalação individual; não disponível com clique duplo — ainda me incomoda a palavra "config" aqui, que para mim, neste caso, é sinônimo de "settings"). E a verdade é que o conceito de múltiplos usuários ainda não está disponível para o Haiku (provavelmente é por isso que tudo é tão simples — não sei, talvez os recursos multiusuário complicariam demais as coisas para um ambiente de trabalho em um computador pessoal).

Nesta categoria, o Haiku ganha, pois consegue trabalhar não apenas com aplicativos, mas também com programas do sistema.

Remover um pacote pela GUI

No Mac, é só arrastar o ícone do aplicativo para a lixeira, e isso é tudo. Fácil!

No Haiku, primeiro, é necessário encontrar onde o pacote está no sistema, porque raramente você o instala onde deveria (tudo é feito pelo sistema). Normalmente, a busca deve ser em /Haiku/system/packages (na instalação do sistema geral por padrão), ou em /Haiku/home/config/packages (já mencionei que "config" é um nome incorreto?). Então, o aplicativo é simplesmente arrastado para a lixeira, e é isso.
Fácil! No entanto, eu não diria isso. Aqui está o que realmente acontece:

Veja o que acontece se você arrastar o aplicativo para a lixeira de /Haiku/system/packages

Simplesmente tentei mover meu aplicativo de ontem "Olá, Mundo" no QtQuickApp para a lixeira. Eu não tentei mover o diretório do sistema, e como todos os pacotes são instalados no diretório do sistema — não é possível remover o pacote .hpkg sem alterar "seu conteúdo". Um usuário comum ficaria assustado, clicaria no botão "Cancelar", definido por padrão.

Explica mr. waddlesplash:

Esta mensagem já tem mais de 10 anos. Provavelmente precisamos configurá-la para que o aviso apareça apenas ao mover o próprio pacote. Usuários normais de qualquer forma não precisam fazer isso.

Certo, talvez devêssemos fazer isso usando o HaikuDepot? Dou um clique duplo no pacote em /Haiku/system/packages, esperando que apareça o botão "Desinstalar". Não, só tem "Instalar". "Desinstalar", onde você está?

Por diversão, tentei ver o que acontece se eu clicar em "Instalar" para um pacote já instalado. Acontece isto:

Isso acontece se você tentar instalar um pacote que já está instalado.

Em seguida aparece:

Se eu clicar em "Aplicar alterações" na janela anterior, ficará assim

Presumo que se trate de um erro de software, já existe um link para o ticket. [o autor não forneceu o link, — nota do tradutor]

Solução rápida: Adicionar o botão "Desinstalar", se o pacote já estiver em /Haiku/system/packages, ou em /Haiku/home/config/packages.

Ao visualizar a lista de pacotes instalados no HaikuDepot, vejo meu pacote na lista e posso removê-lo.

Nesta categoria, o Mac vence. Mas posso imaginar que, com a configuração adequada, a experiência do usuário no Haiku seria melhor do que no Mac. (Um dos desenvolvedores avaliou assim: "Menos de uma hora para adicionar essa funcionalidade ao HaikuDepot, se você souber um pouco de C++", há voluntários?)

Remover algo do pacote

Vamos tentar remover o próprio aplicativo, e não o pacote .hpkg, do qual ele surgiu (duvido que para os "mortais comuns" haja qualquer diferença).

No Mac, o usuário geralmente trabalha com o arquivo .dmg, de onde o pacote do aplicativo vem .app. Normalmente, as imagens .dmg são acumuladas no diretório de downloads, enquanto os pacotes são copiados pelo usuário em /Applications. Há uma opinião de que muitos usuários não sabem o que estão fazendo, e essa hipótese é confirmada por um ex-funcionário da Apple. (Uma das coisas que eu não gosto no Mac. Por exemplo, com o AppImage não há diferença entre o aplicativo e o pacote em que ele veio. Arrastou o ícone para a lixeira = isso é tudo. Fácil!)

No Haiku, também há uma divisão entre apps/ e packages/, então eu duvido que isso tenha tornado mais claro para os usuários. E o que acontece se você arrastar um aplicativo de apps/ para a lixeira:

Isso é o que acontece ao tentar excluir um aplicativo que foi retirado de um arquivo .hpkg

Tecnicalmente está correto (já que o aplicativo é colocado no sistema de arquivos somente leitura, em primeiro lugar), mas isso não é muito útil para o usuário.

Solução rápida: ao invés disso, sugerir através da GUI para excluir .hpkg

Por curiosidade, eu tentei duplicar o aplicativo pressionando Alt+D. Recebi a mensagem "Não é possível mover ou copiar objetos em um volume somente leitura". E tudo isso porque /system (além de /system/packages e /system/settings) é um ponto de montagem do packagefs (lembra como aparece na saída df?). К сожалению, вывод команды mount não esclarece a situação (como foi dito em um dos artigos anteriores), mountvolume não mostra o que é procurado (aparentemente pacotes montados via loop .hpkg não são considerados "volumes"), e eu também esqueci os comandos alternativos.

Nesta categoria, ninguém venceu, exceto o AppImage (mas, se formos completamente honestos, essa é uma opinião tendenciosa). Entretanto, pode-se imaginar que, após ajustes, a experiência do usuário no Haiku será melhor do que no Mac.

Nota: precisa-se descobrir o que é um "volume" em relação a "seção". Provavelmente é semelhante à relação entre "pasta" e "diretório": a maioria dos diretórios aparece no gerenciador de arquivos como pastas, mas nem todos eles (por exemplo, pacotes, tratados como arquivos). Essas conjecturas me tornam um nerd oficialmente?

Copiando o conteúdo do pacote para outro sistema

No Mac, simplesmente arrasto o pacote .app, e como as dependências dentro do pacote — elas se movem juntas.

No Haiku, arrasto o aplicativo, mas as dependências não são tratadas de forma alguma.

Solução rápida: Que em vez disso seja sugerido arrastar o pacote "`.hpkg" inteiro, junto com as dependências, se houver.

Nesta categoria, o Mac definitivamente vence. Pelo menos para mim, que sou fã de sua paradigma. No Haiku, seria necessário copiar .hpkg em vez de um aplicativo, mas o sistema não me oferece isso...

Baixando o pacote com todas as suas dependências

Nem toda máquina está conectada à rede o tempo todo. Por outro lado, algumas máquinas (sim, estou olhando para vocês, modernos Windows, Mac e Linux) esquecem disso. Para mim, é importante que eu possa, por exemplo, ir a uma lan house, baixar software em um dispositivo removível, inserir esse dispositivo no computador doméstico e ter certeza de que tudo funcionará [o cara arriscado, fazendo isso no Windows... — nota do tradutor].

Como resultado, um pouco mais do que sempre, eu geralmente recebo dependências insatisfeitas no Windows e Linux.

No Mac geralmente é apenas um arquivo, tudo que você precisa é baixar .dmg. Na maioria das vezes, ele não tem dependências além daquelas fornecidas pelo próprio MacOS por padrão. Uma exceção pode ser mencionada para aplicativos complexos que requerem um ambiente de execução apropriado, como o java.

No Haiku baixar o pacote .hpkg para, digamos, o mesmo aplicativo em java, pode não ser suficiente, uma vez que o java pode estar presente ou não na máquina de destino. Existe uma maneira de baixar todas as dependências para este pacote .hpkg, exceto aquelas que são instaladas no Haiku por padrão e, portanto, devem estar em cada sistema Haiku?

Nesta categoria, o Mac vence com uma pequena margem.

Comenta mr. waddlesplash:

Para escrever um programa que colete todas as dependências de um aplicativo em forma de um conjunto de pacotes .hpkg para alguém que está familiarizado com a estrutura interna do Haiku, leva cerca de 15 minutos. Adicionar suporte para isso não é tão complicado, se houver uma necessidade real. Mas para mim, isso é uma situação rara.

Vamos prender a respiração até o próximo artigo desta série.

Movendo pacotes para um local separado

Como já escrevi anteriormente, quero colocar meus pacotes .hpkg (bem, ou parte deles) em um local especial, separado da localização normal na unidade de inicialização (partição raiz). Na maioria das vezes (não é algo tão teórico), a razão para isso é que o espaço livre nos meus (internos) discos acaba constantemente, não importa o quão grandes eles sejam. E eu normalmente conecto discos externos ou recursos de rede onde meus aplicativos estão armazenados.

No Mac eu simplesmente movimento os pacotes .app para um disco removível ou diretório de rede no Finder, e isso é tudo. Eu ainda posso abrir o aplicativo com um clique duplo como costumava fazer com o volume de inicialização. Simples!

No Haiku, como me disseram, isso pode ser alcançado movendo meus .hpkg pacotes para um disco removível ou diretório de rede, mas depois preciso usar alguns comandos não documentados no terminal para montá-los no sistema. Não sei como fazer isso utilizando apenas a interface gráfica.

Nesta categoria, o Mac vence.

De acordo com o sr. waddlesplash:

Aqui está a otimização considerando o uso comum. Se houver mais demanda do que um único usuário, nós implementaremos isso. Em qualquer caso, há a possibilidade de implementação de terceiros.

Falaremos sobre isso no próximo artigo.

Falando sobre diretórios de rede: seria ótimo (presumindo uma festa LAN) ter aplicativos simples, detectáveis e de rede (por exemplo, via Zeroconf) que possam ser copiados para o computador local ou executados diretamente da rede local. Claro, os desenvolvedores têm a opção de recusa através de app_flags.

Relatório final sobre a integração do sistema hpkg com GUI

Acho que, em primeiro lugar, devido à relativa novidade, a integração .hpkg com a GUI ainda deixa a desejar. De qualquer forma, há várias coisas que podem ser melhoradas em termos de UX…

Outra coisa: Kernel Debug Land

Seria fantástico ter a capacidade de digitar comandos durante um kernel panic, por exemplo, syslog | grep usb. Bem, no Haiku isso é possível graças ao Kernel Debug Land. Como ver essa magia em ação, se tudo funciona como deveria sem entrar em kernel panic? Fácil, pressionando Alt+PrintScn+D (mnemônico Debug). Isso me lembra imediatamente da Programmer’s Key, que permitia aos desenvolvedores originais do Macintosh acessar o depurador (se estivesse instalado, é claro).

Conclusão

Começo a entender que a sofisticação do sistema Haiku vem do trabalho de uma pequena equipe focada no ambiente de trabalho, enquanto mantém todos os níveis do sistema acessíveis.
Um contraste acentuado com o mundo Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, onde tudo está fragmentado em pequenas partes a tal ponto que a abstração está em cima da abstração e é perpetuada por gambiarras.
Também chegou a compreensão de como o sistema .hpkg combina as melhores práticas dos gerenciadores de pacotes tradicionais, Snappy, Flatpak, AppImage, até btrfs, e as mistura com o princípio de "simplesmente funciona" do Mac.

Como se algo tivesse 'mudado' na minha mente, e eu percebi como o sistema .hpkg consegue reverter, apenas olhando para ele. Mas não sou eu, é a beleza e a simplicidade do sistema. Muito aqui está impregnado com o espírito do Mac original.

Sim, navegar por páginas no navegador pode ser saltitante e funcionar como uma lesma, pode faltar aplicativos (não há Gtk, Electron — os desenvolvedores concluíram que eles não combinam bem com a sofisticação), a aceleração de vídeo e 3D pode estar completamente ausente, mas ainda assim gosto deste sistema. Afinal, essas coisas podem ser corrigidas e elas surgirão, mais cedo ou mais tarde. É apenas uma questão de tempo e, talvez, um pouquinho de olhos vermelhos.

Não posso oferecer ajuda, mas acho que a partir deste momento começará o ano do Haiku na área de trabalho.

Problemas aleatórios

Já podem haver solicitações, ou devo abri-las?

BeScreenCapture deve ter a capacidade de exportar para GIF, como no Peek. Isso pode ser feito com o ffmpeg, que já está disponível para o Haiku. Solicitação.
O programa de captura de tela não pode capturar uma janela modal, em vez disso, captura toda a tela
Não se pode recortar capturas de tela usando a ferramenta de recorte no WonderBrush, e, em seguida, salvar o resultado em um arquivo
Não gosto muito do cursor em forma de mão no Haiku, mas acho que isso está relacionado a sentimentos nostálgicos. Isso é especialmente irritante ao usar a ferramenta de recorte no Krita, pois resulta em um recorte impreciso (veja as capturas de tela com diálogos modais neste artigo). Um cursor em forma de cruz seria maravilhoso. Solicitação.

Experimente você mesmo! O projeto Haiku oferece imagens para download via DVD ou USB, geradas diariamente. Para instalação, basta baixar a imagem e gravá-la em um pen drive usando Etcher

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 sexto artigo de uma série sobre o Haiku.

Lista de artigos: Primeiro Segundo Terceiro Quarto Quinto

Fonte: habr.com