🥇Meu sexto dia com Haiku: por trás dos recursos, ícones e pacotes

TL, DR: Haiku é um sistema operacional projetado especificamente para PCs, por isso possui vários truques que tornam seu ambiente de desktop muito melhor que outros. Mas como isso funciona?

Recentemente Eu descobri o Haiku, um sistema inesperadamente bom. Ainda estou surpreso com a facilidade com que ele funciona, especialmente em comparação com ambientes de desktop Linux. Hoje vou dar uma olhada sob o capô. Sempre que necessário para uma compreensão aprofundada, farei comparações com os ambientes de desktop Macintosh, Mac OS X e Linux originais (padrão XDG de freedesktop.org).

Recursos em arquivos ELF

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

Recursos? Citar de Bruce Chifre, o autor original do Macintosh Finder e o "pai" do Macintosh Resource Manager:

Estou preocupado com a natureza rígida da codificação tradicional. Para mim, a própria ideia de um aplicativo congelado no código, sem a capacidade de alterar nada dinamicamente, é a mais selvagem. Deve ser possível alterar o máximo possível em tempo de execução. É claro que o código do aplicativo em si não pode ser alterado, mas certamente algo pode ser alterado sem recompilar o código?

No Macintosh original, eles criaram uma “seção de dados” e uma “seção de recursos” para esses arquivos, o que tornou incrivelmente fácil salvar itens como ícones, traduções e assim por diante. em arquivos executáveis.

No Mac isso é usado Res, um programa gráfico para - repentinamente - editar recursos.

ResEdit no Macintosh original

Como resultado, tornou-se possível editar ícones, itens de menu, traduções, etc. bastante fácil, mas eles ainda “viajam” com os aplicativos.
De qualquer forma, essa abordagem tinha uma grande desvantagem: só funcionava em sistemas de arquivos da Apple, o que foi 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, então adotou o conceito de pacotes (da NeXT), diretórios que são tratados como "objetos opacos" pelo gerenciador de arquivos, como arquivos em vez de diretórios. Qualquer pacote com um aplicativo no formato .app tem, entre outras coisas, um arquivo Info.plist (em algum tipo de equivalente da Apple a JSON ou YAML) contendo metadados de aplicativos.

Chaves para o arquivo Info.plist do pacote de aplicativos Mac OS X.

Recursos, como ícones, arquivos de UI e outros, são armazenados no pacote como arquivos. Na verdade, o conceito voltou às suas raízes na NeXT.

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

Voltemos ao BeOS, os conceitos nos quais o Haiku se baseia. Seus desenvolvedores, ao mudar do PEF (PowerPC) para o ELF (x86) (o mesmo usado no Linux), decidiram adicionar uma seção de recursos ao final dos arquivos ELF. Ele não usou sua própria seção ELF, foi simplesmente anexado ao final do arquivo ELF. Como resultado do programa strip e outros do binutils, que não sabem disso, simplesmente o cortam. Portanto, ao adicionar recursos a um arquivo ELF no BeOS, é melhor não manipulá-lo com ferramentas Linux.

O que está acontecendo com o Haiku agora? Basicamente, mais ou menos igual.

Em teoria, seria possível colocar recursos na secção desejada do ELF. De acordo com os desenvolvedores do canal #haiku em irc.freenode.net:

Com ELF a seção faria mais sentido... a única razão pela qual não fazemos dessa forma é porque foi feita dessa forma no BeOS."
E não faz sentido mudar isso agora.

Gestão de recursos

Os recursos são escritos em um formato estruturado de “recursos”: essencialmente uma lista de recursos com tamanhos e seu conteúdo. Lembrei-me formato ar.
Como verificar recursos no Haiku? Existe algo como ResEdit?
Conforme documentação:

Para visualizar os recursos fornecidos no pacote do aplicativo, você pode arrastar o arquivo executável para um programa como Recursor. Você também pode ir ao terminal e executar o comando listres имя_файла.

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

Como gerenciar recursos em arquivos ELF? Usando rsrc и rdef. rdef os arquivos são coletados em rsrc. Arquivo rdef é armazenado em formato de texto simples, por isso é muito mais fácil de trabalhar. Formato de arquivo rsrc anexado ao final do arquivo ELF. Vamos tentar jogar:

~> rc -h
Haiku Resource Compiler 1.1To compile an rdef script into a resource file:
    rc [options] [-o <file>] <file>...To convert a resource file back into an rdef script:
    rc [options] [-o <file>] -d <file>...Options:
    -d --decompile       create an rdef script from a resource file
       --auto-names      construct resource names from ID symbols
    -h --help            show this message
    -I --include <dir>   add <dir> to the list of include paths
    -m --merge           do not erase existing contents of output file
    -o --output          specify output file name, default is out.xxx
    -q --quiet           do not display any error messages
    -V --version         show software version and license

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

/> 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.
(...)

Ok, vamos tentar?

/> 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 você pode ler aqui.

Tipos de recursos padrão

Embora você possa colocar qualquer coisa em recursos, existem alguns tipos padrão definidos:

app_signature: Tipo de aplicativo MIME, para mapeamento de abertura de arquivo, inicialização, IPC, etc.
app_name_catalog_entry: Como o nome do aplicativo geralmente está em inglês, você pode especificar os locais onde os nomes traduzidos estão localizados, para que usuários de diferentes idiomas vejam o nome do aplicativo traduzido, se desejarem.
app_version: exatamente o que você pensou
app_flags: indica registrar como processar o pedido. Acho que há mais nisso do que aparenta. Por exemplo, há B_SINGLE_LAUNCH, que força o sistema a iniciar um novo processo de aplicação sempre que o usuário o solicitar (o mesmo princípio é usado para a maioria das aplicações no Linux). Comer B_MULTIPLE_LAUNCH, fazendo com que o processo seja executado por cada arquivo. Finalmente há B_EXCLUSIVE_LAUNCH, que força o sistema a iniciar apenas um processo por vez, independentemente da frequência com que os usuários o iniciam (por exemplo, é assim que o Firefox funciona 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 executá-los novamente: por exemplo, eles recebem o caminho do arquivo que o usuário deseja abrir com sua ajuda.
vector_icon: Ícone vetorial do aplicativo (o BeOS não tinha ícones vetoriais, a maioria dos aplicativos tinha dois ícones raster em seus arquivos executáveis).

Claro, você pode adicionar recursos com quaisquer IDs e tipos desejados e, em seguida, lê-los no próprio aplicativo ou em outros aplicativos usando a classe BResources. Mas primeiro, vamos dar uma olhada no fascinante tema dos ícones.

Ícones vetoriais no estilo Haiku

Claro, não apenas o Haiku escolheu o melhor formato de ícone; nesta parte, a situação com ambientes de desktop 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 você já pode sentir que peça é.

Claro, existe um escalonável que contém, como você pode entender, ícones vetoriais. Por que então há mais alguma coisa? Porque o resultado do desenho de gráficos vetoriais em tamanhos pequenos pode ser inferior ao ideal. Gostaria de ter opções diferentes otimizadas para tamanhos diferentes. Em ambientes de desktop Linux, isso é conseguido espalhando ícones de tamanhos diferentes por todo o 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

Observação: não existe o conceito de versões diferentes do Firefox. Assim, não é possível lidar normalmente com a situação de ter múltiplas versões de um aplicativo no sistema.

Diferentes ícones do Firefox em diferentes versões. Atualmente é impossível lidar com isso no Linux sem várias muletas.

O Mac OS X lida com isso de maneira um pouco mais sutil:

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

Pode-se ver que existe um arquivo firefox.icns Na embalagem Firefox.app, contendo todos os tamanhos para que diferentes versões do mesmo aplicativo tenham ícones diferentes.
Muito melhor! Os ícones acompanham o aplicativo, todos os recursos estão em um arquivo.

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

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

E eles ainda estão otimizados:

Tamanhos de ícones em HVIF em comparação com outros formatos.

A diferença é uma ordem de grandeza!

Mas a magia não termina aqui. O mesmo HVIF pode mostrar diferentes níveis de detalhe dependendo do tamanho exibido, mesmo sendo um formato vetorial.

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

Agora sobre as desvantagens: você não pode pegar o SVG, jogá-lo no ImageMagick e encerrar o dia; você tem que passar por vários ciclos 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 SVG são importados com alguma probabilidade, os 10% restantes precisarão ser configurados e alterados manualmente. Leia mais sobre como o HVIF faz sua mágica uma lata no blog Leah Ganson

Adicionando um ícone ao aplicativo

Agora posso adicionar um ícone ao pacote criado ultima vez, tendo em conta todas as informações recebidas.
Bem, como não estou particularmente ansioso para desenhar meu próprio ícone para meu QtQuickApp “Hello, World” agora, eu o retiro 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 é copiado ele não aparece?

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

O que eu perdi?

Comentário do desenvolvedor:

Precisamos criar um arquivo rdef com todos os recursos e execute o comando rc имя.rdef, isso criará o arquivo .rsrc. Então você precisa executar o comando resattr -o имя_бинарника имя.rsrc. No mínimo, eu uso comandos como esses para adicionar ícones aos meus scripts.

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

Cache inteligente usando o sistema de arquivos

A abertura e leitura de atributos ELF são lentas. Como escrevi acima, o ícone é escrito como um recurso no próprio arquivo. Este método é mais confiável e permite 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 BFS. Os ícones mostrados pelo sistema (no Tracker e Deskbar) são lidos a partir deste atributo estendido, pois esta solução funciona rapidamente. Em alguns locais (onde a velocidade não é importante, por exemplo, uma típica janela “Sobre”), o sistema recebe o ícone diretamente do recurso no arquivo. Mas este não é o fim. Lembre-se, no Mac os usuários podem substituir ícones de aplicativos, diretórios, documentos pelos seus próprios, já que no Mac é possível fazer essas coisas “importantes”, por exemplo substituindo um novo ícone do Slack pelo anterior. No Haiku, você deve pensar no recurso (no arquivo) como o ícone original que vem com o aplicativo, e no atributo (no sistema de arquivos BFS) como algo que permite ao usuário fazer alterações à vontade (embora, dica, a GUI para inserir um ícone personalizado na parte superior do ícone é opcional (ainda não implementada por padrão).

Verificando 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.
(...)

É essencialmente a "cola" que realiza a conversão entre recursos (confiáveis) e atributos (rápidos) do sistema de arquivos. E como o sistema espera receber recursos e faz a cópia automaticamente, não vou mais me preocupar com isso.

A magia dos pacotes hpkg

Atualmente (na maioria das vezes) pacotes são usados para obter programas no Haiku .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ê encontrou, ele tem superpoderes reais.

Com os formatos de pacotes tradicionais, fiquei muito tempo chateado por causa deste fato: você baixa uma coisa (pacote), e outra é instalada no sistema (arquivos dentro do pacote). É muito difícil gerenciar arquivos (por exemplo, excluí-los) ao instalar um pacote da maneira tradicional. E tudo porque o conteúdo da embalagem espalhados por todo o sistema de arquivos, incluindo locais onde o usuário médio pode não ter acesso de gravação. Isto dá origem a toda uma classe de programas - gerenciadores de pacotes. Mas transferir software já instalado, por exemplo, para outra máquina, disco removível ou servidor de arquivos torna-se ainda mais difícil, se não completamente impossível. Em um sistema típico baseado em Linux, pode haver facilmente de centenas de milhares a milhões de arquivos individuais. Escusado será dizer que isso é frágil e lento, por exemplo, ao instalar inicialmente um sistema, ao instalar, atualizar e desinstalar pacotes regulares e ao copiar o volume de inicialização (partição raiz) para outra mídia.

Estou trabalhando no projeto AppImage, uma muleta parcial para aplicativos de usuário final. Este é um formato de distribuição de software que coleta um aplicativo e todas as suas dependências em uma única imagem do sistema de arquivos que é montada quando o aplicativo é iniciado. Simplifica significativamente as coisas, 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 só funciona para software, conforme refletido no nome do projeto, e também tem seu próprio conjunto de problemas, já que as pessoas envolvidas no fornecimento de software para Linux sempre apontam a seta para mim.

Voltemos ao Haiku. Foi possível encontrar o equilíbrio ideal entre os sistemas de pacotes tradicionais e a entrega de software baseada em imagens? Seus pacotes .hpkg na verdade, imagens compactadas do sistema de arquivos. Quando o sistema inicializa, o kernel monta todos os pacotes instalados e ativos com aproximadamente as seguintes mensagens do kernel:

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

Legal, sim? Aguenta aí, vai ser ainda mais legal!

Existe um pacote muito especial:

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

Ele contém um sistema operacional muito minimalista, incluindo o kernel. Acredite ou não, mesmo o próprio kernel não é removido do volume de inicialização (partição raiz), mas é cuidadosamente carregado em seu lugar a partir do pacote .hpkg. Uau! Já mencionei que acho que parte da sofisticação e consistência geral do Haiku vem do fato de que todo o sistema, desde o kernel e o espaço central do usuário até o gerenciamento de pacotes e a infraestrutura de tempo de execução, é desenvolvido colaborativamente por uma equipe. Imagine quantos grupos e equipes diferentes seriam necessários para executar algo assim no Linux [Imagino o projeto PuppyLinux - aprox. tradutor]. Então imagine quanto tempo levará para que essa abordagem seja adotada nas distribuições. Dizem: pegue um problema simples, divida-o entre diferentes executores, e ele ficará tão complicado que não será mais possível resolvê-lo. Haiku, neste caso, abriu meus olhos. Acho que é exatamente isso que está acontecendo no Linux agora (Linux, neste caso, é um termo coletivo para a pilha Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu).

Reversão do sistema usando hpkg

Com que frequência ocorre a seguinte situação: a atualização foi bem-sucedida e depois acontece que algo não está funcionando como deveria? Se você usar gerenciadores de pacotes convencionais, será difícil retornar o estado do sistema a um momento anterior à instalação de novos pacotes (por exemplo, no caso de algo dar errado). Alguns sistemas oferecem soluções alternativas na forma de instantâneos do sistema de arquivos, mas são bastante complicados e não são usados em todos os sistemas. Haiku resolve isso usando pacotes .hpkg. Sempre que os pacotes mudam no sistema, os pacotes antigos não são excluídos, mas são armazenados no sistema em subdiretórios como /Haiku/system/packages/administrative/state-<...>/ constantemente. Operações inacabadas armazenam seus dados em subdiretórios /Haiku/system/packages/administrative/transaction-<...>/.

Conteúdo /Haiku/system/packages/administrative. Os diretórios “state...” contêm arquivos de texto com os nomes dos pacotes ativos, e os diretórios “transaction...” contêm os próprios pacotes.

"Antigo estado ativo", ou seja, lista .hpkg pacotes ativos antes das alterações serem registradas após cada operação no gerenciador de arquivos em um arquivo de texto /Haiku/system/packages/administrative/state-<...>/activated-packages. De forma semelhante, um novo “estado ativo” é escrito em um arquivo de texto /Haiku/system/packages/administrative/activated-packages.

Каталог /Haiku/system/packages/administrative/state-<...>/ contém apenas um arquivo de texto com uma lista de pacotes ativos neste estado (no caso de instalação de pacotes sem remoção), e se os pacotes foram removidos ou atualizados - o diretório de estado contém versões antigas de pacotes.

Quando o sistema inicializa, com base na lista de pacotes, é tomada a decisão de ativar (montar) pacotes. É simples assim! Se algo der errado durante o download, você pode solicitar ao gerenciador de download que use uma lista diferente e mais antiga. Problema resolvido!

Baixador de haicais. Cada ponto de entrada exibe um "estado ativo" correspondente

Gosto da abordagem de ter arquivos de texto simples como lista de "estado ativo", com nomes fáceis de entender .hpkg. Isso contrasta fortemente com ser construído para máquinas e não para pessoas. um monte do OSTree ou Flatpak no sistema de arquivos (no mesmo nível do Microsoft GUID).

Lista de pacotes ativos para cada momento

Dados de configuração

Aparentemente, no catálogo /Haiku/system/packages/administrative/writable-files contém arquivos de configuração para pacotes, mas eles são graváveis. Afinal, como você se lembra, .hpkg montado somente leitura. Portanto, esses arquivos devem ser copiados dos pacotes antes de serem gravados. Tem o significado.

Integração GUI para sistema .hpkg

Vamos agora ver como essas bolsas brilhantes .hpkg lidar com a integração no ambiente de trabalho do usuário (UX). Afinal, o Haiku é destinado ao uso pessoal. Pessoalmente, estabeleço padrões elevados ao comparar a experiência do usuário com os pacotes .app no Macintosh com a mesma experiência em .hpkg. Não vou nem comparar a situação com os ambientes de trabalho no Linux, porque é absolutamente terrível comparado a quaisquer outros.

Os seguintes cenários vêm à mente:

Quero ver o conteúdo de um pacote .hpkg
Quero instalar um pacote
Quero remover o pacote
Quero remover algo que entrou no sistema como parte de um pacote
Quero copiar algo que entrou no sistema como parte de um pacote
Quero baixar todas as dependências de um pacote, que pode não fazer parte de todas as instalações do Haiku (por exemplo, tenho uma máquina fisicamente isolada e sem acesso à Internet).
Quero mover meus pacotes (ou parte deles) separadamente para outro local, separado do volume de inicialização (partição raiz) (porque, por exemplo, não tenho espaço suficiente nele).

Isso deve cobrir a maioria dos casos principais do meu trabalho diário. Bem, vamos começar.

Verificando o conteúdo do pacote

No Mac Simplesmente clico com o botão direito no pacote para abri-lo e visualizar o conteúdo no Finder. Afinal, na realidade trata-se apenas de um diretório disfarçado! (Eu sei que existem pacotes .pkg para uma parte do sistema que não são aplicativos, mas os usuários comuns geralmente não interagem com eles).

No Haiku Clico com o botão direito do mouse no pacote e, em seguida, clico em “Conteúdo” para ver o que há dentro. Mas aqui está apenas uma lista de arquivos sem a possibilidade de abri-los clicando duas vezes.
Seria muito melhor se houvesse uma maneira de montar (temporariamente) o pacote .hpkg para ser visualizado através de um gerenciador de arquivos, e o usuário não precisaria se preocupar com detalhes de implementação. (A propósito, você pode abrir .hpkg pacote em Expander, que pode descompactá-lo como qualquer outro arquivo).

A interface do HaikuDepot permite visualizar uma lista de arquivos de pacotes, mas não há como visualizar o conteúdo, por exemplo, clicando duas vezes em README.md

O Mac vence nesta categoria, mas adicionar a funcionalidade HaikuDepot desejada não deve ser muito difícil.

Instalando um pacote via GUI

No Mac, a maioria das imagens de disco .dmg contém pacotes .app. Clique duas vezes na imagem do disco e copie o pacote, por exemplo, arrastando-o para /Applications no Finder. Nem é preciso dizer isso para mim, mas ouvi dizer que alguns novatos podem não ser capazes de lidar com isso. Por padrão, a Apple “sugere” um diretório para todo o sistema /Applications (no NeXT era tanto em rede quanto individual), mas você pode facilmente colocar seus aplicativos em um servidor de arquivos ou em um subdiretório $HOME/Applications, se você gosta assim.

No Haiku, clique duas vezes no pacote e depois clique em “Instalar”, não poderia ser mais fácil. Estou me perguntando o que acontece se um pacote tiver dependências disponíveis no HaikuPorts, mas ainda não instaladas. No Linux eles realmente não sabem o que fazer nesta situação, mas a solução é óbvia: pergunte ao usuário se ele precisa baixar e instalar dependências. Exatamente o que o Haiku faz.

Baixei o pacote 'sanity' manualmente e cliquei nele, o gerenciador de pacotes sabe de onde obter suas dependências (assumindo que os repositórios já estejam cadastrados no sistema). Nem toda distribuição Linux pode fazer isso.

Outra forma é usar um gerenciador de arquivos, basta arrastar e soltar .hpkg pacote ou em /Haiku/system/packages (para uma instalação em todo o sistema, por padrão) ou em /Haiku/home/config/packages (para instalação individual; não disponível ao clicar duas vezes - ainda me incomoda a palavra "config" neste local, que para mim neste caso é sinônimo de "configurações"). E o conceito de múltiplos usuários ainda nem está disponível para o Haiku (provavelmente é por isso que é tão simples - não sei, talvez os recursos multiusuário compliquem desnecessariamente as coisas para um ambiente de desktop).

O Haiku vence nesta categoria porque pode funcionar não apenas com aplicativos, mas também com programas de sistema.

Removendo um pacote da GUI

No Mac, você precisa arrastar o ícone do aplicativo para a lixeira e pronto. Facilmente!

No Haiku, primeiro você precisa descobrir onde o pacote está localizado no sistema, pois raramente você o instala no lugar certo (o sistema faz tudo). Geralmente você precisa olhar /Haiku/system/packages (com uma instalação padrão em todo o sistema) ou em /Haiku/home/config/packages (Eu mencionei que “config” é um nome impróprio?). Em seguida, o aplicativo é simplesmente arrastado para a lixeira e pronto.
Facilmente! Contudo, eu não diria isso. Aqui está o que realmente está acontecendo:

Isto é o que acontece se você arrastar um aplicativo para a lixeira /Haiku/system/packages

Tentei mover meu aplicativo "Hello World" de ontem no QtQuickApp para a lixeira. Não tentei mover o diretório do sistema, e como todos os pacotes estão instalados no diretório do sistema, é impossível remover o pacote .hpkg sem alteração "seu conteúdo". Um usuário comum ficaria assustado e pressionaria o botão “Cancelar” atribuído por padrão.

Explica senhor. waddlesplash:

Esta postagem tem mais de 10 anos. Provavelmente precisaremos configurá-lo para que o aviso apareça apenas quando o pacote em si for movido. Os usuários regulares não precisam fazer isso de qualquer maneira.

Ok, talvez eu deva fazer isso usando o HaikuDepot? Clico duas vezes no pacote em /Haiku/system/packages, aguardando o botão “Desinstalar” aparecer. Não, existe (apenas) “Instalar”. "Desinstalar", onde você está?

Só por diversão, tentei ver o que aconteceria se eu clicasse em “Instalar” em um pacote já instalado. Acontece assim:

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

A seguir aparece:

Se você clicar em “Aplicar alterações” na janela anterior, ficará assim

Presumo que seja um erro de software; o link para o aplicativo já está lá. [o autor não forneceu um link - aprox. tradutor]

Solução rápida: adicione um botão "Desinstalar" se o pacote já estiver em /Haiku/system/packagesou em /Haiku/home/config/packages.

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

O Mac vence nesta categoria. Mas posso imaginar que, com a configuração adequada, a experiência do usuário no Haiku será melhor do que no Mac. (Um dos desenvolvedores avaliou desta forma: “Menos de uma hora para adicionar a funcionalidade especificada ao HaikuDepot, se você conhece um pouco de C++”, algum voluntário?)

Removendo algo de um pacote

Vamos tentar remover o aplicativo em si, não o pacote .hpkg, de onde veio (duvido que para “meros mortais” haja alguma diferença).

No Mac, o usuário geralmente trabalha com o arquivo .dmgde onde vem o pacote de aplicativos .app. Geralmente imagens .dmg são acumulados no diretório de downloads e os pacotes são copiados pelo usuário para /Applications. Acredita-se que muitos usuários não sabem o que estão fazendo, hipótese confirmada por um ex-funcionário da Apple. (Uma das coisas que não gosto no Mac. E, por exemplo, com o AppImage não há diferença entre o aplicativo e o pacote em que ele estava. Arraste o ícone para a lixeira = é isso. Fácil!)

No Haiku, há também uma divisão entre apps/ и packages/, então duvido que isso tenha deixado isso mais claro para os usuários. Mas o que acontece se você arrastar um aplicativo do apps/ Adicionar ao carrinho:

Isto é o que acontece quando você tenta remover um aplicativo retirado de um arquivo .hpkg

Tecnicamente está correto (afinal, o aplicativo está hospedado em um sistema de arquivos somente leitura), mas não é particularmente útil para o usuário.

Solução rápida: sugira usar a GUI para excluir .hpkg

Só por diversão, 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 porque /system (além do mais /system/packages и /system/settings) é o ponto de montagem do packagefs (lembre-se de como ele aparece na saída df?). Infelizmente, a saída do comando mount não esclarece a situação (como foi dito em um dos artigos anteriores), mountvolume não mostra o que você está procurando (aparentemente os pacotes montados via loop .hpkg não são considerados "volumes") e também esqueci os comandos alternativos.

Ninguém ganhou nesta categoria, exceto AppImage (mas esta, para ser totalmente honesto, é uma opinião tendenciosa). No entanto, pode-se imaginar que após os ajustes, a experiência do usuário no Haiku será melhor do que no Mac.

Nota: você precisa descobrir o que é um “volume” em relação a uma “seção”. Isto é provavelmente semelhante à relação entre "pasta" e "diretório": a maioria dos diretórios aparecem como pastas no gerenciador de arquivos, mas nem todos (pacotes tratados como arquivos, por exemplo). Esse tipo de exibição me torna um nerd oficial?

Copiando o conteúdo de um pacote para outro sistema

No Mac, eu estupidamente arrasto o pacote .app, e como as dependências estão dentro do pacote, elas se movem juntas.

No Haiku, arrasto o aplicativo, mas as dependências não são processadas.

Solução rápida: em vez disso, sugerimos arrastar todo o pacote `.hpkg, junto com quaisquer dependências, se houver.

O Mac vence claramente nesta categoria. Pelo menos para mim, um amante do seu paradigma. Eu deveria copiá-lo para o Haiku .hpkg em vez de um aplicativo, mas o sistema não me oferece isso...

Baixe um pacote com todas as suas dependências

Nem todas as máquinas estão conectadas à rede o tempo todo. Pelo contrário, algumas máquinas (sim, estou olhando para vocês, Windows, Mac e Linux modernos) esquecem disso. É importante para mim poder ir, por exemplo, a um cibercafé, baixar o software em um drive removível, inserir esse drive no meu computador doméstico e ter certeza de que tudo vai funcionar [cara arriscado, fazendo isso no Windows... - Aproximadamente. tradutor].

Como resultado, tendo a acabar com dependências não atendidas no Windows e no Linux com um pouco mais de frequência do que o normal.

No Mac geralmente é um arquivo, tudo que você precisa fazer é baixar .dmg. Na maioria das vezes, ele não possui outras dependências além daquelas fornecidas pelo próprio MacOS por padrão. Uma exceção são aplicativos complexos que requerem um ambiente de execução apropriado, por exemplo java.

No Haiku baixar pacote .hpkg para, digamos, o mesmo aplicativo em java, pode não ser suficiente, uma vez que java pode ou não estar presente na máquina de destino. Existe uma maneira de baixar todas as dependências de um determinado pacote .hpkg, além daqueles que são instalados por padrão no Haiku e, portanto, deveriam estar em todos os sistemas Haiku?

O Mac vence esta categoria por uma pequena margem.

Comentários Sr. waddlesplash:

Escrever um programa para coletar todas as dependências de um aplicativo como um conjunto de pacotes .hpkg para alguém familiarizado com o funcionamento interno do Haiku, cerca de 15 minutos são suficientes. Adicionar suporte para isso não é tão difícil se houver uma necessidade real. Mas para mim esta é uma situação rara.

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

Movendo pacotes para um local separado

Como escrevi anteriormente, quero colocar meus pacotes .hpkg (bem, ou parte deles) para um local especial, separado do local usual no volume de inicialização (partição raiz). No caso usual (não tão teórico), a razão para isso é que fico constantemente sem espaço livre em meus discos (integrados), não importa quão grandes eles sejam. E normalmente conecto unidades externas ou compartilhamentos de rede onde meus aplicativos estão localizados.

No Mac Estou apenas movendo pacotes .app para uma unidade removível ou diretório de rede no Finder e pronto. Ainda posso clicar duas vezes para abrir o aplicativo como faria normalmente no volume de inicialização. Apenas!

No Haiku, como me disseram, isso pode ser conseguido movendo meu .hpkg pacotes para uma unidade removível ou diretório de rede, mas você precisará usar alguns comandos não documentados no console para montá-los no sistema. Não sei como fazer isso usando apenas a GUI.

O Mac vence nesta categoria.

De acordo com o Sr. waddlesplash:

Esta é uma otimização baseada no uso normal. Caso haja demanda de mais de um usuário, iremos implementá-la. Em qualquer caso, existe a possibilidade de implementação por terceiros.

Falaremos sobre isso no próximo artigo.

Falando em diretórios de rede, seria ótimo (suponho que partes da LAN) tivessem aplicativos simples e detectáveis em toda a rede (como o Zeroconf) que pudessem ser copiados para o computador local ou executados diretamente da rede local. É claro que os desenvolvedores têm a opção de cancelar por meio de app_flags.

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

Penso que, principalmente devido à relativa novidade da integração .hpkg a GUI ainda deixa muito a desejar. De qualquer forma, existem algumas coisas que poderiam ser melhoradas em termos de UX...

Mais uma coisa: Kernel Debug Land

Seria ótimo poder inserir comandos durante o kernel panic, por exemplo syslog | grep usb. Bem, no Haiku isso é possível graças ao Kernel Debug Land. Como você pode ver essa mágica em ação se tudo funciona como deveria, sem entrar em pânico no kernel? Fácil pressionando Alt+PrintScn+D (mnemônico de depuração). Eu imediatamente me lembro Chave do programador, o que permitiu que os desenvolvedores originais do Macintosh entrassem no depurador (se algum estivesse instalado, é claro).

Conclusão

Estou começando a entender que a sofisticação do sistema Haiku vem do fato de o trabalho ser realizado por uma pequena equipe com foco claro no ambiente de trabalho, com todas as camadas do sistema acessíveis.
Um nítido contraste com o mundo do Linux/GNU/dpkg/apt/systemd/Xorg/dbus/Gtk/GNOME/XDG/Ubuntu, onde tudo é dividido em pequenos pedaços a tal ponto que a abstração fica na abstração e é conduzida com muletas.
Houve também uma compreensão de como o sistema .hpkg combina as melhores práticas dos gerenciadores de pacotes tradicionais, Snappy, Flatpak, AppImage e até mesmo btrfs, e as combina com a abordagem "simplesmente funciona" do Mac.

Foi como se algo “mudasse” na minha cabeça e eu entendesse como o sistema funcionava. .hpkg sabe rolar só de olhar para ela. Mas não sou eu, mas a beleza e a simplicidade do sistema. Muito disso é inspirado no espírito do Mac original.

Sim, a navegação no navegador pode ser irregular e funcionar como um caracol, podem faltar aplicativos (sem Gtk, Electron - os desenvolvedores concluíram que não combinam com sofisticação), vídeo e aceleração 3D podem estar completamente ausentes, mas ainda assim gosto deste sistema. Afinal, essas coisas podem ser corrigidas e aparecerão mais cedo ou mais tarde. É só uma questão de tempo e talvez um pouco de olho vermelho.

Não posso oferecer ajuda, mas acho que vai começar a partir de agora ano do Haiku no desktop.

Problemas aleatórios

Talvez já existam solicitações ou devo abri-las?

BeScreenCapture deve ser capaz de exportar para GIF como o Peek. Isso pode ser feito usando o ffmpeg, já disponível para Haiku. Aplicação.
O software de captura de tela não consegue capturar uma janela modal, em vez disso captura a tela inteira
Você não pode cortar capturas de tela usando a ferramenta de corte do WonderBrush e depois salvar o resultado em um arquivo
Eu particularmente não gosto do cursor manual no Haiku, mas acho que tem a ver com o sentimento caloroso e nostálgico. Isto é especialmente irritante quando se usa a ferramenta de corte no Krita, pois resulta num corte impreciso (veja as capturas de tela das caixas de diálogo modais neste artigo). Um cursor de mira seria maravilhoso. Aplicação.

Tente você mesmo! Afinal, o projeto Haiku disponibiliza imagens para inicialização a partir de DVD ou USB, geradas diariamente. Para instalar, basta baixar a imagem e gravá-la em uma unidade flash USB usando Etcher

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

Lista de artigos: primeiro O segundo Третья Quarto Quinto

Fonte: habr.com

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